spacer.png, 0 kB
spacer.png, 0 kB
Home arrow Projects
SCORE Projects

This page lists all available projects for the SCORE contest. For each project, a document describes the content of the work to be done, a person in the program committee which will be the contact person for teams developing the project, and possibly some organizational issues concerning the project, such as the expected frequency of interaction between teams and contact person, the maximum number of teams that will be allowed to work on the project, etc.

A few additional remarks applying to all project descriptions:

  • (October 24, 2008) The Global Studio Project (GSP) is no longer available for registration.
  • (August 03, 2008) The two projects "Awareness tool for distributed software teams" and "Design rationale investigation tool" are no more available for subscription. Teams that already registered for these projects are guaranteed full support to continue their participation in SCORE. If some team has been working on one of these projects without registering, it should notify the SCORE PC ( This e-mail address is being protected from spam bots, you need JavaScript enabled to view it ) as soon as possible.
  • Some projects require the use of specific hardware or software. In such cases, the project description details how teams can acquire such hardware or software at little or no cost.
  • The products listed as "deliverables" in the various project descriptions are meant to be submitted in what is called "Final deliverable" in SCORE's Call for Participation. Thus, only teams passing the first round of reviews, based solely on the "summary report", will actually submit these final deliverables to the program committee, although all teams may summarize them in the "summary report".
  • Formal Methods Europe will award a special recognition for the use of formal methods in project developments. Although some project descriptions explicitly encourage the use of formal methods, the award is open to any team that uses formal methods in any of the project.

Registation Procedure

Teams will register by sending an email to This e-mail address is being protected from spam bots, you need JavaScript enabled to view it with subject "SCORE team registration" containing the following information:

  • The title of the chosen project (one from the list below);
  • The list of all team members; for each team member specify:
    • name,
    • email address,
    • institution,
    • undegraduate/master's student;
  • One team member with the role of reference contact person;
  • Optionally, if the project is being performed in conjunction with an academic course, then the name of the course, and the name and email of the course instructor. The course instructor must be made aware that students are participating in SCORE, and the SCORE committee may cc the instructor in certain communications.

Project Titles

Click on a project title to access the documentation for the project. 



Diogene (Digital I/O GENerator Engine)

Abstract:

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

Abstract:

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

Abstract:

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)

This project is no more available, see the remarks on top of this page.

Abstract:

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.
  • Full project description (PDF)
  • GO PLM Grant Application for Teamcenter (PDF, DOC)
    • Note: all teams participating in SCORE can use this form to get a Teamcenter license

Awareness Tool for Distributed Software Team

This project is no more available, see the remarks on top of this page

Abstract:

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

This project is no more available, see the remarks on top of this page

Abstract:

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

Abstract:

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

Abstract:

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.

Last Updated ( Thursday, 06 November 2008 )
 
spacer.png, 0 kB
spacer.png, 0 kB
 
Joomla Template by Joomlashack
download components joomla modules free joomla templates