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



(Old news further down. Info related to the course is found on the main course page.)

·       2010-01-04 Project grades. The project grading has taken some time, among other reasons, there have been (and are still) some artifacts missing (actual product and/or documents). At the time of writing I am waiting for a final notification from the following groups that you have completed everything: group 2, group 3, group 5, group 6. Also, some customers have been slow in giving me their feedback; but currently I am only waiting for group 1’s customer. As soon as I get the final info needed, you will get your project grade. See the overview page on how your individual final course grade is calculated.


Project Schedule and Admin



How the projects are graded


Article: Twenty Dirty Tricks


Ada stuff










Game project

Robot project

Aero resource site

Decision support

Scheduling support for short term home

Lactate threshold


Ant wars

Poseidon Project

Aero resourse site





Rikard Lindell

Lars Asplund

Gustaf Enebog

Erik M Olsson, Peter Funk

Christina Tjärnström

Mia Folke

Steering Group

Frank Lüders, Yue Lu

Rikard Land, Frank Lüders

Rikard Land, Frank Lüders

Frank Lüders, Yue Lu

Rikard Land, Yue Lu

Rikard Land, Yue Lu

Project Members

PL: David Lindström

John Ernberg

Henrik Hansson

Daniel Thorell

Robin Wahlstedt

Mattias Ekström

PL: Georgios Arvanitidis

Michel Uncini

Samuele Sabbatini

Francesco Lilli

Rubén Navarro Arévalo

Sergio Dominguez Fernández

PL: Torbjörn Nyberg

Eric Johansson

Björn Lindblom

M Umair Zahid

Naeem Ullah

PL: César Pinto Castillo

Robert Gawrylczyk

Elin Dahlgren

Ligaj Pradhan

PL: Anders Carlsson

Daniel Watson

Ceren Ahıska

PL: Jesper Melin

Daniel Boström

Victor Lundquist

Nalle Rooth

Lidia Tesfazghi

Peter Lännhult








Documentation (10)






Project work (10)







Product - Software (10)







Presentations (10)







Sum (max 40 points)







Old News

·       2009-12-15 Final presentation. There is a schedule for the final presentation further down on this page. Also, there are instructions what is interesting for us others to see! Please plan for around 20 minutes presentation. We will end the presentation event with two specially invited surprise guests...

·       2009-11-24 Notification of documents. To make it easier to manage the steering group’s review of your documents, we kindly ask you to send an email Mondays around noon (or earlier) and say which documents you would like feedback on, and any specific questions like “we are unsure if we should write more details about XYZ”, or “the section about architecture we are unsure of”, or “do we really need to make one hundred sequence diagrams for every simple function that looks basically the same?!?”. (The project description and the requirements document are in practice approved – but if you want the highest grade on each doc, you might want to ask us again for some specific changes you have made.)

·       2009-11-24 Next week’s presentation. On Dec 1st, we will have somewhat shorter steering group meetings (see schedule below), and project presentations for the whole class 11:15-12:00. See some guidelines for the presentation under “Design presentation” below. Even if you have collisions with other classes, try to make it to at least some part of the presentations!

·       2009-11-24 Testing info. On today’s steering group meetings, we discussed testing with most of the groups. In addition to the test specification document template, please don’t miss the section with general guidelines further down (kept from some FAQ previous years).

·       2009-11-18 Automatic update of www folder working again. There was something wrong with access rights for the script, but now it is working again. The folder being copied is “trunk/www” in your group’s root folder (not “www”).       

·       2009-10-03 Automatic update of www folder. Everything you put in your trunk/www folder is copied automatically every 5 minutes to the web page. See the links below, click your project name. (If you want to host your own web page instead, please send me the link and I will put it below.)

·       2009-10-03 Next week’s meetings. On Nov 10th, we first have steering group meetings, 25 minutes per group, between 8:30 and 11:00 (see detailed schedule further down on this page). At 11:15-12:00 all groups present their project so far for the whole class.

·       2009-10-03 Group rooms. I have booked a group room for group 6 (should be on the schedule soon). If other groups would like a project room, please give me your (reasonable) wishes!

·       2009-10-29 For first steering group meeting Nov 3rd. Make sure you have done some planning, i.e. your project plan document should be in as good shape as possible. Also you should have a weekly report and presentation slides checked in. We will review your documents Monday afternoon, the deadline for docs are always Monday 12:00. Presentations may be checked in Tuesday morning. Frank will be absent on Nov 3rd.

·       2009-10-15 Project groups formed! See table below. You will start working in your projects during next week, as lab 8. I have a very good feeling overall of the class, and I am sure that all projects will be very successful! I want to be very explicit however, that you (individually) have to take your responsibility to meet your group, be active in meetings etc. from the very start! If you are absent, or produce essentially nothing, and contribute very little for a few weeks, you will not get a pass grade. You have an individual responsibility to project success!

·       2009-10-08 Projects presented! Now it is your turn to choose your desired project on this poll. Observe the deadline: Thursday Oct 15th 12:00. Groups will then be announced on the lecture the 15th.

Steering Group Meetings

Each weekly follow up meeting with steering group will be 30 minutes per group on Tuesdays (look at the schedule for exact dates, and rooms):

Most weeks:

·         08:30-09:00 gr6

·         09:00-09:30 gr2

·         10:00-10:30 gr4

·         10:30-11:00 gr1

·         12:00-12:30 gr5

·         12:30-13:00 gr3

Nov 10th and Dec 1st:

·         08:30-08:55 gr6

·         08:55-09:20 gr2

·         10:00-10:25 gr4

·         10:25-10:50 gr1

·         11:15-12:00 All groups, presentations. (If you all spend 7 minutes each, we will be three minute early for lunch! ;-) Make sure your presentations are uploaded to SVN Tuesday morning so we don’t need to take time for fiddling with switching computers and USB sticks during the presentation…)

·        12:00-12:30 gr5

·        12:30-13:00 gr3

If there are any collisions with other courses, discuss within the group for a solution, and suggest a change to me that you feel is reasonable. If it involves swapping slots with other groups, please contact that group directly first.

Deadline for weekly reports, and slides for the meeting are Mondays 12:00.

General about presentations

We have two presentations during the projects with quite short presentations per project, and one final presentation. These presentations are mandatory for everyone.


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 (in addition to 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 Project Plan & Requirements Presentation (First Presentation, Nov 10th)

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

·         What is the task you will be solving? Try to not repeat exactly what the customers presented to the whole class, but also you should not spend too much time on this. Any interesting photos/figures?

·         What are the roles in the group? Do you think you have any particular roles which may be specific for your group?

·         Describe your time plan, e.g. with a Gantt diagram and/or a list of milestones, but don’t spend too much time on details, just focus on whatever you think is important (e.g. a milestone/deliverable prototype for the customer, incremental development)

·         How will you communicate in the group? E.g. weekly meetings on fixed dates, everyone together most of the time... How will you use email, SVN, phone, meeting in person, ...?

·         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?

·         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.


About Design Presentation (Second Presentation, Dec 1st)

You will have quite little time per group, so make a focused presentation, and rehearse it before! We have to squeeze 6 groups into 45 minutes.


Describe any important events in the project since last time, especially changes or surprises, with a focus on design. For example:

·         How have you communicated with the customer? Have you modified your understanding of the problem, have you re-formulated/deleted/added requirements? If you created a user interface prototype, please show it (very briefly) and describe the customer’s feedback.

·         Show the (internal) design. You will not have time to go through all diagrams in detail! Only show something that is representative and explains the fundamental behavior of the system, such as (if applicable):

-   The architecture: what are the main components? What are on the same or different hardware/computers? Loosely connected components, more tightly connected?

-   How do buttons, text fields, graphical elements etc. correspond to entities in the design such as classes, php files, etc.?

-   Some (parts of) selected class diagrams.

-   Sequence diagram(s) of the most important or interesting behavior, perhaps for some interesting use case, or if you have a time-triggered system, what happens in the main control loop?

-   State diagram(s), if applicable

-   …or whatever makes the most sense to explain your solution!

·         Why does the design look like it does? For example:

-   Motivate the allocation of different functionality/responsibilities to different components/classes.

-   How have the requirements affected your choice of architecture? For example: robustness/independence of some parts à make the other parts loosely connected; interaction à time-triggered loop; how will it be used à distributed system or local system…

-   What is the worst thing that can happen in your system and how do you address that? For example: loss of data à continuously save to file; user experience in a distributed system à simple synchronization scheme to ensure all clients are consistent; inadvertent modification of data à user warnings before each read/write; corrupt data in the database à some internal validation, regular backup?

-   How did you select external packages such as middleware, graphics packages, database, simulation engines, etc.? What are you experiences – did you select them without knowing fully what you selected, did you prototype anything to learn about them, did you assign someone specifically to do that? Any particular problems?

·         If you have some (partial) implementation, please show it in some way!

-   Screenshots, a short movie…

-   If you show a live demo, please rehearse and prepare what you will show – there will not be time to present every little nice detail you are proud of! ;-)  Also, prepare a backup solution (screenshots, movie) in case something goes wrong.

·         A short note on how you intend to spend the last time of your project. For example, how/when will you perform testing, how/when will you involve the users, etc.

·         …and/or anything else that should be interesting for the other groups to hear!


Observe, these things should not necessarily be presented in this order, you may e.g. want to show the demo first and then explain how it works, or in the architectural diagram add notes relating to the requirements, or…

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…

About Final Presentation (Jan 8th)

The final presentation is mandatory for everyone. Each group have ca 20 minutes to present.


Approximate schedule:

13:20-13:40  Group 2

13:40-14:00  Group 3

14:00-14:20  Group 4

14:20-14:40  Group 5

15:00-15:20  Group 6

15:20-15:40  Group 1

15:40-16:00  Surprise guests


You should cover (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. Perhaps you can do some things hands-on, other things may best be shown by screenshots or a recorded video. Of course, you should rehearse beforehand exactly what you will show, to avoid embarrassing situations (the “demo ghost”), and prepare a plan B such as screenshots in your slides. Make sure (the latest version of) the slides are in SVN in case your computer crashes, etc. You should probably spend some time planning and practicing the demo! (I know one student presentation once where everything broke down because (they understood later) they entered a Swedish “å” in a field, which they apparently had not rehearsed, and not tested for... They were embarrassed of course, blocked mentally, and spent several minutes in front of everyone, redoing the same mistake again and again... and had no backup plan. Read more here about Windows 7 launch, and see a video of the famous Windows 98 launch demo: )





Rikard Land, last update: 8 March 2010