Hide menu

General Project Instructions

Part of the perspectives course consists of a programming project that you will pursue together with a couple of your fellow students. This project starts in the second period (HT2).

In addition to this page, there is also a separate seminar explaining the project. The information given in the seminar slides is also important!

Why a project? Why now?

The TDDE25 programming project is important for several reasons.

  • It gives you direct hands-on experience in using programming to solve interesting problems at an early stage in your university education.

  • It is sufficiently large to let you produce a very interesting final "product", in contrast to ordinary short lab exercises.

  • It lets you use your own creativity in extending the initial, mandatory part of the project.

  • It allows you to practice working without constant guidance and to take personal responsibility for what you do, how you do it, and how much you learn.

Though this course is comparatively early in your studies, the project part does not start until the second period, when your first programming course has been completed. We therefore expect you to be able to enthusiastically dive head first into the world of software development, to work hard and spend a great deal of time on the project, to write a lot of code, to try different approaches to solving problems, to make mistakes, to learn and recover from those mistakes, and to show us what you have learned.

During 2021, all students participate in the Capture the Flag programming project.

How to pass the course (important!)

The only grades given for the project are U (Fail) and G (Pass).

The requirements for passing this course include:

  • Participating in project discussions and development together with your group
  • Participating in weekly progress report sessions, as described below.
  • Finishing the mandatory part of the project according to the project-specific instructions linked above
  • Demonstrating your project to your assistant during the final progress report session
  • Handing in the final code together with any documentation that may be described in the project-specific instructions

If you reach the end of the course period without satisfying these requirements, or you miss the mandatory demo or presentation, you will also be able to finish this course and receive course credits in the re-exam periods in March and August the following year.

Please be aware that labs and projects are supposed to be finished during the course. As stated above, we will definitely extend this default deadline up to August next year, but we can't guarantee that you will be able to hand in "kompletteringar" later than that! It may be possible, but this depends on circumstances we can't necessarily control.

Randomized Project Groups

For this project, we will randomly divide you into groups of 3 students. The random assignment has similarities to working at a software company, where you cannot expect to personally choose your coworkers. Getting used to this is important for your professionalism.

This usually results in up to around 50 groups of 3 students. These groups are then divided into what the scheduling software calls "Storgrupp 1" through "Storgrupp 5". Each such large group has its own lab assistant. Once everything have been set up and you have been assigned a group, you can see who your assistant is both in Webreg and in the TimeEdit schedule.

In addition, Cyrille Berger (cyrille.berger@liu.se) has the ultimate responsibility for the current Capture the Flag project and its definition, while Jonas Kvarnström (jonas.kvarnstrom@liu.se) has certain overall responsibilities for the project part of TDDE25.

Setting Up and Using Version Control

After the project groups have been finalized and before the project starts, we set up Git projects for all groups in GitLab. Using version control is mandatory – here, in most companies, and in most open source or commercial projects.

When this happens, you will get an email notification from the LiU GitLab server.

Please check in (and push) your code often! Do this at least every day, but preferably many times per day.

Working Together in Groups of 3

Working together in groups of 3 is not necessarily trivial. Here are some instructions that you will need to keep in mind.

Work individually on some parts of the project.

When working in groups of two, as in TDDE24, it may be natural to keep working together at all times. In groups of three, you will definitely have to divide some aspects of the project among you and work on them individually. Otherwise you may not finish in time, and more importantly, you may not learn as much!

For example, maybe two project members work on one feature together while a third works on another.

(Not enough computers? During scheduled labs we generally have additional computers available. For example, we may have 20 computers for 12 groups, and you should ask students not taking this course to leave so that your group can have two computers.)

Keep everyone up to date, and explain what you have done.

Working alone on a specific feature does not mean working in a vacuum. Everyone must have working knowledge of every part of the project and must be able to explain what others' code does and why. Spend the time to discuss the code you write, so that everyone understands what the others have written and designed! This is not wasted time: Seeing and understanding what others write helps you learn, which will be rewarded in evaluations.

Divide the tasks equally, regardless of experience.

Even when you work individually on different tasks, everyone still has to do all types of work. Most importantly, everyone must write a significant amount of code.

Never take over another group member's job.

Everyone must let the other group members do their part. Don't take over their jobs, even if you feel you can do something faster. We will evaluate you individually!

If you are inexperienced, you must still try, and you must make sure you get your share of coding time. Be active, and be proud of what you learn!

If you are experienced, you must also work hard. If the basic project isn't challenging, then challenge yourself by spending time elaborating it, inventing and designing new functionality, and exploring new aspects of programming. No project is so simple it cannot be expanded into something that you can learn from.

No group member is allowed to take over the project. Leave a third of the basic functionality to each participant – however inexperienced they may be, they are not helped by having someone else do their job. The product we aim to produce consists of knowledge and skills, not the project code.

In fact, less experienced members should write more code. More experienced members who want to write more code can devise their own extensions to be implemented in parallel, as long as this does not impede the other members' progress.

If you help someone, give hints – don't do their job. And even if you tell them how to solve a problem, it should be their hands on the keyboard, not yours.

Stay active, even if you are having problems!

Saying "I didn't get anywhere this week" or "I didn't know how to continue so I haven't done anything" is obviously not sufficient, not here and not when you finish your education and get a job.

Be active and proactive! Try to find more information about the problem, from different sources. Try again. Think, abstractly, but also write code and experiment with programming.

Ask the assistant – and ask in a way that provides the necessary information so the assistant can understand what the problem is, when it arises, and what you have already tried.

How will you work together?

In addition to the general instructions above, you as a group have to come to an agreement about how you will work together. You should discuss this openly at the beginning of the project!

In some courses a group contract is set up and signed – here we'll try to keep the discussion less formal, but do not skip it just because there is no paper to sign. Simply bringing up these issues in an honest discussion can help you avoid a lot of misunderstandings and problems later in the course.

Some topics to consider:

  • When will you do the work? Will you meet (physically or virtually) during all of the scheduled lab times, and work together as recommended? When will you do the rest of the work that won't fit into the scheduled labs? Remember that a lot of work needs to be done outside of scheduled hours.

  • What will you aim for? Do you aim to go as far as possible with your project, or do you just want to pass the course? If you have different aims, how will you reconcile this so that some of you can add more functionalities without "leaving others behind"?

  • How would you like to work in the project, in general? What makes you like working together? What do you think would be problematic, given your own experience?

  • Will you be splitting off some parts of the project into tasks that individual members can take care of separately? How will you then make sure everyone knows "everything" within the project? Or will you work together, and only together?

  • If someone doesn't show up, how will you deal with this?

  • What do you need to learn for the project, as individuals or as a group?

Project Tasks

The specific programming project instructions for Capture the Flag specifies what you need to do in order to complete this particular project.

Make sure that you read those instructions carefully! It may be tempting to just go ahead and write a lot of code, but you need to read carefully in order to understand exactly what is expected of you.

Lab Sessions and Supervision

There will generally be two 4-hour labs booked every week. The intention is to ensure that you get the time to work with your project for longer periods of time without interruption. Lab assistants will only be present/available for half of this time! (The alternative would have been to book two shorter labs each week... But that would give you exactly the same amount of lab assistance, and make it harder for you to find times to work together!)

At these sessions, you can ask the assistants about issues that have come up since the previous supervised lab. You must also use them to discuss your current progress and results with the assistant. Even if you have nothing in particular to discuss, you should be present during most of the supervised labs so that the assistant can see your progress and perhaps give you some tips. If you skip this, you risk failing the course due to insufficient feedback.

Continuous Examination: Progress Reports

Each week, there is a two-hour progress report session marked as "Redovisning" in the online schedule. All group members must participate in order to discuss the report and demonstrate their current progress.

The day before the report session, each group member must individually send in a short progress report document according to the template below.

There are two separate reasons for these reports and seesions. First, it gives us a chance to provide comments and guidance relative to your current progress, which gives you a better chance of passing the course at the first attempt. Second, it serves as a form of individual examination allowing you to show to the assistant that you are making progress and should pass the course.

What should be in the progress report document?

The progress report document is individual and must be sent to your assistant in an email the day before the progress session. Send the report in plain text in the email, so that the assistant can easily see it without opening an attached document. You can use Swedish or English.

The format should be as follows. Be careful to follow the template so that assistants can more easily organize the up to 36 reports they must handle each week.

Subject: TDDE25 progress report {Your LiU ID},
         group {Your complete group+subgroup number},
         week {Calendar week number}
What have you personally done in the project since the last report?
{Your answers in Swedish or English}

How many hours did you personally spend during each day?
{Your answers in Swedish or English, for each day}

How do you think the collaboration has worked?
{Your answers in Swedish or English}

Explanations:

  1. Note that the important part of the group number is the index of your 3-person group. For example, "SG1-CTF-5" is a complete group number; don't forget to include the "5" as the assistant already knows which project you have.

  2. What have you personally done in the project since the last report? You can discuss:

    • Code that you have implemented
    • Problems you have had, solutions you have tried
    • Bugs you have fixed
    • Information you have gathered
    • And so on...

    Relate this to specific milestones or tasks in the project description, and please be reasonably detailed. This will be part of how you show that you have personally done enough to pass the course!

    If you have worked closely with others in your group, you can explain this – but still explain what your particular contribution was, and what role you took, during this teamwork.

  3. How many hours did you personally spend during each day since the last report? This is partly for your own immediate benefit (giving you a better idea of where you are spending the most time), partly for the long term (in case of conflicts within the group, which are rare but do happen), and partly a basis for discussing your progress.

  4. How do you think the collaboration has worked? Are you getting a chance to write code? Is everyone present? Do you agree on what should be done and how? This is your chance to bring up potential problems at an early stage. Doing this is not disloyal -- it is just a way of letting the assistant know that the group as a whole may need some help.

Sending in this information in advance lets the assistant spend less time taking notes during the progress report session.

What will we discuss during the progress report session?

During the session, each group will demonstrate and discuss their current progress with their assistant. Around 7-10 minutes will be available for each group. Use this time wisely, and be well prepared! (Groups who are not currently reporting will of course continue working on their projects.)

The following topics are examples of what may be discussed. All members must be able to answer questions about any part of the project, including code they did not write. One member might be asked to answer all questions during one session!

  1. What is the current state of your project?

    The reports should already have given the assistant a good idea about where you are and what the problems were, in some detail.

    During the session you instead give a brief demonstration of what you have done by running the code you have written so far. Don't worry too much about being able to give a "perfect" demo of all features – we need to see how far along you are, but we are just as interested in seeing what difficulties you have as in seeing what works perfectly. See this as an opportunity for feedback. At the same time you should have something that actually runs, not just some code that won't start. Keep track of "working" revisions in Git so that you can bring back a stable working version if necessary.

    Be prepared: decide what you want to show, and test it before the session.

  2. How did you reach the current state of your project?

    Which parts were easy and which parts were difficult? Which difficulties have you encountered in the last week? How have you resolved them, or how are you planning to resolve them?

  3. How do you intend to continue?

    What do you think you will do in the following week (which milestones, which subproblems, which issues to resolve, what progress is expected)? Do you foresee any new problems?

If there is no progress in terms of tasks and milestones, simply saying "we didn't get anywhere" isn't sufficient: Explain clearly what you wanted to do, how you tried to do it, what happened, and why this direction was not appropriate. This does not represent progress in producing a product, but it can definitely represent progress in learning about programming!

What if I can't come, or I miss the report or session?

If you miss sending in the report on the day before a progress session, the assistant can't prepare properly for the session. If you miss the actual session, the assistant can't ask you questions. This means you have a problem in terms of showing us that you should pass the course.

If you miss a report and/or session at most twice, you will get a second chance to complete the course by filling in a longer report template that will be provided at that time. This is not a punishment but simply an alternate means of examination, which will cover the questions that could otherwise have been asked at the weekly progress report session. The longer report must be handed in by Wednesday the week after the missed report/session. The assistant may add additional requirements for examination purposes.

If you are sick, please inform the assistant before the session. You will still have to write the longer report: The examination is necessary for everyone, regardless of circumstances.

If you miss a report and/or session more than twice, the longer reports will not be sufficient: We do need regular opportunities to talk to you and ask additional questions, and this should be done during the actual report sessions. In this case you must email the project coordinator Jonas Kvarnström, who will discuss the issue with your assistant and the senior advisor. Include an explanation of why this happened.

Requesting Assistance

Throughout the project we expect you to encounter a large variety of problems that need to be solved. For each problem you need to do your best to strike a good balance between trying to find a solution on your own and asking your assistant for help.

If you immediately ask the assistant, you lose an opportunity to practice independent problem solving and to develop your own skills. Therefore you should generally start by discussing within the group, searching the web for information, discussing with other groups, and using whatever other channels are appropriate depending on the problem or question you have.

On the other hand, you lose too much valuable time if you spend days trying to solve a single problem on your own, and for some problems (in particular when it comes to unclear instructions) it may be obvious that asking the assistant is better.

If you send questions by mail, make sure that you include all relevant information about the problem itself, how you have already tried to solve it, and why the solutions did not work or did not seem appropriate. If you don't provide enough information you will receive questions instead of answers! Learning how to describe an issue in a useful way is also important for your education.

Assistants will be available by email throughout the period but will not necessarily be at their computers at every moment. If you don't receive a reply within 48 hours (during weekdays, not weekends!), please try again. We cannot guarantee that every problem is actually solved within this time limit, but you should still receive a reply telling you that the question was received.

Final Demonstrations

During the last demo session ("redovisning"), you will demonstrate the final version of your project. Spend some time polishing the software accordingly – this is your final chance to give a good impression! As usual, participation is mandatory for all project members.

The fact that the project is final does not mean that every milestone in the project description must be achieved – in fact we try to specify too many tasks for you to have a reasonable chance to finish them all, and/or leave projects very open-ended. Discuss your progress with your assistant continuously so that you can see if you are on the right track or if you have to do more. Aim to have all features implemented early and then "freeze" the list of features, so that you can spend a full week making sure all the features you already have are functional and polished.

If you have finished everything early, you can choose to make your final demonstration during the last regular weekly progress report session. Earlier final demonstrations are not accepted.

Final Hand-In

The final project code, and any documentation, must be handed in by the deadline 2022-01-07. Feel free to hand in the code earlier, but we will not be grading or submitting results until 2022!

To hand in, you must first make sure that all the required code and documentation is committed and pushed to Gitlab. Then you simply create an issue in our central TDDE25 issue tracker, which is similar to what you have done in TDDE24.

The issue is how you indicate that you consider yourselves finished. Don't forget the issue, or your assistant won't know you want your project to be graded!

As stated earlier, you will also be able to finish this course and receive course credits in the re-exam periods in March and August the following year. Note that we can't guarantee that you will be able to hand in "kompletteringar" later than that! It may be possible, but this depends on circumstances we can't necessarily control.


Page responsible: Jonas Kvarnström
Last updated: 2021-12-08