Staff Handbook: 3.2.2 Module Quality Assurance Procedures

Original Approved: 14 Nov 2007
Original Author: P Coxhead
Link to Previous Version: Version 3.0
Relevant University documentation: University Regulations Section 6: Programmes of Study
Guidance on Peer Observation of Teaching Staff
Code of Practice on Taught Programme and Module Assessment
Module Development and Approval Guidance
Annual Programme and Module Review
Relevant School documentation: Notes on XML Module Descriptions
Module Box Contents Form
Module Change Request Form
Teaching Observation
Information Disclosure Form

Version Number Notes on Changes Author(s) Date
2.0 Information Disclosure Form L Ewers February 2009
2.1 New Module Approval Process L Ewers 3 June 2009
2.2 Teaching Observation L Ewers 16 June 2009
3.0 University legislation, module link page, module changes, Annual Review L Ewers 25 September 2009
4.0 Annual Review L Ewers Sept/Oct 2010

Contents

1. Definitions

University Legislation is the definitive source of this information. The latest regulations apply to all students, regardless of their year of study.

Programme

A 'programme of study' (also called 'degree programme' or just 'programme') is roughly all that a student must complete to the satisfaction of the Board of Examiners in order to obtain a degree.

Module

The University's Code of Practice on Taught Programme and Module Assessment defines a module as:

"[...] a coherent and identifiable unit of learning and teaching with defined learning outcomes. A module is passed if its specified learning outcomes have been achieved. The assessment of each module shall be designed so as to assess the achievement of the learning outcomes of the module. The assessment of each module shall generate a single mark between 0 and 100. A number of different assessments may be combined within a module to generate the single mark."

See below for Linked modules.

Course

The term 'course' is used ambiguously in some of the University's older documentation for either programme or module. Please avoid it when writing documentation.

Credits

The standard building block at Birmingham is 10 credits; all modules must be multiples of this figure. 10 credits corresponds to a notional 100 hours of study time, which includes contact hours, time spent on assessed work, private study, revision and sitting examinations. A standard full-time undergraduate programme has 120 credits in each academic year.

Level

A level roughly corresponds to a year in a degree programme.

C (1) Certificate Certificates of Higher Education
I (2) Intermediate Foundation degrees, ordinary (Bachelors) degrees, Diplomas of Higher Education and other higher diplomas
H (3) Honours Bachelors degrees with Honours, Graduate Certificates and Graduate Diplomas
M Masters Masters degrees, including MEng and MSci, Postgraduate Certificates and Postgraduate Diplomas
D Doctoral Doctorates

Levels C to H (1-3) are the three taught years of an undergraduate Bachelor's degree. (A year abroad or in industry can be taken between Levels I and H.) An undergraduate Master's degree (e.g. MEng, MSci) has in addition Level M. Modules in a taught postgraduate Master's degree (e.g. MSc) are also designated as Level M, although the regulations applying to undergraduate Masters and postgraduate Masters programmes are different. See also Stage below.

Stage

All undergraduate degree programmes have three Stages. Each Stage must be completed satisfactorily in order for a student to progress to the next Stage. For an undergraduate Bachelor's degree, the Stages correspond one-to-one with Levels. For an undergraduate Master's degree, Stage 3 consists of 240 credits, taken over two academic years. Gaining credits and progressing takes place at the end of each Stage, NOT each Level.

Prerequisite

A prerequisite of a module is another module in which credit must be gained before a student can enrol on the module. It follows that a prerequisite must be in an earlier Stage since credit can only be gained at the end of a Stage. Students who enrol on a module must have gained credit in all of that module's prerequisites.

Corequisite

A corequisite of a module is another module which must be taken in the same Stage as the module. Thus students who enrol on a module must enrol on all of that module's corequisites.

Note carefully that a module in the same Stage can only be corequisite, not a prerequisite. Thus a module taken in Semester 1 can only be a corequisite of a following Semester 2 module, not a prerequisite. (In an MEng programme, a Level 3 module can similarly only be a corequisite for a Level 4 module, since Levels 3 and 4 form a single stage.)

Linked modules (see below) are corequisites for each other.

Linked Modules

Two modules may be linked. Each module has a separate Module Description and Module Code. Each linked module has the other as a corequisite. They may either have separate or shared assessments, but in either case gaining credit will depend only on a SINGLE combined mark for both modules. The School no longer uses linked modules.

Module Code (Banner Code)

Module Codes are often called Banner Codes ('Banner' from the supplier of the database system used). Every module is given a UNIQUE 5 digit number by the Curriculum Development Unit in Academic Services. The five digit number is preceded by a two digit code representing the subject area (06 for Computer Science). Since the remaining digits are unique, the subject area can often be omitted. An example of a Module Code in the 'official' format is 06 12345, although it is often written with a hyphen, i.e. 06-12345.

2. Module Documentation

Quick links:

  1. To change/create module documentation, see MDs-XML-Notes.
  2. A template for the XML module description can be downloaded from /resources/modules/template.xml

2.0 XML Source File

Module documentation within the School is currently based on an XML source file which is then used to generate two web pages: a Syllabus Page and a Module Description (see next sections).

A new XML file (and hence a new Syllabus Page and Module Description) will be created for each academic year (which for these purposes can be taken to begin on 1 August).

A link to the XML source file appears at the very bottom of each of the generated web pages. The XML file for a module with Module Code 06-12345 for the academic year 20YY/ZZ will be found at http://www.cs.bham.ac.uk/resources/modules/20YY/xml/12345.xml, i.e./bham/htdocs/www/resources/modules/20YY/xml/12345.xml.

To change the XML source file (and thus ultimately the generated web pages) follow the instructions at MDs-XML-Notes.

Do not simply edit the XML file in situ. Your changes will simply be over-written later. Look at the bottom of the corresponding web page, where you will find a link to the maintainer. Send this person an edited copy of the XML page; he or she will then generate the required web pages.

To create a new XML source file, download a copy of the template found at /bham/htdocs/www/resources/modules/template.xml. Then follow the instructions at MDs-XML-Notes. (Further information is needed for a new module -- see the Section on New Modules.)

2.1 Syllabus Page

The Syllabus Page for a module is basically an HTML version of the XML source file, augmented with some extra notes (e.g. highlighting recent changes).

The Syllabus Page for a module with Module Code 06-12345 for the academic year 20YY/ZZ is kept at http://www.cs.bham.ac.uk/resources/modules/20YY/12345.html. Alternatively, or if no Module Code has been assigned, use the Module Catalogue to find the web page.

To change or create a Syllabus Page, follow the instructions above to change or create the XML source file.

See below for some further information on components of the Syllabus Page.

2.2 Module Description

Each module has an officially approved Module Description. New or changed Module Descriptions need to be approved by the School's Teaching Committee and are then forwarded to the College Learning & Teaching Committee for approval. The form will then be submitted to the Curriculum Development Unit (CDU) which is part of Academic Services. The School tries to be as flexible as possible in the approvals process.

  • Ideally changes for the following academic year should be submitted to the Teaching Committee meeting in March of the current academic year.
  • Changes not likely to be contentious can be made by Chair's action, possibly following e-mail discussion, up to the time when students choose modules for the following academic year (usually around Week 7 of Term 3).
  • After this point, changes, particularly those affecting assessment, require the consent of the students involved. In particular any changes after the start of teaching will only be made where no student objects.

The officially approved Module Description is based on a subset of the information in the XML source file (see above). Hence the Module Description is generated from the same XML file as the Syllabus Page. MDs-XML-Notes makes clear which parts of the XML are used in both the Syllabus Page and the Module Description, and which are in the Syllabus Page alone.

A version of the module description will appear as part of the web site maintained by Academic Services. Module documentation is the responsibility of the Curriculum Development Unit. Module descriptions can be accessed via the 'Module Search' link on the Programmes and Modules website. Unfortunately the School has experienced considerable difficulty in trying to ensure that the information on this web site is up-to-date with the School's own.

The School's local copy for a module with Module Code 06-12345 for the academic year 20YY/ZZ will be kept at http://www.cs.bham.ac.uk/resources/modules/20YY/mds/md-12345.html. Alternatively, or if no Module Code has been assigned, use the Module Catalogue to find the web page.

To change or create a Syllabus Page, follow the instructions above to change or create the XML source file.

Module Descriptions should be 'high level' and should ideally be written so that they do not need regular changes. More detailed information should be kept in the Syllabus.

An important part of a Module Description is the list of Learning Outcomes (LOs). These should follow on from a standard introduction, "On completion of this module the student should be able to:". Note that LOs don't say what students 'will' be able to do but only what they 'should' be able to do.

  • LOs should be grammatically and semantically consistent with the introduction. Normally they will start with a verb, e.g. "write simple programs in Java". Note that "know" is not grammatically acceptable! You could use a phrase such as "demonstrate a knowledge of" instead, but in general, 'mental capacity' verbs (know, understand, experience, be aware of, etc.) are best avoided.
  • The target audience includes the learners, so LOs should be written in learner-comprehensible language.
  • LOs should be capable of being assessed.
  • The suggested number of LOs is (3-)5-8(-10). Over-detailed LOs should be avoided.
  • The University's position is that a bare pass in a module represents 'threshold' attainment of the module's LOs . Merely attaining the LOs definitely does NOT represent what is required for a first-class performance. Learners need to be clear that although meeting all the LOs will guarantee a pass, it will not guarantee a high mark.

Each LOs must be accompanied by a statement of how it is assessed, i.e. whether by examination, coursework, project work, etc.

Programmes also have Outcomes.

3. New Modules

Proposals for new modules or for major changes to modules should be in the form of:

  • A proposed Module Description, created as described above.
  • A supporting case for the new or changed module. This might include a more detailed Syllabus but this is not essential at this stage.

These documents should be submitted to the Head of Academic Programmes for processing.

The new module has first to be endorsed by the School's Teaching Committee. The overall effect on degree programmes must be fully considered, and this is particularly important for core modules (in any of our degree programmes). The module will then be submitted to the College Learning and Teaching Committee for approval. Once approval has been granted, the new module is reported to the Curriculum Development Unit in Academic Services for the allocation of a Module Code. The detailed Syllabus should then be completed.

This process takes some time and ideally new module proposals should be made early in the Semester 2 of the preceding year. It is appreciated that this is sometimes not compatible with providing the best and most up-to-date module, particularly for modules given by newly-appointed staff or for modules on topics involving very recent technological advances. If circumstances dictate, late proposals (at any time of the year) will be considered. Nevertheless, proposals for new modules should always aim to meet these lead times if possible.

4. Module Preparation

In preparation for the next academic year any necessary changes should be made to the XML module documentation file, consulting MDs-XML-Notes. Note that there will be a new XML file for each academic year. Ideally any changes which would affect the Module Description should be completed by the end of February in the preceding academic year to allow time for the changes to be approved by the College and passed to Academic Services, and for their web site to be updated.

Normally all Module Descriptions and Syllabus pages for the next academic year should be available four weeks before the end of the third term of the current year. This is so that accurate information is available to students well in advance of the start of the academic year. This is particularly important for all second and third year modules as these students are expected to choose their modules at the end of the previous year.

Any changes to the computing facilities required for a module should be discussed with the Director of Computing Facilities at the earliest opportunity.

5. Changes During Delivery

Information which is in the Syllabus Page but not in the Module Description can be changed by the module lecturer at any time (by the process described in MDs-XML-Notes). Students should be informed.

Sometimes circumstances arise during the course of delivery of a module that demand changes from the already approved and published Module Description. If there are sound reasons for doing so, lecturers have the authority to make such changes. Teaching Committee approval should be sought as soon as possible. Changes should be made only if the reasons are compelling and only if all students taking the module can be given adequate notice. It is particularly important that changes are not made to the published assessment methods and deadlines unless sufficient notice can be given to all students.

Wherever appropriate, students should be consulted before changes are made during delivery of a module. Changes should not be made if any students object strongly.

Students must be informed of changes (or proposed changes) to Module Descriptions by ALL of the following:

6. Teaching Observation

School Policy is that each taught module will be observed every other year by the Module Reviewer. To ensure this, modules will be observed only in even calendar years. Thus Semester 1 modules will be observed in the academic years 2002/03, 2004/05, 2006/07, etc. and Semester 2 modules in the academic years 2003/04, 2005/06, 2007/08, etc.

In addition to this process, the School's Head of Quality Assurance & Enhancement also initiates extra observations for new staff and any other staff who would otherwise not be observed at least once every two years. Further observations take place for probationary staff and those taking the PGCert in Learning and Teaching in HE.

The procedure for observing teaching and a report form are available online.

Reports of teaching observations will be reviewed by the Chair of QAE Committee, and any relevant matters (good practice, problems identified, etc.) reported to teaching staff and QAE Committee as appropriate.

7. Module Questionnaires

Students on each module are asked to complete, anonymously, a standard questionnaire twice in each semester.

  • The primary purpose is for module quality assurance and enhancement, i.e. to enable the School, and particularly the Quality Assurance & Enhancement Committee (QAEC), to monitor the quality of module delivery. The questionnaires are not part of staff appraisal or any other system for staff evaluation and may not be used for this purpose without the consent of the member of staff concerned.
  • A secondary purpose is assist students in making informed choices of optional modules.
  • The School operates on a general principle of maximum openness of information within regulatory and legal constraints. This principle will be applied to the dissemination of the results of the module questionnaires.
  • Teaching Staff are invited to complete an Information Disclosure Form to give consent that, for the modules they teach, the Module Questionnaire results can be made available on the School of Computer Science website, to be viewable only by staff and students of the School

After completion, the questionnaires will be analysed and the results displayed on the web in the following format:

  • individual module analyses will be made accessible to staff and students, with staff names removed to emphasize the focus on module quality assurance and enhancement
  • comparative tables will be made accessible to staff only, with staff names removed

In addition:

  • all members of QAEC, whether members of teaching staff or not, will be given access to the comparative tables
  • where concerns about individual modules are identified by the Academic Management Team or by QAEC, members of the Academic Management Team will be able to obtain any necessary identification in order to discuss issues with the staff involved in module teaching

8. The Module Box

Note: This section is out of date and will be revised.

The Module Box is a file currently kept in the room opposite the School Office. All documentation relating to a module must be placed in the Module Box. The Module Box Contents list specifies what should be included. Some items are:

Modules whose content and delivery are essentially the same but which, for administrative reasons, have different Module Descriptions, Module Codes, etc. will be allocated a single Module Box.

The Module Box is confidential. It may be looked at by academic staff in the School, but is not open to students or people outside the School other than during university or external audit or review.

9. Annual Review

Annual Review is a process that consists of several stages. There are currently different timetables for Undergraduate (UG) and Postgraduate Taught (PGT) Annual Review.

  1. Module leaders complete the annual module review form in June each year. A form has to be completed for each module that has been offered in the academic year. The forms will be distributed by the QA Secretary. They should be completed using a word processor and submitted electronically. Inputs are:
    • student numbers
    • module performance (scatter plots and BOXI reports)
    • student feedback (module questionnaires and other methods of student input)
    • external examiner feedback (at this stage, mainly oral feedback given at the Exam Board meetings)
    • general reflections by the module leader on the module's performance and any planned changes or enhancements
  2. Programme directors complete the annual programme review form. This is done in October for UG Annual Review and December for PGT Annual Review. The programme groupings are as follows:
    1. Single honours programmes: BSc Computer Science, BEng/MEng Computer Science and Software Engineering, BSc Artificial Intelligence and Computer Science, BSc in Computer Science with Study Abroad. To be completed by the Director of Undergraduate Studies.
    2. Joint honours programmes: Computer Science Major in the Natural Sciences Degree, Computer Studies in the BA Joint Honours, BSc in Maths & Computer Science, BSc in Pure Maths & Computer Science MSci in Maths & Computer Science, MSci in Pure Maths & Computer Science BEng in Electronic and Software Engineering, MEng in Electronic and Software Engineering, BSc Computer Science with Business Management. To be completed by the Director of Undergraduate Studies.
    3. The Intercalated Year in Computer Science. To be completed by the Programme Director.
    4. All PGT programmes: MSc in Computer Science, MSc in Internet Software Systems, MSc in Computer Security, MSc in Intelligent Systems Engineering, MSc in Natural Computation, MSc in Advanced Computer Science. To be completed by the Director of Postgraduate Studies.
  3. The Head of School or a nominee completes a School summary form. For UG Annual Review, this is done in late October, and for PGT Annual Review in January. The form will be forwarded to the College Director of QAE (with a copy to the Academic Quality Unit).

Further guidance can be found on the Academic Quality Unit website. A sample form can be accessed here.

10. Timetables of Actions Required

Note: This section is out of date and will be revised.

10.1 Module Lecturer

  1. TARGET: End of February in the preceding academic year
    Proposals for major changes to modules or new modules should be completed by this time if possible. These have to be approved by Teaching Committee and then passed to Academic Office for central approval before the end of the Spring Term. A 'major change' is one which would require changes to the description, outcomes or assessments sections of the Module Description.
    Any changes needed to the Module Description should be made. Changes should be made as soon as possible because of the lead time in Academic Office. You will need to ask the person who maintains the module web pages (link at the bottom of each page) to create an initial XML source file for next academic year; then you can amend it as described in MDs-XML-Notes.
  2. TARGET: Four weeks before the end of the third term of the preceding academic year
    Changes affecting Module Descriptions should already have been made. Changes affecting Syllabus pages for all second and third year modules should be completed (see MDs-XML-Notes for how to do this -- the XML source files should already have been copied into next year's directory. Second, Third and Fourth Year students need the syllabuses before their Induction Days to enable them to choose their modules for the next academic year. Normally, Syllabuses for First Year and MSc modules should also be completed by this time.
  3. DEADLINE: Three weeks before the start of Term 1 and Term 2
    Module preparation for that term should be completed. The Module Preparation Report must be written and signed by the module lecturer and given to the QA Secretary.
  4. DEADLINE: End of Term 1 and Term 2
    The Module Box for that term's modules should be complete, excluding assessment.
  5. DEADLINE: End of June
    Assessment details should be added to the Module Box. The Module Completion Report must be written and signed by the module lecturer and given to the QA Secretary.
  6. DEADLINE: End of July
    Any response to the comments of the module reviewer should be added to the Module Completion Report by this time. Module Box Documentation should be complete.

10.2 Module Reviewer

  1. DEADLINE: One week before the start of Term 1 and Term 2
    Module preparation review completed. The Module Preparation Report must be completed and signed by the module reviewer and given to the QA Secretary.
  2. DEADLINE: Second Friday in July
    Module Box review completed. Module Completion Report must be completed and signed by the module reviewer and given to the QA Secretary, who will send a copy to the module lecturer.

10.3 QA Secretary

  1. Mid-February
    Remind all module lecturers that any major changes to modules for the next academic year must be submitted to the next Teaching Committee meeting.
  2. Start of Term 3
    Remind the maintainer of module web pages to create new XML source files for module descriptions and syllabuses for the next academic year. Remind lecturers of the need to update these XML files before the Induction Days. Together with the Head of Student Development and Support and the Director of Undergraduate Studies, organise Second and Third Year Induction Days to take place during the second-to-last week of the academic year.
  3. Five weeks before the start of Term 1 and Term 2
    Remind module lecturers of the module preparation deadlines. Give blank Module Preparation Reports to module lecturers.
  4. Three weeks before the start of Term 1 and Term 2
    Pass completed Module Preparation Reports and attached documents to Module Reviewers.
  5. Before the start of Term 1 and Term 2
    Copy Module Preparation Reports and any attached Module Change Request forms to Teaching Committee. Check that outstanding Module Change Requests have been answered. Note any missing reports.
  6. After Teaching Committee Meetings
    Copy relevant decisions to module lecturers.
  7. Three weeks before the end of Term 1 and Term 2
    Remind module lecturers of the deadline for completion of the Module Boxes.
  8. End of Term 1 and Term 2
    Check that module boxes for modules taught in that term are complete, except for assessment materials.
  9. Mid-June
    Add assessment information, where available, to the Module Boxes. Remind module lecturers to add other assessment information they may have. Pass blank Module Completion Reports to module lecturers.
  10. During July
    Forward Module Completion Reports to module reviewers. At the end of the month, check all module boxes and inform the Head of Quality Assurance & Enhancement of the situation.
  11. Over the summer
    Set up next year's module boxes.