The project is done in groups of four persons, during period II and it should be completed by mid-December. A selection of topics will be offered, but you can also propose own topic. Own topic should be about similarly sized as the given topics, and needs to be approved first by course personnel. Each project group is assigned an advisor (one of course personnel) who will be available to help in the project and who will give feedback at different phases of project.
The project will start with a kick-off session on Friday, October 11 at 14:15 - 16:00, in TU2 (Maarintie 8). During the session we will go through the project arrangements and possible project topics. At the end of the session there will be some mingling time to discuss about the different topics and to find yourself group with similar interests.
Learning objectives of the project
- Get more familiarity with C++ by designing a whole program from scratch that utilises different C++ features
- Learn to design object-oriented program that consists of multiple modules, developed by multiple developers
- Group work, where the strengths of each group member are taken properly into account, such that each group member will have an important role in the outcome
- Get to know about different libraries that can be used in a C++ program
- Get familiar with various important software development tools, such as Git and CMake
- Reviewing and giving feedback on work made by others
Project timing and deadlines
- Friday, October 18: Everyone should have submitted a web questionnaire where project group (if known) and topic preferences are indicated.
- Tuesday, October 22: Groups and topics will be confirmed
- Friday, November 1: Project plan submitted to git
- week 47 (Nov 18 - Nov 22): mid-term meeting with advisor for questions and feedback
- Tuesday, November 26: mid-term peer-reviews delivered
- week 50 (Dec 9 - Dec 13): Final demonstration meeting
- Friday, Dec 13: Deadline for final git commit, completion of project. The project must be in git master.
- Wednesday, Dec 18: Deadline for submitting final evaluation forms: 1) one evaluation per group for peer project; 2) one self-evaluation per group for group's own project; 3) each group member submits an individual evaluations group members' work.
Choosing topic and group
Please indicate your (group's) two preferred topics (in order of preference) in a web form. Short descriptions of the topics are available here. They will also be discussed at the end of kick-off session.You can also propose own topic, but in order to have own topic accepted, you need to have a full group of four people. The topic should also be of about similar level of complexity and work as the above proposed topics. If you propose own topic, provide a short description of the work (one or two paragraphs), so that we can evaluate if it is appropriately scaled and scoped for the course.
In the questionnaire you will need to indicate the names of the group members in your group. If you don't have enough many group members, just indicate the names you know (even if it is just yourself). We will then do some matchmaking to fill the remaining slots for your group. In all cases we will aim to have four people in all groups whenever possible. Each group submits just one form.
Project plan is a PDF document describing the scope of the project, major architectural decisions, preliminary schedule and distribution of roles in the group, design rationale and so on.The document should be roughly five pages long, with a couple of diagrams illustrating the program design (for example, the planned class relationships).
Project plan must be put in the Git repository in the plan/ directory.
The project plan deadline is on Friday, November 1. On the following week your advisor will provide feedback, and the group can request a meeting to discuss about the plan if needed.
Project plan contains an idea of the high level structure (e.g. high-level class hierarchy) and of potential algorithms to use for problematic parts, but there is no need to go into details at this phase. It is not uncommon that plans change during implementation of the project for various reasons (improved understanding of the problem, possible changes in group composition, etc.), and this is fine.
The project plan should also describe the features planned to be included in the implementation (see topic descriptions for details), and consequently, group's objective regarding the extensiveness score for the project (on the range of 0 - 10 points, see evaluation description below).
You must use git repository for the work on the project, making frequent enough commits so that the project group (and course staff) can follow the progress.
The completed project work will be demonstrated to the group's advisor at a demo session. The final demonstations are arranged on week 50 (9.-13.12.). After the final demonstrations project group evaluates again another project, and self-evaluates own project. In addition, project members will give confidential individual assessment of each group member
The course staff should be able to easily compile the project work using the computing center's Linux computers (based on Ubuntu 18.04), using makefile provided in the git repository. The final output should be in the master branch of the git repository.
Mid-term meetingProject groups meet with advisor on week 47 (Nov 18 - Nov 22) to discuss progress of the project. Each meeting involves 2-3 project groups. Each project group evaluates the work of another project group, and gives feedback by Nov 26 according to evaluation criteria provided below.
The actual project documentation is stored in the doc/ folder in the Git repository. It should be formatted similarly to the project plan, and also be in PDF format. Separate PDF document needs to be provided also if your project uses Doxygen for inline documentation.
The deadline for project documentation and the project source code is Friday, December 13 at 23:59. No commits to git should be made after this.
The document should contain the following parts:
- Overview: what the software does, what it doesn't do? (this can be taken/updated from the project plan)
- Software structure: overall architecture, class relationships (diagram very strongly recommended), interfaces to external libraries
- Instructions for building and using the software
- How to compile the program ('make' should be sufficient), as taken from git repository. If external libraries are needed, describe the requirements here
- How to use the software: a basic user guide
- Detailed description of division of work and everyone's responsibilities
- For each week, description of what was done and roughly how many hours were used, for each project member
The course grade will be composed as follows:
- 45% Exercises
- 45% Project
- 10% Review and comment of other projects (there are four evaluation forms during the project. Group members will get one point for each sufficient evaluation. Max points: 4)
Each group will do a self-assessment of own project, as well as review one other project after according to following criteria. For each criteria, the score must be justified with small description (about one paragraph, i.e., few sentences):
Overall design and functionality (0-6p)
- 1.1: The implementation corresponds to the selected topic and scope. The extent of project is large enough to accommodate work for everyone (2p)
- 1.2: The software structure is appropriate, clear and well documented. e.g. class structure is justified, inheritance used where appropriate, information hiding is implemented as appropriate. (2p)
- 1.3: Use of external libraries is justified and well documented. (2p)
Working practices (0-6p)
- 2.1: Git is used appropriately (e.g., commits are logical and frequent enough, commit logs are descriptive). (2 p)
- 2.2: Work is distributed and organised well. Everyone contributes to the project and has a relevant role that matches his/her skills. The distribution of roles is described well enough. (2p)
- 2.3: Quality assurance is appropriate. Implementation is tested comprehensively and those testing principles are well documented. (2p)
Implementation aspects (0-8p)
- 3.1: Building the software is easy and well documented. CMake or such tool is highly recommended. (2p)
- 3.2: Memory management is robust, well-organised and coherent. E.g., smart pointers are used where appropriate or RO3/5 is followed. The memory management practices should be documented. (2p)
- 3.3: C++ standard library is used where appropriate. For example, containers are used instead of own solutions where it makes sense. (2 p)
- 3.4: Implementation works robustly also in exceptional situations. E.g., functions can survive invalid inputs and exception handling is used where appropriate. (2p)
- Project contains features beyond the minimal requirements: Most of the projects list additional features which can be implemented for more points. Teams can also suggest their own custom features, though they have to be in the scope of the project and approved by the course assistant who is overseeing the project. Project topic descriptions give a rough guideline about how these points are awarded on different topics, but note that this will be always case-by-case estimation by the supervisor, depending on the actual implementation and its characteristics. (0-10p)
- Project plan is specific and discusses the requested aspects
Some frequently asked questions:
- Can we implement our software on platform X? A: Our wish is that the software works on Aalto Linux machines, using the readily installed libraries there. You must negotiate with your project instructor on exceptions (e.g. using Windows instead).
- I work in company X on their software, can I make my project on our software component Y? A: Likely not. All four project members should be able to fairly participate the project, and in many cases the rights of the other members would be unclear, if code becomes a part of a commercial product. Course personnel should also be able to compile and test the code in Aalto Linux machines.