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 w47
Design description w49 w02
Product w49 w02
Test specification w51
Project report w02

General instructions

Submitting a document means committing it in the project SVN and sending a mail to the steering group informing us that the document is ready for review, and where we can find it. Deliverables should be submitted before midnight between Thursday and Friday, in the deadline week.

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 steering group perspective. Does it provide enough details? Is there a clear structure and line of reasoning? Is it consistent? 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 wit 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 describe how the work will be organized. Finally, the document should also list the initial set of requirements.

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 repository folder.

Test specification

Purpose: The test specification document should describe the planned test activities.

All projects must have some kind of acceptance test, which should be related to the client requirements. Depending on the nature of your project, you may also want to do usability tests, either on the final system, early prototypes or simple GUI mockups. In some cases, integration testing and/or unit testing could be relevant as well.

The test specifications will differ a lot between different projects, and you have to decide what tests are relevant in your particular project and how to describe them in the best way. The following items should be addressed in some way, though:

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.

The following items (at least) should be addressed: