Deliverable #2 - Initial Project Analysis

While you are JUST getting started with this project, it is important to get off on the right foot.  In order to do this I would like each team to conduct an initial project analysis to start to define the scope/magnitude of their project domain as well as the boundaries of their specific project.  At this point this is NOT a contract with what you WILL accomplish, but a fact finding mission so that you can begin to discover where you might go in preparation for a formal proposal (which will become your contract of sorts).

This deliverable will consist of two parts - a printed deliverable and an in-class presentation of the contents of that deliverable.

The printed deliverable should consist of a 3-4 page document which should contain sections addressing the following information:

• A description of the project problem domain. This description should answer the questions:
  • What is the initial problem you want to address?
  • What types of users might use your  program?
  • What approach(es)  would users currently use to address this problem.  This might be paper/pencil based or computer based, but either way, make sure you fully explain what it is that a user would currently do.
  • Why is this current approach (or multiple approaches) currently insufficient?
  • What do you hope to "improve" with your project?
  • What types of things will users try to accomplish with this program?
  • What context of use is relevant to the project? (For example, must it work real time or can parts of it be accomplished offline.  Do you  envision users interacting directly with your system or is your system plugged in to the back of some other software/system?  If you were selling this system would you sell it to the end user or some intermediary service? etc.
  • What kind of data and/or knowledge will be needed to run your system?
  • Where will you obtain that data/knowledge (is it seeded, learned, a combination of approaches?)

• A description of where your group wants to focus, and your particular strengths (as a team) in that area.  It is not always necessary to do a complete design or application -- for some projects it will be most valuable to focus on a particularly difficult part of an existing system or process.  When you're looking for an advantage, familiarity with the domain, with existing applications, etc., can all help you.  Feel free to include a list of "out of scope" items, if you want to be clear in managing our (and your) expectations.

• A description of the tools and environment you expect to use for the project. Is this a project that can be completed in Java? Will you be developing a Visual Basic application? How will you conduct version control with your project?

The grade on the project analysis will be based on the evidence that you understand the project, the existing solutions, and the project environment. Length is not a good indicator of quality; excessive detail often reveals insufficient understanding and thought. Poor proposals, and proposals for projects that are rejected as inappropriate, can be revised and re-submitted before our next studio.

In addition to the printed document that I will grade, it is expected that you will prepare a 20 minute presentation on these materials to share with your classmates.