Topic outline

  • Software project

    The project is done in groups of four persons, starting in mid-October and concluding in 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 Thursday, October 8 at 16:15. This will be online session in Teams.

    See project group distribution.

    Learning objectives of the project

    • Get more familiarity with C++ by designing a whole program from scratch that utilizes 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 16: Everyone should have submitted a web questionnaire where project group (if known) and topic preferences are indicated.
    • Tuesday, October 20: Groups and topics will be confirmed
    • Friday, October 30: Project plan submitted to git
    • Weekly meetings with group advisor at agreed time
    • Friday, December 11: Project deadline
    • Wednesday, December 16: Deadline for evaluations

    Choosing topic and group

    Please indicate your (group's) two preferred topics (in order of preference) using this web form by Friday, October 16. Possible project topics are described here.

    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

    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, October 30. 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 should describe at least the following aspects:

    • Scope of the work: what features and functionalities will be implemented, how is the program used, and how does it work
    • High-level structure of the software: main modules, main classes (according to current understanding)
    • Planned use of external libraries
    • Division of work and responsibilities between the group
    • Planned schedule and milestones before the final deadline of the project

    It is not uncommon that as the project progresses, there may be changes relative to project plan, and that is fine. The final outcome will be described in the final documentation, that can be based on the project plan. 

    Project implementation

    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 demonstrations are arranged on week 50 (7.-11.12.). After the final demonstrations project group evaluates 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 makefile and related instructions provided in the git repository. The final output should be in the master branch of the git repository.

    Working practices

    Each project group is assigned an advisor from the project teaching personnel. There will be a dedicated Teams channel for each group, to facilitate discussion between the group and advisor. Group should meet with advisor weekly. The weekly meeting does not need to be long if there are no special issues to discuss, and can be taken remotely as voice/video chat on the group Teams channel (or Zoom or other similar tool), preferably at a regular weekly time. In the meeting the group updates:

    • What each member has done during the week
    • Are there challenges or problems? Discuss the possible solutions
    • Plan for the next week for everyone
    • Deviations and changes to the project plan, if any

    It is understood that note everyone may not be able to participate to all meetings, but at least a couple of members should be present in each meeting. Regular absence from meetings will affect in individual evaluation.

    Project documentation

    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 11 at 23:59. No commits to git should be made after this.

    The document should contain the following parts:

    1. Overview: what the software does, what it doesn't do? (this can be taken/updated from the project plan)
    2. Software structure: overall architecture, class relationships (diagram very strongly recommended), interfaces to external libraries
    3. 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
    4. Testing: how the different modules in software were tested, description of the methods and outcomes
    5. Work log
      • 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

    Project Evaluation

    The course grade will be composed as follows:

    • 45% Exercises
    • 45% Project
    • 10% Review and comment of other projects (there are three evaluation forms during the project. Group members will get one point for each sufficient evaluation. Max points: 3, which equals to subgrade 5.5)

    For project evaluation we apply the following matrix and evaluation guidelines. For each category a subgrade between 0 and 5 is given, and a weighed average is calculated based on them, which will be the project grade that values 45% of the total course grade. The descriptions below are for guidance, and the actual evaluation is based on overall judgement on each category. Grades 2 and 4 are also in use in each category.
    135
    Project plan (evaluated in July) [10%]Minimal description written
    		Project plan contains requested parts, but is unspecific (libraries unspecified, functional requirements unclear, division of work not specified, etc…)
    		Project plan contains the required descriptions, and gives a convincing description on, features, technical ideas, and work plan on the intended target state
    Design [15%]The software does not apply coherent structure, external libraries are not used appropriately, design principles are not documentedBasic class structure exists, C++ standard and third-party libraries are used where appropriate (e.g. for containers)Advanced C++ constructs are applied usefully (abstract classes, inheritance, templates, algorithms), use of libraries is good. Design is well documented and justified and is extensible for future additions.
    Working practices [15%]Use of git is inappropriate (confusing commits, unclear log messages, etc). Distribution of work is unclear. Communication with advisor is lacking. No steps are taken towards testing the quality of implementation.Git is used appropriately. Communication between group and advisor is regular, and a well-balanced work plan is maintained throughout project. There is some documentation about testing of the software.Use of Git features and version management tools is good (e.g. feature branches, issue tracking, etc.) Work distribution is well tracked and documented. Testing and quality assurance is well documented, perhaps automated.
    Implementation [20%]Building software is difficult. Software does not work robustly and crashes e.g. with unexceptional user behavior. Memory management is inadequateThere is a make/Cmake or equivalent for easy building of software. Basic operation works without crashing. There are no problems with memory managementCmake works robustly and can adapt to different environments. Software works robustly also with unexceptional user behavior. Memory management is pedantic and well documented, e.g. smart pointers are used and RO3/5 is followed
    Topical features [40%]Minimal features from the topic description are implementedBasic features are implemented, and they work.Many additional features are implemented, and they work robustly


    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.

◄ Previous section
Exercises