This paper describes a collaborative project undertaken between
the Department of Physiology and the School of Computing and Information
Technology at Monash University, to involve computing students
in the development of an interactive CBT package for instruction
in morphometry, a class taught to 360 science students. The computing
students, working as a series of independent project groups, have
used Toolbook to translate a preexisting paper-based practical
class into a suite of CBT exercises. The paper discusses the roles
of the computing students, the project supervisor and the client
(the academic from the subject area), and the necessary interactions
between all those involved, in order to ensure that the project
is developed successfully.
Since the "Dawkins Revolution" in tertiary education in Australia, which has seen the advent of a system of mass access to higher education without any expansion of the physical resources to manage the increased numbers of students, many departments and faculties have felt the need to reorganise the method of delivery of academic content, without compromising on quality. One possible alternative delivery mechanism is the use of Information Technology to support the current pedagogies. However, the development of Computer Based Training (CBT) multimedia materials can be costly in terms of both time and money for the tertiary academic. While the lecturer of a subject will be the acknowledged content expert and should have experience in instructional design, he / she may not have the expertise required in the program design and development area to implement CBT multimedia materials. Even for those keen to undertake the learning of an authoring tool to develop such projects themselves, time may prohibit such development, thus requiring payment for programming and technical expertise to allow the project to become a reality. Unless funding can be gained, something that may be increasingly difficult with the funding cuts to tertiary education, CBT multimedia materials may be beyond the reach of the average academic. A possible solution is to use tertiary computing students to develop CBT multimedia materials for academics in other disciplines as part of their project course work (eg. see Browne C. and Chapman, J. B. [1]). This paper discusses a project undertaken between the Department of Physiology and the School of Computing and Information Technology at Monash University that has achieved just such a solution.
The Department of Physiology at Monash University teaches both Medical and Science students, largely using a number of traditional modalities such as lectures, tutorials, problem classes and practical classes. The second year Physiology science class numbers some 360 students, the largest second year class in the Science Faculty at Monash, and the largest Physiology science enrolment in the country. Each student must attend a practical class every week, and as the laboratory class space is physically limited to 90 students, with practical exercises limited to 30 students per 'experiment', these practicals are routinely operated on a 4 x 3 x 3 rotation. This means that each week, for four days, three different practicals are offered, and each student will participate in one practical exercise per week for three weeks, until all 360 students have completed all three practicals. Thus each practical exercise is put on 12 times. Then a new set of three practicals will run over the next three weeks. This repetition places strains on the demonstrators and lecturing staff who supervise the classes. Clearly, any practical which can be removed from the practical class timetable and offered in an alternative way will improve the efficiency of space utilisation in the practical laboratory. The project described in this paper is the conversion of one of these practicals to computer form.
The 'Morphometry' practical traditionally uses three sets of seven 'charts', each of which contains text, electron micrographs ( grey scale, black and white images of cells obtained from an electron microscope), and explanatory diagrams presented as black and white line drawings. Each chart requires the students to read the textual information, to examine the images, and to measure or count various features within the images. The objectives of the Morphometry practical class are:
There were several drawbacks to the 'traditional' chart based approach.
Each chart was large and unwieldy, and quite time consuming to make up from text, photomicrographs and diagrams.
Charts often had to be repaired or remade from year to year, as students have tended to deface the charts by drawing on them, or by leaving a variety of marks on the pictures.
With three sets of seven charts available, and the students working in pairs, it was not possible to have all students start on chart one and work through the charts in the optimal order of 1 through 7. Instead, students had to start anywhere in the sequence of charts and complete them in an order which is determined by availability, rather than by educational design. This is compounded by each charts normally requiring a different length of time for completion, as well as some students needing more time than others.
The educational intention of the practical could get lost in the mechanics of the measuring and counting processes required.
Students tended to skip over the associated textual material that explained the physiological principles in order the get to the "hands on" part of the exercise, and it was not possible for the staff member supervising the practical to monitor this.
It seemed obvious that this practical exercise could be better mounted as a series of computer based teaching modules, which would solve many of the problems outlined above, and could lead to an enhanced version of the practical class by taking advantage of some of the extra elements available on multimedia-capable computers, such as colour, sound and animation as well as monitoring and note-taking features.
The students developing the multimedia applications are final year students completing a Bachelor of Computing degree, either singly or in combination with another degree such as Bachelor of Business or Bachelor of Arts. The computing degree is based in commercial data processing applications development rather than a computer science orientation. Thus the students have developed appropriate skills in the areas of Systems Analysis and Design, Project Management and Programming as they relate to commercial applications in industry. They may not, however, have been involved specifically in the development of multimedia applications and the life cycle process peculiar to this type of application, as subjects relating to graphical user interfaces and multimedia interface design and development are elective components of the degree.
The industrial experience subject is a final year undergraduate subject in the Bachelor of Computing Degree at the Peninsula School of Computing and Information Technology, Monash University. The subject usually runs for two semesters (approximately nine months of elapsed time), with students working together in teams of three to five, to develop a small computer application for a client from industry. The purpose of the subject is to bring together all the various aspects of system development learnt in previous years of their degree, in a single project, together with the variation and unpredictability of working for a real client. At the present time, the assessment for the subject is on the basis of the group's work, and is assessed to the level of a pass grade only. There are a number of hurdle requirements during the project, including two presentations and a walkthrough.
For the project to have a successful outcome, there are three areas that must have appropriate input; the students developing the project, the supervisor overseeing the project and the client for whom the project is intended.
The multimedia development life cycle poses an approach for the students that is different to the traditional system development life cycle based around data analysis and flow. It tends to be one of functional task analysis and incremental design and development, due to the highly interactive nature of the applications and the use of hypermedia principles that often bring together material of a heterogeneous nature (see Ellis, A. E. [2]), rather than a data centred approach. They will need to investigate the different tools, in particular storyboards and object hierarchy diagrams used in the design phase.
One of the important aspects of these applications, as for any computing application, is the management of the project and control over the various aspects of its analysis, design, development and implementation. The group should select a project leader who becomes the primary liaison person between the supervisor and the group, particularly in reporting progress. The leader may have to be politely persistent in liaising with the client, as often he / she has other commitments that cause the immediacy of the project to be reduced. It is the project leader's responsibility to ensure that the project plan is adhered to and the members of the group are performing their tasks satisfactorily. The incremental nature of the development lends itself to changes proposed by the client that also perturb the development life cycle and hence the time to develop the project. In this project, when discussions have taken place with the client, individual members of the team have picked up on an idea and enthusiastically overcommitted the group to yet another extension or change to the basic project brief. This is an area that needs to be stressed in relation to project management as what appear to be minor changes to the scripting of the project can be quite significant when all aspects of the life cycle (ie. documentation and testing) are included.
The project leader should be made to realise that
this role is no sinecure, as he or she is ultimately responsible
for the project's success. In the past, a project leader has found
that he / she has been left with a substantial workload due to
another member's failure to produce, when the management responsibility
and importance of the role has not been fully understood.
A project plan needs to be developed that shows the breakdown of the work into appropriate parts of the development life cycle and incorporates the incremental nature of design and development. This needs to be as detailed as possible, and should include:
Time allocated to learn the authoring tool (how much time will depend on the student's prior knowledge of the package).
Allowance for workloads in other subjects - particularly when assignments are due and at exam time.
Meeting times with the client and supervisor and also for the group itself.
Allocation of tasks to individuals in the group - the group members should assess for themselves their strengths and weaknesses and allocate tasks accordingly. eg. Students who are better at programming should take a larger role in the scripting and implementation process, while those that are better at written communication might undertake to do more of the documentation such as the user manual and testing strategy. It should be noted that testing for a part of the application should not be carried out by the author of that part.
It is suggested that all group members be involved in the analysis and broad design phases of the project, and that group meetings are held to ensure all members have a broad familiarity with individual work being done when task allocation becomes more fragmented.
A record of both elapsed and actual time needed
for each task. Students frequently underestimate the time needed
to complete parts of the application, particularly the design
and development phases. Appropriate monitoring of both elapsed
time and actual time needs to occur, with variations in progress
from the project plan noted, and the plan adjusted to incorporate
these alterations.
Documentation is often the bugbear of the project. Students get involved in the fascinating task of multimedia development and there is a danger that the documentation might become rudimentary at best and non-existent at worst.
The students should be aware that documentation serves a number of purposes.
It provides a written substantiation of the requirements of the system.
It provides a development vehicle during the implementation of the application.
It provides information for future maintenance and development of the system.
If these projects are to serve a useful purpose other than a case study vehicle for the industrial experience subject, quality documentation becomes vital.
It is suggested that the following documentation should be present for the application.
Project brief - this describes the scope of the project and any constraints together with a delivery date.
Analysis document - this document should show the breakdown of the application into its separate functional components together with an understanding of the type of multimedia tasks associated with the component. It is this document that is the first detailed description of the tasks required and must be completed early for client approval.
Design Documents -
Storyboards - these provide a "snapshot" of each screen with annotations for each interactive object regarding the nature of its function (see Figure 1).
Hyperlink Map - if hyperlinks are extensive, the storyboards can be shown in miniature with the hyperlinks indicated between them.
Object hierarchy diagram - a diagram showing the hierarchical structure of objects (eg. buttons, pictures, pages, backgrounds) and their relationship to one another within the application.
Printouts of scripts (only controlling scripts (eg. system and book scripts) and those scripts that are complicated or extensive).
Testing strategies for each function of the application - Testing should be oriented around the tasks to be completed by the user, as well as testing for all objects of an interactive nature. An appropriate test plan with associated input data, actions to be executed and expected outcomes must be included. Students should be aware that their on-going checking of the working of parts of the project is not an adequate substitute for rigorous, formal testing.
User manual - documentation on the installation and operation of the application. While on-line context sensitive help should be built into the application, written instructions should also be available (see Figure 2).
While some might argue that the supervisor's role is of minor importance, a good supervisor can mean the difference between the client receiving a viable product, particularly one that can be passed onto others for improvement and maintenance, and a useless one. Clearly it is not the supervisor's role to do, or even manage, the project, but appropriate close monitoring and timely advice can be crucial. The supervisor's responsibilities include:
The evaluation of the feasibility of the project in terms of the allotted time scale, the student's capabilities and resources available.
Ensuring that, once the students have developed the project brief, the scope of the project is manageable for the total time available. This means that the supervisor has to have a working knowledge of multimedia design and development as well as some understanding of the intended project.
Contact with the client to monitor appropriate progression of the project.
Monitoring, usually by weekly meetings, the progress of the project in relation to the project plan and gantt chart developed by the students. This may involve advice to the students regarding appropriate timing of milestone deadlines and workload management.
Discussion with the group regarding the multimedia development life cycle, and the development tools and documentation deliverables associated with this.
The supervisor needs a good working knowledge of the multimedia development life cycle, in particular the type of analysis techniques and design tools, such as storyboards and object hierarchy diagrams, that are to be used. Students may be unfamiliar with these techniques, as the subjects in the degree that relate to multimedia are elective areas.
While knowledge of the authoring tool is not imperative for the supervisor, the students will need access to expert technical help in this area, and the supervisor should ensure that appropriate assistance is available. Certainly, a familiarity with the authoring tool can help the supervisor provide appropriate advice regarding the scope and design possibilities for the project. Similarly, some understanding of purpose of the project itself can also help in clarification of requirements, but detailed knowledge is not essential.
The main role of the client is the content provider, and as such, needs to ensure that the project group produces a product in which the academic content is preserved at the highest possible quality, and that the interface used would be meaningful and easy to use for the target audience - in this case Physiology undergraduate students with limited and varied computing skills. This is achieved through frequent meetings between the project group and the client. Deliverables such as the project brief, analysis document and final project acceptance should be formally "signed off" after agreement between the client and the group.
The client has to be able to explain the purpose and content of the project in language appropriate to the project group, keeping in mind that these computing students may have had little exposure to the subject area. In cases where a version of the content already exists it is necessary for the client to explain how the old system works and to indicate what educational objectives must be retained in the new CBT version.
In this project the client explained to the project teams the purpose of the chart that each team had elected to develop in non-physiology terminology. He demonstrated how the old paper based charts were used , and suggested possible ways that the same educational objectives in the multimedia version of the chart material might be achieved, without being proscriptive and thus stifling the students' creativity.
The client needs to separate the "need to knows" from the "nice to knows" when asking for functional aspects to be included in the project. Often, enhancements may occur to the client as the process of consultation with the project groups proceeds. These should be kept strictly as secondary goals for the group.
The client, in this case, emphasised the critical parts of each chart-based exercise, to ensure that the core material was properly understood and developed by the student project groups. Sometimes, particularly creative groups and individuals would suggest enhancements themselves. This was encouraged, as long as the core material was completed or was clearly on track to be completed.
The client needs to define the minimum presentation platform specifications, (both hardware and software), especially screen resolution and colour definitions, as this is more readily under the client's control than anyone else. It is also important to ensure that help screens, user manuals, interface integrity and general ease of use are constantly considered, as the end users may have varied competence, confidence and experience with computers.
The client starts by showing the project groups the pre-existing learning environment. Indeed the starting point may be for the client to provide copies of existing material for the current system (in this project the groups were supplied with scanned images and appropriate text taken directly from the existing charts). The client needs to suggest the approach or approaches that the project groups might consider in their implementation of the material. However, it is important that the project groups are encouraged to think more laterally to provide a better way of implementing the CBT product, rather than by merely 'mimicking' the old technology. For this project, several groups showed great imagination in this regard, particularly in the use of animations.
The client was in this case perhaps a significantly better informed client than is often the case, being a Toolbook multimedia author himself. However, this may not always be the case, and should not be a deterrent in attempting these projects. It is the students' and supervisor's joint responsibility to ensure adequate expertise in this area. Knowledge of the authoring tool may help in recognising the technical possibilities available for the project, but is not essential.
Frequent face-to-face meetings between students and supervisor are vital to the successful and timely completion of the project. The frequency of these meeting will depend on the capabilities and enthusiasm of the group members. Certain stages of the project also affect the frequency of meetings. They tend to be more frequent at the start, with fewer meetings during the development phase, finishing with a greater frequency during the final (panic) phase of the project. In this project, groups met with the supervisor weekly, each meeting lasting from 30 minutes to 1½ hours during the early and final stages, and fortnightly during the development phase. Progress was checked against the gantt chart, with gains or slippages in times discussed and solutions for slippages advised on. Drafts of documentation and on-line demonstrations of ongoing work was expected to be shown at meetings, with discussions about any problem areas. The supervisor kept a record of meetings with the students, detailing who attended, what work was presented and what deliverables were to be developed for the next meeting.
As part of the purpose of these projects is not only to provide the client with a working system and to give the students experience in developing and implementing a live project, but also to foster good working relations between faculties, it is important that the supervisor doesn't leave all of the contact with the client up to the student. Verbal contact between the client and supervisor can provide a basis of reassurance for the client that work is on schedule and also provide an extra monitoring point for the supervisor. The supervisor's involvement here can facilitate the relationship between client and students.
One of the vital aspects realised from working with these projects is that frequent liaison between the students and the client is vital due to the incremental nature of design and development. Methods of contact include email, face-to-face meetings, telephone conversations and even the use of snail mail. Meetings were almost always initiated by the students, either when they had a deliverable ready or had reached a point in the product development where a decision or an approval was required from the client. Meetings were held at the client's location, and normally involved a demonstration of new features of the product. For most groups, these occurred fortnightly or monthly. The client's presence at the student presentation for the project shows his / her commitment to the project and confidence in the students' ability to produce a worthwhile product. It also fosters good interfaculty relations.
It may be that a project is too large for a single group to undertake. In this case, an appropriate breakdown of the project should be discussed between the client and supervisor. For the morphometry project the overall task was broken down as follows:
In semesters 1 and 2 of 1995, groups 1 and 2 generated the overall structure for the project (ie. navigation, help system, note-taking facility) as well as two of the charts.
In the summer semester of 1995 / 1996, groups 3, 4 and 5 generated a chart each.
In semesters 2 and summer of 1996, groups 6 and 7 will generate the last two charts. They are also enhancing the base structure of the project.
It is intended that a group will be allocated the task of bringing all parts of the project together and packaging it for classroom as well as home use in semesters 1 and 2 of 1997.
This illustrates that the client must be patient in the production of the overall project as producing a quality product may take some time. Due to this, the client should be careful in selecting projects where the content will not change excessively over its useful lifetime.
Prior to the final acceptance of the overall product, pilot testing by the intended users should be carried out. This will help determine the level of intuitive use and user friendliness of product. It should also highlight any potential trouble spots in the operation and presentation of the content.
Evaluation in terms of learning produced, time taken to complete the practical, and student and staff acceptability should also be implemented. For this project some pilot testing has already occurred of the parts completed in 1995. The client was particularly interested in feedback on the availability, depth and sufficiency of online context sensitive help as well as the more usual evaluation of screen design, ease of navigation, quality of images, and clarity of instructions.
One must remember that the product is being developed by inexperienced students. As such, it comes with no warranty or guarantees. There is also the issue of lack of ongoing support as the students will be finishing their degrees and moving on. It may be necessary to gain some professional assistance in the latter stages of the project to ensure flexibility and robustness has been built in. While this incurs a cost, this would be a small amount compared to having the whole project undertaken by professionals. The other possibility is to make the final group's project the job, with appropriate supervision, of ensuring this robustness and flexibility is included. This may required the "hand picking" of the students for the job by the supervisor. It also raises the issue of quality documentation being of prime importance so that, as in industry, another developer can continue a project without having to redo work already done.
The client recognised the potential of CBT materials in this context, but realised that he had neither the time nor the expertise to attempt this project as sole author/developer. He needed a team of committed and talented multimedia developers to collaborate with. Unfortunately, his department and faculty, like the vast majority of institutions, could not possibly supply this infrastructure support. Using a commercial supplier of multimedia applications was prohibitively expensive. Even consideration of similar in house university providers was expensive.
Similarly, the computing supervisor needed appropriate projects from genuine clients for her students to develop as part of their computing degree.
A serendipitous meeting between the two academics established the possibility of collaborative work in this area. Members of other faculties have shown an interest in pursuing this type of multimedia development.
Working with non-physiologists helped avoid any possible tunnel vision regarding the presentation and implementation of the project. A benefit of undergraduate student involvement in the development of materials for undergraduate student teaching is that the designers and users of the system have an affinity with each other that facilitates the presentation of the materials. Every university has a pool of latent talent in its student body that often goes unrecognised, and certainly is under-utilised. It is a nice thought that current Monash students are 'giving back' something to future students by providing these CBT materials.
Development of these CBT materials will enable the replacement of standard practical classes. This should reduce the frustrations felt by the students and demonstrating staff that were inherent in the old system. It also allows a more flexible use of the practical class space, and of staff and student time. It also opens up the possibilities for home use, student server based distribution, Web presentation and distance education.
[1] Browne, C. A. and Chapman, J. B. (1995) Electronic Practical Notes I: Permeability Of A Biological Membrane in Proceedings of the Australian Physiological and Pharmacological Society V26 No2. p272P 1995
[2] Ellis, A. E. (1996) Design, Implementation and Testing Techniques for Multimedia Industrial Experience Projects. SIGCSE Bulletin, Volume 28, Special Edition, 1996, Pages 119 - 121.
We would like to acknowledge the computing students who have been involved in the development of the CBT Morphometry Practical up to this time.
Alfian Ahmad, Lucas Canavan, Eric Ch'ng, Simon Chin, Ricardo De Marco, Steven Ellis, Kristina Gnankone, Michael Hayles, Millie Ho, Hui Mei Thoh, Iain Jacob, Susan Khor, Joseph Kong, Rolf Kuntze, Leong Say Kwee Alex, Nathan Lillee, Lo A Siong, Sylvia Lo, Julian Morgan, Benedict Ng, Ng Siok Keng Angelyn, Ngui Khee Teck Norman, Daniel Tan, Tang Kok Wai, Willy Tanta Utama.
Ellis, A. E. and Browne, C. A. (c) 1996. The authors
assign to ASCILITE and educational and non-profit institutions
a non-exclusive licence to use this document for personal use
and in courses of instruction provided that the article is used
in full and this copyright statement is reproduced. The authors
also grant a non-exclusive licence to ASCILITE to publish this
document in full on the World Wide Web and on CD-ROM and in printed
form with the ASCILITE 96 conference papers, and for the documents
to be published on mirrors on the World Wide Web. Any other usage
is prohibited without the express permission of the authors.