(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








AI (Brain Modeling)

MDF Customer Management System

Robot Command Center



Blind Cortex


Robot Command Center

Access Point Activities


Baran Cürüklü

Johan Marklund (MDF)

Lars Asplund,

Jörgen Lidholm

Rikard Lindell

Steering Group

Frank Lüders,
Farhang Nemati,
Yue Lu

Frank Lüders,
Farhang Nemati,
Yue Lu

Frank Lüders,
Farhang Nemati,
Yue Lu

Christer Sandberg,

Rikard Lindell,

Rikard Land

Project Manager

Jenny Jutterström

Abtin Hassani

Caroline Uppsäll

Per-Henrik Lam

Result (40 points)





Documentation (10)





Project work (10)





Product - Software (10)





Presentations (10)











·         2008-05-08 About test document. I got some questions about unit testing in the test document, and I put the response here. 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…

Steering Group Meetings

Game project (CDT311) only: Schedule for steering group meetings in period 3, see schedule, in “Projektstudion” U2-040.

In period 4, schedule for steering group meetings are as follows:


Look at the schedule for exact dates, and rooms.

Final Presentation

The final presentation (pending date: May 30th) 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: 16 June 2008