Iteration 0: Project Elaboration

Like Project Inception, calling this iteration Project Elaboration is a bit of a misnomer. Project elaboration typically requires several iterations. To satisfy the time constraints imposed by a 10-week course, our project elaboration constitutes 1 iteration.

The Project Elaboration Process

In general, the purpose of this phase is to:

  1. Build the core architecture
  2. Resolve the high-risk elements
  3. Define most requirements
  4. Estimate the overall schedule and amount of needed resources.
In this course, elaboration entails the first 3 of these activities.

You should:

  1. Write most of the use cases and their descriptions in detail, through a series of team meetings.
  2. Rank the use cases as a function of their risk and criticality.
  3. Select the highest rank use cases, attempting to ensure that the set chosen covers the core architecture.
  4. For each selected use case:
    • Identify pre-conditions and post-conditions. (Please see section 6.9)
    • Identify key technical issues.
    • Describe a correctness test or tests.
  5. For the set of selected use cases, design an architecture that resolves the key technical issues.
  6. If your project will use a database, develop database schemas for the selected use cases. If these database schemas will evolve in subsequent iterations, devise a database migration plan.
  7. Create a domain model (Please see chapter 9).
  8. Implement the use cases, using your domain model as a guide.
  9. Implement your use case tests (requirement tests). Test your system early and often, to ensure that it passes the use case tests, and that the implementation of new use cases does not cause previously successful requirement tests to fail.

Expect the process above to precipitate changes in essentially all of your Project Inception documents. Although the process above was described sequentially, it typically includes a lot of feedback. For example, writing preconditions, postconditions, and tests may cause you to alter the use case itself (e.g., to be more easily tested). These changes, in turn, may cause you to modify your vision or Supplementary Specification, and add to, or modify, your glossary. Resolving key technical issues often is a source of dramatic change to your use case model and other Project Inception documents.

Deliverables

This iteration has much more, and more complex, deliverables than the project inception. To produce quality deliverables on time, your team will benefit from working smart.

Project Documents

Quality writing is important. Endeavor in all your documents, including Java documentation, to be clear, succinct, and precise.

Use Case Model

This now should be nearly complete, with detailed descriptions of each use case. For the use cases that have been selected for implementation during this iteration, give preconditions and postconditions (please see chapter 6).

In addition to improving and expanding each of the documents created in the project inception, your project web site should add the following documents:

Project Development Principles

Declare a set of software development principles for your project. These can be anything you like, and need not be original. For example, you could take the Agile Principles as your own. Consciously commit to the principles you select: They are your principles.

Architecture

Your architecture answers the question: What are the big ideas in your project with respect to motivations, constraints, organization, design patterns, and responsibiities.

As noted above, for the set of use cases that you have selected for implementation, enumerate the key technical issues. For each such issue, describe how the architecture of your system resolves the issue.

Various UML diagrams are welcome here. For example, you may include a package diagram to convey your architecture's layers. To convey the elegance of an object-oriented design, it is helpful to display class diagrams of key classes and interfaces, showing inheritance and interface relations, and inter class associations, especially "hasa" relations.

Download/Deploy

If your project is a desktop application, explain how to download, install, and launch your project. If your project is a web application, give system administration instructions for bringing up your application (e.g., set up the web server, etc.). If you are not in charge of the web server, give the sequence of instructions to deploy a new version of your system to the web service that you use. If your project is a smart telephone application, explain what needs to be done to run a simulation.

User Guide

Provide a user guide that explains the use of the project with respect to the use cases delivered. Maximally leverage the organizational and content commonality between your user guide and your use case model. Your development process should ensure that these documents stay synchronized.

Libraries

Name any libraries and resources that your system uses or installed software that it depends on (e.g., Ant).

Postmortem

Give a distinct postmorten for this iteration. What went well? What did not go well? What would you do differently, if you were to do it again? What will you do differently for the rest of the project? Should you refine your project development principles?

The Project Itself

Your web site contains documents that describe your project. Also provide access to the project itself: links to distinct directories for the following:

Submitting Deliverables

In manner that is a mutually agreed upon by your team and the instructor, provide your entire project as of the due date for this iteration. For exampe, no later than the due date and time, mail the instructor a jar, tar, or zip file containing your entire site, including the project code, etc.

 cappello@cs.ucsb.edu © Copyright 2010 Peter Cappello                                           2010.11.16