The aim of this week is to get a headstart on SDP. Note that the work you put in this week is not meant to be in addition to the total hours for SDP expected through the semester. Rather, it is a chance to put in concentrated work now, without the usual distractions of other courses, so that the work remaining for SDP for the rest of the semester should be manageable, relative to the time needed for your other courses.
Day 1: Opening session
students should attend this event, on Monday 15th January, from 13:30 to 16:00, in G.07 Informatics Forum. There will be:
- Introduction to aims of the course and the resources
- Getting to know your group, mentor and client
Day 2: Kit handout
Day 3: Lectures and workshops
Day 4: Refine ideas and prepare pitch
Day 5: Present your pitch
Each group will present a two minute pitch to the whole class, outlining the system they plan to build. There will be a debriefing from their client.
Note that one approach you might want to adopt for planning the project is Agile programming, in which you define the tasks to be done in the form of 'stories':
Related to a 'use case', an agile user story describes some feature of the desired system from the point of view of the user, in a simple and concise form such as "As robot user, I want to be able to stop and start the robot easily, so that I can override if things are going wrong", or "As the robot, I want to make a predictive update of the position of the user relative to me, so that I can return to them when asked". (Note the general pattern - who is the user, what do they want, and what purpose would that serve?)
If a story is too large, it is an epic, and needs to be broken into smaller stories: a useful story should be clear, feasible to implement, and testable.
- Workload estimation:
A popular approach in Agile is to use the 'planning poker' method; for each story, all meeting participants make an independent estimate of the amount of work involved, using an exponential scale: 1, 2, 4, 8 etc. Note that the scale is relative, it is not meant to map onto hours of work or the like, but rather to allow identification of stories that are too large (and should be broken down) or to determine what looks reasonable to expect people to complete. After the independent scoring you can discuss and come to a consensus on the appropriate workload for each story.
- Deciding what to do next:
In Agile, the work is usually planned in short cycles (e.g. 1-2 weeks) at a meeting attended by the entire team, as it is important that all take ownership of the decisions. The process is then 1) review the list of stories 2) decide on the set that could be tackled in the coming cycle 3) discuss criteria for completion and how it will be verified 4) discuss dependencies between storied and how to handle them 5) discuss whether special skills are needed 6) revise the story list given these considerations then allow team members to select tasks 7) if there is a task that seems necessary but noone wants to do it, consider if there is an alternative or an incentive that can be offered.
Return to the course webpage.
|Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail:
Please contact our webadmin with
any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright ©
The University of Edinburgh