Action learning for information systems teaching

David Avison gained his BA in social sci- Introduction ences at Leicester University. He has worked for a number of companies as chief Teachers of information systems are well aware of the limitations of programmer, systems analyst and project leader and as independent consultant. Be-

lectures as a way of teaching information systems, and examinations as a

fore joining Thames Polytechnic as a lec- way of assessing the subject. Many alternatives have been adopted.

turer in systems analysis, he gained his MSc Tutorial problems are limited in scope because although they prove in Computing. He has been a lecturer in information systems for the last 12 years in

appropriate to simple techniques or methods, such as the technique of

the Department of Computer Science and normalization or drawing data flow diagrams, they are not appropriate

Applied Mathematics at Aston University, to the definition and development of an information system, in particu- Birmingham B4 7ET, UK. lar the ‘people-orientated aspects’ which are crucial in information

He wishes to thank the following students systems work. and ex-students who have contributed to For some years teachers of information systems have used case the project: S. Delbridge, A. Cough, R. Landsbert, D. Smith and J. Terry; J. Fow-

studies to support their lectures. Case studies usually stem from real-life

ler, S. Howe, W. Inglis, I. Louwerys and situations, but are expressed in a simplified form. If the teacher is A. Quinnel; C. Ashton, S. Brown, N. following a case from a text, assumptions have to be made. Pressures, Crosswell, F. Devlin and S. Harris; A. Lewis and D.A. George; A. Bell and P.

such as the time allocated, also lead to simplifying the situation and

Uppal; C. Boshell, J. Olszanski and S. reduce the potential richness of the learning experience.’ Indeed, it Stipidis; and also academic and non- academic colleagues at the Department of

could well be argued that students would gain most out of attempting to

Computer Science and Applied Mathema- solve those difficulties in ‘real-world’ situations that case study authors

tics, Aston University. have to leave out. This is not to say that ‘the case study is dead’; case studies are very useful as practical work for larger classes and to form the practical element of basic courses in information systems, but there needs to be a further sophistication for ‘committed’ information systems students who, for example, might take an advanced information systems option in the final year of their computer science or business courses. These students need to analyse, design and implement information systems of comparable size and complexity to information systems in the ‘real world’ and to tackle them in project teams.

international Journal of information Management (1989) 9 (41-50)

Action Learning for Information Systems leaching

D.E. AVISON

This paper discusses the teaching of information systems using action learning methods. Such methods enable students who have already completed courses in information systems to practise using the methodologies, techniques and tools learnt, in a real-world situation. The paper describes the impact of action learning in the teaching of information systems on the Department of Computer Science at Aston University, where students have developed a prototype information system which is to be used by staff and students of the Department. Some of the issues concerning action learning are also discussed.

This paper describes the attempts made at Aston to increase the potential learning experience of information systems courses by the use of action learning methods. The relevant course-units are final year options in our undergraduate course in computing science and compul-

‘HAMMEKSLEY, P. (1981). The Case Study is sory course-units for our final year joint degree in management and

Dead. Information Systems Teachers’ Con- computer science. Action learning methods enable students who have ference, Cambridge. already completed course-units in information systems to practise using

02684012/89/01 0041-10 $03.00 0 1989 Butterworth & Co (Publishers) Ltd 41

Action learning for information systems teaching

some of the methodologies, tcchniqucs and tools learnt in a formal course,’ to a ‘real-world’ situation.

There have been a number of attempts at Aston to apply action learning techniques. Prior to starting the project which is described in this paper, action learning projects concerned particular tasks for those outside organizations where ‘sandwich’ students had worked. Those students who had completed an industrial year were allocated, one to each group of four or five students. This method worked in some instances,3 but there were problems, for example:

1. There was an over-dependence by other team members on the student with experience of an industrial year. so that projects might stand or fall on the basis of his or her enthusiasm and contribution.

3 -. Communications with host organizations were often difficult to sustain, perhaps due to distance from the univeristy.

3. The project might be difficult to contain in the time available, particularly if there was a slow start in gathering the basic information about the organization from the sandwich student.

3. The organization may not be very cooperative, because the benefits to them or to their liaison officer were not apparent.

5. The project requirements of the organization were often different from the educational requirements of the course.

Further, it was difficult for students to place the project in the context of the whole organization as well as difficult for them to experience a wide range of methododologies, techniques and tools. Most ‘real-world’ organizations have standardized on one methodology and on tools relating to that methodology. They are unlikely to have a range of options. With an in-house project, as described in this paper. with students working in groups, the USC of a number of methodologies, techniques and tools becomes a real possibility and the potential learning experiences thereby increase.

Experience with the action learning project

The in-house project concerns the development of an information system for the Department of Computer Science and Applied Mathematics at Aston University. It aims to fulfil the information requirements of staff and students of the Department and also integrate with the other systems of the University. (The author is a member of the University steering group deciding on the University’s strategy for management information systems over a period of ten years.) The departmental information system will take some years to develop. There are several possible components. including:

I. An admissiwzs suhsy.stem to handle enquiries, arrange visits of prospective students to the Department, arrange the supply of handbooks. etc.

2. A Iecturc~rl.stlidrnticollrse ,suh.system providing class lists, syllabi, reading lists, tutor names, etc.

DAVISON. I>.F. ,\NL) ,,I Il(it.KAI.L). <i. (1988). 3. A tim&hlir~g .suhsystem which helps the drawing of timetables as

Itzformarion systems clevdopmcw~: M&o- well as answering timetable queries and printing timetables in a dologie.s. fechnicrucs NIZ~ roolv. Oxford: standard format. Blac‘kwell Scieatjfic. ‘AVISON, D. F, (1985). I~ljornzurior7 .\)‘.Y/WL~

4. A careerslir~cl~~.strirl placement .suhsy.stem providing records, lists,

drwlopn~et~r: A dutu husc uppr~uch. standard letters, and helping staff to keep up to date with our pp. 206222. Oxford: Blackwell Scientific. graduates’ progress. etc.

42

D.E. AVISON

An examinations subsystem to plan timetables and keep track of the writing, typing and checking processes, arrange Boards of Examin- ers’ meetings, etc. A library subsystem to list the contents of the Departmental library, keep track of borrowings and liaise with the University library. A research subsystem to detail calls for papers, conferences attended, papers published, etc. An electronic notice board and departmental diary subsystem to hold details of our meetings, including the seminar programme, staff meetings, committee meetings, etc. An equipment subsystem to detail equipment, owners, serial num- bers, maintenance details, etc. A computer registering subsystem for registering computer users and handling requests for paper, disk space, etc., and deleting students details when students leave a course. An accounting subsystem to detail the financial incomings and outgoings of the department,

5.

6.

7.

8.

9.

10.

11.

amongst many others. The overall system is to produce standard reports for regular output, provide statistical analyses, and handle ad-hoc queries.

This paper does not detail the project work itself, apart from giving some examples, but rather discusses some of the issues involved.

In developing the departmental information system, the cooperation of colleagues was and still is required, and the prospective carrot of an information system to help administrative work, although neither guaranteed nor short-term, proved tempting to academic and non- academic staff alike (or perhaps they are simply a very helpful group of people). Colleagues agreed to help both the academic staff leading the project and the students requiring advice when investigating the application area. Such cooperation was agreed informally, through discussions, and formally, in a departmental staff meeting.

This promise of help has been fulfilled and I am grateful to my colleagues. (One colleague even ‘played’ a non-helpful role - some- thing that was not agreed with me beforehand, but happened ‘naturally’ - and this proved useful to students who could experience and react to this situation.) In general, those colleagues teaching information systems and other teachers of computer science, administrative staff, technicians, indeed all my colleagues, have proved willing to be interviewed, participate in the prototype development, use the prototypes, comment on the design, attend formal presentations, and help in the assessment proces.

In the first intake, thirty students came to the introductory lecture for the option. Six students decided to take the course. The warnings of hard work and many difficulties reduced their number. The present intake is fifteen, divided into three groups, each investigating different areas within the overall project. They do meet frequently to ensure that their efforts integrate successfully. Indications are that the next intake will require five groups, as the course has gained popularity. The initial small number proved a help, as the students were highly motivated and they have provided a sound basis for future years.

43


University 0 0 0

0 Dept Head Mtgs

0 0 0

Room allocation service

4

f Bookshop

Careers advisory / service

+--I - A i’ External companies I

Accreditation bodies

Prospective c--) students

Faculty of Engineering

’ \ \o*]o

1’ I

0 0 Ob Deoartment of comnrrter .wience 1 -N\\ \ -. ----.r---. _ _ _ _ _

and mathematics

Skior H

\

0000 Computer registration

\

- tutor \

\ .Technical

I- officers

z Y22tarial / El 0 staff 0 0

Admissions

C.E.E.

k Geology

w department

T

Telecoms department \ . . . 53 . . . * -

---C Clerical /f and

financial

University registry

UCCA - Prospective ! f

students *-Lnance contractors

Figure 1

44

D.E. AVISON

Interview transcript 4: timetabling offker

Timetabling Officer - C. Hunt

Operation

The Timetabling Officer is responsible for arranging the timetable scheduling and room allocation for all courses run within the department. This involves liaising not only with departmental staff, but also with other departments (e.g., Combined Honours), external lecturers and the university’s room allocation service.

Many people within the department need to know timetabling information in one form or another. Students and lecturers need to know when and where a lecture is taking place, lecturers will want to know who is attending, Students may want to be able to find a certain lecturer at a particular time etc. Non-academic staff and secretaries may also have need of such information. Many aspects and details of timetabling information were discussed during this meeting - what data should be stored, what information should be available and to whom, how that information should be presented, etc. It would not be possible to give a full account of the meeting in this short transcript, but all the information obtained has proved useful and has been discussed by the project group and is reflected in the information requirements list shown below.

Information requirements

The structure of the timetabling information required on the DIS is quite complex and only a simple list of those requirements is given here. To better appreciate the complexity of the data the reader should also consult the revised DIS data model.

Timetable slot number Day Time Term number Course code Module code Lecturer ID code Room number Capacity of room Facilities, e.g., overhead projector, flipchart, etc.

NB. The DIS will have to provide several different reports in order to satisfy the timetabling requirements, and details of these will be given at a later stage.

Figure 2. Interview transcript

45


Figure 3

This first group adopted the following methodology:

1. Develop an overview of the organization - of the department and the university. The rich picture, shown as Figure 1, provides part of this overview.

3 _. Analyse the information requirements of each member of staff in the department. Figure 2 is an interview transcript from a first

meeting with the timetabling officer and this gives an overview of his information requirements.

3. Consolidate all the information required and draw a detailed data model (Figure 3 shows part of this model).

4. Produce an initial report and present this formally to staff and students.

5. Produce a model of a proposed subsystem. 6. Develop and implement a prototype system. Figure 4 shows two

menus from one prototype. 7. Demonstrate the final prototype. 8. Produce final documentation.

The cooperation of members of academic and non-academic staff in the department proved crucial. Stage 1 was mainly achieved by interviewing members of staff. At stage 4, a presentation of the department’s information model along with discussion of the prospective prototype was followed by an open question-and-answer session. Stage 7 furthered this involvement, through a demonstration and, following this, the use of the prototype. Throughout the project, users have tried, commented

46

D.E. AVISON

Figure 4

on and suggested changes to the prototype. Both the formal presentations were attended by a large proportion of staff as well as many students who were not taking the course. They provided valuable feedback to the project teams. Further, the demonstration of the prototype system proved to be of interest to members of other departments within the University.

There have been a number of small prototypes, on a wide range of hardware, using a number of application packages. The most successful prototype is implemented on an Apple Macintosh Network using 0mnis3 Plus as the main tool. Omnis3 is a database package which makes full use of the window-icon-mouse-pull down menu (WIMP) interface of the Macintosh. The Macintosh network is widely available to staff and students and the ‘friendly’ interface is well liked. However, although Omnis on the Macintosh proves a good environment to develop a prototype, the size and complexity of the application cannot be handled on a microcomputer system. For example, Omnis imposes a limit of 25 files for an operational database, and the actual system must support over sixty integrated files.

The system is now being implemented on VAX hardware using the DM system. DM is a fourth-generation system which has a database and data dictionary. Although it does provide the necessary facilities, DM has proved a more difficult system to use. This is likely to remain the major implementation, but other tools are being used as appropriate to staff requirements. Further, some students are developing a facility for accessing the DM system on their Macintosh using the more ‘friendly’

47


Mac interface. In other words, they are writing routines which will shelter the user from the worst aspects of conventional user interfaces.

Observations

Over the three years of the in-house project, students on the action learning course have gained experience in:

1. Interviewing techniques. 2. Group work and inter-group work. 3. Project control. 4. Presenting seminars. 5. Training users. 6. Report writing and other documentation techniques. 7. Understanding roles, such as that of the database administrator. 8. Using and evaluating contrasting methodologies, techniques and

tools used in information systems work. 9. Producing part of a working information system.

Groups were asked to produce reports contrasting the use of different techniques and automatic aids in given situations. As well as using different application packages, such as Jazz, Omnis, and Open Access, they used more general tools. such as application generators and documentation tools (including those that help draw data flow diagrams and ‘normalize’ datasets), and also tools designed to support particular information systems development methodologies. Some groups followed different methodologies. This might have been forced on them. Some of my colleagues were more willing than others to give up significant amounts of their time ‘participating’ in the development of the system.

All this enables an understanding of what to look for in exercising choice. In assessing work, analysis based on these comparative studies is rewarded as much as ‘results’. Mistakes are not rewarded, but marks are awarded to those students who recognize their mistakes in retrospect and suggest better alternatives. These are important learning experiences which can be catered for in this action learning project, but might lead to problems when action learning techniques are used to develop a project for an outside organization. In these circumstances, the ‘pro- duct’ might become much more important than the ‘learning experience’.

As each group takes over the project, they learn from previous efforts. It may be argued that this is not as valuable as a ‘green field’ project, but there are many subsystems which have not been looked at yet, and, in any case, few project teams in the ‘real world’ tackle a completely virgin area. Learning from other groups can expose other groups ‘positively’ (for example, part of a previous project can be used as a basis for further development work) or ‘negatively’ (for example, one previous project report did not give data dictionary details of all data items, and this required systems investigation work to be repe- ated).

Students are also able to look at some of the wider implications of information systems work, such as the effect of the law (for example, the Data Protection Act) and the ways people react (for example, to requests for cooperation, to different interviewing methods, and to change in general). Students made recommendations for the depart-

48

D.E. AVISON

mental information system concerning the roles of the database administrator (DBA) and security levels for the DBA, academic staff, non-academic staff, research students and students taking courses.

The project would seem to be appropriate to systems project, module 3.4, in the information systems curriculum.” It follows the recommenda-

tions for a:

1. Single large project. 2. Single application area. 3. Practical analysis and design work. 4. Design of systems rather than programming.

Although the emphasis is on systems rather than programming, the use of software tools is considered important in our project. One area of difference, although this does not appear to be ruled out in the information systems curriculum, is the emphasis we place on group work.

This work would also seem to be similar in many ways to that of the Information Systems team at the University of East Anglia,’ although all groups there would appear to be following one methodology (multiview’). The area of information systems is a varied and rich area, with many alternatives in systems development, and it is a goal for us to make students more aware of this richness and to enable them to exercise choice. A second difference lies in the emphasis placed at East Anglia on working for an outside organization. The information systems curriculum’ suggests that the ‘live’ assignment could be carried out at the teaching institution as well as a local firm, public authority, etc. Having experienced similar work at a number of organizations, the author would argue that the arrangement of working within the teaching institution is more satisfactory from many points of view, including control, continuity, and the ability to emphasize academic requirements rather than business needs. Further, whereas a computer science or business department at a polytechnic or university is likely to have a range of databases, fourth-generation languages, project management tools, etc., outside organizations are likely to standardize on one of each.

Supervision consists in the main of guidance and ‘availability’ when difficulties are experienced. It has not been considered my role to interfere. The groups have to think for themselves and as a result get valuable experience from the project.

The same difficulties found in assessing individual work in group case studies are experienced when attempting to assess contributions to an action learning project. Assessment is important - there is no examina-

4 BUCKINGHAM, R.A., HIRSCHHEIM, R.A..

tion. Other course-units are assessed through examination. The Board

LAND, F.F. AND TULLY, C.J. (1987). /n- of Examiners require detailed justification of the marks given. Group formation Svstems Educution: Recom- members are asked to include in their reoort a breakdown of the work. ‘mendations hd Implementution. pp. 119-

1

122. Cambridge: CUP. along with the names of contributors to each part. Further, tutors meet

SWOOD-HARPER, A.‘,. AND I-LINN, I1.J. the groups for two sessions each week, more than that for a convention-

(1983). Action learning for teaching in- al project (it is timetabled for three hours per week) and therefore we formation systems. Computer Journal. 26. p. 1.

are possibly better able to assess contributions of group members than

‘WOOD-HARPER, A.T., ANTILL, L. AND A”,- in a conventional case study which forms only a part of a course. A

SON. D.F.. (198%. Information svstems de- proportion of marks is also allocated for the nresentations to staff in the finition: Tie mthvikv approach. Oxford: Blackwell Scientific.

department who have taken an interest in the project. Another differ- 7

BUCKINGHAM, op. cit.. Ref. 4. ence with the information systems curriculumX is the emphasis on oral ‘Ibid. presentation as well as written presentation.

49


Students who have taken over the project from previous years have detected flaws in previous efforts which were not detected by the author when assessing the work. The course, therefore, could be said to provide useful action learning for information systems teachers! These flaws might concern analysis and design errors, and weaknesses in the documentation. These problems are likely to be found in the ‘real world’. Further, by using packages in realistic settings (that is, in a real problem situation rather than in a limited application, case study, or through following a disc tutorial), students arc able to see the limitations of a package, such as the maximum number of files permitted in a microcomputer database system and other ‘quirks’ not apparent through study of the manuals. Some of the problems are unexpected, such as the recent difficulties experienced when transferring data in a suitable form between different packages and different computers. According to the manuals, this should have been a simple matter! Students also learn to be more critical of information presented. Commercial ‘relational database systems’, for example, do not neces- sarily have all the characteristics of ‘relational database systems’ as described in textbooks. Further, textbook idealism had to be set against the practicalities of the application. This ‘feel’ for the subject cannot be gained through lecture work, but is invaluable experience for people ready to enter the ‘real world’.

The action learning project has increased the respect that information systems has in this Computer Science Department, because my colleagues are more aware of the relevance of the subject in a computer science curriculum. Further. the information system itself is likely to be of use to staff of the department who want to spend their time teaching and researching, and will therefore appreciate help with their adminis- tration tasks.

A disadvantage of this approach concerns the time required to supervise the students. Students on the course have also pointed out that it requires a disproportionate amount of their time. This is as much to do with their interest and enthusiasm, as with the many problems which occur. However, it is an option chosen by only those students ‘committed’ to information systems, and feedback suggests that it is enjoyed and appreciated by those who opt for the course and is also of

interest to potential employers.

50

Documents

Action learning for information systems teaching