The Rational Unified Process: An Introduction (3rd Edition)

BUILDING AN ITERATION PLAN

Now let's examine how to build a fine-grained plan for one iteration, an activity that you will repeat once per iteration. We have seen that the nature and focus of iterations vary over time from phase to phase. Although the criteria that we will take into consideration will vary through the lifecycle, the detailed recipe remains the same. So we take an iteration in the elaboration phase as our main example, and later we describe how iterations differ in other phases.

First, consider the iteration, its length, and the resources you have allocated to it to be the bounding box. The idea is to avoid a situation in which you first define ambitious goals and plan to achieve them, only to discover that one iteration is not enough. You must define only enough work to fill the iteration. You are scheduling by time and not by volume.

The iteration plan describes at a fine level of granularity what will happen in the iteration. It allocates activities to workers and allocates individuals to workers. (Remember that we use the term worker in a special sense; see Chapter 3.) A planning tool, such as Microsoft Project, is useful for handling the details, in particular the dependencies and allocation of tasks to individuals.

To build an iteration plan, follow these four steps:

1. Define objective criteria for the success of the iteration. You will use these criteria at the end of the iteration, in an iteration assessment review, to decide whether the iteration was a success or a failure.

2. Identify the concrete, measurable artifacts that will need to be developed or updated and the activities that will be required to achieve this.

3. Beginning with a typical iteration work breakdown structure, massage it to take into account the actual activities that must take place.

4. Use estimates to assign duration and effort to each activity, keeping all numbers within your resource budget.

Now let's look at how an iteration varies from phase to phase.

Iteration in the Elaboration Phase

There are three main drivers for defining the objectives of an iteration in the elaboration phase:

• Risk

• Coverage

• Criticality

The main driver to determine the iteration objectives is risk. You must mitigate or retire your risks as early as you can. This is especially the case in the elaboration phase, when most of your risks should be mitigated, but it can continue to be a key driver in the construction phase as some risks remain high or new risks are discovered .

But because the goal of the elaboration phase is to baseline an architecture, other considerations must come into play, such as ensuring that the architecture addresses all aspects of the software to be developed ( coverage ). This process is important because the architecture will be used for further planning: organization of the teams , estimation of code to be developed, and product structure of the development environment.

Although focusing on risks is important, you should keep in mind the primary missions of the system. It is good to solve all the difficult issues, but it must not be done to the detriment of the core functionality: make sure that the critical functions or services of the system are covered ( criticality ) even if no perceived risk is associated with them.

Let's assume that we have a current, up-to-date list of project risks. For the most damaging risks, identify a scenario in one use case that would force the development team to "confront" the risk. The following are two examples:

1. If there is an integration risk, such as "database D working properly with OS Y," be sure to include one scenario that involves some database interaction even if it is only a modest one.

2. If there is a performance risk, such as "excessive time to compute the trajectory of the aircraft," be sure to include one scenario that includes this computation, at least for the most obvious and frequent case.

For criticality, make sure to include the most fundamental function or services provided. Select some scenarios from the use cases that represent the most common, or the most frequent, form of the service or feature offered by the system.

For example, for a telephone switch, the plain station-to-station call is the obvious "must" for an early iteration. It's far more important to get this right than to perfect the convoluted failure modes in operator configuration of the error-handling subsystem.

For coverage, toward the end of the elaboration phase, include scenarios that touch areas you know will require development even if these scenarios are neither critical nor risky.

It is often economical to create long end-to-end scenarios that address multiple issues at once. For example, suppose that one single scenario is critical and confronts two technical risks. Try to achieve some balance and avoid scenarios that are too "thick" too early ”that is, scenarios that try to cover too many aspects, variants, and error cases.

Also, in the elaboration phase, keep in mind that some of the risks may be of a more human nature, such as managing change, fostering a team culture, training workers, and introducing new tools and techniques. Simply reviewing them during an iteration tends to mitigate these risks, but introducing too many changes at the same time becomes destabilizing.

The following are four examples of iteration objectives :

1. Create one subscriber record on a client workstation; the record is to be stored in the database on the server, including user dialog but not including all fields; assume that no errors are detected .  

   This scenario combines critical functions with integration risks (database and communication software) and integration issues (dealing with two different platforms). It also forces designers to become familiar with a new GUI design tool. Finally, it leads to production of a prototype that can be demonstrated to end users for feedback.

2. Make sure that as many as 20,000 subscribers can be created and that access to one subscriber takes no longer than 200 milliseconds .  

   This scenario addresses key performance issues (data volume and response time) that can dramatically affect the architecture if they are not met.

3. Undo a change of subscriber address.  

   This scenario picks a simple feature that forces you to think about a design of all "undo" functions. This may, in turn , trigger the need to communicate with the end users about what can be undone at reasonable cost.

4. Complete all the use cases relative to supply-chain management.  

   The goal of the elaboration phase is also to complete the capture of requirements.

Iteration in the Construction Phase

As the project moves into the construction phase, risks remain a key driver, especially as new and unsuspected risks are uncovered. But the completeness of use cases also becomes a driver. You can plan the iterations feature by feature, trying to complete some of the more critical ones early so that they can be tested thoroughly in more than one iteration. Toward the end of the construction phase, the main goal will be to ensure coverage of full use cases.

The following are examples of iterations in this phase:

1. Implement all variants of call forwarding, including erroneous ones.  

   This is a set of related features. One of them may have been implemented during the elaboration phase, and it will serve as a prototype for the rest of the development.

2. Complete all telephone operator features except night service.  

   This is another set of features.

3. Achieve 5,000 transactions per hour on a two-computer setup.  

   This may increase the required performance relative to what was actually achieved in the previous iteration (only 2,357/hr).

4. Integrate new version of geographical information system.  

   This may be a modest architectural change, perhaps necessitated by a problem discovered earlier.

5. Fix all level 1 and level 2 defects.  

   This fixes the defects discovered during testing in the preceding iteration that were not fixed immediately.

Iteration in the Transition Phase

The main goal is to finish this generation of the product. Objectives for an iteration are stated in terms of which bugs are fixed and which improvements in performance or usability are included. If you had to drop (or disable) features to get to the end of the construction phase (the IOC milestone, or first beta) on time, you can now complete them or turn them on if they won't jeopardize what has been achieved so far.

The following are five examples of iteration goals in this phase:

1. Fix all severity 1 problems discovered at beta customer sites.  

   A goal in terms of quality, this may be related to credibility in the market.

2. Eliminate all start-up crashes caused by mismatched data.  

   This is another goal expressed in terms of quality.

3. Achieve 2,000 transactions per minute.  

   This is performance tuning and involves some optimization: data structure change, caching, and smarter algorithms.

4. Reduce the number of different dialog boxes by 30%.  

   Improve usability by reducing visual clutter.

5. Produce German and Japanese versions.  

   The beta was produced only for English-speaking customers because of the lack of time and to reduce rework on the beta release.

Detail the Work in the Iteration

Now that we have objectively defined the pending iteration's goal, we can proceed to the detailed planning stage, as for any other project.

After the scenarios or full-blown use cases to be developed (plus defects to be fixed) have been selected and briefly sketched, you must determine the artifacts that will be affected:

• Which classes are to be revisited?

• Which subsystems are affected or created?

• Which interfaces probably need to be modified?

• Which documents must be updated?

The next step is to identify in the Rational Unified Process the activities that are involved and to place them in your project plan. Some activities are done once per iteration (building an iteration plan), whereas others must be done once per class, per use case, or per subsystem (designing a class). Connect the activities with their obvious dependencies and allocate an estimated effort. Most of the activities described in the process are small enough to be accomplished by one person or a small group of people in a matter of a few hours or a few days.

You will probably discover that there isn't enough time in the iteration to accomplish all this work. Rather than extend the iteration (and thereby extend the final delivery time or reduce the number of iterations), reduce the ambitiousness of the iteration. Depending on which phase you are in, make the scenarios simpler or eliminate or disable features.