TDDD63 7 hp / Perspectives in Computer Science and Computer Engineering (7 ECTS)
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. Skip this at your own risk!
Read this entire document!
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 always 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!
At the beginning of the course you signed up in WebReg for a set of initial quizzes. In the middle of the first period you signed up once more, this time for your preferred project type. We will divide everyone who has signed up into groups. Preferences will be taken into account to the greatest amount possible, but we also have to take into account limitations in equipment, space and supervision. Group assignments will be published before the beginning of the second period. This has similarities to working at a software company, where you cannot expect to personally choose your coworkers.
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.
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 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!
Your project assistants may ask any project member to explain any part of the code!
Project Types and Project Instructions
Several different types of project will be available, and several groups will perform the same type of project. 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 other day-to-day contact with each project group.
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.
Introductory Phase. At the end of the first period 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.
Six supervised lab times are scheduled in the introductory phase. This is intended to help you get off to a good start with the project. You are expected to spend more time on the exercises outside these lab times and finish the introductory phase before the start of the second period!
You should be present during most of the supervised lab times so that the assistant can see your progress. You will also have to demonstrate your solutions to the initial exercises.
Main Phase. 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. Investigate, explore, and write a lot of code!
In most weeks there will be two four-hour labs in your schedule. The intention here 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. More information will be given once the final schedule for the second period is officially published.
There will usually also be one two-hour progress report session during which you will discuss your current progress with your project assistant.
Again, you must spend more time on the project outside these lab times! The scheduled lab times only correspond to around half of the total time you should spend. For the remainder of the work you will need to find time outside the schedule.
The following is a rough outline of the project timeline. Details about deadlines and scheduling are discussed later.
|Week 38 (130916-130922)||Project lecture|
|Week 39 (130923-130929)||Project signup in Webreg.|
|Week 40 (130930-131006)||Project groups and assignments are announced.|
|Week 41 (131007-131013)||Introductory phase begins.|
|Week 42 (131014-131020)||Introductory phase week 2.|
|Week 43 (131021-131027)||Final lab in the introductory phase.|
|Week 44 (131028-131103)||Exam period.|
|Week 45 (131104-131110)||Main phase begins.|
|Week 46 (131111-131117)||Main phase week 2.|
|Week 47 (131118-131124)||Main phase week 3.|
|Week 48 (131125-131201)||Main phase week 4.|
|Week 49 (131202-131208)||Main phase week 5.|
|Week 50 (131209-131215)||Main phase week 6.|
Possible (but not mandatory) to demonstrate your project.
|Week 51 (131216-131222)||Final polish for the projects.|
Deadline for project demonstrations.
Final presentations in larger sessions.
IDA has a central server running the Subversion version control system. Before the project starts (131008) we will set up accounts for every group on this server.
Version control systems essentially allow you to store and keep track of multiple versions of your code, documents and files. By regularly checking in the current version as you implement new features and resolve bugs, you will be able to:
- Keep track of what has been changed, when, and by whom.
- Retrieve and merge the latest changes checked in by other project members, without manually emailing versions back and forth.
- Provide a specific version of the code to your assistant simply by giving him a revision number, rather than mailing your code.
- Revert to an old version if you realize that you made a bad change, without manually copying versions and getting directories such as "project", "project-old", and "project-really-the-newest".
- See exactly what you have done since last week's progress report.
- ...and so on.
As already stated, we will use Subversion in this course – this is not optional. Follow the version control instructions and check in your code regularly.
While we know some of you will prefer other systems and we would prefer to be able to accommodate these wishes, using the centrally installed Subversion server allows the assistants to access every group's code in the same way and facilitates keeping track of current progress across many project groups.
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, you should primarily ask your project assistant during scheduled lab times. If the question is more urgent, you can send an email. We ask you not to seek out assistants outside scheduled lab times unless the assistants themselves ask you to come: each assistant also has other duties and needs to be able to plan his/her time accordingly.
If you send questions by 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.
Progress Report Sessions
Throughout the main phase, there will be a progress report session each week. These sessions are mandatory for all project participants. If you are too sick to be able to go to the university, mail the assistant before the session starts. Traveling, recreational activities etc. 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.
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 in the room, but the groups that are not reporting at any given time may continue working with the project at their computers.
Preparation. By 07.30 the day of the progress session, each group must send in a brief progress report in plain text or PDF format to the assistant. This report should cover the following.
What have you done in the project during this week? (Describe the code that you have implemented, problems you have had, bugs you have fixed, information you have gathered, ...)
Which milestones or tasks had you already completed last week? Which new milestones/tasks have you completed this week? (Specify the numbers or names of the milestones/tasks, depending on how they are specified in your project specification.)
Report. During the session, each group will give a presentation / demonstration / discussion of their current progress. Approximately 6-7 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?
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. Keep track of "working" revision numbers in the version control repository so that you can bring back a stable working version before the report session if necessary.
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!
Though the main focus in this project is on writing code, you will also write a short document. The contents of this document will be specific to each of the five project types. Its length would typically be 3-6 pages. This must be handed in during the last week of the project. Further information will be given in the project-specific instructions.
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 tasks 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 tasks as you can and you should clearly indicate at the demonstration which tasks 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 must be handed in by 140110. Feel free to hand in the code earlier.
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 around 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.5 minutes to make sure your presentation will not be cut off once you're "on stage"!
Both movies and live demonstrations are allowed (and encouraged). Just remember that during most of the presentation you should be presenting. A five minute movie where you just stand beside the screen is not a good idea, for example.
We expect that most of you already have your own computers on which you want to run the demonstrations. If not, you need to tell the senior person responsible for the project at least one week before the presentation, and we need the actual presentation materials two days before the presentation!
Be prepared, and have your computers "running" before you present (there are electrical outlets at every chair so you don't have to worry about losing battery power). Make sure you know how to force the laptop to show a picture on the external (VGA) port even if it doesn't detect a projector there. Be in Visionen in time and try connecting the computer to the projector during the break.
Presentation slides can be made in a tool such as OpenOffice Impress or Powerpoint.
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.
In the last week, you must hand in the final version of your documentation.
By 140110, 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.
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 tasks 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: Jonas Kvarnström
Last updated: 2013-11-20