Lancaster University
Electronic exam system to help them meet the rigorous standards needed for medical student testing.
Lancaster University’s Medical School (“LUMS”) had started using an electronic exam system to help them meet the rigorous standards needed for medical student testing.
At the time, they had 200-300 students, and being a university, they create their own exam questions which need to go through several stages of quality control and editing, and after the exams, the performance of questions is monitored to ensure that the exams are fair and valid.
The system is “Rogō”, created by the University of Nottingham and used by several universities around Europe. After using the system for a while, Lancaster staff were having a few difficulties and needed help in using the system, and Lancaster University’s IT department had nobody who specialised in supporting the system. They needed a software partner to help make changes specific to their needs, to provide emergency support during exams, and to work with Nottingham to keep the system up to date.
To add further difficulty, the school was growing from an intake of 50 students to 150+ per year
We got to know the software, and began to deliver improvements very early on. Over time, we began to collaborate with the original authors, make changes more efficiently and quickly, and contribute those changes back to other users of the software.
During all of this, security and confidentiality are important, so we worked closely with Lancaster University’s IT team to agree and stick to best practices. We also provide emergency support directly to staff during exams, so that any technical issues can be quickly resolved.
Starting with a Wish List
We began with a “wish list” created by LUMS staff, who needed these changes to make it easier to create and deliver exams, and to feed back to the students afterwards.
This software had no formal support, and needed a company not only willing to take on somebody else’s code, but to provide reassurance and support based on that. We began the process of learning about the code, discovering how it worked and how best to maintain it
Collaborating with the Authors
Over time, we got to know the software well, and so we were able to pull in the latest improvements from Nottingham University, and combine them with our own, to create a “Lancaster version” of the system.
We then refined our approach, and began collaborating with Nottingham University very closely to discuss the best way to make changes, and contribute those changes back to the community so that everyone could benefit.
Reducing ongoing Costs
During this time, we had to make a huge shift from “forward porting” to “backward porting”. The “forward porting” means that when a new version of the system is released, we had to take each of our changes, and “re-apply” them to the latest version of the system. That became quite a lot of work, so “backward porting”, where our changes were made on the newest version of the system, and were therefore made to work with the latest version, became a far more cost effective way of keeping our “Lancaster version” up to date.
Improving Efficiency
Our latest improvement to the process is creating “unit tests” for each feature, which is a type of automated test that can be run by the computer, which dramatically reduces the time taken to test each new release of the system.
