Chapter 3: Starting
Now that the most important stuff is out of the way, let's take a closer look at what you're actually supposed to be doing.
For the purposes of this guide, these have three characteristics. First, learning how to work in a team is a goal of the course. This distinguishes these courses from (for example) upper-level courses in operating systems or computer graphics, in which you're working in a team but not being taught explicitly how to do so.
Second, your grade depends primarily on the software you build. You may also be required to write reports and sit an exam, but these are based on the practical work—if you don't actually build some software, you can't pass the course.
Finally, you are supposed to work as if you were trying to meet the needs of a real customer. You might start with a blank sheet of paper or have to fix and extend an existing application; either way, you and your team are responsible for some or all of requirements analysis, design, implementation, testing, documentation, packaging, deployment, handoff, and review.
Why Projects?
Project courses exist for several reasons:
- To teach you things that can only be learned by doing
- If you pursue a career in industry, or if you go stay in academia and do anything other than pure theory, you will need to know how to build things. This is a craft, not a science: you can't learn how by listening to lectures any more than you can learn to ride a bike by watching the Tour de France on TV.
- To tie everything you've learned together
- i.e., to demonstrate that the trees and pointers and joins and semaphores you've been wrestling with for the last two or three years are actually good for something.
- Because they're fun
- At least, if they're done right.
...
Backlinks