« Back to List

Booked [JK03] A call button system for computer lab practicals

Project overview

During busy times in a computer lab practical, it can be difficult for students to find an available TA in a timely manner and for TAs to decide which student to help next. Computer lab practicals differ from other teaching settings, such as lectures and tutorials, in that students and TAs do not maintain visual contact during a session. Indeed, students tend to focus on their screen and keyboard as they complete their lab tasks and TAs tend to focus on an individual student. As the Department has recently grown considerably and it now has very large labs in which practicals are organised, this issue has been exacerbated.

This project aims to produce a software based call button system that allows students with a question to identify themselves and their location, and that directs free TAs to those students. The system is expected to enable or facility meeting the following objectives:

  1. The system must be accessible by all students, irrespective of the equipment that they choose to use or own, and the TAs, who will be moving around in the lab a lot and who are not bound to any one desktop or laptop computer.
  2. The system must instruct TAs to support students using a fair queueing system. What constitutes a fair queueing system is a challenging question that you have to attempt to answer in this project. Different approaches are possible ranging from first come first serve to something far more sophisticated that takes into account a range of variables (e.g. waiting time, question priority, the amount of TA support a student has already received, etc.). Ideally, the system is flexible and enables module organisers to specify the constraints the system should adhere to and objectives it should achieve.
  3. The system must direct TAs to the location of the student they have been allocated. You will need to device an approach that makes it easy for TAs to find a particular student. The system must be flexible enough to be deployable in a range of labs. It must not overburden the administrators who may need to set up the system for the different labs.
  4. The system should give students a reasonable estimate when they are likely to receive a TAs attention.
  5. The system should produce data that informs module organisers of the demand for and supply of TA support.
  6. Some students may obtain a TA's attention in the conventional way. The system should accommodate this. What this means depends on your system's functionality. For example, if your system collects statistics on the TA's work, data on these conversations needs to be collected.

The challenge of this project is to specify, design, build and evaluate a system that meets these objectives. Note that I have kept the objectives quite broad and you are free to choose how you translate these objectives into requirements and specifications. I do not have a particular system in mind. That said, I would urge you not to jump to conclusions and take your time to identify a coherent set of specifications. Note that the objectives are not independent from one another and that sophistication in working on some objectives will make meeting other objectives much harder. For example, the more sophisticated the queueing system (Objective 2), the harder it becomes to estimate waiting times (Objective 4).

It may be possible to evaluate the work in term 2 by using it in an actual lab. However, this would require a prototype system to be produced in time.

Initial background reading suggestions

You may be able to produce a good solution to this problem with limited background reading. Nonetheless, a strong project is able to identify useful existing techniques and adapt them to this project. To develop a sophisticated approach to assign TAs to students, you may wish to familiarise yourself with multi-criteria decision making approaches. If you wish to learn more about how you could calculate expected waiting times for students, queueing theory is a good start.

Who is this project for?

This project is aimed primarily at BSc students who aim to begin a career in industry, ideally in software engineering. It can be tackled by an MSci student, though it is essential that the work engages sufficiently with suitable peer-reviewed literature. Ideally, the student who takes this project is organised, capable of tackling a complex problem in a systematic manner and enjoys substantial development work.

Note that you are not required to have a specific idea for features to incorporate in this project. Instead, I would prefer the student taking this project to take some time carefully analysing the project objectives after they have been allocated the project, rather than rush this crucial activity of the project.

Questions about this project

Q: Can I discuss this project with you in person?

A: Yes, I have arrange a project Q&A session on Thursday 27 September, 18:00%—20:00 in Bush House (SE) 2.12. All students in an undergraduate Computer Science programme doing an individual project this year are welcome. I'm afraid it is not feasible to meet all students with questions on a one-to-one basis this week. I am supervising 11 undergraduate projects this year and usually receive 5-6 meeting requests per project on average (because most students explore a range of different projects). As it is simply not feasible to schedule that many meetings in a single week, a group Q&A session seems to me to be the fairest approach to meet everyone.

Q: Does this project involve any hardware development?

A: No, normally, this project would not involve any hardware development and the solution would be entirely software based. I suspect that a software based solution is more likely to be adopted as that limits the investment required to deploy it.