CS 342: Mobile Application Development
Detailed project description and development plan
Based on your short project description and user stories, your mockups, and
the feedback you received, it's time to write a more detailed project plan. This
should be a document between 2 and 5 pages long, or possibly a bit longer,
depending on how many mockup images it contains.
The first two sections of the document
(description and use cases) should be written for an audience of intelligent non-programmers.
For the four groups who are working with outside clients, those clients would be the
non-programmer audience. The remainder of the document should be written for an
audience of programmers who are not yet familiar with your project. Don't assume
anybody already knows what you are talking about.
Write this seriously, as though it would be shared with paying clients or
your boss at a real job. Serious writing doesn't have to be boring--it can
even be funny sometimes. But you should keep the needs of your audience in mind,
take care with formatting, spelling and grammar, pay attention to
clarity and precision of expression, and so on.
Here's what your project plan should contain.
- The name of your app, followed by a short descriptive subtitle.
- A one-paragraph description of the app.
- A list of the app's essential use cases. (You should highlight
between three and five of the most important actions a person could
take with your app.) Each use case should consist of:
- A statement of a goal or desire of a prototypical user of your app.
(I use A, B, C names for this: Alice, Bob, Clara, Daniel, etc. For
example: "Alice wants to know the first person plural past conditional
form of the French verb 'dormir'.")
- A concise step-by-step description of the actions the person
would take to achieve the stated goal.
- One or more screen mockups illustrating the person's steps.
- A short description of each of the main data models your app will need. You may
describe your models in prose, or as a combination of prose plus Java or Objective-C
class interfaces. For example, my dictionary apps depend on a "dictionary data source" that gives
bilingual dictionary translations with parts of speech, example
phrases, etc. It also depends on a "language data source" that has single-language
information, like how to conjugate verbs in that language, or how to form
plural nouns. A detailed description of these two main data models would
be quite lengthy. I would probably give a couple sentences of background, and then
just give the signatures for the most important methods in the DictionaryDataSource
and LanguageDataSource classes.
- A development plan. This should consist of a chronological list of small steps you will take
to go from nothing to an app that achieves all the use cases listed above. Each
step of your development plan should include two parts:
- a description of a feature that one developer could complete in one or two full-time days
- a description of how you will test the resulting feature(s), including whether the
test could be automated
Some of these features will be user-facing, and some of them will be internal. Keep the descriptions
concrete enough that someone who is not you would be able to start work on the feature without
coming to ask you lots of questions about what you meant.
Ideally, you will be able to cluster these features into work that can be done in parallel, which
will help you divide the work among your team members. As a simple example, projects with a server
side can start with the whole team agreeing on the design of an HTTP-based API, and then the team
can split into implementers of the server side and the client side. As another example, if you have a
tabbed interface, one person could work separately on each tab.
- A short list of risks for your project, and what you can do to mitigate the risk.
For example, a risk might be "We may not be able to get GPS to work in the arb" with a
mitigation of "we could restrict our app's range to the main campus."
- A short list of support you need or want (e.g. web server space with a 10MB database quota, or an
example of multi-threaded iOS code from Jeff, or...).