Iteration 1

In Iteration 0: Project Elaboration, you addressed the essential technology used by your project. In this iteration, you should be able to add many more use cases.

The Development Process

In general, the purpose of an iteration is to implement use cases of highest value: They reduce risk and/or increase business value.

You should:

  1. Identify more use cases via team meetings.
  2. Rank the unimplemented use cases as a function of their risk and business criticality.
  3. Select the highest rank use cases.
  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, revise your architecture so that it resolves the key technical issues.
  6. Update your domain model (Please see chapter 9).
  7. Implement the use cases, using your domain model as a guide.
  8. 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.

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 documents.

Deliverables

Project Documents

Writing quality is important. In all your documents, including Java documentation, be clear, succinct, and precise.

All deliverables for previous iterations are deliverabe for this and subsequent iterations. Update these documents to reflect this iteration's use cases.

In your architecture document, include a package diagram to convey your architecture's layers. To convey the elegance of your object-oriented design, it is helpful to display class diagrams of key classes and interfaces, showing "isa" (inheritance), "implements" (interface) and "hasa" relations—both composition and aggregation. If these diagrams seem more complicated than you would have guessed, you may wish to identify the source of the complexity and refactor.

Deliver the following new documents:

Javadoc

Javadoc all non-private attributes and methods for all domain model classes. Use the @author tag for each class that you Javadoc. Use the -author option when you run javadoc. Here are some guidelines for authoring good Javadoc.

Technology We Learned:

Give a web page that enumerates all technology that you learned for your project (i.e., was not learned in previous CMPSC courses). Technology that you use and is new to you that can be in your list includes:

Client Demonstration Instructions:

Give a clear, detailed, complete and correct sequence of instructions for demonstrating your project to the client (the instructor), starting from your Java source code and non-Java resources. Debug your instruction sequence.

The Project Itself

Make available on your team web site all the files needed to build and run your project.

Submission Procedure

Jar all Java source files and non-Java files that you need to build and run your project. Include in that jar file all deliverable documents. If including such documents in a jar file is, for any reason, inappropriate, propose as soon as possible an alternate method for transmitting this information when it is due.

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