The project work is done in teams of two. You should start working on the project by the end of period 1. Before that you can get to know the project and learn things related to it for example in the weekly exercises.
The course contains only one ”larger”, but still reasonable to the size of the course, project assignment as the usefulness of most of the programming techniques used becomes clear only as the size of the project increases. In addition, working in a software team is one of the learning objectives of the course and it requires a large enough project.
Project teams are registered in Moodle by 8.2. You can use the Moodle discussion area to look for a project partner.
To be acceptable the following needs to be completed:
The project environment is practised in the weekly exercises (and in Programming 2).
A virtual desktop is available for working on the project linux-desktop.tuni.fi. You can log on to the virtual desktop with your intra account. Instructions on using the remote desktop.
Git version control is used when coding the project. The course will provide the project teams a repository for the project. Make sure both team members push their work regularly to the remore repository. This makes the assesment of even distribution of work easier.
More info on the repositories will be published later. The course side code is also provided through versio control.
There are two types of submissions:
As the project work is developed in Git, it is sensible to use it and GitLab also when questions and problems arise. The teaching assistants can access the team repositories and hence they are able to read the source code when sorting out problems. Still, a few things need to be taken into account when asking for help.
Most importantly: git push. The TA can take a look at the code only it the code has been added to the remote repository using git push. In addition the question itself should contain a depiction of the problem that is as detailed and clear as possible. Also a depiction of how the team has tried to solve the problem independently should be included.
The main channel for asking questions and getting help is the course email prog3@tuni where a clear as possible depiction of the problem is sent. In addition, especially, if the questions is related to the code on the course’s side of the implementation, it is useful to add an issue to the template_project in GitLab. The issue must include a clear enough depiction of the problem. Also it is worth to tag those people from the course personnel you wish primarily to answer the question.
When you have questions about your team’s own code, you can depict the problem in more detail in an issues in your Git repository. Especially with these, it is important to tag the TAs so they can notice the issue. You can also use the Git repository to plan your project.
The projects are automatically given a week of a grace period after the deadline. Using this time will affect the grade. This year the grace period has the Finnish independence day in the middle. To compensate, the deadline has been set later that one week exactly. The effect on the grade will not change due to this.
The absolute deadline for the project is 26.4. at 23.59. Even under grace submit the project as early as possbile as the grading gets tougher over time (see below).
A project submitted under grace gets a grade sanction which gets tougher over time. The grading is changed as follows:
The limit to pass (grade 1) does not change.
Other grades are raised as the grace period starts by half a grade. For example, right after the actual deadline, a project must gain points worth the grade 4.5, the limit for 3 is 3.5 etc.
The limits are raised gradually over the grace period so that by the end of the week the limit for 4 is the same as the original 5. The other grades scale accordingly.
The sanction effect is not disjunct but gets tougher gradually over the week.
It is possible to get an extension to the deadline for a valid reason. In addition the submission schedule can be adjusted to individual needs beyond the course schedule if the reasons are considered valid enough. Lots of different reasons can be grounds for an extension so if you feel you are unable to work on the project, contact the lecturer. If you fall ill, you’ll need a doctor’s or nurse’s certificate on the illness. The assumed time frame to work on the project is from the 1srt period onward so a normal seasonal flu is not grounds for an extension but falls under grace instead. Similarly travelling is not a valid reason unless unforeseen and urgent (e.g. work related). Personal holidays are never a reason for an extension beyond the grace. Note also that the project is a team effort. Any changes to the schedule affect your team mate as well. Thus the extensions need to be discussed with the whole team.