Module Registration Migration from OMR to SITS Introduction

advertisement
Module Registration
Migration from OMR to SITS
Introduction
This document explains the reasoning behind the migration of the module registration
process from OMR to SITS e:Vision and MRM and discusses the benefits and
challenges of the migration.
Background
OMR is Warwick’s current system for online module registration. It was developed in
2003 and provides students with a means to electronically record their module choices,
and staff with a means to approve them. OMR has a user-interface that works well, but
behind the scenes there are fundamental problems which have become increasingly
hard to address.
By 2009, it became clear that OMR would need to be replaced. A fundamental issue
was that OMR did not sit well with the University’s Student Records system (SITS),
despite the fact that the two systems relied heavily on each other. SITS, supplied by
Tribal, is widely used at Warwick to manage a raft of student processes including
enrolment, student finance, student marks and HESA returns. Since the initial
development of OMR, Tribal had improved their own web-based module registration
offering. Although we considered an in-house redesign of OMR, it became clear that
there would be significant benefits if students could register their modules direct into
Student Records using Tribal’s system.
Benefits of Registering for Modules Direct into Student Records
Some of the advantages of bringing module registration into the existing Student
Records system (SITS e:Vision) are:



Any actions taken in SITS show up immediately in e:Vision module registration,
and vice-versa. Previously data needed to be loaded from SITS to OMR and
back again and it could be nearly 2 working days before changes appeared. This
means students and staff see accurate data more quickly.
Student timetables are now up to date whenever the timetabling office generate
them (usually daily). This means that accurate timetables will generally be
available to students within one day instead of two.
Data problems can now be diagnosed more quickly by administrators, without
having to wait to see if discrepancies (e.g. between route diets and student
choices) are caused by data being out of sync.











Administrators are empowered to manipulate data at all stages of the process
through the SITS client, which means problems can be sorted out more quickly.
The SITS student records system is now being used in a way that is more
consistent with the intention of its designers, so the SITS data is more intuitive to
work with for administrators.
Programs which are used to load data between SITS and OMR take up to 12
hours of intensive processing power on a daily basis and impose an extra burden
on the Student Records servers, competing for resource with other functionality.
Without OMR these can be eliminated.
These load programs are complex and problematic to maintain. If changes are
required, they are difficult to test reliably, imposing unnecessary risk on data
quality.
A separate database needs to be maintained for OMR. Registering direct into
Student Records means this can be eliminated.
OMR relies on third-party software to interface with its database and this has
proved to be unreliable, sometimes throwing up worrying data inconsistencies
which cannot easily be resolved, again imposing risk on the reliability of the
service.
This third-party database software is resource-hungry to support.
e:Vision module registration is already supplied to us and supported by Tribal as
part of our SITS package at no additional cost.
SITS are committed to modifying their product to continue to meet external
requirements, such as requirements for HESA reporting on which the University’s
funding is based. We will be supplied with these, as well as likely improvements
to the product itself, as part of the SITS package.
e:Vision module registration comes with functionality that OMR does not have,
including encoding of course regulations, ability for departments to enter diet
data themselves, the possibility of encoding pre- and co-requisites, module
quotas etc, all of which had been asked for by departments.
e:Vision offers some benefits in the user interface, such as the ability to pick
several modules from the same screen.
Issues for the Migration
As well as the benefits outlined above, there are of course disadvantages. The OMR
user interface is not perfect but most people accept that the quality of design of the
OMR screens is better than the SITS e:Vision equivalents. The e:Vision screens are
less self-explanatory, which is a major issue with such a large student user-base who
only use the system on an occasional basis. To address this, the Academic Office
have provided detailed documentation for students and have worked with IT Services to
improve the screens as much as possible through customisation. This work will
continue following the pilot run in 09/10.
Another issue was that SITS Module Registration did not provide a means of choosing
the assessment method for a module – an essential requirement at Warwick. Tribal
worked with us to create a screen to enable this process. However, this screen is not
working as effectively as it could be and following the pilot run the project team have
identified it as a priority area for improvement.
A key issue has been that of changes to module diet data after module registration is
opened – see Changes to Module Diet Data below.
It would be possible to write a bespoke module registration system which would
combine some of the advantages of OMR and e:Vision. To date it has not been clear
that the issues encountered represent a business case to justify the resource required,
though this is an option that remains open.
Staff Functionality
OMR provides a number of reports for staff which are not provided by SITS. In addition,
there are some Warwick-specific requirements for approvers which are not provided by
SITS, such as the ability to mass approve students and the ability to change
assessment group for everyone on a module.
A bespoke system has therefore been created for staff, called Module Registration
Manager (MRM). With this bespoke system which interacts directly with the Student
Records database, we are able to give staff the views that they need while keeping the
data where it is needed. MRM was designed with maintainability in mind and can
evolve as required.
It was originally planned that MRM would not include functionality to add or change
student modules as staff can amend modules on behalf of a student through SITS
e:Vision. This takes advantage of the SITS functionality which encodes diets and
checks course regulations and other controls. However, during the pilot this proved
cumbersome and time-consuming for staff and functionality to amend module
registrations in MRM was added in March 2010.
Changes to Module Diet Data
When OMR was first written, students were given the module choices that were
encoded in SITS at the time. However, after module registration opened the module
diets continued to change. This lead to a problem – a student could have confirmed
their module choices, but the choices might no longer be valid. To attempt to cope with
this, OMR was altered to re-read module diets every night and revise student choices.
If it makes changes, the student’s confirmation is negated.
There are a number of problems with this. The nightly re-jigging means that “the
system” is tampering with student data and this is not always perceived as a good thing.
Students may think they had confirmed their modules when in fact the confirmation has
been backed out and the choices changed. The extra functionality also added some
complex code to the system that is difficult to maintain and risky to change, since it is
not easy to test and the introduction of a bug could potentially cause wide-scale
problems.
Tribal have provided some mechanisms for changing student data following changes to
module diets but they involve manual intervention and are not designed to cope with
significant data flux. During the pilot, the most significant problems were caused by
data issues with module diets.
e:Vision module registration has been customised by us so that the date it opens can be
set on a per-department basis by the Exams Office. Key to the success of module
registration is ensuring that module choices are accurately encoded prior to opening.
Summary
ITS is committed to providing a module registration system that meets the needs of all
users, including students, departmental staff and central administrators, while enabling
the University to fulfil its statutory obligations. Of primary concern is providing a reliable
service. Bringing module registration into line with the other processes we support is an
essential part of that.
We work closely with the Academic Registrar’s Office who help us balance the many,
sometimes conflicting, requirements. Our work is prioritised by a Service Board on
which both students and staff are represented, and based on business case.
As we go forward with module registration, we will continue to look for ways to improve
it and will continue to evolve it to better serve staff and of course our customers,
Warwick students.
Zoe James, 24 Nov 2009 (updated March 2010)
Download