Information about some of the tools you will use in the course. Note that these instructions are preliminary, and might be extended or adjusted.


To plan and manage the activities for each week, you will use a simple online tool called Trello. Each group member should create an account at, unless they already have an account. Next, the project manager creates a group and a board and invites all group members to it, as well as the steering group (jancarlson and jurajfeljan1). Your board should have the following lists:

Activities (called cards in Trello) can be assigned to group members. They can also be given labels to, for example, separate between meetings, implementation tasks, documentation tasks, etc. Finally, there is a plug-in (downloadable from that provides some simple GUI support for associating cards with an effort value and effort spent so far on it.

Regarding the effort estimation, you just need to come up with rough effort estimations, in person-hours, for your backlog items. We know it is very hard to get it right, but it shows that you have thought about the size of the tasks. When you plan the coming week, you can adjust the estimations, because at that point you also know how many persons are allocated to each task, and you should have an idea how the planned workload is distributed over the group members.

During the initial planning phase, the backlog list will be empty, and the cards in the other list will represent meetings, presentations, work on specific parts of the deliverable, etc. At the end of the first phase you should have produced an initial backlog with cards representing specific design/implementation tasks (high-level features/functionalities/requirements). During the design and implementation phase, backlog items should be prioritized, selected and elaborated (typically further decomposed into concrete design/implementation tasks).

In the internal planning meeting (before the weekly meeting with the steering group), the group should:

Git or Subversion

Submission of deliverables to the steering group, as well as distribution of feedback, is done through Git or Subversion. For documents, we only require that you put the final version there, in case you prefer some other tool for collaborative writing. For the source code, however, we strongly recommend that you use the repository as the only means to share and collaborate on the implementation.

If you want to use Git, you have to set up the main repository yourself, for example at GitHub, and don't forget to invite the steering group to it (jancarlson and jfeljan). If you prefer to use Subversion, let us know and we will create a folder for you on the university SVN repository.

As a first step, to make sure that all group members are familiar with the basic concepts, you can created a folder "members" in your svn folder, and a file "members.txt" in it with just the names of each member on a separate line in te file. Then commit it, and let each member update their local copy from the repository, add some contact information to their name, and commit the changes. You can also experiment with conflicts and merging in this folder.

If you are new to Git/SVN, spend some time learning the basics first. For Git, you can have a look at Pro Git (Chapter 2, Git basics is probably enough). For SVN, Version Control with Subversion could be useful.

TortoiseGit and TortoiseSVN are good Git/SVN clients for Windows. For Mac, there are several clients, each with some pros and cons. For example, you can use SmartGit and SmartSVN. Note that Mac has command line support for Git and SVN in the default terminal. Moreover, many integrated development environments, such as Eclipse, include good Git/SVN support.