Having completely overhauled our BSc, we have now delivered a full year of the revised course – and the results are even better than we expected.
In order to achieve these aims, we decided to think beyond the standard Computer Science course structure. We developed a tool that manages Student Observable Behaviours (SOBs). This tool allows us to give students the freedom - within reason - to choose how to do certain challenges, and thereby when to demonstrate what they've learnt.
Most courses in the UK are divided into a number of modules, each of which has its own syllabus and assessment processes. We believe that this module-based system can make it difficult to let the learning process grow naturally.
A typical Computer Science first year contains modules for Architecture, Programming, Fundamentals etc; topics such as graphs, events, or binary representation can occur as important features in any or all of these modules.
If strict separation is imposed, then modules can tend to be overstuffed and repetitive, or there is a danger that topics might be missed. What's more, passing the year tends to require a total mark of 40% across the modules, typically with some minimum threshold in each.
This raises the question: what does a student who has achieved 40% overall actually know? 40% of what?
Our plan was to introduce a sequence of examples, challenges, mini-projects and case studies in the first year. These would all provide an opportunity for multiple topics to be introduced and investigated, and allow our students to demonstrate the acquisition of knowledge and skills. Each of the key CS topics might occur multiple times throughout the year.
Of course, this approach introduces a new challenge: how to manage the learning portfolio of each student. That's why we decided to introduce the tool to manage Student Observable Behaviours (SOBs).
The key course topics are broken down into a collection of SOBs, which can be measured by a member of academic staff in a number of ways, including labs, group sessions, observing presentations, or one-to-one tutorials.
SOBs are tagged as: threshold, typical, or excellent. All essential foundation topics in CS are covered by threshold-level SOBs, and to pass the year a student must have demonstrated all threshold SOBs. This ensures that the 40% problem described above does not arise: students who pass the year have acquired a minimum knowledge of CS across all topics.
The typical-level SOBs might introduce more in-depth or specialist knowledge and skills. Excellent-level SOBs provide an opportunity for students to demonstrate advanced standing through activities such as mini-projects.
Our SOB tool provides a platform for managing students' portfolios, and also has the benefit of generating a number of reports for both the students and the staff. Students can use these reports to measure their performance to date against what is expected and against the rest of the cohort.
Our experience so far is that this real-time reporting is an excellent motivational tool, maximising performance through competition within the cohort.
A screen-shot of the tool showing the current progress of students against threshold-level SOBs appears above, while the typical and excellent levels can be seen below.
The black line shows the expected progress; actual progress is better than expected: most are around the 12-18 threshold-level SOB mark, which is about right.
The fact that quite a few students are ahead of the game is consistent with our experience that our new approach has improved engagement over previous versions of the CS First Year.
Another important change to the Middlesex University Computer Science BSc was the decision to use Racket as our programming technology.
There were various reasons for this, including the support Racket provides in terms of the Dr Racket tool, referential transparency, interaction through REPL, and the ability of Lisp-based languages to have a close association with foundational concepts such as sets, functions and data structures with the minimum of boiler-plate.
The year is organised as a sequence of three blocks, each of which has a different academic team. Every team organises labs and workshops around the SOB framework, and sets a single holistic block challenge.
The first challenge uses an Arduino connected to Racket to build a collection of traffic lights.
The second challenge is to use data structures in Racket to build a simple dungeon game. The third challenge is to build a robot using Racket and a Raspberry Pi.
The block 2 challenge handout can be downloaded here. It uses a series of simple games implemented in Racket: dungeon_rooms.rkt, moving_about.rkt, monsters_attack.rkt, command_language.rkt, items.rkt.
The first cohort completed the newly designed first year in 2013/14. We were delighted with the results: students' engagement was at an all-time high with many students determined to get ahead of the game by demonstrating SOBs as early as possible, and progression to the second year was over 90%.
Although many of the excellent-level SOBs are designed to be very challenging, some students are keen to try them, as shown above. The use of Racket has gone well, although the small number of textbooks for Racket, and the dry nature of the online documentation, is a problem for introductory-level students who want to go further through self-study. However, in practice this appears to be a very minor issue.
The SOB tool is working better than we could have expected. Developed at Middlesex University, the tool isn't tied to Computer Science or any course in particular.
If you're interested in using the SOB-tool, or would like to find out more details about how the CS First Year has been designed and delivered, we'd be happy to chat.
This article was written by Professor Tony Clark, Head of Computer Science at Middlesex University.
