| Douglas Siviter, Peter Linecar, | Phil Siviter, | |
| School of Computing, | Department of Computing, | |
| Information Systems and Mathematics, | University of Brighton, | |
| South Bank University, | Lewes Rd, Brighton BN2 4GJ | |
| Borough Rd, London SE1 0AA |
This paper describes some of the experiences and technical issues which arise in large-scale courseware developments projects, sometimes involving consortia of collaborating academic institutions. The paper provides several perspectives on approaches to large-scale courseware development including impressions from project managers, authors, courseware developers, and tools developers.
The paper tries to address generic issues which arise in many projects, in the hope that other practitioners might benefit from some of the experiences. Specific examples are drawn from the authors' experiences of producing courseware management systems (i.e., HyperCourseware) and from using these systems on a variety of projects including a current project to develop courseware for the Analysis and Design of Software Systems.
The paper provides a very brief overview of how HyperCourseware techniques and tools address various courseware management and courseware development problems. In particular, HyperCourseware enables the evolutionary development and delivery of flexible large-scale courseware and supports the integration of material produced using a diverse collection of authoring tools.
Within the UK there are now many courseware development initiatives which have progressed well beyond the small 'cottage industry' approach and there is a growing trend towards large-scale developments via consortia of institutions. Collaborative developments are increasingly being shown to be more viable (both educationally and economically) than small-scale isolated developments. The courseware development process in large projects has been forced to mature from the previous ad hoc production of 'small-scale lessonware' to the progressively more organised development of 'large-scale courseware'.
Larger development projects require team efforts where the teams comprise people sharing a variety of roles e.g., project management, subject authoring, instructional design, courseware development, tools development, courseware evaluation, etc.
Although courseware development projects have unique aspects to them, there is a sense in which they can be regarded as just specialised software development projects; hence, the planning and management of such projects can adopt techniques from many kinds of construction project.
The authors regard all of the following as important aspects of large-scale courseware development projects.
As with the example above, there are several places within this paper where an abbreviated lists of issues is presented without having the space to adequately elaborate on all the issues.
These issues are never neatly distributed amongst the project team; they are frequently concerns which are shared by all participants but from different perspectives.
This section provides a thumbnail sketch of courseware development projects from the perspectives of the various project participants.
One set of clients are the academic staff who are expected to exploit the end product within a conventional teaching framework, i.e., the courseware is expected to be integrated into conventional teaching rather than serve only as a stand-alone distance learning package. It is common to find that the subject authors for a piece of courseware are a subset of these clients (i.e., they are writing the material for use by themselves and others). Below is a typical list of issues which might concern such clients; in this case they are from a subject author requiring courseware to support the teaching of Information Systems Analysis and Design within a computing school. The expressed requirements could be typical of many subject areas.
We can return to the clients' perspective later in the paper when describing the development activities; Meanwhile a crucial perspective which the client brings to the process (questioningly) is :-
"Is all this an opportunity to reduce staffing? This should certainly not be the case. However, there are indications that with well developed material the learning experience of the student can at least become more student based, allowing a greater role for the tutor as a consultant rather than an instructor; somebody to call upon for input to a particular problem situation experienced by a group, rather than somebody who is a primary source of information."
The usual concerns arise here i.e., "how will the project be completed on time, to acceptable levels of quality, and within budget?". As projects become larger it becomes more essential that inputs are derived from Quality Assurance, Project Planning, Managing the development of Prototypes, etc. As a bare minimum, producing and maintaining an explicit Project Specification document is mandatory. The minimum requirements for the contents of this project specification document could be something like :-
Minimum Contents of a Project Specification document
0 Admin Header Page: (Project Title; Team Details; Distribution List, etc.) 1 Project Aims and Objectives (exactly what deliverables is this project intending to produce) 2 Target Audience (who, how many, in what circumstances, etc.) 3 Courseware Specification (description of subject matter - topics and teaching methods) 3.1 Long Term Development (context including areas which are 'just out of scope') 3.2 Proposed Development (what will get developed within the scope of this project) 4 Work Packages Definitions (specification of all activities which consume resources) 5 Work Packages Schedules (the notorious process of 'guesstimating', bar charts, etc.) 6 Resources Summary (people, time, money, software, equipment, books, whatever)
Elaborating on point 4. from the above list of contents, an example set of Work Package Definitions could be as follows:-
Each work package should be described according to some agreed convention e.g.,The full (structured) set of work package definitions should be outlined and refined.
The example below was the preliminary starting point for the Systems Analysis courseware project. (It contains some specification jargon which is peculiar to HyperCourseware - explained later)
| WP1 | Project Management | ||
| WP2 | Investigations, Research, Background Reading, etc. | ||
| WP2.1 | Authoring Tools & Training | ||
| WP2.2 | Instructional Design | ||
| WP2.3 | Collaborative Learning | ||
| WP3 | Courseware Specification | ||
| WP3.1 | Identify Topics Outline | ||
| WP3.2 | Evaluate Topics Outline | ||
| WP3.3 | Identify Topics, Educational Activities (and Facets of Activities) | ||
| WP3.4 | Evaluate choice of Topics, Educational Activities (and Facets of Activities) | ||
| WP3.5 | Specify Content and Style of Educational Activities | ||
| (This deceptively simple list includes a mass of complex authoring issues) | |||
| WP4 | Courseware Development | ||
| Note: these software development activities produce ongoing | |||
| updates to the project specification documents | |||
| WP4.1 | Implement Initial Course Skeleton | ||
| - a browseable collection of empty topics | |||
| - each topic can launch empty 'activity templates' | |||
| WP4.2 | Evaluate Initial Course Skeleton | ||
| WP4.3 | Implement Sample Topics | ||
| recommend :- | |||
| - a high level topic (close to root of course e.g., Systems Analysis and Design) | |||
| which typically provides 'overview' activities | |||
| - plus one low-level topic (e.g., Elements of Data Flow Diagrams) | |||
| which exemplifies a typical set of (hopefully interactive) educational activities | |||
| (e.g., presentation, assignment, self-assessment, etc.) | |||
| WP4.4 | Evaluate Sample Topics | ||
| WP4.5 | Implement and Evaluate all Topics | ||
| (a separate WP for each Topic or specified for sets of Activities across Topics) | |||
A development strategy is implied in the above list of work packages. The only viable strategy for courseware development is 'incremental development' i.e., a subtle blend of traditional software development life cycle approaches and systematic prototyping. Courseware developers should quickly realise that they are either producing an evolutionary product or they are producing a dead duck. The only way that higher education institutions will embrace courseware is if the products are endlessly adaptable. Flexibility in production is required both during the initial production and beyond.
A detailed specification of the intended product is the cornerstone of a successful development effort. The courseware developer's main concern can frequently be :- "when is the author going to adequately specify the material - its shape, size, and other qualities?"
The HyperCourseware approach to courseware development encourages authors and developers to adopt a specific technique for specifying the structure of the courseware. The HyperCourseware framework is both flexible and powerful; it allows virtually any courseware structure to be specified precisely without restricting an author's imagination.
HyperCourseware structuring principles are described in (Siviter, Brown 1992) but are briefly summarised here for convenience :-
HyperCourseware is based upon the following definitions :-
- A course is a collection (more specifically a hierarchical network) of topics.
- A topic is a collection of educational activities.
- An educational activity is a collection of primitive activities.
These definitions are very flexible and allow authors to determine what constitutes a coherent collection of related topics for a particular piece of courseware, and what constitutes a coherent collection of related educational activities for each topic in a course.
Educational activities for a topic might include some traditional ideas such as:
- stating the objectives of the topic
- stating the pre-requisite knowledge a user should have before embarking upon the topic
- providing presentations, resources, assignments, sample solutions, and formative assessments, etc.
An educational activity can be composed of any combination of primitive activities e.g., read a piece of text, look at a picture, listen to a sound, look at an animation (computer based or video based), play with a computer based interactive device (e.g., simulation), or follow some instructions to perform an assignment away from the computer.
Referring back to earlier in this paper :- "The courseware development process in large projects has been forced to mature from the previous ad hoc production of 'small-scale lessonware' to the progressively more organised development of 'large-scale courseware'."
Using HyperCourseware terminology, many previous developments in Computer Assisted Learning would be classified as :-
Very few examples exist which, in HyperCourseware terms, would be classified as 'courseware', i.e., which embody large, structured collections of Topics.
The section below is an example extract from a project specification for courseware on Systems Analysis and Design. The project manager needs to see this refined as part of the project specification. The subject author needs to produce and maintain this as part of the courseware specification (see work package WP3. above). The courseware developer needs this specification as a basis for implementing the courseware, initially as a rapidly developed skeleton (see work package WP4. above).
This is obviously a critically important stage of the development and it is notoriously difficult to get it right. It is vital to complete this section before real development begins but obviously the definitions need to be flexible and must accommodate changes later.
The author's task is to first identify the 'Topics' to be developed and then identify the 'Sets of Educational Activities' proposed for each Topic. This should also eventually describe the activities in terms of size, features (especially interactive features), complexity, probable implementation approach, etc.
| 1. | Systems Analysis and Design | |||
| 1.1 | Some sub-topic of Systems Analysis and Design | |||
| 1.2 | Data Flow Diagrams (DFDs) | |||
| 1.2.1 | Elements of Data Flow Diagrams | |||
| 1.2.2 | Creating a Data Flow Diagram | |||
| 1.2.3 | Partitioning & Levelling of DFDs | |||
| 1.2.4 | DFD Case Study | |||
| 1.3 | Another sub-topic of Systems Analysis and Design | |||
This Topics Structure is then shown again, but this time it includes all the educational activities which are to be associated with each topic. The activities are determined totally by authors but might be chosen as some appropriate subset of activities from a generic activities list.
| 1.2 | Data Flow Diagrams | |||||
| A | How to use this courseware also permanently available as on-line Help | |||||
| A | About this Course | |||||
| · Objectives · Target Audience · Pre-Requisites · Authors · References | ||||||
| A | Purpose of Data Flow Diagrams (a presentation) | |||||
| A | Where Next ? | |||||
| 1.2.1 | Elements of Data Flow Diagrams | |||||
| A | About this Topic: · Objectives · Pre-Requisites | |||||
| A | Presentation (including sections of Case Study A) | |||||
| · Processes · Data Flows · Data Stores | ||||||
| · External Entities · Systems Boundaries | ||||||
| A | Self Assessment | |||||
| 1.2.2 | Creating a Data Flow Diagram | |||||
| A | About this Topic: · Objectives · Pre-Requisites | |||||
| A | Drawing a Data Flow Diagram (presentation including sections of Case Study A) | |||||
| A | Case Study: Part 1 (or some similar title) (Case Study A. presentation) | |||||
| A | Assignment (Case Study B. includes suggested answer and self marking criteria) | |||||
| 1.2.3 | Partitioning & Levelling of DFDs | |||||
| A | About this Topic: · Objectives · Pre-Requisites | |||||
| A | Presentation (including sections of Case Study A) | |||||
| · Modelling a Level 2 Diagram · Numbering | ||||||
| · Consistency Checking · Limits to Levelling | ||||||
| A | Case Study: Part 2 (or some similar title) (Case Study A. presentation) | |||||
| A | Assignment (Case Study B. includes suggested answer and self marking criteria) | |||||
| 1.2.4 | Case Study | |||||
| A | About the Case Study | |||||
| · Purpose of Case Study · Target Audience · Pre-Requisites · Authors | ||||||
| A | Presentation | |||||
Producing the above specifications can be demanding work but authors or developers who pretend that they can cope without doing something like this have almost certainly never successfully worked on a genuinely large project!
It used to be true that the bottlenecks in courseware development were all in the software development stages. Now, authoring packages (like ToolBook, Authorware, HyperCard, etc.) can greatly enhance the productivity at the level of producing 'small-scale lessonware' (what HyperCourseware refers to as Activities). At a higher level, i.e., courseware as opposed to lessonware, HyperCourseware tools can be used to construct fully browseable course skeletons in very short periods of time (consider implementing the skeleton for the above example in a matter of just a few hours!). Tools like HyperCourseware allow courseware developers to forget about the many complex software development tasks required to structure courseware, provide views of courseware, navigate through courseware, etc., and instead to concentrate on educational design issues. A discussion of the many evolving requirements which developers of such tools face is beyond the scope of this paper; see (Siviter, Brown 1992) (Siviter, Ling 1993).
There is an argument for suggesting that the client does not need to understand the media in which the development is carried out. Indeed there is little reason why s/he should understand the practical processes involved in the construction of HyperCourseware. However, we have found that we need to know at least enough to identify the 'kind of problems that can be solved'.
We also need to understand the terminology and notation of the developer. What is a topic outline, sub-topic, learning activity, etc.? Perhaps such familiarity is not essential, but it certainly eases communication.
While the actual process of courseware production is best left to the expert in the development environment, there are significant stages at which the client needs to be heavily involved.
It is a common experience that the development of quality learning resources is a time consuming process. HyperCourseware is in some ways an exception, since the available software toolkits are becoming better and faster at developing quality material. However, we have found that the tasks described above still call for substantial time commitment.
A significant issue has been the way in which parts of the package inter-link with other parts. In particular, we have attempted to use a consistent case study which will run through the complete package. Every time a new part of the package is developed, we realise the need for another change to the case study. This invariably has implications for earlier parts of the project which are at or nearing completion. Time taken in making changes can be a problem, as can version control, but at least the system makes this feasible.
From the Computer Supported Collaborative Learning (CSCL) point of view we are faced with many challenges. Group working is a notorious problem area. Is every member pulling his/her weight? How can we assess each member fairly? How do the failures of one member affect others in the group? Clearly there are issues to address, and we must look for solutions which best use the technology; perhaps revolving around 'management reporting' to the tutor. We intend to look at concepts such as the electronic equivalents of the 'library', the 'coffee room', etc., and the tools developers are upgrading the development systems to support the integration of courseware resources with CSCL environments. Can we make these new ideas work?
| (Siviter, Brown 1992) | Siviter,D., Brown,K., |
| 'HyperCourseware', In: Computers and Education | |
| Vol. 18, No. 1-3, pp. 163-170, Pergammon Press, January 1992. | |
| (Siviter, Ling 1993) | Siviter,D., Ling,E., |
| 'Using HyperCourseware for Computer Assisted Education' | |
| Proceedings of the International Conference on Engineering Education, | |
| Politehnica University, Spl. Independentei 313, | |
| 77 206 Bucharest, Romania. September 1993. |