Deliverables

The following table lists the deliverables that should be produced during the course, and their respective deadlines.

Document First version Final version
Project plan Nov 16
Design description Nov 30 Jan 11
Product Nov 30 Jan 11
Project report Jan 11

General instructions

Submitting a document means committing it, in pdf format, in the project SVN (or Git) and sending a mail to the steering group informing us that the document is ready for review, and where we can find it.

All submitted documents should have project name, group number, date, and document title on the first page.

Before submitting, spend some effort reviewing the result to get rid of minor issues like spelling, grammar and layout. Try reading it from the perspective of somebody unfamiliar with the project. Does the document give a clear and understandable picture? If you were to get a new group member, would he/she be able to quickly pick up the important project aspects from your documents? Does it provide enough details? Is there a clear structure and line of reasoning? Is it consistent? If you were the steering group, what grade would you give it?

The deadline for the final product also includes the product being delivered to the client (in case your client wants a different delivery date, check with us first so that it doesn't affect the grading) .

Instructions defining what we expect each document to cover are given below.

Project plan

Purpose: The reader should quickly get a general understanding of what the project is about, and some basic facts such as who the customer is, who is in the group, and what is the timeplan for the project. The document should also describe how the work will be organized. Finally, the document should also list the initial backlog, i.e. the initial list of features defining the functionality the client wants.

The following items (at least) should be addressed:

Design description

Purpose: The design document should capture important design decisions you have made in the project, and should provide a good basis for understanding the implementation. A possible reader (in addition to the steering group, of course) would be a new member joining the group, or someone who will maintain or evolve the system further.

Note that submission of a first version refers to contents and not document structure and quality. For the first version we still expect a document where the overall structure and layout is correct, although describing your current understanding of the design. Perhaps some sections remains to be written, or are expected to change a lot later, in which case you should make a note about this.

The following items are relevant in most projects, but you should really think about what is important to capture (maybe some of this can be skipped, and probably additional things should be added):

Product

The implementation should be available in your SVN/Git repository folder. For the first version, there are no specific requirements on how much functionality it should contain. We mainly want to ensure that practical issues are solved (such as setting up a development environment that all members can use), that you have started implementing and that you have something that can be executed.

Project report

Purpose: The project report should summarize the outcomes of the project, both in terms of results produced and experiences from the project work. It should describe what you have done and what you have learnt.

The following items (at least) should be addressed:

Regarding the acceptance test: All projects must do some sort of acceptance test, related to the client requirements or use-cases. In the report, describe how the acceptance test was conducted (e.g. if the customer was present or if you did it on your own and presented the result to the client), and describe the overall outcome of the test (e.g., how many tests passed and which tests failed). Include an appendix where the detailed acceptance test cases are defined (i.e., the detailed sequence of user interaction and expected system responses for each test case). Tests cases should be detailed enough to allow someone else to carry out the test based on the instructions.