Project Inception
It is a bit of a misnomer to call this step inception. In the inception step, the team does not necessarily commit to doing the project that is being explored. However, for this class, the project described in the "inception" step is your course project.
Project Selection Guidelines
This course is about analyzing problems and designing programs. It is not primarily about programming, at least not programming at the method or class level. What we are looking for in projects therefore are problem domains that are have design interest: They have around two dozen key concepts, and interesting relationships between these concepts.
Suppose you have a choice between two projects, A and B:
Project A - GOOD Choice Project B - POOR Choice Has many concepts with complex relationships between them, but each resulting class is simple to implement. Has fewer concepts, and classes are difficult to implement due to tricky algorithms and/or fancy graphics.
Project Ideas
- Here are some really old suggested projects from previous CS 50 instructors (any "I" on that page probably refers to Professor Acharya, the Spring 1998 instructor).
- Here is a list of prior CS 50 projects, completed by selected classes over the past several years (sorry, no descriptions available).
- Working examples of games (always a popular choice) are widespread, as at the MSN and Sony sites.
- Or just look around! Fill a need. Do something fun. We will approve almost any project idea ... as long as it minds the project rules.
Inception Process
Meet as a team, preferably over several days, to perform what probably will be a 3-phase process:
- Brainstorm (i.e., uncritically search) for project ideas.
- Critically examine each idea to explore its suitability, considering both the desires of the team members and the needs of the course.
- Select a few use cases to analyze in depth that are architecturally significant and/or high risk and/or of high impact. This result of this analysis may cause you to return to step 2.
The above process is different from a typical project inception, because it is intended to satisfy the constraints imposed by a 10-week course.
Deliverables
One member of each team sends an e-mail whose subject line is "CS 50 project inception" to the instructor. The message should include a url to a web site with the following information:
Project Title
Give a 1-sentence description of your project.
Team
Give full team names & email addresses (display addresses so that crawlers do not harvest them).
Vision & Business Case
Tersely communicating the project's big ideas, it describes high-level goals and constraints, and the business case. See section 7.6 of textbook for an example and section 7.7 of textbook for guidelines.
Use Case Model
The use case model is a set of typical scenarios of using the system. They primarily are for describing the system's functional requirements. During inception, the names of most use cases are identified. Perhaps 10% of the use cases are analyzed in detail. Use a casual style for your use cases: a title followed by a terse informal paragraph or paragraphs that describe various scenarios. See sections 6.1 and 6.2 of the text for examples. Chapter 6 of the textbook gives good guidelines for discovering and writing use cases.
Supplementary Specification
This contains non-functional aspects of the system (e.g., performance). See example in section 7.4 and 7.5 of textbook.
Glossary
It defines noteworthy terms. See section 7.8 of the text for an example. You do not need to include any data dictionary aspects for the inception.
References
This section is a repository of all references (e.g., other or related work). Definitely include all web references.
Postmortem
This, by definition, is very last thing you do before you turn in your work. During this process, what went well and what did not go well. What would you do differently, if you were to do inception again? What will you do differently for the rest of the project?