Home
--- Introduction
--- Content Summary
--- Acknowledgements

Context
--- Teaching Philosophy
--- Institutional Context

Course Structure
--- Aims, Objectives, Content
--- Delivery Methods
--- Assessment

Reflection
--- Commenting on Content
--- Use of Voting Handsets
--- Laboratory Examination
--- Written Examination
--- Continuous Assessment
--- Overcoming Blocks

Outcomes
--- New course rationale
--- Personal learning

The principal contact hours between staff and students are through lectures, tutorials and laboratory sessions, and these are glued together with short-answer tutorial questions and a series of fortnightly assignments - significant sized programming tasks.

The learning design lying behind this structure is in summary that students first hear about programming concepts and techniques in lectures. They work on small questions and start exploring a larger programming assignment ready for a tutorial where they can get feedback from a tutor on their progress. They then continue with the programming assignment in their own time before attending a laboratory session where they can get further feedback and assistance from a tutor. They submit the assignment a day after their lab session, and this is typically returned to them a week later with written feedback.

The written message that the students get about how to learn on this course is spread across pages 2-7 of the lecture guides pack

Summary of course structure

The formal contact hours are as follows:

• 48 hours of lectures at 2 hours per week
• 12 hours of tutorials at 1 hour per fortnight
• 20 hours of labs at a 2-hour session per fortnight, interleaved with the tutorials

The course notionally takes 200 learning hours, so students are expected to spend somewhat more than half of their time on private study.

Two lecturers are involved with the course, with me lecturing in the first 12 week semester, and my colleague lecturing in the second half. The students are allocated to a tutorial group with around 10-15 members for both the tutorial and laboratory sessions. These are led by a tutor, who may be an academic member of staff, but is more usually a postgraduate student or a post-doc.

The assignments

Students are expected to complete a significant programming task each fortnight. Examples of these for the first half of the course are given in this Assignments Pack that the students receive. These are submitted at the end of the fortnight and students receive formative feedback on their progress. Details of assessment are given in the next section

The aim in developing these assignments was to connect them to some real world problems, in an attempt to make them interesting to the students. The interest part is laudable, but sometimes this makes the exercises a little more difficult than we would have liked. Examples of problems include working with ISBN numbers, or directing animated figures around a room, or creating animations themselves.

Lectures

Lectures are used to introduce the concepts of the course to the students - both those of the programming language and programming, and those involved in problem solving. The students are not expected to have done any pre-reading before coming to lectures.

As I've discussed earlier in my teaching philosophy, I reluctantly use lectures to teach such a practical discipline. In an attempt to fire some life into them, and more importantly, to get the students working with the concepts as soon as possible, I get the students answering questions with electronic voting handsets. The intention is that the lectures become more of a place for active working, not just listening/note taking.

Students receive a pack of lecture guides. These are a bare minimum set of notes designed to assist the students during the lecture so that they don't have to be frantically writing all the time. They are not, however, a complete record of what is said in the lectures by any means, and students are expected to augment them with additional personal notes.

Tutorials (1)

Tutorials appear twice in this list because they serve a dual role. The first is as an opportunity for the students to work with and/or ask questons about (a) the material currently being covered in lectures and (b) the current assignment. For any given assignment, which runs over a fortnight, the tutorial is in the first week of the fortnight, followed by the laboratory session in the second week. Students are expected to start working on their solutions either away from or with a machine, during the first week.

In order to further engage the students with the concepts under discussion in lectures, the lecture guides pack is interspersed with short answer questions, and I will typically have told students to prepare solutions to particular questions in preparation for the tutorial, in order to assist tutors to structure their sessions.

Laboratories

These two hour sessions take place in the second week of the fortnightly assignment cycle. Students are expected to have made a good start on their solution to the assignment by the start of the lab, so that they are in a position to ask for help if needed from the tutor. After an initial plenary session, where group questions and answers may be handled, the tutor works with each student to find out how they're getting on, offering advice/assistance as necessary.

Students have 24-hours beyond the end of their lab session to complete their assignment and submit it through an automatic collection system. Hence the lab is designed as an opportunity to get help in an on-going programming process which should have started before the lab and for which time is provided to continue it beyond the end of the lab.

Tutorials (2)

The second function of a tutorial is to allow the tutor to give feedback on the submitted work, the week after it was handed in, to the group as a whole. Often, a similar mistake will have been make by many of the group, and so the tutor can design an exercise to get the students looking at this aspect.

Students also receive individual written feedback on their programs.

Textbook

We have found that our style of teaching does not match that of any Ada text book, and so have relaxed our requirement that students buy a textbook. The problem partly arises because there are so many different ways to progam in Ada, so many different styles, that it is unlikely that any particular style will match our own. This is inevitable in a language designed by committee. More thoughts on this later.