TDDE25 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 finish the base project as early as possible. 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.

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.

Project Phases and Mandatory Tasks

Each project has a mandatory part that every group must complete in order to pass the course. Exactly how this mandatory part is defined depends on the type of project.

• Many projects have an initial core that is linear in nature: There is a natural step-by-step progression where each task forms a stepping stone that is needed in order to reach the next step. In some cases, the core is sufficiently large that nothing more is needed in order to pass the course. Then the mandatory part is also, by necessity, a list of steps to be achieved in sequence. You are then free to build upon the core in any way you want.

• In some projects the initial core is smaller. This opens up the possibility of giving you more freedom in choosing what to implement even in the mandatory part.

In either case, the mandatory part is usually split into two phases, described in the project-specific instructions.

• An introductory phase, where the 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.

• A main phase, where there will be a set of milestones or tasks but you will be encouraged to use your own creativity and programming skills to determine how to achieve the desired results.

  You may also be able to choose to define your own alternative main project. In this case you must write your own task definition document that must be approved by the assistant and the senior person involved. Talk to them first!

Lab Sessions and Supervision

There will generally be two four-hour supervised 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 1 to 1.5 hours.

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 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. If you skip this, you risk failing the course due to insufficient feedback.

As an experiment, we also have non-supervised lab sessions where we have reserved time and lab rooms for you in the schedule (marked "Eget arbete").

Continuous Examination

Each Thursday, every group member must (individually) send in a short progress report document according to a template that will be distributed.

Each Friday, there will be a two-hour progress report session marked as "Redovisning" in the online schedule. All group members must be present in order to discuss the report (if needed) and demonstrate their current progress.

There are two separate reasons for this.

• First, we want a chance to provide comments and guidance relative to your current progress. Misunderstandings are not uncommon, and without regular discussions, more of you will go in the wrong direction, will fail the course during this period, and will have to redo some of your work and wait for your credits. This is a pattern that repeats itself in all courses we have held.

• Second, every course requires a certain amount of individual examination. The project groups are too large for this examination to be performed at the end, because the final hand-in does not clearly show who did what. The reports and sessions allow the assistants to follow every participant's progress week by week, and to ask questions to each participant to verify this.

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

If you miss sending in the report on a Thursday, 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 your examination.

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 much longer report template that will be provided at that time. This is required in order to cover all questions that may arise at the normal weekly presentation / examination. 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 for your project type. Include an explanation of why this happened.

What should be in the progress report document?

The progress report document is individual and must be sent to your assistant in an email on each Thursday. 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 regardless of project type. Information to include:

1. 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, ... Please relate this to specific milestones or tasks in the project description, and please be reasonably detailed.

   If you have done this together with someone else (or the entire group), you should tell us this. Otherwise there will be a conflict with the other members' reports.

2. 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 log can also help you in case of conflicts within the group, which are not common but occasionally happen.)

3. 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 prepare, and 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!

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!

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.