Organizing RUP SE Projects

Staffing Curve

RUP projects are typically not fully staffed at their onset. For larger projects, there is not enough work to keep everyone busy during the Inception phase; a core group of key staff should carry out Inception activities. Once they meet the Inception lifecycle goals, then managers should have enough confidence about the scope and required effort to fully staff the project.

The same is even more true for RUP SE projects. Note that creating the analysis model is primarily an Elaboration activity, so in principle, the development teams should not be fully staffed until the end of Elaboration. In practice, however, managers can typically identify core competencies among staff members at the beginning of a project, so the Inception team can include development team leaders. As their understanding of the project deepens, managers can better estimate the optimum size for these teams and begin staffing up at the beginning of the Elaboration phase. By the end of Elaboration the teams should be fully staffed.

Key Roles

Note that each team works throughout the entire project. Hence, each system team (project management, enterprise modeling, analysis, test, and build and integration) needs a lead responsible for maintaining the system perspective, delivering results, and coordinating with development team representatives.

Iteration Planning

A key feature of the RUP lifecycle is that the project team builds the product through a series of iterations of increasing capability. At a system level, the standard iteration principle applies: Iteration content is described by an increasing set of use-case scenarios. Early iterations address technical risk; later iterations address content risk. Since there is a large body of literature describing the advantages of iterative development and ongoing iteration planning, we will not describe those benefits here.

In addition to the standard iteration planning concerns, system development involves other critical issues:

• Each development team needs its own derived iteration plan.
• Hardware delivery dates may not support iteration delivery.

The notion of derived iteration planning is not new, and with every RUP product, IBM Rational delivers a whitepaper by Maria Ericsson that discusses the principles of derived iteration planning. In the following section, we will see how to apply those principles to RUP SE projects.

Derived Iteration Plans

Recall that an iteration plan consists of specifying a sequence of partially functional versions of the system, which culminates in a completely functional system. So each iteration requires a set of test cases to verify the functionality and the hardware and software components required to provide that functionality. Each development team needs the means for determining what logical and physical modules it must develop to support each iteration, and the integration team needs to know what pieces to expect from the development teams for integration. The specification of these pieces for each iteration, based on the system iteration plan, results in a derived iteration plan for each of the teams.

The IBM RUP SE requirements flowdown workflow provides the means for deriving these team iteration plans. Recall that the use-case flowdown workflow produces surveys:

• Derived use-case surveys are produced for each of the UML systems, along with UML subsystem services that enable the use cases.
• A survey of hosted subsystem services is produced for each locality.

Each element of these surveys traces from one or more system use-case scenarios. Following the traceability, the subsystem iteration plan is derived from the system iteration plan by including the subsystem use-case scenarios traced from the included system use-case scenarios. Subsystem services define the interface requirements for a subsystem, and they must also be supported by the hardware realization of the localities.

Following this traceability path results in the locality iteration plans. The integration of the modules that make up the realizations of the development team iterations must be included in the build and integration iteration plan so that each team's iteration plans may be derived from the system iteration plan.

If hardware is not yet available to pursue a locality team's derived iteration plan, project management is faced with an important decision: Is the benefit of risk reduction worth the extra investment in a simulated hardware platform? The derived iteration plan provides the necessary information to scope the simulator capabilities requires and conduct a cost/benefit analysis. Often the analysis points toward doing a simulation, in which case, the derived iteration plan provides the necessary requirements for it.

Resource Balancing and Smoothing

One challenge of managing a large-scale iterative development is to ensure that the effort required from each team to support an iteration is reasonable. Each of the teams' project managers needs to ensure that the team resources are adequate to support their derived iteration plans. In addition, managers need to ensure that staff is not idle during iterations that place only a "light" demand on their team.

For example, it is generally not possible for a major subsystem to become fully functional in the first iteration; only some of the subsystem's functionality can be delivered that early on. The system project manager and subsystem lead typically negotiate and revise the system iteration plan to reflect what each of the subsystem teams can actually deliver within the iteration schedule. This activity, a standard project management responsibility, is the often called resource smoothing.

Resource smoothing is the responsibility of the project management team. They achieve the balancing by jointly performing the following workflow:

1. Set the system iteration plan using the usual RUP principles of addressing technical and content risk.
2. Use requirements traceability to set the derived iteration plans.
3. Assess team resources for the derived iteration plan and propose an achievable alternative plan (performed by each project manager for each team).
4. Unify alternative proposals by shifting functionality in the system iteration plan, and occasionally planning to shift resources between teams.

As in standard RUP projects, RUP SE project iteration plans are never frozen; they continually evolve as managers examine the results of the delivered iterations. Maintaining the system plan and derived iteration plans is an ongoing responsibility of the project management team.