Hide menu

TDDD63 Project: Instructions

Read these documents now!

  1. General project information, before you start

  2. How to complete a project (this document)

  3. Final demo, presentation, hand-in

How to Work Together

With three people in most groups, you will have to divide some aspects of the project among you and work on them individually. Without this you may not finish in time, and more importantly, you may not learn as much! During scheduled labs we generally have additional computers available (for example, 20 computers for 12 groups). Ask students not taking this course to leave so that your group can have two computers.

Everyone still has to do all types of work. For example, everyone must write a significant amount of code. Less experienced members should write more code. The point is to learn, not simply to complete a task as quickly as possible.

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. 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.

Completing a Project: Intro Phase, HT1

The project begins with an introductory series of mandatory exercises described in the project-specific instructions. These exercises have detailed instructions and are designed to help you learn about the project topic at hand, such as Lego Mindstorms or working with maps. They will also help you gain additional programming experience and learn the programming interfaces to the relevant existing hardware and/or software.

At the supervised lab sessions, you can ask the assistants about issues that have come up since the previous supervised lab. You must also use them to demonstrate the results from each of the introductory exercises and discuss them 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.

As implied above, you are expected to spend much more time on the exercises outside these lab times. In most projects you should finish the introductory phase before the start of the second period – discuss this with your assistant.

All groups should be present at the start of labs 4 (161010) and 7 (161017), where part of the time is set aside for discussing each group's progress. Before these sessions you are also expected to hand in a progress report (Swedish or English).

Completing a Project: Main Phase, HT2

In the second period (after exams), you are expected to start with the main phase of the project as defined in the project-specific instructions. There will be a set of milestones or tasks, but you will be encouraged to use your own creativity and imagination to determine how to achieve the desired results. In most cases you can also choose to define your own alternative main project, in which case your own task definition document must be approved by the assistant and the senior person involved. In either case: Investigate, explore, and write a lot of code!

There will generally be two four-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. Project assistants will only be present for part of these labs, typically one hour.

You should be present during most of these times so that you can discuss your work with the assistant and verify that you are on the right track. If you skip this, you risk failing the course due to insufficient feedback.

There will be one mandatory two-hour progress report session per week, during which all group members will discuss current progress with your project assistant. As in the intro phase, you are expected to hand in a progress report before each progress session.

Again, you must spend more time on the project outside these lab times – in the main phase, approximately another 4-hour session per week.

Progress Report Sessions

There are progress report sessions 2016-10-10, 2016-10-17, and most Fridays in the second period. This will allow us to provide comments and guidance relative to your current progress, and is mandatory for all project members. If you are too sick to come, mail the assistant before the session. Traveling, recreational activities etc. are not valid reasons for not participating.

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 will be discussed, in addition to any other questions the assistant may ask. 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!

  • What is the current state of your project?

    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 the version control repository 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.

  • 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?

  • 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?

  • Do you feel there are any fundamental problems?

We emphasize again that the end result of the project is not a product but that you learn – so show us what you have learned. If you have spent a week going in the wrong direction, tell us so! Simply saying "we didn't get anywhere" isn't sufficient, though: You should 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 definitely does represent progress in learning about programming!

Progress Report Documents

Not everything can be discussed during a brief progress session. Therefore we also require a progress document that must be emailed to the assistant (plain text or PDF!) by 17:00 the day before each progress session. There should be a single document for each group, stating for each individual project member (in Swedish or English):

  • What have you personally done in the project since the last report? (Code that you have implemented, problems you have had, solutions you have tried, bugs you have fixed, information you have gathered, ...)

  • How many hours did you spend since the last report? (This is mostly for the benefit of you and your group. We often experience time differently depending on how much else we have to do and whether we are having problems or not, so please try to keep track of the actual hours – if nothing else, you can get a better idea of where you are spending the most time. This can also help you in case of conflicts within the group, which are not common but occasionally happen.)

  • Is there anything in particular that you would like assistance with? (Could also be answered at the group level.)

  • Do you see any particular problems with the project setup itself (documentation, bugs in interfaces, assistance, ...)? You can also send this feedback to Jonas Kvarnström (project coordinator) if you don't feel comfortable sending it to your assistant.

And for the group as a whole:

  • Which milestones or tasks had you already completed last week? Which new milestones/tasks have you completed this week? (Clearly specify the numbers/names of the milestones/tasks.)

Again, there will be a single document per group, which should be "approved" by all members. If there are disagreements, feel free to note them in the document or to send them separately. We need to know about potential conflicts as early as possible.

As usual this report has several purposes. We need to see what you are doing in order to help you (so make sure you are upfront about any problems, or we won't be able to do that). Written reports allow us to see progress over time much more clearly. And you need to practice writing clear reports of this kind in order to become professional engineers (so spend some time trying to explain clearly).

Completing a Project: Demo, Presentation, Hand-Ins

During the last week, you will demonstrate and present your results. You will then hand in the project code and documentation before the start of the next period. See the detailed requirements for more information.

Resources: 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.

Page responsible: Jonas Kvarnström
Last updated: 2016-09-26