One of the 2nd Year Computer Science modules at York is the Software Engineering Project (SEPR). In this module, you work with a team of ~6 randomly allocated peers on a project to simulate an industry environment. Since I’ve had a good amount of industry experience I thought I’d write something about the module and how it simulates industry.
First, let’s talk about SEPR – what is it? The idea is that it simulates your team working within a company to produce a product. Different members of the module leaders act as the ‘customer’, module support team and ‘managers’ (i.e. for if you’re having major problems in your team). The customer gives all the teams a specification document of the product he wants to be produced, and this simulates industry in that the document is vague at points and has gaping holes (where the customer doesn’t know what he wants).
A number of things are been testing in SEPR:
- how you work with a team (i.e. if you’re a team player),
- how you work collaboratively (i.e. are you emailing code or using collaboration tools like Git),
- the structure of your product (i.e. is your product expandable – is it easier to add more classes to enable more features?),
- the quality of your code,
- how you market it (at two stages in the course you are required to take up another teams code and to try and convince other teams to take up your code).
For our year, the project specification was to create an Air Traffic Control game, where planes would come onto the screen, with a route marked as a series of way points. The players job was to prevent collisions. In the revised specification for the final assessment, we were required to implement a multiplayer game mode.
So, how well does this simulate industry? In my opinion, it does a pretty good job. The structure of the SEPR module means that you have a wide variety of personalities that you have to work with, which can of course be difficult at times – some people have only worked in isolated environments in the past, but it works out well and it’s rewarding when you work out how to work together. Specifically with my team, I think it’s fair to say that a couple of members would not be friendly with each other outside of the module, but it didn’t take too long for everyone to learn to work together, and that’s a very valuable skill.
Collaboration tools are of course a big thing in industry – it’s not possible to develop just by sending code by email and on flash drive to people, although up until the SEPR module I’d say a large proportion of students in my course had been surviving that way. A team of 6 is big enough that you need to use these tools, which is great as they’re the same (or very similar) tools as those used in industry.
It’s obvious, but it needs mentioning – in industry you’ve got to write very maintainable code – code that will remain within a product for 10+ years. Since the module is marked on this (and UML diagrams should be provided in the written reports), it represents industry well, although perhaps with less consequences if you do screw up!
The only imperfection in the module that I was aware of was how teams are created and managed. Teams were selected almost entirely randomly by the SEPR module leaders, under the justification that “in industry, you can’t choose who you work with”. That means that each team was made up of people with vastly varying skill levels – some teams had multiple people in them who couldn’t program at-all (which, in my opinion, is not good to say they are passed their first year of study in Computer Science). But – in industry, you do work with people of a similar skill level – that’s why companies have interviews, to ensure that their new employees meet the level of the current employees. And poorer quality companies don’t end up with a random group of 3 geniuses (or at least, they normally don’t), because those 3 people know they could go and get a better-paying job at a better company. So I don’t think this was done well in the SEPR module – teams should have been made up of groups of students of similar ability, so that good students got good marks and vice versa, rather than students of extreme (either poor or great) ability levels having a great influence on the mark of the overall team.
So, to conclude, other than with team selection, I think the SEPR module does a great job of simulating industry – the right things are taken into account (team skills, working collaboratively, and code quality), and the structure of the module in terms of lecturer leadership accurately simulates the various levels of management in a company.
To take a look at and try the three games we created, check out the SEPR section of my projects page.
