Projects form a substantial and important part of our computer science degree courses.
Final year individual project
In the final year you will work on a major individual project, chosen by you to suit your particular interests, to give you the opportunity to study one aspect of computer science in detail. The work will normally involve the development of a software system. Topics can range from purely theoretical studies to practical work building a system for a third party, although most projects aim to provide a balance between the theoretical and practical aspects of the subject.
The MSci has individual and group projects. The individual project is similar in concept to the third year individual dissertation project that you will have already undertaken as part of your third year of studies. However, the major difference is in the extent of the project and the intended target deliverable. The group project is similar in nature to the second year Software Engineering Group Project but of a greater scope and extent.
Some examples of successful projects
Automated design of WoodBlocX structures
by Niall O'Dwyer and Laurence Herbert
WoodBlocX is a garden landscaping company that produces lego-like structures for the garden. the structures are made from wooden blocks of varying lengths. Customer designs are produced using the computer-aided design software AutoCAD. This then outputs a bill-of-quantities based on the design, which is used by the company warehouse to determine the parts that need to be shipped to each customer. During the design process in AutoCAD a number of extra components may require insertion to give a robust structure. These are:
The addition of these entities was being done entirely manually. This had meant that the designers at WoodBlocX had been subject to a not only time-consuming, but also erroneous design process. In the 2011/2012 academic year, Niall O'Dwyer produced a system that automated the insertion of dowels. In this project, Laurence Herbert has worked alongside Niall to expand this system to provide complete automation.
The end result has been a system that WoodBlocX can use in their daily design work, thereby slashing the time taken to produce customer designs.
Final year projects
The full development of a Drug-Drug interaction algorithm for any drug pair in the Health Improvement Network Database, implemented with Paroxetine and Tamoxifen
by Gemma Louise Ames
Drug-drug interactions are a large cause for concern in the medical world and are an area medics are keen to develop. This project uses computerised tools to perform in-depth statistical analysis of the drubs Paroxetine and Tamoxifen including adverse drug reactions and interactions. This dissertation addresses the issues arising in the medical world of drug interactions and the possible negative side effects they might cause, as well as finding a way to detect these interactions and provide implications for medical advances. A general Drug-Drug interaction detection algorithm using The Health Improvement Network database is defined using Paroxetine and Tamoxifen data for base of development. This research has potential to benefit the real world, particularly patients that are prescribed multiple drugs.
Late Acceptance based selection Hyper-Heuristics for Cross Domain Heuristic Seach
by Warren Jackson
Hyper-heuristics are an iterative heuristic search method used to find a solution which is as-good-as optimal to NP-optimisation problems in a fixed given amount of time. Current hyper-heuristics often make use of complex acceptance criterion such as Simulated Annealing which requires problem specific expertise in controlling the various parameters, such hyper-heuristics however are oftem problem specific yielding good results for problems belonging to a particular problem domain.
Late acceptance is a very simple yet powerful local search method which has only one parameter to control. By creating a late acceptance based selection hyper-heuristic, and utilising the generality provided by the HyFlex Framework, the hope is to be able to create a hyper-heuristic which is both very powerful and general purpose, allowing it to be applied to many different problem domains without alteration or expert knowledge and yielding solutions in line with, or better than, those submitted to the Cross-Domain Heuristic Search Competition (CHeSc 2011). Upon completion of the study, the resulting hyper-heuristics power and generality will be benchmarked in line with, and compared to, the results of the CHeSC 2011 Competition
Interface Detection and Deposit Segmentation of Multidimensional Electrical Resistivity Tomography Images
by William Ward
The main focus of this project was to determine an effective means of identifying the location of bedrock surface using models created using Electrical Resistivity Tomography (ERT). the data available exists in both 2-dimensional (2D) and 3-dimensional (3D) forms and so any method on 2D would have to be extended to 3d data. A number of existing techniques were investigated and implemented, and their effectiveness reviewed.
It was found that a good approach to detection of interfaces, or edges, was to use a clustering approach. Different methods of clustering were tested, and a fuzzy algorithm was adopted. This dealt well with the uncertainty of interface caused by smoothing constraints during inversion. This fuzzy approach was further adapted to include statistical estimates of resistivity population density. This increased the runtime and removed randomness from the methods.
Using both visual and numerical analysis, the algorithms presented perform well on data sets. They are as accurate as some of the leading methods of analysis and require significantly less input. This shows that the investigation presented in this paper offers a viable means of both automatically identifying bedrock surface, but also segmenting individual mineral deposits. The lack of required input also means that the fuzzy clustering approach presented is suitable for accurate analysis by any non-expert operators.
In my past two years I have been able to explore and learn a variety of Computer Science topics which act as a skill base. Third year builds on this with many optional modules allowing for more depth in a particular field. The individual dissertation in third year allows me to demonstrate all the skills I have learnt and is supported by friendly and helpful staff.
Peter Timson, Final Year Computer Science
Second year group projects
In the second year group project, a team of students work to design a complete system to give some experience in the various aspects of software engineering in groups. These include:
- engineering requirements
- system architecture and design
- user interface design
- implementing a medium sized, multi-component system
- systematic testing and debugging
- programming in a team
- use of software engineering tools
Team-working aspects are also central including:
- running meetings
- making collective decisions
- time and people management
- writing reports
- giving presentations
- interpersonal skills
- resolving conflicts
Being a member of a programming group can also be great fun!
Some examples of second year projects
Networked Board and Card Game Emulator—Without Automation
by Mohamed Abdullah, Nathan Bratby and Hein Min Htike
The aim of this project is to develop a program which will allow multiple human players to play board and card games together remotely. It will basically emulate the board(s), cards, dice, counters (to track values) etc., without actually automating things (other than simple standard things like shuffling the cards, rolling the dice, and following simple rules about when to make cards visible to other people). In general, whatever you would do manually in the board/card game you will also do manually in this program — such as dragging pieces around, working out who won a “hand”, working out scores, etc.
A number of standard, customisable and re-usable components should be defined (such as cards, decks of cards, tokens, boards/background images, counters, etc) and people will be able to use these to create their own games, applying their own images.
A key requirement is that it be easy for somebody to implement their own game within this framework without any coding; e.g., by specifying data file contents and providing images to use. It should be tested on a number of different games, such as Whist (cards), Scrabble (board game) and Risk (board game with dice and pieces).
The program will track what has happening in the game (i.e., what positions is each piece at), provide good seamless networking, saving, loading, replay facilities, etc, and provide individual views of a shared playing area (so players can move their view around, zoom in or out, etc.).
by Stephen Cooke, Ryan Fulton, George Hallam, Da Huo, Jonathan Sherry and Michael Tawafig
The “Harmonic Table” is a clever way to arrange musical notes on a hexagonal grid. The clever bit is that the various directions correspond to different musically meaningful intervals. Thus, if this layout is used as the basis for a musical keyboard, many runs and chords become quite easy to play, at least compared with playing on a conventional, “piano-style”, layout. In particular, note how easy it is to play minor and major triads. Moreover, transposition becomes very easy, as playing in a different key is just a matter of playing a piece at a a different position, in stark contrast to playing in different keys on a conventional keyboard that requires significant changes to the fingering.
The fact that the layout is a 2-dimensional grid is also interesting in its own right as it opens up new creative possibilities. For example, what happens if one considers this grid to be a cellular automaton, and arrange to have the automaton play the corresponding notes as it evolves?
A variation on this theme is the reacTogon, a “chain reactive performance arpeggiator”. The reacTogon offers a completely new approach to composing music, or maybe more accurately, creating reactive musical performances. And a very immediate, tactile approach to boot!
While it would be fun to play with a real reacTogon, we unfortunately don't have that kind of hardware. So this project is about doing the next best thing: creating a software emulation. And while we are at it, explore, alter, and extend its features.
This may seem complicated, but, if viewed as a kind of cellular automaton, the basic process that governs the behaviour of the reacTogon is actually quite simple. In fact, fully realizing this is critical to the success of this project. A related but distinct key to success is proper synchronization of musical events. This ultimately boils down to adopting proper data structures such as time-stamped queues of events, either directly, or indirectly through the use of appropriate libraries (like JFuge). (Attempts to synchronise independent concurrent threads are unlikely to yield acceptable results.)
This project can be pursued in one of two basic directions:
- A program for a conventional computer (desktop/laptop), but possibly with an interface that lends itself in principle to interaction via a touch screen. An advantage here is that there there is a wide choice of programming languages and libraries to tap into.
- A program for a mobile device, such as an Android tablet (or possibly phone). Here, the programming environment may be a bit more constrained (meaning that more functionality may have to be programmed from scratch, and that the overall set of features may have to be a bit more basic), but the experience that can be provided through a sophisticated touch screen interface is likely to be more satisfying.
Here are some possible features, beyond a basic re-implementation of a reacTogon:
- Additional counter types and/or more detailed control of counter parameters (note lengths, volume, ...
- Multiple layers controlling different instruments
- Different tempo settings for different layers
- Real-time manipulation of the configuration for reactivity
- Real-time transposition of parts, or muting/unmuting of parts, or switching among patters, to allow a reacTogon to be “ performed”
- Control of performance aspects such as “swing”
- Interfacing to MIDI input devices, again for performance purposes
- Making the reacTogon generating MIDI output
Development of a Greenhouse Appliances Control System
by Adam Gask, Tai Nguyen Bui, Antreas Paschalis, Joshua Rose and Arjun Sharma
Your group is hired to develop new greenhouse (appliances) control system. The goal is to maximise plant growth and plant quality while minimising production/running costs. Currently the greenhouse keeper controls everything manually. In the future the new system is supposed to control heating, water, light, plant feeding, and ventilation.
The software you are going to develop should be easy to maintain and extend. Therefore an object oriented approach to system analysis and design seems to be the right choice. Furthermore, before the software is implemented in the real greenhouse the greenhouse keeper wants it to undergo extensive testing in a virtual environment.
After an initial discussion with the greenhouse keeper you start by putting together a report that will help you to present your ideas and to make sure that you capture all the requirements (the report includes a requirement analysis and the conceptual system design). Then you program the control software (either in Java or C++) and a simple testing environment that allows testing the functionality of your software. The testing environment needs to have a GUI for controlling and visualising the simulation and its results and should provide an estimation of greenhouse running costs for different (varying) weather conditions.