Courseware Engineering

Learning Technology by Stephen Bostock

You are here: Keele University > Learning Technology home > Documents

Courseware Engineering
- an overview of the courseware development process

Stephen Bostock, February 1996
(revised March 1998, reformatted Nov 2003)

1. Introduction
2. Instructional design
3. Software engineering
4. Courseware engineering
5. Comparing models
6. Prototyping
7. Software tools
8. Multimedia

Further reading
References
Appendix 1: published models
Appendix 2: a practical courseware engineering model
Appendix 3: paper appendices in original

1. Introduction

This topic gives a view of the whole process of developing educational software, as a prelude to a more detailed and practical study of important parts of it. Inevitably, ideas and methods are mentioned which would justify greater description and discussion than is possible here. However, many of these are dealt with later in the course and references to further reading are given. You can return to these notes at the end of the course and explore the readings and references then.

There is no single recipe for courseware development which is either universally accepted or could be used in all circumstances. Instead there is a broad pattern into which the many published versions fit, and variations on that depending on circumstances. In trying to make sense of this variety I describe Courseware Engineering as a mix of two well established disciplines: Software Engineering as the process of developing business software and Instructional Design as the process of developing instruction (for delivery by computers or other means).

Starting with Instructional Design, I describe one example theory in some detail (Gagné) to illustrate the importance of an underlying theory of learning to an instructional design model. Then I briefly describe Software Engineering and graft it onto Instructional Design to give Courseware Engineering. Then I describe two well known published schemes for Courseware Engineering. There are many other published schemes and I propose five core activities which are found in all the schemes in different combinations.

Then two variations on this general scheme are discussed. I describe Rapid Prototyping in software engineering and discuss its relevance to courseware engineering. I consider the effect of the courseware being multimedia on the development process.

Lastly I describe different types of software tools that can be used in Courseware Engineering using the analogy with CASE tools in Software Engineering. This leads to a final consideration of the progress towards automating courseware development.

The terms 'education' and 'training' are overlapping concepts; for convenience, I will use education to include training situations.
back to top

2. Instructional design

The purpose of software for education or training is to promote learning. This is quite different from the function of business software such as accounts packages or decision support systems, and much more difficult. With educational or training software the requirement is to change the capabilities of human learners, so analysis and design must involve their learning processes, which are not completely understood, and are different in detail from one person to another.

Unfortunately the learning process is difficult to replicate and it seems impossible to portray it entirely in an automated model.
Barron (1995).

Developing instruction (for computers and other media) is called Instructional Design (in the U.S.). The word "Design" actually means "Development" as it includes prior analysis, the design, delivery considerations (like suitable media) and later evaluation. The word "Instruction" implies a didactic presentation, which may not be appropriate. I prefer the term "educational intervention" meaning any activity by a teacher to encourage learning in students. However, Instructional Design (ID) is more convenient than "intervention development".

ID is a systematic approach to designing instruction and instructional materials to achieve specified learning objectives. This contrasts with traditional methods such as sitting at the feet of a Master, or "sitting with Nellie". ID is independent of the use of computers to "deliver" the instruction. The ideas of Robert Gagné and his colleagues are well known and illustrate the importance to ID of an underlying theory of learning.

Gagné

Robert Gagné (1985) classified the types of learning outcomes. A good way to identify the types of learning is to ask how learning could be demonstrated:

intellectual skills - concepts
are demonstrated by labelling or classifying things,

intellectual skills - rules
are applied and principles are demonstrated,

intellectual skills - problem solving
allows generating solutions or procedures,

cognitive strategies
are used for learning,

verbal information
is stated,

motor skills
enable physical performance,

attitudes
are demonstrated by preferring options.

These outcomes are the results of the internal processes of learning in individual learners. They provide the learners with the improved capabilities which we desire. The external conditions of learning (such as instruction) which cause the learning are different for different types of learning outcome. For example, we need to do different things to learn attitudes than to learn intellectual skills or motor skills. Nonetheless, Gagné suggests that although different in detail, the same types of instructional activity are needed for all learning processes and learning outcomes. He suggests that there are nine general Instructional Events which are always relevant, even though in detail they will vary with the type of learning outcome being achieved, and with the specific content of the learning (Figure 1).

Figure 1 Gagné's nine Instructional Events

External instructional event Internal learning process

Gaining attention
To ensure reception of coming instruction we give the learner a stimulus.

Tell learners the learning objective
Tell the learner what they will be able to do because of the instruction.

Stimulating recall of prior learning
Ask for recall of existing relevant knowledge.

Presenting the stimulus
Display the content.

Providing learning guidance
Help understanding (semantic encoding) by providing organization and relevance.

Eliciting performance
Ask the learner to respond, demonstrating learning

Providing feedback
Give informative feedback on the learner's performance.

Assessing performance
Require more learner performance, and give feedback, to reinforce learning.

Enhancing retention and transfer to other contexts
Provide varied practice to generalise the capability.

This provides a good starting point for designing any instruction. Now we consider how we might arrive at such instructional events. The learning outcomes, internal conditions and external conditions can now be used. Briefly, Gagné describes the development process as follows.

Gagné's Instructional Design

Analyzing the requirements for learning simply works back from the intended learning goal.

1. Identify the types of learning outcomes we wish to achieve.

2. Most learning outcomes are not simple, each outcome must be broken down into a hierarchy of dependent learning outcomes and pre-requirements, to give a learning hierarchy of simple outcomes (example hierarchies can be seen in the appendix).

3. Identify the conditions or processes internal to the learner must occur to achieve those outcomes.

4. Specify what external conditions or instruction must occur to achieve these internal conditions.

Selecting Media

5. Record the learning context.

6. Record the characteristics of the learners.

7. Select media for instruction - how will we deliver the instructional events? Books, whiteboard, Computer Assisted Instruction and video are common examples.

Design Instruction - planning instructional events to support learning activities

8. Plan to motivate the learner by incentives, task mastery or achievements.

9. For each of the planned learning outcomes in the learning hierarchy, the Nine Instructional Events are designed relevant to the type of learning outcomes required, in the order of pre-requirements in the learning hierarchy, and with appropriate media and use of tutors.

10. Although the instruction is apparently ready to use, in practice they are tested in trials with learners (formative evaluation).

11. After the instruction has been used, a summative evaluation can judge its effectiveness.

In brief, Gagné's ID produces an analysis of the learning to be accomplished (1-6) and then translates this into a design for instructional events which will prompt and support the internal processes of the learner (7-9). These are then tested, used and evaluated (10-11). It says little about creating the instructional materials themselves (but see Petry, Mouton & Reigluth, 1987).

Summary

Gagné's ID is based on different types of learning outcome needing different learning activities and therefore different instructional conditions. Nine basic instructional events have variations for the type leaning outcome. Developing instruction involves analyzing requirements, selecting media and designing the instructional events.
back to top

3. Software engineering

Having looked at ID we will now switch to the other parent of courseware engineering - Software Engineering. This term distinguishes it on the one hand from unsystematic, amateur programming and, on the other, from computer science which is its theoretical basis. It is both disciplined and practical. Briefly, to produce business software, an analysis of the current manual system or the need for a new system can specify what needs to be done, a design can specify how this can be achieved and then programmers can implement the design to produce working software. With appropriate testing, the software can be installed and should do the job (although see the discussion on prototyping later).

Software Engineering is the systematic approach to the development, operation, maintenance and retirement of software.

(IEEE Glossary, in van Vliet 1993)

Figure 2
Figure 2. Waterfall software life cycle
The waterfall model (text)

Activity
product

Analysis of requirements

requirements specification

Design of software

design specification

Production

software

Testing

working software installed

Maintenence

Figure 2 shows the traditional linear sequence of activities. This linear sequence has been called the "waterfall" model. Different authors have variations on this scheme, and use different terms for the same ideas, but the basic sequence is widely agreed (e.g. Sommerville 1989 chapter 1, van Vliet 1993 chapter 3). Put briefly it is:

analysis,

design and

production

In detail they are :

A feasibility study assesses whether the solution is economically and technically practicable. This is an initial analysis, producing options with costs.

The requirements analysis produces a description of the problem. This involves describing the functions of the software needed, possible later extensions to it, the documentation needed, performance requirements such as response time. It also includes the environment in which the solution must work (hardware, software, organisation, users). The result of the analysis phase is a requirements specification document. It describes what is needed.

The design phase produces some sort of model of a system satisfying the requirements. The required functions are decomposed into modules and their interfaces. The user interface is designed. Data structures are specified. Design transforms the what of analysis into the how of a design specification but they do not trespass into implementation details.

Production (also called coding or implementation) involves creating software that works. The details of this will depend upon the construction tool being used, but there are some general principles. There may be a transition stage in which the logical design specification is transformed into a more detailed specification, such as using a high level language for processes. Production proceeds module by module. These are assembled into working software.

Testing has several aspects and does not happen only after production but throughout the development. Low level testing and debugging occurs as each module is written. Tuning and optimization may be necessary once they are assembled. Verification checks that the product of coding is a correct translation of the design specification. (Just as the design specification is verified against the requirements specification.) Validation checks that the software product is still fulfilling the user requirements.

Installation puts the working software in place. There are different ways this can be done.

Maintenance. The software may have undetected errors in it. In addition it will need adapting or improving over time. (For commercial software this can be more than half the total development effort.)

This represents the simple view of the development process. Each stage produces something (plans, diagrams, code...) which the next stage starts with and develops. In practice this logical, sequential approach is improved by feedback processes. This is because as we continue the development in the next stage we realise that the product of the previous stage was not quite right, so we revise it. That does not mean that it is not worthwhile adopting this sequence, just that we should not be surprised when we have to "back-up".

Summary

Software engineering is the systemmatic approach to software development. The waterfall model is a sequence, with feedback, of analysis, design and production activities, followed by testing and maintenance.
back to top

4. Courseware engineering

[Courseware engineering is] an emerging set of practices, tools and methodologies which result from attempts to take an engineering approach to the production of courseware. The engineering approach is in contrast to a craft or artisan approach ... [it] emphasises the use of principled methods rather than intuition .. [it] values replicability of processes and results rather than idiosyncratic creativity.
Goodyear (1995).

The development of educational software is related both to general software engineering and to the instructional design of educational interventions. It is posible to view as just part of software engineering but it is such a special category that it is better treated separately.

The clear and unequivocal emphasis on human learning and knowledge acquisition sets educational software apart (De Diana & van Schaik 1993)

Developing materials for teaching and learning which is to take place without a computer requires the same early stages of analysis and design, but production, testing and maintenance are different if the instructional medium is a computer or print materials, for example. Developing educational software has parallels with software engineering, especially some aspects of design (the user interface) and production (coding) because the medium is the same and the production tools (languages) may be similar. But the early stages are quite different. So courseware engineering is rather like grafting the early stages of educational development onto the later stages of software development, to give a development method for educational software development.

(Inconsistency in terminology is a problem in both education and computing, so I provide equivalents in parentheses below.)

Dean & Whitlock

In A Handbook of Computer Based Training (1992) Christopher Dean and Quentin Whitlock describe the basic development process in a commercial environment.

Problem investigation (i.e. analysis)
Course Planning (i.e. design)
Development (i.e. production)
Implementation and evaluation (i.e. installation and evaluation)

In more detail:

Problem Investigation (analysis)

1. Goal analysis, identifying the performance required,

2. Training Needs Analysis (or "front end analysis"), identifying a deficiency in performance and its cause.

3. Establish that computer training is needed.

Planning (design)

4. A description of the tasks to be learnt.

5. A hierarchical breakdown into sub-tasks,

6. A profile of the target population of learners.

7. Modularize the course, and then for each leson module.

8. Specify the detailed skills needed, the detailed content and its sequence.

Development (detailed design and production)

9. Define the content as a "rule set" (detailed analysis)
a detailed description of procedures and concepts to be learnt.

10. Decide learning steps (design)
divide the rule set into chunks to determine the lesson size before testing.

11. Decide the sequence/branching of screens, perhaps with flowcharts (design).

12. Design screens as storyboards (design).

13. Produce code in a programming language or authoring language (production).

Implementation and evaluation (testing)

14. Peer evaluation before use.

15. Course validation with a pilot group of trainees.

The above development scheme is geared towards Computer Aided Instruction, with just text and graphics, and assumes that the programming (a very small part of the life cycle) is done in an authoring or general-purpose language, by programmers.

Alessi & Trollip

In Computer-Based Instruction (1991) Stephen Alessi and Stanley Trollip have a more detailed development scheme. They too are concerned with instructional software (including tutorials, simulations and drills) but they are addressing teachers working in small teams. Their model has ten steps for the development of a single lesson. The tools mentioned will be described elsewhere.

Determine needs and goals (analysis)

Collect resources (design)

Learn the content (analysis)

Generate ideas (design)

Design instruction (design)

Flowchart the lesson (design)

Storyboard the displays (design)

Program the lesson (production)

Produce supporting materials (production)

Evaluate and revise (testing)

Alessi and Trollip make several points about their model:

evaluation and revision takes place at several points not just at the end;
it is based on principles of cognitive psychology: perception and attention, memory, comprehension, active learning, motivation, locus of control, transfer of learning and individual differences;
creativity is important for good design;
discussion proceeds to paper design to software implementation; computer use should be delayed;
a team approach is best, it has more creative ideas and can be more self-critical.

Summary

Courseware engineering is software engineering applied to courseware but the requirement for learning means most activities are different. The analysis and design phases are from ID while production and testing come from software engineering. Practical schemes involve various analysis and design techniques.
back to top

5. Comparing models

We have seen courseware development models Dean & Whitlock and Alessi & Trollip. There have been many other courseware development models published and six are listed in the appendix.

These development models differ not because of different explicit theories of instruction underpin them but more because different methods work best in different circumstances. One way to synthesize the different steps in the various development models is in terms of functional categories.

analysis (A)

design (D)

production (P)

evaluation-revision (E)

management processes (M)

The first three are the fundamental process. We want to produce software, but before we can do that we must design its functions. Before that we must understand the requirements it must satisfy - we must understand the learner, the learning objective and the subject.

Formative evaluation and revision is applied at one or more places in the process. It is always applied after production before installation and use, and sometimes after that. It can also be applied to the products of analysis and design. Generally, the more evaluation-revision cycles there are, the better the product. Each process can result in a revision of the product of the previous one (backing-up the waterfall) (van Vliet 1993, p.33). The precise evaluation methods will vary depending on the stage of development and the scale of the project. Early ideas can be subjected to an Inspection Conference. Designs and code can be the subject of a Walkthrough. Working software can be tested for usability, peer review, pilot tests and field tests. Prototyping (see below) involves evaluation-revision of working software.

The size of the project determines the importance of management processes; which become necessary once courseware is being developed other than by one person for their own students. In large, team projects full project management techniques are needed. Commercial considerations include financial and contractual issues, for example signing-off development milestones, and estimating costs and sticking to budgets. There are two aspects: timescales and resources. Starting with an initial requirement from a client, the timescale of each phase and process must be managed if the project is to deliver on time and on budget. Timescale management requires "deliverables" or "milestones" in the process. Resourcing includes resource collection and allocation, and managing creativity in brain-storming. The management of courseware projects is described by Foster (1993) and cost-effectiveness by Friedler and Shabo (1991).

Go back to the lists of courseware development methods and mark each step with A, D, P, E or M..

Why do we need a development method at all?

1.Developers need different levels of abstraction.
The first statement of requirements is the most abstract level of the problem being solved. At each stage in a sequential development more detailed, concrete solutions are produced, ending in a specific software solution. Even if not produced sequentially, the different levels are needed and must be consistent.

2.Management and control.
The managers of development need specific points in time and end-of-stage milestones (deliverables) so that they can monitor development progress.

The waterfall model should not exclude evaluations by the client. Each stage has products: text and graphic descriptions of analysed needs, designed functions and finally software features. These can be evaluated (figure 3) and in a commercial environment they will be signed-off for the purposes of a contract.

Figure 3. Evaluations & Sign-offs

Figure 3 (text)
Analysis -->       Client evaluation and sign off
Design -->   Client evaluation and sign off
Production --> Client evaluation and sign off
Testing -->   Client evaluation and sign off
Installation -->   Client evaluation and sign off

Summary

There are many published schemes for developing courseware. They are different combinations of analysis, design, production, evaluation-revision and management activities.
back to top

6. Prototyping

In software development, the waterfall method has in some circumstances been replaced by "rapid prototyping". Where the process being "computerised" is well understood and stable the basically sequential waterfall method works because the initial specification of requirements is accurate. But if requirements are not clear, or the situation is changing, this method is unwieldy.

If the risks of software development are examined, then the highest risks, ignoring resource problems, are in building the wrong system. Even if unlimited resources are available, people will still build systems that do not meet their needs. (Maude and Willis 1991, p. 46)

There is too long a gap between the user giving their requirements and the software being ready to use. Put another way, the requirements should be accurate, consistent, complete and realistic if they are to be the basis of a successful development. A tall order! Users and developers can check them on paper, but users will be more sure of their requirements if they can use something resembling the final software. Prototyping achieves this by quickly producing a version for the user, which gives a feel for what the final software will be like.(Sommerville1989, van Vliet 1993, Schach 1990).

A prototype is a software model of system behaviour which can be used to understand the proposed system, or certain aspects of it, and to clarify requirements. (Maude and Willis 1991, p. 50)

A prototype will differ from the final product by having less functionality and complexity. It may have poor speed performance and be fragile to wrong user inputs. Nonetheless it may be used to illustrate the principles and usability of the planned system.

Prototyping has been made easier (or feasible) by the availability of software construction tools ("fourth generation languages") which are much faster to use than traditional languages for which programs have to typed as text, compiled and then executed, hence "rapid" prototyping. Without such tools, software prototypes are almost as expensive as final products and so historically they have not been used. These new tools for software production are also available for developing educational software (authoring tools). So prototyping is possible when developing educational software.

One approach (in software engineering) uses a prototype only as a visualization model. It is an early, incomplete model to help the client visualise the product and refine the requirements specification (but nonetheless requires some analysis and design). Once this is agreed, the prototype is scrapped and the software is built from scratch in the normal way using a programming language. Some specific components of the prototype (for example, a user interface) may be kept and incorporated into the finished product, which will nonetheless be better built than the prototype. This approach is less necessary with educational software as execution speed is less likely to be a problem.

At the other extreme, another form of prototyping -exploratory programming - presents the user with software which is known to be incomplete, and on the basis of their views it is augmented and improved. Effectively the software goes through the A-D-P-R cycle quickly and repeatedly until a version is accepted. The user is likely to get what they want but the software is probably technically poor. Poor internal structure may mean poor robustness and difficult maintenance. It may execute slowly if an authoring system is used to create it.

Figure 4. Two uses of prototyping

The waterfall sequential development model includes some client feedback to one or more steps, or even to all steps. Prototyping is an extension of this, where partial products are developed repeatedly to clarify analysis and design.

Should prototyping be used when developing educational software? Yes.

Educational software is software and as such, functional prototyping and CASE tools can very probably promote the efficiency of development work (De Diana & van Schaik 1993)

Learning is an unpredictable business, different in different people and situations, so the analysis stage for educational software is difficult. We are not likely, therefore, to be able to get our analysis and design right first time and prototypes allow early evaluation of instructional strategies. In any case, prototying is particularly relevant for user interfaces and this is always important in instructional software.

But there is a special problem with prototyping educational software - we cannot truly evaluate its effectiveness for learning. With business software, a prototype might be just the screen layout or a working but simplified version of the software. This would be enough to let users see what the final software would be like, and refine their specification. But with educational software prototypes cannot be presented to learners. They will not work at all in the sense of producing the learning objectives. True, the learners' opinion of the software is useful but they are in no position to judge whether they will be able to learn from it. This evaluation must wait for pilot testing and field testing.

However, often we are producing courseware for a client teacher or company. This client "gatekeeper" may be able to judge the educational effectiveness of the prototype software and thus improve the requirements and the design. Prototypes will help clarify the client's requirements. Commercially it may be more important to satisfy the gatekeeper than the learner.

Prototyping is especially valuable where requirements cannot be specified clearly. For example, Sandford (1990) and Tripp and Bichelmeyer (1990) have proposed its use for the development of interactive multimedia. Friedler and Shabo (1991) suggest it when using authoring systems. Witt and Wager (1994) recommend something similar for the development of Electronic Performance Support Systems (just-in-time training).

The term "prototyping" can be misused to mean client evaluation of all deliverables other than working software, such as design documents, but this is part of waterfall development using milestones (Figure 3). While user involvement at all stages is useful, and current software engineering emphasises "user focussed" development methods, it is best to restrict the term prototype to software.

Authoring tools

Authoring tools have made prototyping cost-effective. Software can be produced using general purpose languages (BASIC, Visual BASIC), specialised authoring languages (Tencore or PC-CAI) or specialised authoring tools which require little or no text coding (like Optima or Authorware). This order represents increasing abstraction, productivity and size of reusable software components. The trade-off is that they can be used for a narrower range of software products. The move to Windows and other GUIs which require event-response applications greatly increases the programming effort and thus the value of authoring tools for these environments.

an example

An example is Sanderson CBT, a CBT company producing bespoke courseware and generic packages. Figure 5 shows their development model when they were using a traditional authoring language, Tencore. It also shows their new model after moving to a Windows environment with Toolbook as the production tool.

The programming stage has essentially disappeared. Specialist Tencore programmers are no longer required. The basic team for a project is a training designer and a graphic artist. There has been a shift towards prototyping (but not exploratory programming) made possible by using an authoring system. Instead of initial prototypes being paper or static screens, they are early Toolbook implementations with some interactivity. The designers use Toolbook to produce both prototypes and the working software. (The designers were trained in using Toolbook.) Programmers (in C) are only needed for special software fixes. Apart from the productivity advantage (one less programmer is needed!) the shortened life cycle is more flexible. A quality inspection including usability testing is now more explicit before final sign-offs.

Figure 5. Traditional and prototyping methods

Figure 5 Sanderson CBT (text)

Traditional life cycle using Tencore 3GL

(analysis)

client call
initial analysis
prototype on paper
detailed needs analysis
report to client - sign-off

(design)

outline storyboard
shell design
first content design
usability test
amendment cycle
sign-off
full content design
sign-off design module by module

(production)

programming module by module
sign-off module by module

Authoring life cycle using Toolbook

(analysis)

client call
initial analysis
prototype with Powerpoint
detailed needs analysis
report to client - sign-off

(design and production)

prototype developed with Toolbook
usability test
amendment cycle
sign-off

full content design in Toolbook
edit and test
Quality inspection
sign-off module by module

To speculate about the long term, software production tools may become so easy to use that it will not be necessary to design on paper first. At least with educational software, the problems with incremental development of prototypes to finished product will disappear. We will then be left with only analysis and design before installation, and even they need not proceed in sequence, but rather in parallel. A future courseware development model might be summarised as figure 6.

Figure 6. Complete prototyping

Figure 6 (text)
Analyse/design  <---> Evaluate  --->

Summary

Prototyping provides earlier evaluation and revision than the waterfall model by providing software for the client to evaluate early in development. This reduces the risk of a faulty requirements specification. Prototyping is worthwhile in coursware development. Authoring languages make it possible.
back to top

7 Multimedia

What difference to the development process does developing multimedia courseware make? CBT was once based on fixed width text. Then graphics, variable fonts, animation, sound and finally video became possible. Each such medium (presentation mode) now needs selecting, designing and producing before being integrated with the software.

Selection of media takes place at two levels. At the broad level of a course a choice between delivery media must be made: print, lecture, computer tutorial, simulation and so on. At a finer scale, within a CAL lesson, decisions are made on the use of graphics, voice-over, animation and so on, both to convey the content and as part of the user interface. Parallel to the design of other aspects of courseware (notably the learner activities and the user interface) each significant presentation mode must also be designed. For example, the text content, structure and appearance must be designed. The content and characteristics of audio and video must be designed and specified as scripts.

After design, each medium must be produced. In traditional CBT the only medium is text but it still needs designing according to typographic and educational principles and with guidelines for presentation on the screen (Hartley 1994, Clarke 1992) . Instructional designers and authors often gain these skills. Other media are more complex and require specialist skills; the production of photo-realistic images, animations, audio and video. Unless a large team is producing the courseware, in a commercial environment these will be bought in from studios to meet the design specification.

After each medium is produced independently, they must all be integrated into the control software and its user interface.

Does the use of additional media affect the overall life cycle? Figures 1 and 2 from Marshall et al. (1994) compare the waterfall model of general software development with that for multimedia courseware. The design phase is divided into two - overall instructional design and detailed media design. The production phase is divided into the production of the media and courseware integration which brings all the media together with the controlling software ready for testing. Production becomes more complex as more media have to be integrated.

After analysis and design, Sandford (1990, Table 1) also separates the production phase into two. The production of each medium and of the controlling software could proceed in sequence or in parallel; once designed their production is independent. The second part is integrating the media into one package. This means providing each finished medium in a form readable by the controlling software, followed by fine tuning their use and interactions, for example adjusting the the position of graphics, or the pauses for reading time of text, and improving consistency across media.

Figure 14-1 from Multimedia Tay Vaughn (1994), shows an elaborate development scheme but only two steps are specifically multimedia (Audio/Visual Pre-production and Post-production). Most of it concerns aspects of design, which could apply to text-only courseware, but each step is made more complex as media are added so that the total time and resources involved increase. Installation or publishing are also more complex because of the larger volumes of data and the greater demands on the delivery platform.

PROFIL

Koper (1995) proposed a development method ("PROFIL") specifically for multimedia courseware which incorporates many of the ideas discussed above. It attempts to integrate instructional design, software engineering methods, prototyping and the selection of media. There are six phases in a sequence. Iteration is restricted to within-phases rather than looping between adjacent phases as in the waterfall model.

Preliminary investigation, producing a course plan (analysis).
Definition phase producing a project plan for each medium (instructional and media design)
Script phase producing a script for each medium, a design detailed enough for the media producers (detailed design)
Technical realisation phase producing a master program, including media. Content is integrated with software, an alpha version is peer reviwed and a beta version is pilot tested with students. (production)
Implementation phase producing an installed product (installation, publication).
Exploitation phase producing a summative evaluation (maintenance).

a practical model

Assuming an authoring tool is being used to produce multimedia software, how should prototyping be used? A "practical CE model" for medium-sized multimedia projects is given in the appendix. While using prototyping, it differs from the incremental development method described above in that :

it is assumed that the initial requirements could be specified clearly so feasibility and analysis phases are not part of the evaluation-revision cycle,
the first cycle of design and prototype production is different in that the separate media fragments are designed and scripted here, and not revised later,
modular design of the courseware means that only the first module needs intensive revision while later modules are based on it.

Summary

Interactive multimedia is developed as other courseware. The additional media need designing and producing in parallel with the control software. Production includes integrating them in the interface.
back to top

8. Software tools

Just as in software engineering, software tools can be used in many ways in the courseware development process. Computer Aided Software Engineering (CASE) products can be classified as : (Harmon and Hall, 1993)

generic productivity tools for project management,
4GLs (fourth generation languages) and application generators,
Lower CASE (code generators for e.g. COBOL code, interface generators),
Upper CASE (analysis and design tools),
Integrated tools for upper and lower CASE, taking analysis and generating code

The equivalents for courseware are

generic productivity tools for project management....
4GLs - authoring tools for prototypes and final product -described above.
Lower CASE - some authoring tools generate code.
Upper CASE - support tools for analysis and design.
Integrated tools for automation of courseware production; the possibility of automating the courseware engineering process.

These will be described in turn.

Project management

Personal productivity tools can aid courseware development in many obvious ways. Wordprocessing and DTP can be used to produce manuals, spreadsheets for costing and designing models for simulations, databases for tracking resources. As large scale courseware production is done by teams, groupware on a network can speed integration. Tools for brain-storming include electronic whiteboards which give everyone a hard copy. Project management software can be used to control projects of all sorts including courseware development.

Upper CASE

Upper CASE tools help in analysis. Tools for supporting analysis of learning content (see Alessi and Trollip page 263) include outlining programs (or functions in word-processors), which generate hierarchies of ideas. There are packages for drawing networks such as semantic nets. There are interactive guides to interviewing subject matter experts when eliciting knowledge.

DAT

For example, the Domain Authoring Tool (DAT) supports the modelling of knowledge to support the design of instructional systems. It performs four functions.

requirements analysis
This records information on learner prior knowledge, learner style and motivation, domain name and the goal tasks to be performed after instruction

domain analysis
This requires the modelling as a network of domain concept classes, subclasses and instances in a hierarchy. Later, non-hierarchical links can be added. This is effectively a decomposition of the subject to produce a semantic net.

learning goal analysis
This takes the overall goal tasks and decomposes them, taking the domain analysis into account. Its product is a text structured list of skills and knowledge.

content analysis
This converts the goal analysis into the content of learning. The product is a text list or a network which specifies what is to be taught (as items and their relationships), but it does not specify how items should be taught.

DAT is passive - the subject expertise comes from the author. Crudely, it can be regarded as a restrictive template in which to organise a domain description and a decomposition of learning goals. It is therefore largely analysis, but the conversion of the learning goal analysis into content analysis begins the design phase. It has the general productivity advantages of a software tool over paper methods (revision, documentation) and it checks consistency and completeness for the author. But it stops short of the difficult process of deciding how to teach the content. Some screens and printouts from DAT are provided in the Appendix.

Design

Some design tools are simple. Flowcharting software is more productive than redrawing drafts on paper. Screen design can be done with an authoring tool or another type of presentation tool such as Freelance or Powerpoint.

Integrated tools & automation

Integration suggests moving smoothly from analysis to design and even to production. The translation of analysed needs to designed functions is the hardest part of instructional development. Methods such as that of Gagné (above) use an explicit model of learning as the framework of that translation. The automation of instructional (and courseware) development is more difficult than for CASE tools because the underlying model is a theory of human learning.

Peter Goodyear (1995) distinguishes weak and strong support tools. Support in a weak sense is passive support, relieving some of the tedium or cognitive effort to allow the courseware engineer to concentrate on more important aspects. Strong tools would automate some of the decisions and would therefore need to be based on a model of learning and contain expertise. All of the tools described above are weak in this sense.

Strong tools incorporate one of two ideas. By being based on a particular theory of learning and instruction, their structure may only allow certain approaches to instructional design. This is like an elaborate template and is similar to CASE tools. Secondly, a somewhat weaker and more empirical approach is to incorporate an expert system which suggests particular design decisions. Brent Wilson and David Jonassen (1990) describe eighteen systems automating some parts of the development process. Their table listing the characteristics of the systems is in the Appendix - annotate it with A,D,P,R and M according to the systems' characteristics.

Summary

A variety of software tools exist to aid courseware development. Weak (passive) tools include support for project management, analysis and design. Authoring tools are used in production and change the development model. Strong tools would automate design decisions but they are in their infancy.
back to top

Appendix 2 : A practical courseware engineering model

A practical courseware engineering model
(Stephen Bostock & Paul Drummond 1995, modified by Bostock in 1998)

(text version)

1. Feasibility analysis --> feasibility report

2. Needs analysis --> requirements specification

3. Design phase 1 --> first design specification

4. Production phase 1 --> media and first prototype control software

5. Prototyping cycle of evaluation and revision of software
--> beta test software
(first evaluation may require feedback to 2, or 3.)

6. Pilot & Field testing and revision --> courseware for installation

7. Install and maintain

In detail:

1. Feasibility study
Goal: green flag for go ahead
Inputs: client with requirement
Tasks: Low detail in
        target population description
        task analysis
        domain analysis
        develop alternative implenetation strategies
        constraint analysis
        cost analysis
Output: feasibility report with costed alternatives

2. Needs analysis
Goal: describe current situation, learning points/objectives
Inputs: initial requirements from feasibility
Tasks: 
        describe target population 
                (knowledge, motivation, ability, variation)
        Training needs analysis
                (learning objectives hierarchy)
        Learning needs analysis
                (subject domain )
        describe environmental constraints
                (access, hardware, operating systems...)

        develop evaluation documentation

Outputs: Requirements specification, 
        a theory of learning/instructional framework

3. Design phase 1
Goal: production of media requirements including software requirements
Inputs: Requirement specification, instructional framework
Tasks:

    conceptual/instructional design:
        pedagogical design
        generic media selection
        content/curriculum structuring
        instructional events and sequence

    presentational design:    
        script for each medium (including control software)
        navigation design
        user interface design
    peer/expert review

Outputs: functional specification

4. Production phase 1
Goal: first working prototype
Inputs:
        functional specification
        
Tasks:
        development/recording of media according to scripts
        editing of media
        integration of media
Outputs: Media master copies, first working prototype

5. Prototyping cycle
Goal: software for pilot testing
Inputs: First (then succesive) prototypes
Tasks:
        quality review
        evaluation of alpha test version for
                robustness, usability by peer review 
        as necessary: revision of design, revision of software
Output: working software for pilot (beta) test

6. Pilot & field testing
Goal: evaluation of beta test version
Inputs: beta test software
Tasks:
        evaluate using pilot or/and target (filed) group
        as required, revise design, revise software
Outputs: finished courseware ready to install

7. Install, along with any documentation for users and maintenance

back to top

Appendix 3 materials (in paper original) List of ID models

Development task list of Kang 1994

Petry, Mouton and Reigluth 1987. A lesson based on the Gagné-Briggs theory of instruction.

Checklists from Allesi & Trollip (1991)

Goodyear (1994)

DAT screen, list and network

Wilson and Jonassen (1991) Table 2

Marshall et al. (1994) Figures 1 & 2.

Sandford (1990) Table 1.

back to top

Stephen Bostock

Keele University Home | Learning Technology Home | email Stephen Bostock

Stephen Bostock asserts his moral right to be acknowledged as the author of documents on this site, unless another author is identified. Copyright remains with Keele University, or the author. The views expressed in this site are those of the author and do not necessarily represent those of Keele University.
Last edited: November 22, 2006