Supervisor / student relationship

The IBM mentor will not interfere with the traditional supervisor / student interaction. Students are still responsible for identifying and engaging a suitable supervisor from the Computer Lab (who must be made aware of IBM's involvement from the start), and should continue to look to their supervisors as the main source of advice. The project mentor is expected to maintain a removed view of the student's progress and offer high-level advice on directions in which to take the work, rather than answers to day-to-day technical questions. This degree of separation will help the mentor to track the project impartially, and to offer constructive criticism from an outsider's perspective when the dissertation is being drawn together. The mentor will provide regular feedback to the student and supervisor on the project's progress as they see it, the open issues and so on, in order to foster open discussion between the three of you. It is important that you involve your mentor when you feel it appropriate, as the mentor has no means otherwise of knowing if you require assistance at any particular time.

Intellectual property ("IP")

As IBM believes is the case for other dissertations at Cambridge University, a student who chooses one of the topics listed below will naturally retain all rights to any IP or collateral material produced as part of the dissertation work. All IBM request is a right of "first refusal" to discuss the possibility of licensing the IP (in whole or in part) from the student, or to consider engaging the student on a consultancy basis, if the project becomes potentially valuable. However, IBM is not guaranteeing to do so, particularly as the topics below are deliberately removed from IBM's current fields of business, in order to prevent overlap.

Confidentiality

No IBM (or third party) confidential information will be passed from the mentor to the student, and IBM asks students to work to the same principle in reverse. If the student - e.g. through interaction with peers or members of the Computer Lab. - comes into contact with confidential information, they must not pass it on to their mentor, directly or indirectly, unless a specific written agreement is put in place beforehand to provide for that communication.

The mentors

Everyone involved on the IBM side is doing this on a voluntary basis. Each mentor is expected to spend up to 1-2 hours a fortnight advising on the project. The mentors all work in a variety of roles within software engineering in IBM's development laboratory at Hursley. Each student will be able to talk the project through with their mentor prior to their formally accepting it, to ensure that they will be able to work effectively with the mentor.

Each of the topics listed below will only be the subject of one dissertation and each mentor will only be responsible for mentoring one student.

Please be aware that neither IBM nor any mentor makes any claim or provides any warranty as to the mentor's expertise in any given area; rather, each mentor's input is expected to be high-level, and removed from the day to day running of the project. The supervisor could be, and ideally should be, more experienced in the specific fields on which each of the topics focus.

Contact

If you choose one of these projects, you will be communicating directly with the mentor, e.g. by phone or e-mail. Each mentor is expected to spend up to around 1-2 hours a fortnight in working with you on your project. If you have any questions about something not specifically to do with one of the given topics, before during or after the project, contact james.brady@uk.ibm.com.

What next?

To apply for one of these projects, send an email to james.brady@uk.ibm.com, containing (a) your name, (b) the title of the project (or projects) in which you're interested, and (c) how you'd like us to contact you; also, if you have any specific questions, then please include those as well at this time - they will be forwarded to the relevant IBM mentors who will get in touch to talk through the project and address any specific concerns you may have.

If you have any questions about IBM's involvement, would like further details on the process or anything not specifically related to one of the topics below, then please send an email to james.brady@uk.ibm.com.

The topics

Most personal organisers, personal and electronic, contain two distinct concepts - to-do items and calendar items. These can be seen as two ends of a spectrum - to-do items typically have a general action to be done and a relative priority. Calendar items, on the other hand, have a specific time when they need to be done, but no associated priority. Most practical tasks fall somewhere between these on the spectrum - perhaps they have to be done on a certain afternoon, or by a certain time, but are not totally fixed to that. Or maybe some clashing calendar entries have a higher priority than others. They are thus more 'hazy'.

1. Determine a generalised system for describing tasks and events anywhere on the spectrum between 'calendar' events and 'to-do' tasks, with a specification of the parameters required for those tasks. Verify that that this system can represent real-world tasks.
2. Develop a computer interface for intuitively creating and maintaining these events for a particular person - in other words, part of a personal organizer. The presentation of the events is probably the key part - how to represent them onscreen in a useful, flexible and interactive way. Consider the possibility of interfacing this system with existing organisation systems.
3. Extend this presentational technique to other domains beyond personal organisation - e.g. organisation of projects, representing historical events or trends, or describing risk and uncertainty.

References

Examples of the existing organisation systems being referring to are:

Laser pointers can currently only be used to produce a single dot on a screen. It should be possible to point a web camera at the projected image and work out where the laser pointer is, then use that information to draw a line. After this basic task, there's a whole host of extensions to work on, such as gesture recognition, shape recognition (so when they circle something, it actually draws a circle, not a wobbly line) and related to that there would also be smoothing of the input (to try and get every line "smoothed out" not just recognisable shapes). Other things to consider would be ambient light, calibration, that type of thing (also how to achieve these things with off the shelf consumer web cams etc.)

Project Goals

1. Implement a system which will track a laser pointer dot on a projected image, and plots its path with a line. This should be done with inexpensive, off the shelf products (i.e. a home web cam). Either using an existing implementation or standard computer vision techniques (it shouldn't be too complicated as you would be able to ignore factors such as lighting conditions for now)
2. Just drawing a line following a point results in quite unstable / wobbly lines. The next challenge is to recognise what shape the user was trying to draw, and replace it with a cleanly drawn shape in the correct position. This will use similar techniques that tablet PCs use to recognise the shapes drawn with pen input. An achievable goal should be to recognise a straight line, a box, and a circle. (shapes typically used by presenters to highlight parts of the screen)

Project Extensions
From this point there are a number of directions the project could take; here are just a few ideas for further work.

1. If this was to be used in a real situation, there would more than likely be some "wise guy" in the audience with their own laser pointer who would try to sabotage the screen. A sensor could be placed in the laser pointer (wired or wireless) which could detect when the presenters laser was active. It would then only track the presenters pointer; ignoring the malicious attempts to deface the presentation.
2. An investigation into the limits of the system. This can include the positioning of the web cam (i.e. can you still make it work, with the web cam positioned at the side of the room, and not directly in-line with the projector...), the accuracy and responsiveness of the system, how fast and automatic can the calibration be completed
3. Fault tolerance of the system; i.e. how it copes with something temporarily blocking the line of sight, changing lighting conditions, jogging of the web cam, and how could be improved?
4. Gestures. These have been around for a while with mouse input, so how easy would it be to detect them, and make them do something useful (like advance a slide etc.)

Software testing is an expensive undertaking which is the first development activity to get squeezed when time gets tight on a project. In order to reduce testing time and cost, techniques such as model-based testing have been pioneered. The ultimate goal of model based testing, as its name suggests, is to generate a set of test cases for a piece of code from a model of the system under test.

Currently lacking from state-of-the-art model based testing solutions is a generic system that can determine how to manipulate objects into desirable or interesting states based on information in the model.

The goal of this project is to produce a simple object model and goal-seeking engine that can use that model to produce the sequence of steps required to create an object and push it into a particular state.

You can model the object in terms of its internal state (fields) and the methods that manipulate or mutate that state. This defines a state space which you can wander by calling methods on the object. The state of the object when constructed defines where you can start in the state space.

1. Design a modelling language that allows you to describe an object, its internal state, its methods and how those methods manipulate the state in terms of pre- and post-execution conditions. Write a library that can parse your modelling language and represent it programmatically.
2. Write a goal seeking engine that can take a model description and a goal to look for; the response should either be a list of operations starting with object construction to manipulate the object into the state described by the goal or an error message saying the goal is impossible - delivered in finite time.
3. Extend your goal seeking engine so that for every goal the engine produces a sequence of operations and tests that operate on the external interface of the object that verify you reached the goal (something that could be asserted in JUnit for example).

1. Model interdependent objects such as the iterator objects returned from Java collections.
2. Try your engine on an object whose methods' effects vary depending on the internal state of the object.
3. Try modelling objects that have external state such as a file system representation or physical memory limits.
4. Model interactions of objects - objects with methods that have other objects as arguments. How can you keep the state space manageable?

As software companies continue to develop products assembled from more and more components, these products become increasingly reliant on multiple prerequisites and corequisites. The dependencies for a software product are determined prior to its release. This can lead to discrepancies between the prerequisite software versions at a historical point in time, reflected on an install CD for example, and the latest software versions available, which might offer fixes to defects detected since release. Often administrators must identify, obtain, and install these levels themselves. The manual process of investigating the latest levels of prerequisite products, and whether they are all compatible, can be time consuming and complex. In the worst case scenario businesses could end up using incompatible versions of software leading to instabilities in their systems.

Businesses need easy access to the prerequisites they require and confidence that the combination of software products installed will work smoothly together.

1. Provide a mechanism to store up-to-date software dependency information online (software dependency repository)
2. Provide an intelligent installer that:
   • automatically queries the software dependency repository
   • can display dependency information from the software dependency repository
   • installs software including the dependencies derived from the up to date contents of the software dependency repository
   • takes can be completed by users with no expert knowledge and with minimum manual intervention

The following would be valuable extensions to the proposed solution

1. Provide the ability for collaborative maintenance of the software dependency repository, perhaps drawing on web 2.0 for ideas, and could include the notion of the product owner verifying that community-supplied dependencies are subsequently tested.
2. Provide an updater that automatically queries the software dependency repository and installs the updates required to bring an existing install to the up to the most up to date levels.
3. Provide a function to verify whether the software currently installed on a machine is actually compatible and highlight to the user any incompatibilities to help avoid instabilities.
4. Provide ability to use latest dependency information to perform automated installs, for example running silent installs using existing packages, and selecting the best and most compatible levels of prerequisites.
5. Use RDF or some other technology to allow richer relations between packages, beyond just "depends on".

There are currently some evolved and powerful applications, such as Avid, Adobe Premiere and Apple FinalCut Pro which have brought video production and programme making away from large, heavily equipped studios into the small non-linear production company/freelancer domain.

However these applications have been "closed" systems and make it difficult where lots of external material is required.

This project will look into the possibility of providing a way to allow people to use the internet to combine all the separate sources - video, audio, titles, graphics and voiceovers - into a collaborative media production. A "merge" facility to allow worldwide participants to submit their content and for this to be assembled into production.

Some or all of:

1. To implement a "merge" system that takes collaborative parts of a production and creates a final programme.
2. To provide checking and verification of all collaborative components - ensuring specified project expectations are met (e.g. all video must be in 16:9 widescreen format)
3. To implement a system that allows "foreign" programme material to be submitted - such as language translations, captions and voiceovers, and these to be used in specific programme creation, e.g. French captions and voiceover used when generating the French final programme.
4. To create dynamic exchange between contributors - the programme being re-created online when material is submitted.
5. To provide "reports" when the programme is assembled to warn about missing or required material. It could also be used in a version-control capacity, so if a name was misspelt, the correction could then be requested from each of the contributors.
6. To allow additional requirements for material and changes to be made to an existing production - during the production an additional caption might be required for a speaker or interviewee, but this is required in all the target languages, so perhaps build a mechanism to make the request for the new material from the collaborators.
7. Different versions can be made available - the programme can be "created" for different markets - French, with French captions and voiceovers, German, Italian - and perhaps constructed slightly differently to suit the stations format, e.g. the length of programme parts between advert breaks.

1. It might be possible to create a "history" and change-management component to this system to allow the program to be modified and then, if rejected by the director, individual collaborative components restored to previous versions.
2. With the advance in personal devices, mobile phones and offline-players, it might be a good idea to look at the implications of making the programmes available in multiple formats, resolutions and aspect ratios.
3. This system might create a market for online-footage, and with this might be "Rights Management" (DRM) and Cost/Charging issues. It would be interesting to include "usage" and "source/ownership" information to allow for a future charging system.