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

WORKFLOW

Figure 7-3 illustrates an iteration in project management in UML activity diagram form. Each activity state represents a workflow detail in the Rational Unified Process, for example, Conceive New Project. Each workflow detail, in turn , is composed of one or more activities. Observe that some workflow details are time-dependent. For example,Conceive New Project is performed only once, at the start of the project, and Close-Out Phase is performed only when terminating the final iteration of each phase.

Workflow Details

The workflow is decomposed into a set of workflow details.

Conceive New Project

This workflow detail is composed of the activities identify and assess risks, develop business case, and initiate project, performed by the project manager, and the project approval review, performed bythe project reviewer. The purpose of this workflow detail is to bring a project from the germ of an idea to a point at which a reasoned decision can be made to continue or abandon the project.

Evaluate Project Scope and Risk

This workflow detail is composed of the activities identify and assess risks and develop business case, performed by the project manager. The purpose of this workflow detail is to reappraise the project's intended capabilities and characteristics, and the risks associated with achieving them. This evaluation is done once after the preferred approach is chosen and the project is initiated, to give a solid basis for detailed planning, and then at the end of each iteration, as more is learned and risks are retired .

Develop Software Development Plan

This workflow detail is composed of the activities:

• Develop measurement plan.

• Develop risk management plan.

• Develop product acceptance plan.

• Develop problem resolution plan.

• Define project organization and staffing.

• Define monitoring and control processes.

• Plan phases and iterations.

• Compile software development plan.

These are performed by the project manager, and the project planning review is performed by the project reviewer.

The purpose of this workflow detail is to develop the components and enclosures of the software development plan and then have them formally reviewed, for feasibility and acceptability to stakeholders and as the basis for the fine-grained plan for the next iteration (the iteration plan). The major effort in creating these artifacts comes early in the inception phase; thereafter, when this workflow detail is invoked at the beginning of each iteration, it is to revise the software development plan (and its enclosures) on the basis of the previous iteration's experience and the iteration plan for the next iteration. The project manager will also collate all other contributions to the software development plan.

Plan for Next Iteration

This workflow detail is composed of the activities develop iteration plan, develop business case, and the workflow detail develop software development plan, performed by the project manager, and the iteration plan review, performed by the project reviewer. The purpose of this workflow detail is to create an iteration plan, which is a fine-grained plan, to guide the next iteration. After creating the plan, adjustments may be needed to the software development plan (for example, if planning the next iteration changed the allocation of functionality to subsequent iterations) and the business case (for example, if costs change, or the return-on-investment calculation is affected by changes to the availability dates of important features in the software).

Monitor and Control Project

This workflow detail is composed of the activities schedule and assign work, monitor project status, handle exceptions and problems , and report status , all performed by the project manager, and the project review authority (PRA) review , performed by the project reviewer. This workflow detail captures the daily, continuing work of the project manager and covers:

• Dealing with change requests that have been sanctioned by the change control manager, and scheduling these for the current or future iterations

• Continuously monitoring the project in terms of active risks and objective measurements of progress and quality

• Regularly reporting project status, in the status assessment, to the project review authority, which is the organizational entity to which the project manager is accountable

• Dealing with issues and problems as they are discovered and driving these to closure according to the problem resolution plan

Manage Iteration

This workflow detail is composed of the activities acquire staff, initiate iteration, and assess iteration, all performed by the project manager, and the iteration evaluation criteria review and the iteration acceptance review, both performed by the project reviewer. This workflow detail contains the activities that begin, end, and review an iteration. The purpose is to acquire the necessary resources to perform the iteration, allocate the work to be done, and finally, to assess the results of the iteration. An iteration concludes with an iteration acceptance review, which determines, from the iteration assessment artifact, whether the objectives of the iteration were met.

Close-Out Phase

This workflow detail is composed of the activities prepare for phase close-out, performed by the project manager, and the lifecycle milestone review, performed by the project reviewer. In this workflow detail, the project manager brings a phase to closure by ensuring the following:

• All major issues from the previous iteration are resolved.

• The state of all artifacts is known (through configuration audit).

• Required artifacts have been distributed to stakeholders.

• Any deployment (e.g., installation, transition, training) problems are addressed.

• The project's finances are settled, if the current contract is ending (with the intent to recontract for the next phase).

A final phase status assessment is prepared for the lifecycle milestone review, at which phase artifacts are reviewed. If project state is satisfactory, sanction is given to proceed to the next phase.

Close-Out Project

This workflow detail is composed of the activities prepare for project close-out , performed by the project manager, and the project acceptance review, performed by the project reviewer. In this workflow detail, the project manager readies the project for termination. A final status assessment is prepared for the project acceptance review, which, if successful, marks the point at which the customer formally accepts ownership of the software product. The project manager then completes the close-out of the project by disposing of the remaining assets and reassigning the remaining staff.

Let us now examine some important aspects of these activities in more detail.

Building a Phase Plan

To start building a phase plan, you need at least a rough estimate of the " size of the mountain." You must consider, for example:

• How high is it (total effort)?

• When do I need to arrive at the top (date of final release)?

You then work backward from the end date to "plant" tentative dates for the major milestones.

Staff/Schedule/Scope Trade-off

Many studies (and common sense) have shown again and again that you cannot trade staff for schedule. This is the classic example: "If it takes nine months for a woman to make a baby, why can't we have nine women produce one in a month?" Experience also shows that "adding people to a late project delays it further." You can use a cost model, such as COCOMO, to validate that you have the right relationship between effort, elapsed time, and staffing level.

To reach a reasonable ratio in your product's first generation, you usually must trade off features, or you must be creative in other ways, such as increasing reuse. Note that you could trade off another parameter ”quality ”but that is another discussion.

The Rubber Profile

After you have an idea of the limits of the three variables , you must shape your effort profile and refine the dates of milestones, taking into account the specific circumstances of your project. To do this you can start from a typical profile. The profile in Figure 7-4 shows the relative duration and effort per phase. It is suitable for a project that has the following characteristics:

• Is of moderate size and effort

• Is in an initial development cycle

  Table  7-1. Relative Weight of the Phases of Schedule and Effort for a Typical Project

  Phase	Schedule	Effort
  Inception	10%	5%
  Elaboration	30%	20%
  Construction	50%	65%
  Transition	10%	10%

• Has no preexisting architecture

• Has a small number of risks and unknowns

Table 7-1 shows the profile in tabular fashion.

Now let's assume that this profile is made of rubber. Let's stretch it and massage it to fit your circumstances using the following heuristics:

• If you need a long time to scope the project, find the funding, conduct market research, or build an initial proof-of-concept prototype, stretch the inception phase.

• If you have no architecture in place, if you envisage using new and unknown technology, and/or if you have severe performance constraints, a number of technical risks, and a lot of new staff, lengthen the elaboration phase.

• If this is the second generation of an existing product (an evolution cycle) and if you will make no major changes to the architecture, shrink the inception and elaboration phases.

• If you must hit the market quickly ”because you are late or because you are creating the market ”and plan to finish the product gradually, you can shorten the construction phase and lengthen the transition phase.

• If you have a complex deployment, such as replacing an old system without interruption of service, or if you have regulatory requirements to satisfy or certification to obtain (as in domains such as medical instrumentation, nuclear industry, avionics , and public telephony), you may have to stretch the transition phase.

Again and again, verify that you are not overstaffing the project.

Another element to consider is how many iterations you will perform in each phase. Before deciding this, let's first discuss the issue of the duration of an iteration.

Duration of an Iteration

We have defined an iteration as a nearly complete miniproject in which you go through all major workflows, which results, in most cases, in an executable, yet incomplete, system. Although the cycle (edit, compile, test, debug) sounds like an iteration, it is not what we have called iteration here. The daily or weekly build, in which you incrementally integrate and test increasing numbers of elements of the system, may sound like an iteration, but such builds are not what we call an iteration. An iteration starts with planning and requirements and ends with a release, either internal or external.

Ideally, an iteration should span from two to six weeks, but this varies from project to project. How quickly you can iterate depends primarily on the size of the development organization. Here are some examples:

• Five people can do some planning on a Monday morning, have lunch together every day to monitor progress, reallocate tasks , start doing a build on Thursday, and complete the iteration by Friday evening.

• With 20 people, achieving this scenario would be rather difficult. It would take more time to distribute the work, synchronize the subgroups, and integrate. An iteration might take three or four weeks.

• With 40 people, it takes a week for the nervous influx to go from the brain to the extremities. You have intermediate levels of management, and the common understanding of the objective will require more formal documentation and more ceremony. Three months is a more reasonable iteration length.

Other factors come into play: the degree of the organization's familiarity with the iterative approach; the stability and maturity of the organization; and the level of automation used by the team to manage code (for example, distributed configuration management), distribute information (such as through an internal Web),

Table  7-2. Iteration Duration for a Range of Interative Projects

and perform testing. Also, be aware that an iteration has some fixed overhead for planning, synchronizing, and analyzing the results.

Convinced by the tremendous benefits of the iterative approach, you might be tempted to iterate furiously, but the human limits of your organization will cool your fervor.

Although this is just an empirical approach, Table 7-2 gives some order of magnitude of iteration duration we collected on a few actual iterative projects. ^[5]

^[5] Joe Marasco looked at this sample of projects and noted that the duration, D , in weeks, was related to the size of the project, S (in thousands of lines of code), by the formula but you should take this with a grain of salt.

Number of Iterations

After you have an idea of duration of iteration your organization can tolerate , you can complement the "rubber profile" heuristics by looking at how many iterations you should perform in each phase.

Often, in the inception phase, there will be no real iteration; no software is produced, and there are only planning and marketing activities. In some cases, however, you will have an iteration for the following:

• Building a prototype to convince yourself or your sponsor (perhaps your customer or a venture capitalist) that your idea is a good one

• Building a prototype to mitigate a major technical risk such as trying out a new technology or a new algorithm or verifying that a performance objective is attainable

• Getting your organization up to speed with tools and process

Remember that the goal of inception is not to accumulate code. After all, you want these answers quickly.

So that's zero or one iteration.

In the elaboration phase, you should plan at least one iteration. If you have no architecture to start with and must accommodate a lot of new factors ”new people, tools, technology, platform, or programming language ”then you should plan two or three iterations. You cannot tackle all the risks at once. You may need to show a proto-type to the customer or end users to help them define the requirements better (remember the IKIWISI effect). You will need an iteration to correct your early mistakes on the architecture.

So this gives us one to three iterations.

In the construction phase, you should plan at least one iteration. Two is more reasonable if you want to exploit the benefits of iterative development and allow a better job of integration and testing. For more ambitious projects, three or more iterations are even better if the organization can support the stress and if there is a sufficient level of automation and process maturity.

So that's one to three iterations.

In the transition phase, plan at least one iteration, for example, final release after beta. Too often, the realities of the market or the (poor) quality of the initial release will force you to do more iterations.

That's one to two iterations.

So over the entire development cycle [I, E, C, T], we have three levels:

Low: three iterations [0, 1, 1, 1]

Typical: six iterations [1, 2, 2, 1]

High: nine iterations [1, 3, 3, 2]

We can summarize by saying that "normal" projects have 6 ± 3 iterations. We call this our "six plus or minus three" rule of thumb.