Any questions or comments should be emailed to Don Sannella at
|Project proposals due||January||February||February|
|Projects advertised to students||January||February||February|
|Selection made||end Jan||March||March|
|Work starts in earnest||May||September||September|
|Final report submitted||August||early April||early April, 1 year later|
|Duration||5 months||6 months||12 months|
|Elapsed time||8 months||13 months||25 months|
Though the bulk of BSc and MSc project allocations should be finalised in March, a few new BSc projects can sometimes be accommodated in September.
It is the responsibility of supervisor(s) to provide an environment (software, hardware and place of work as necessary) where the student can produce the best work of which he or she is capable. Note: We provide lab space with generic Linux or Windows PCs but can rarely afford specialised hardware or software. Much of our software was purchased under academic software licenses for which commercial application is specifically forbidden.
In the early stages the supervisor will need to inform the student, ensure that he or she understands the project and what skills and action will be needed to make progress, agree a methodology, ensure the project is sound and modify it if not, ensure that necessary resources are available, evaluate the student as far as possible and form an opinion as to whether the student is capable of the work. The student is expected to take the initiative on the project at an early stage so as the project progresses the supervisor's role should settle down to being that of monitor and consultant.
During the term the supervisor will need to meet regularly with the student to ensure progress is being made and address problems promptly if they occur. At points during the project, the supervisor will be invited to attend a presentation by the student in the presence of other staff and students at which the student will receive a critical assessment of the project and his or her progress.
Supervision will require half an hour per week on average for regular meetings, two hours for each of the presentation sessions and possibly a half day to read the final report and partial intermediate drafts.
In most cases where an external partner organisation is involved, joint supervisors (an internal supervisor from Informatics and an external supervisor from the partner organisation) should be identified before the project is proposed. This reduces the travel overhead for students, improves continuity and reduces the risk if, say, business priorities affect supervision from the external partner. It also reduces the workload of external supervisors who can quickly reduce their commitment to being technical consultants once the project is underway. The internal supervisor will ensure that the requirements for the degree are met.
Supervisors need to be willing volunteers - they need to communicate enthusiasm and commitment and be prepared to accept some demands on their time. This is particularly important for external supervisors where the student has several handicaps not present for purely internal projects:
External projects may involve a considerable amount of "tacit" knowledge and supervisors need to think about how the student can learn what is needed to complete the work. "When the student turns up on your doorstep what are you going to tell them to do?"
A good project allows the student to demonstrate the ability to take what they have learned on the course, apply it to a real problem and write up the results. The mark is awarded for the write-up, not the project. The project should contain avenues for contraction or extension, since a) the ability of the student will not be fully known at the outset and b) it is all too easy to specify a project that turns out to be more or less difficult than one expects once it is underway. Once committed the student must be protected against changes in priorities - if staff have to be moved or priorities shift away from where the project is based, supervisors have responsibility to ensure continuity.
Good students are generally steered towards open-ended projects where they can demonstrate that they can grasp a concept and extend it. This does not necessarily rule out bounded projects ("implement an X to do Y", where X and Y are well specified) but if a good student picks up the project they may be encouraged to regard it as an instance of a class of problems and generalise the solution or at least discuss doing so. Projects should contain conceptual problems - students need opportunities to demonstrate their skill.
We cannot guarantee how a particular student will perform in any project - course marks are only a rough guide and marks can only be made available with the agreement of the student. We try to guide weaker students towards less challenging projects but there is an element of pot luck here which has to be accepted.
Intellectual Property in a venture is owned by the people or organisations who supply original ideas. Students are not employees of the University and they are marked in part for original input so ipso facto they will own at least some intellectual property of any creative project they are engaged in. If this is an issue, the external organisation should arrange for the student to sign a waiver prior to committing to the project. It may also be necessary to ask the student to sign a non-disclosure agreement if the student is privy to confidential information. Special restrictions or agreements may apply to sponsored students. The University must be informed of any restrictions being imposed on or agreed with the student and would veto any agreement that imposed employment restrictions on students after graduation. Project reports are in the public domain unless a specific undertaking is agreed to keep them confidential.
Updated by Don Sannella, 19 September 2012. Based on an original version due to John Butler, modified by Helen Pain.
Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: email@example.com
Please contact our webadmin with any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh