SCORE logo

Student Contest
on Software Engineering

Main Menu

Score 2009 Projects

SCORE 2009 is now complete (and these projects are closed), but they may still be a valuable resource for students and teachers in project-oriented software engineering courses. The project descriptions for the currrent contest, SCORE 2011 are now available on this page.

Diogene (Digital I/O GENerator Engine)

In the field of industrial automation it is common to have quite long periods of system integrations on customer's site, especially due to the difficulty to reproduce the system to be controlled in a laboratory. As a result, not only system test, but also debugging could have to be done on field. In many cases, the quality of a delivered control system and the time spent on testing on customer's site are strongly related to the accuracy and the completeness of system testing done in the software factory. Whenever target system is not available, an effective system test can be done only if a suitable target simulator is available. The system to be designed is a programmable generator of digital signals that can be used to test a control application when final target system is not available, mainly to reproduce expected behaviour of the target, but also with the capability to simulate error cases (e.g. hardware problems or random jitters) that could actually occur when interacting with real target system.

Distributed Decision in a Mobile Context

This is a system through which it is possible to cast votes and obtain voting results in order for decisions to be made among a predefined group of people or systems (through particular interfaces). This is done applying different asynchronous mechanisms and technologies such as SMS for mobile phones, e-mails sent through WiFi, 3g, etc, taking into account the necessary security measures (i.e., a validation and digital signature will be required, etc.). The project should focus on interfaces and algorithms (not on technologies).

BTW: if you go, my advice to you

We ask teams to consider a route-planning system that allows community input. Imagine planning a trip in an unfamiliar city, and having the advice of those who live in the city at your disposal. Once you have a route you think looks reasonable, you can ask to see what others have to say about that route. Perhaps some have positive things to offer: the route is fully wheel-chair accessible; there are plenty of public restrooms along the route; street crossings are all reasonable. Some may have warnings to pass along: certain parts of the route can be dangerous at night; construction along one block forces a detour; a specific crossing has quick-changing signals. As you can see, advice might need to be filtered: the traveller may not want to see all advice about the route being considered, but instead filter that advice to match his or her abilities and preferences. In summary, the system, which we call BTW, is an attempt to move beyond the official GIS information that might be provided by a government or private agency, and allow the travelling public to provide advice.

Personnel Access Control System (PACS)

Global Studio Project (GSP)

Siemens Corporate Research (SCR) has been performing research to decompose large-scale software system requirements into a well-structured set of software components that can be developed in parallel among globally distributed development teams. The processes resulting from this research are being experimentally applied within the Global Studio Project (GSP). This project develops software components for a Siemens product line while applying an experimental global development process using globally distributed student teams located in universities in Europe, Asia, and the Americas.

Awareness Tool for Distributed Software Team

Geographically-distributed software development teams are increasingly common, in both industrial and open-source contexts. Some of the difficulties faced by distributed team members is maintaining awareness of the evolution of the software design and implementation, work items and bugs, and teammates' activities. In collocated work environments this information is often supplied by intentional conversations, peripheral awareness of others' conversations, and opportunistic discussions. The absence of these mechanisms leads to impeded knowledge flow and thus difficulties in coordination. The purpose of this project is to attempt to use technology to partially fill this knowledge flow gap for a distributed team. This might be addressed by a "developer dashboard", an information display that a developer could use to quickly get an idea of the recent changes to the software, work items, coworker activities, etc. The display might take the form of a web page, a dedicated screen, a sidebar gadget, etc. Ideally the most important information would be available at a glance, whereas the developer could investigate deeper into the details by interacting with the system.

Design Rationale Investigation Tool

Software developers working in a team environment must often work with code written by someone else. They approach understanding the rationale behind code by reading the code directly, by examining its execution in the debugger or log files, reading bug reports, by examining the change log for the code. Often these information sources are insufficient, and the developer needs to seek the advice either of the person who wrote the code or someone else on the team who may be familiar with it. Such "rationale investigations" are a difficult, tedious, and error-prone endeavor. The purpose of this project is to build a tool to help developers do rationale investigations. The tool should synthesize as many relevant information sources as possible, including the source code, its comments, the bug/work item database, the source code control system change log, the team's or user's email and IM conversations, specs or design documents, the results of static analysis, the results of execution logs or dynamic analysis, etc. On the other hand the tool must not overwhelm the user, elegantly presenting the information most likely to be helpful but allowing the user to dig for details. Ideally the traces left by these investigations should be saved in a team-accessible repository and themselves become another information source.

A Simple Pacemaker Implementation

Boston Scientific has made available a natural language requirements document for a previous generation pacemaker. This document has become the basis for a Grand Challenge, and is ideal for realistic, safety-critical student projects. Pacemakers operate under a number of "modes" that are fully explained in the requirements document. This particular project will require teams to implement only a few of those modes, namely "VVI", "DDD" and "DDDR".

GPXCleaner: GPS Path Editing and Simplification

There are many commercial and non-commercial systems for displaying GPS paths on a map and/or profile graph. They are typically used by runners and cyclists to record and analyze their excursions. An important and poorly supported function in these systems is reducing a GPS path (typically represented in the open GPX XML format) into a simpler path with fewer points, which is particularly important when producing a "mash-up" application with a service like Google Maps. The user should be able to vary the degree of simplification to balance accuracy with performance. Additional editing functions (clipping to a subset of the path, combining paths, inserting waypoint data) could also be supported.

  • Full project description (PDF)
  • Report on finalist project by Tin Tvrtkovic, Tihomir Bregovic, Josip Labor (students at the University of Zagreb in Croatia), Federico Ciccozzi, Jenny Jutterström, Pablo Santibañez Jara, and Coen Tempelaars (students at Mälardalen University in Sweden)

2009 Winners

SCORE 2009 Vancouver, British Columbia, Canada Part of ICSE 2009

SCORE overall award 2009 Undergraduate award 2009 Formal methods award 2009

Contact webmaster. Based loosely on Transparentia design by Arcsin, from OSWD.org. SCORE logo by LimKis, 2014