The following table lists the deliverables that should be produced during the course, and their respective deadlines.
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. 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 with us first so that it doesn't affect the grading) .
Instructions defining what we expect each document to cover are given below.
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:
- Introduction (who is the client, what is the project about)
- Project organization
- Project group (members, contact info, roles or responsibilities)
- Organization and communication (meetings, forms of contact, routines, how should worked hours and results be reported, configuration management)
- Planned effort per member for each week in the project (should sum up to roughly 150 hours per student, which includes all project work e.g. scheduled presentations etc.), known absences
- Deliverables, deadlines and milestones, both external (e.g. defined by the steering group) and internal (decided by the group)
- Quality assurance (any planned activities or routines for ensuring quality, both regarding the final product and other deliverables)
- Description of the system to be developed
- High level description of the domain and the problem
- Description of existing system, if the project is about extending or improving something that exists, or the context i.e., any existing or planned entities that the developed system should interact with but which will not be developed in the project (for example physical equipment, or an existing database).
- High-level description of the desired functionality, for example captured by a use-case diagram (note, however, that you probably don't have enough knowledge at this point to include detailed descriptions of each use-case).
- Initial project backlog of system features to be implemented and other planned activities. Define priority/importance and estimated effort (e.g. in person-hours) for each entry in the backlog.
- If needed, you can also list additional functional or non-functional requirements that are not covered by the backlog.
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):
- Short background (you can refer to project description document for details, if you have more details there)
- High-level description of the system to be developed and the desired functionalities
- System overview, especially if the developed software is part of a larger system (e.g., describing the hardware and any equipment controlled by or providing input to the system, and detailed descriptions of interfaces to other systems or existing parts of the system not developed within the project)
- Software architecture. The overall decomposition of the software into modules/units/components (from a static and dynamic perspective, i.e., what are the units, and how do they interact)? What is the rationale (motivation) for this design? Depending on your project, you might also want to describe concerns such as major system states, persistent data, access control, synchronization and timing, error handling, security, etc. Use appropriate figures and diagrams to define and exemplify.
- Detailed software design. For each of the architectural units (or some, in case others are trivial or uninteresting), provide a detailed description of its internal design from a static and dynamic perspective. I.e., what are the parts (e.g. classes) and how do they interact. Use appropriate figures and diagrams to define and exemplify. Make sure the description is consistent with the description of the architecture.
- Graphical User Interface. Describe the structure and general layout of the interface.
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.
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:
Regarding the acceptance test: All projects must have carried out 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.
- Background information, and references to other related documents
- Project results
- Give an overview of the results produced in the project
- List the produced deliverables and the dates when they were finished
- Summarize the results of the acceptance test (see comment below)
- Comment on missing functionality or possibilities for improvements and extensions
- Project work
- Changes to organization and routines (refer to project plan and describe if there have been any changes during the project or if you have stuck to the initial plans)
- Total project effort (e.g., in person-days) and how it was distributed over different activities
- Worked hours per group member
- Distribution of work and responsibilities. Who has been involved in, and responsible for, the different activities?
- Positive experiences (for example successful routines or techniques)
- Improvement possibilities (for example, what would you do different if you were to do a similar project again?)