(CDT310 Foundations of Software Engineering and CDT311 Game Development - project course)


Project Schedule and Admin



How the projects are graded


Twenty Dirty Tricks


Ada stuff







Game project

Robot project

Mind Map


Symphony of Destruction




Rikard Lindell

Lars Asplund

Terje Engelbertsen

Steering Group

Rikard Land,

Rikard Lindell

Rikard Land,

Yue Lu

Rikard Land,

Yue Lu

Project Manager

Olov Wingren

Niklas Pettersson

Product owner:
Dirk Debertshäuser





Documentation (10)




Project work (10)




Product - Software (10)




Presentations (10)




Sum (max 40 points)



(Result pending)


·         2009-01-09 Post-final presentation info. I have sent my notes from the presentations to the project leaders. You will get more feedback on the project with a motivation for the project grades later... (when the projects are graded ;-)

·         2009-01-08 Schedule for final presentation (but each group can take as much time you need, we will not hurry):

13:15 Mindmap

14:00 SOD

14:45 WeRobot

·         2009-01-05 Final presentation. I hope all of you have had a nice holiday with some days off and not only project work ;-)  On Thursday Jan 8th 13:15 we have the final presentations, we start in R1-302 but will move to the robotics lab at the end for a demo of the robotics project. Will we see Dasher run? ;-) There are lots of hints and instructions further down on this page. Since this is a course, I want to stress the part where you describe what you have learned, both in the presentation and in the report. Be as specific as possible. But of course we want to see your program executing as well! Make as convincing demo as possible – view it as a competition! All documentation should be finished by Monday Jan 12th so that we can start grading.

·         2008-11-25 Schedule for next week’s presentations will be: 8:15 Symphony of Destruction, 8:45 weRobot, 9:15 Web2Map.

·         2008-11-06 Deadline for weekly reports and documents are Mondays 12:00.

·         2008-11-06 Schedule updated. Schedule for steering group meetings and reqs/design presentations updated. See schedule and below for details.

·         2008-11-05 Info about requirements presentation next week. Below there are some guidelines what to present on Tuesday (...or will there be any change in schedule...???)

·         2008-11-03 ...And don’t forget to read news on this page. Otherwise it is useless for me to put any info here. ;-)

·         2008-11-03 More on the topic “Collision in schedule”. It seems to be an unsolvable problem. At least for me. I have spent fairly much time on emails from individual students, and trying to get the info from project leaders who for various reasons did not respond in time. My requirement is that these meetings with all groups can be put (at least almost) consecutive so they don’t split two days for us teachers. I am willing to spend lunch time on this (12-13), either Monday or Tuesday, this would fit two of the groups. Now, to not give me more work on this issue: the project leaders have to collect each group’s collisions, then the project leaders should synchronize and propose a schedule. However, the steering groups (half an hour per week! Only!) and the presentations in class (two hours on two occasions) are mandatory. It is not OK to email the afternoon before simply that you “cannot come”. No absence is allowed. (One exception: Nov 4th for the members in the robot group, because they actually have done their part to solve it.)

·         2008-10-28 Collision in schedule. Many students have emailed me that there is a collision in their schedules. The groups have got the task to internally find hours which would work. Important to understand is that there are both the usual steering group meetings as well as presentations with/for the whole class on three occasions (including the final presentation).

·         2008-10-14 Project groups formed. See Project Schedule and Admin.

·         2008-10-09 Project page created. Here you will find news about the projects.

Steering Group Meetings

At regular week, all but W46 and W49, we start steering group meetings early:

gr1  8.30-9.15

gr3 9.20-10.00

gr2 10.00-10.40

At weeks with presentations, W46 and W49 we start with the presentations presentation 8.15-9.45, and then we have steering group meetings:

gr3 10.00-10.45

gr2 10.45-11.30

gr1 12.00-12.45

Deadline for weekly reports and documents are Mondays 12:00.

Look at the schedule for exact dates, and rooms.

About Requirements Presentation

What is interesting for the other groups to hear? Some of these things, and possibly some more:

·         How have you worked with the requirements? How have you divided this task within the team?

·         How have you interacted with the customer? (How many meetings, how prepared have you been, etc.) How clear requirements has the customer given you, and how much have you had to develop yourself and suggest to the customer?

·         Give examples of some requirements – preferably some that were not so obvious and describe how they have evolved. (Have you already removed some of your initial requirements?)

·         What non-functional requirements are important in your project? (E.g. reliability, availability, performance, real-time behaviour, portability, usability/user interaction, ease of use, etc...) What NF requirements come directly from the customer, and which have you defined yourself? (E.g. in the robot project there are already a lot of hardware and technology in place, which you must use, while the mindmap project is more exploratory in this sense.)

·         How do you formulate your requirements? Why? (E.g. a list of functional behaviour and/or NF requirements, use cases, some other ways to express the goals and requirements of the product?)

I think you get the idea.


Possibly several of the team members present some parts each. Our only requirement on this is that everyone should have made some (parts of) presentations in the course, on this presentation, or the design presentation, or final presentation, and also at least one of the steering group meetings.


(Remember that presentations are one part that is graded in the project! Communication is actually one very important part of any project. We really want you to get some practical experience with preparing the contents of a presentation, and making good-looking and pedagogical slides.)

About test document

You should not describe every unit test in the documentation (that will become a nightmare to keep in sync with the actual tests). But you should describe the strategies you have for unit testing at a high level; examples:

-          Some strategy for testing of normal values, for example: “every function will have unit tests covering the extreme values of input parameters (highest and lowest expected value)”, and “every function will be tested for at least 5 representative values in between”.

-          Any white-box strategy (like test all paths)

-          Error handling(!) (like “every function will be tested for the values closest outside the valid range”, “every exception will be provoked to make sure the expected exception will occur”)

Perhaps you will have to distinguish between different classes or types of classes which require more thorough testing, some algorithms perhaps which require some special type of testing, some harder testing where sporadic (hardware-related) errors may be expected (such as wireless communication). Then describe explicitly where in SVN the tests reside (like “every class file xxx.class has a corresponding xxx.test file in the same directory” or you have a special test directory tree which is a “mirror” of the src tree, or...). The unit tests should then be documented in some detail in the code, so it is understandable what you are testing (like “the following 14 tests test the black-box behaviour” and “in the following 10 tests we use illegal values and make sure an exception is raised”). Also, not all the tests in the test doc are applicable to different kinds of projects. Therefore, for those tests that can't be done in the project, the titles should be kept, while some statements like "Not applicable due to the fact or reason..." should be specified.

The purpose of all this is that someone (for example your steering group :-) should be able to review your strategies and agree that it makes sense, and it should also be possible with little effort to take your testing doc, find the actual tests and assert that you do what you set out to do! Good luck…

Final Presentation

The final presentation is mandatory for everyone. Each group have ca 45-60 minutes to present (not necessarily in this order):

1) The project results – you should present things like:

  - Activities and worked hours summarized.

  - Timeliness. Which milestones were met, which were missed? Why? Which deliverables did you deliver, how timely were they? Why?

  - Describe the overall features of the system. How many (and which) requirements are fulfilled? Do you fulfil the use cases you have promised?

  - Some graphs would be nice, e.g. a Gantt chart illustrating activities, milestones etc.

2) What did you learn from the project – you should present things like:

  - How much of the initial plan held – how did you manage changes along the way?

  - Did you spend less time than you wanted on any particular activity (e.g. testing)?

  - Did you divide and synchronize the work in a proper way? What are your experiences?

  - What is your experience from working in a group? What were the problems (please do not be too detailed or personal)?

  - What turned out as you expected? What will you improve the next time?

3) Requirements and Design. Present the fundamental ideas in your solution, e.g.:

- What were the fundamental requirements? (You should not go through each requirement in detail, but stay at a high level; showing some use case diagrams may be a good idea.)

- Are there any requirements of particular interest, e.g. non-functional requirements, very strict requirements, very difficult requirements?

- What are high-level design (architectural) decisions? How is the program structured? How do you use the available technology?

- How do you ensure the important qualities (e.g. real-time behaviour)?

4) Result demonstration. This means showing your application, describing all features in a pedagogical and convincing way. Of course, you should rehearse beforehand what you will show, to avoid embarrassing situations (the “demo ghost”). You should probably spend some time planning and practicing the demo!




Rikard Land, last update: 20 January 2009