Lancaster University eLearning Case Study

Home » eLearning Blogs » Lancaster University eLearning Case Study

eLearning Development Case Study:

Lancaster University

John Software Developer

Connect with Managing Director John

About the Client

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.

How Do You Create a PunchOut Catalog?

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

The Solution

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.

Outcomes

  • Emergency support during exams
  • Increasing reliability and performance to handle over 200 simultaneous exam takers
  • Staff feel supported and more confident in using the system
  • The original authors are able to help more effectively by working with other engineers

The Process

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.

Would You like Some Expert Advice?

Contact Us

Connect with Managing Director John

John Software Developer