Swedish web site
TDDD63 8 hp /Perspectives in Computer Science and Computer Engineering (8 ECTS)
Ht1-Ht2 2012
Introduction to the Programming Project
Part of the perspectives course consists of a programming project that you will pursue together with a couple of your fellow students. The following instructions contain information that will be useful to you throughout the duration of that project. Though they are comparatively long, you still need to read them and understand them in their entirety before you begin!
The programming project is essential in several ways. It will give you direct hands-on experience in using a modern programming language to solve interesting problems at a very early stage in your university education. In contrast to ordinary short lab exercises, each serving to illustrate a particular aspect of a particular topic, the project will be sufficiently large in scope for you to produce a very interesting final "product". And after a set of introductory tasks where detailed guidance is provided, you will get many chances to use your own creativity to solve interesting problems. The fact that later steps of the project are not guided in every detail will also allow you to practice working independently and to take a considerable amount of personal responsibility for what you do, how you do it, and how much you learn.
As already noted, this course takes place very early in your studies. You have begun learning about Python programming, but you have not yet had the chance to take courses about data structures, algorithmic techniques, or various programming paradigms such as functional, imperative and object-oriented programming. Therefore we don't expect the end result to be a perfect product satisfying a set of strict functional requirements. What we do expect is for you to enthusiastically dive head first into the world of programming and 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 the problems you encounter, to make many mistakes, to learn as much as possible from those mistakes, and to show us what you have learned. Enthusiasm and hard work counts!
Project Groups
At the beginning of the course you signed up in WebReg for a set of initial quizzes. Towards the end of the first period you will sign up once more, this time for the project part of the course. We will then randomly divide everyone who has signed up into groups. Group assignments will be published before the beginning of the second period.
UPDATE: Group assignments are now online.
Each group will generally consist of three students, though different group sizes can occasionally be used for particular project types or (of course) when the number of students is not divisible by three. To ensure you will work with someone you have met before, each group will usually only have members from a single class (C1, D1A, D1B, D1C).
We expect everyone who signs up for the project part to remain and complete the course. If someone does choose to leave the course after signing up for the project, the remaining participants should inform their project assistant immediately in order to minimize the impact. This also applies if a participant disappears without warning and cannot be contacted for several days.
Working in Groups
The fact that you will generally work in groups of three has certain consequences for the way you work. In particular, everyone cannot expect to work on every aspect of the project, with three project members sitting at a single computer at all times. Some aspects of the project will have to be divided among you. For example, two participants might write code while another searches for information.
Despite this, everyone must perform every type of work associated with the project! Everyone should do approximately the same amount of coding, for example. If some participants are less experienced in this department, this does not mean they do not code, or that they simply observe someone else writing code – on the contrary, they should perhaps do more coding. The intention is for you to learn, not simply to complete a project task as quickly as possible.
Similarly, everyone should have working knowledge of every part of the project. No one should be completely unaware of any aspect. This means you will have to sit down occasionally and simply discuss different aspects of your project, how they are designed and how the implementation works. This may not feel as if this leads you closer to finishing a new feature, but it does lead you closer to understanding what you are doing and why you are doing it!
Project Types and Project Instructions
Several different types of project will be available, and several groups will perform the same type of project. Project types will be assigned randomly after the groups have been defined. To avoid the risk of problems with peer pressure, switching project type will not be permitted. This also has similarities to working at a software company, where you cannot expect to personally choose the type of project you work on.
For each project type there is a senior person with the ultimate responsibility for the project definition. There is also an assistant taking care of questions, progress reports and all other day-to-day contact with each project group.
For each project type there will be a specific set of instructions including necessary technical information about the project topic. These instructions will be linked from the project name below.
Completing a Project: An Overview
Once a project has been assigned to your group, you will generally proceed through the following phases. Further details will follow below.
Repetition. To refresh your memory and fill in potential gaps in your Python programming skills, we expect you to sign up for an account at Codecademy and then begin the project by completing a series of Python exercises. At the moment there are 82 exercises in this tutorial. This sounds like a lot, but each exercise is quite short and provides detailed guidance. Note that each project member should complete these exercises individually.
-
Introductory Phase. During the first one or two weeks of the project, you will go through an introductory series of exercises outlined in the project-specific instructions. These exercises will initially be described in detail and will be designed to help you learn about the project topic at hand, such as Lego Mindstorms or humanoid robots. Going through each step will also help you gain additional programming experience and learn the programming interfaces to the relevant existing hardware and/or software.
-
Main Phase. After the introductory phase, you will continue with the main phase of the project as defined in the project-specific instructions. There will be a set of milestones, but you will be encouraged to use your own creativity and imagination to determine how to achieve the desired results. Investigate, explore, and write a lot of code!
Demonstration and presentation. During the last week, you will demonstrate and present your results.
Once every week there will also be a support session (resurstillfälle) to deal with questions that cannot easily be handled by email, as well as a progress report session where you present your current progress. The dates and times of these sessions are given in the official schedule but could possibly be different for one or two project types due to project-specific requirements. If so, you will be notified separately after project groups and topics have been assigned.
The following is a rough outline of the project timeline. Details about deadlines and scheduling are discussed later.
| Week 40 (121001-121007) | Project signup in Webreg. |
| Week 41 (121008-121014) | Final seminar covering projects. |
| Week 42 (121015-121021) | Final week of the first period.
Begin working on Python exercises. Exams begin on Saturday. |
| Week 43 (121022-121028) | Exam period. Project groups are announced. |
| Week 44 (121029-121104) | Project begins. Final project descriptions are made available. Introductory phase begins. |
| Week 45 (121105-121111) | Project week 2. |
| Week 46 (121112-121118) | Project week 3. |
| Week 47 (121119-121125) | Project week 4. |
| Week 48 (121126-121202) | Project week 5. |
| Week 49 (121203-121209) | Project week 6. Possible (but not mandatory) to demonstrate your project. |
| Week 50 (121210-121216) | Project week 7. Deadline for project demonstrations. Final presentations in larger sessions. |
| Week 51 (121217-121222) | Exam period. |
Project Assistance
Throughout the project we expect you to encounter a large variety of problems that need to be solved, with widely varying levels of difficulty. 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.
When you do have questions, the primary channel for assistance is email to your project assistant. You should also CC the senior person. Remember to include "TDDD63" in the subject of your mail.
This differs from many other courses where assistance is only available during a number of scheduled lab times, and has the advantage that you can ask questions any time of the day, any day in the week. We ask you not to seek out assistants in their offices unless the assistants themselves ask you to come, partly because the assistant may need to investigate the question to find correct answers and partly because each assistant also has other duties and needs to be able to plan his/her time accordingly.
In each mail you must 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!
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.
Support Sessions
In each of the first six weeks of the project, a single support session (resurstillfälle) is booked. Each session will take place in a PUL or another location where demonstrations are possible, depending on the project type – more information will be given by each senior person. The project assistant and possibly (but not necessarily) the senior person will be available at these sessions.
These sessions are not ordinary lab sessions where you will be working with your project and asking whatever questions occur to you at the time. Instead, the Q/A sessions are intended for certain types of questions that require a greater degree of interaction to be resolved. You must still ask each question by email well in advance, and it is then up to the assistant to decide whether the question will be answered by email or referred to the Q/A session! This is because the assistant may need some time to fully understand the problem and to do some initial research to find the correct answer.
We repeat that these are not ordinary lab sessions. Questions that have not been sent in by email in advance can be deferred to another time at the assistant's discretion. When all submitted questions have been discussed, the assistant will leave. If no questions have been scheduled, the assistant will not visit the lab.
Progress Report Sessions
In addition to the support sessions, where only some groups may be present, there will also be a progress report session in each of the first six weeks. The sessions are mandatory for all project participants. If you are sick, mail the assistant before the session starts. Traveling or recreational activities are not valid reasons for not participating.
The main intention behind these sessions is to give you a chance to present and demonstrate what you have done so far and what you plan to do in the near future, allowing us to see your progress continuously and provide additional comments and guidance. As for support sessions, each report session will therefore take place in a PUL or another location where demonstrations are possible, depending on the project type.
The project assistant and possibly (but not necessarily) the senior person will be present. The assistant is your main audience: Other groups may also be present, but the groups that are not reporting at any given time may work at their computers.
Preparation. At least 24 hours before the session begins, each group must send in the current version of their code, code documentation and user manual to both the assistant and the senior person. The entire package should be sent as a single archive in ZIP or tar.gz format.
Report. During the session, each group will give a presentation / demonstration / discussion of their current progress. Approximately 12 minutes will be available for each group. Use this time wisely, and be well prepared! Given the limited time available, assistants do not generally help you solve your current problems during report sessions.
The following topics will be covered, in addition to any questions the assistant may choose to ask. Remember that all project members must be able to answer questions about any part of the project, as stated earlier. Presentation slides are not expected but can be used if you feel that they are helpful.
-
What is the current state of your project?
Most weeks you should be able to 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 the demonstration as an opportunity for feedback. At the same time you should generally have something that actually runs, as opposed to just having some code that won't even start. To make this possible you should save copies of your project whenever you feel the code is stable enough for demonstration – when it is actually time to demonstrate you might be in the middle of implementing a new feature, and then you need to be able to bring up a stable earlier version.
Be prepared – decide in advance 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? Do you foresee any new problems?
-
Do you feel there are any fundamental problems?
We want to 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!
Writing a User Manual
Though the main focus in this project is on writing code, you will also write a short and pragmatic user manual. In this manual you will not have to repeat generic information that is already known from the basic background of the project. Instead the focus should be on providing enough information for someone to be able to both start and actually use your software without too much previous knowledge.
The manual should be written incrementally during the project and continuously kept up to date with your current progress in terms of programming and software development. The current version will be sent to your assistant ahead of each progress report session as discussed above. If you are uncertain about the proper contents of the user manual, please make sure you make use of this opportunity to get continuous feedback.
In addition to the user manual you should also write a technical overview of your project. This overview should discuss the overall design of your software, as opposed to the more detailed code documentation that should generally be expressed in the shape of comments in the actual code. For example: How does the project work, how is the implementation structured, and so on?
Like the manual, the technical overview should be written incrementally during the project and continuously kept up to date with your current progress in terms of programming and software development. The current version will be sent to your assistant ahead of each progress report session as part of the code documentation. If you are uncertain about the proper contents, please make sure you make use of this opportunity to get continuous feedback.
At the end of the course, we would expect the technical overview to be approximately 3-5 pages.
Final Demonstrations
In the last week of the course there will be a special final demonstration session. This session is similar to the progress reports you have had throughout each project and takes place in the same location, the main difference being that you will be demonstrating the final version of your project and that you should 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 milestones for you to have a reasonable chance to finish them all, and/or leave projects very open-ended. However, you should still do your best to finish as many milestones as you can and you should clearly indicate at the demonstration which milestones have been completed.
If you feel that you are already finished at the end of week 6, you can also choose to make your final demonstration during the progress report session that week. Earlier final demonstrations are not accepted.
The final project code should normally be handed in at the final demonstration, together with the final versions of all related documents. In some cases you or the project assistants may prefer the code to be refined a bit before the final handin, in which case you have one more week before the final deadline, the end of Tuesday 18/12.
Final Presentations
For each class (C1, D1A, D1B, D1C) there will also be a special 2-hour final presentation seminar in the Visionen lecture hall in the B building. You must participate in the entire session where your project is presented, while participation in other sessions is voluntary.
Before this seminar, each group will prepare 5 presentation slides "selling" your project to a potential "client". For example: Here's what we have done, here's what is nice about it, this is why you want to use it, and so on. You should also practice giving this presentation a couple of times. Each group will have 7.5 minutes for their presentation, and this time limit is sharp. You might want to aim for 6 minutes to make sure your presentation will not be cut off once you're "on stage"!
Presentation slides can be made in a tool such as OpenOffice Impress or Powerpoint.
Deadlines
To pass this course you must finish the project within the course period. If this is not the case, your next opportunity to finish this course and receive the associated course credits will be by participating in a new project next year. This follows IDA's standard policies for computer labs and project work and is due to the fact that assistants and other people involved in the course have other duties after the course ends.
In particular, we have the following specific deadlines.
Each week, you must send in background information at least 24 hours before each progress report session, as discussed above.
In the last week, you must make a final demonstration of your project to the assistant. Make sure you demonstrate even if you wish you had been able to do more. Again, the alternative is doing another project next year.
In the last week, you must make a final presentation during a special session as discussed above.
By the end of Tuesday 18/12, you must hand in the final version of your code and all associated documents.
A direct consequence of these deadlines is that you should make sure to "round off" your project in time before the end of the period. Rather than working on additional features up to the final deadline, you should make sure that the features you have already implemented are functional to the extent possible and take a little bit of time to polish your work.
Grades
The only grades given for the programming project are U (Fail) and G (Pass).
The critieria for passing the course are not expressed in terms of code quantity or the number of milestones achieved. Such quantitative criteria are easy to measure but often do not correspond to actual knowledge being gained. What we care about is that you participate, work hard, show a practical understanding of programming, and learn a great deal. That you have learned can of course be shown by flawlessly achieving milestone after milestone, but also by making mistakes, explaining the mistakes, and demonstrating that you know better now. Your project assistant will try to help you stay on the right track, and the input you provide to the project assistant will influence your grade.
Page responsible: Patrick Doherty
Last updated: 2012-11-09
