Organizing RUP SE Projects - The Article

(Page 2 of 5 )

• The project lifecycle model includes the four RUP phases-- Inception, Elaboration, Construction, and Transition -- and the RUP disciplines: business modeling; requirements; analysis and design; implementation; test and assessment; deployment; configuration and change management; project management; and environment. In fact, the familiar RUP diagram (see Figure 1) applies unchanged to RUP SE.
• Project activities are not serialized; instead, teams evolve artifacts -- including the project plan -- in parallel, and detail them as their understanding of the project problem and solution increases.
• The system is developed through a series of iterations, each satisfying more of the functional requirements. The focus is on finding and eliminating problems early, thereby reducing risk.

Figure 1: The Rational Unified Process lifecycle phases focus on risk reduction

Applying these principles to systems development raises two major issues:

• Team structure. How do we partition the staff into development teams and assign staff roles and responsibilities?
• Iteration planning. For large IBM RUP SE projects, how do we coordinate multiple development teams? When hardware is involved, how do we apply iterations to the hardware development?

This article addresses these issues, by showing how to apply RUP principles to RUP SE projects. It starts with a general discussion of the concepts underlying development project organization: basing the team organization around the project architecture, and the role of requirements analysis in partitioning effort. A brief overview of the RUP SE architecture framework follows that discussion.

Note that this article assumes an understanding of the fundamentals of
IBM RUP SE:

• The RUP SE architecture framework  ¹
• UML (logical) subsystems ²
• Localities
• Requirements flowdown

For a more complete description of these concepts, see the IBM Rational whitepaper, "Rational Unified Process^® for System Engineering, RUP SE 1.2,"³ and the RUP SE Rational Unified Process Plug-In.⁴

Partitioning Strategies

One lesson learned from software development that carries over into system development is that there is a diseconomy of scale related to effort. As a project grows, more and more effort is spent on communication among the developers. As Fred Brooks⁵ points out, the number of conversations required has the potential to grow quadratically with the number of team members, and this growth can actually occur in poorly organized projects. Even in well-organized projects, the effort can grow to the 1.2 power with the number of staff.⁶

Hence individual productivity falls off as the size of the effort increases. A fundamental management task is to partition the effort so as to manage communication among the developers. One strategy is to partition the effort into teams and then minimize communication among those teams. This divide-and-conquer strategy can prevent a quadratic loss of individual productivity.

There are two approaches for partitioning the effort:

• Partitioning by requirements. Partition the system requirements into sets, and then assign teams to take responsibility for developing the parts of the system that deliver each of those sets.
• Partitioning by architecture. Assign teams to develop subsystems or subcomponents of the system. The requirements for these architectural elements are derived from the role they play in meeting the system requirements.

Let's explore each of these approaches.

Using Requirements to Partition Effort

The requirements approach is common in systems development. The perceived advantage of partitioning by requirements is that it sharply decouples the effort, which simplifies the management problem. Different teams build different components that meet different requirements. These teams do their work in relative isolation, and, at the end of the project, bring their component to be integrated into the system.

This means of decoupling the development seems very attractive on the surface: There is little need for the teams to communicate. The belief is that each team can enhance productivity by using its own processes. In the end, what was originally a big, unmanageable project becomes a set of smaller, manageable programs.

However, this apparent simplicity often comes at a price. First, note that decomposing the system by requirements does, in the end, impose architecture: The components built in isolation become an implicit architecture. However, since this architecture was not explicitly constructed to address such quality issues as extensibility and maintainability, the resulting system tends to suffer from high service costs and may be incapable of evolving to meet changing mission needs.

A second problem with the requirements approach is that complications can arise when the team efforts are coupled at integration. Even though the components meet different requirements, they often need to communicate. Interface documents specify how the components access each other's services, and before they can proceed with their work in isolation, each team needs a fully documented, frozen interface document.

For a new system, it is unlikely that such a document will be available early on, since such interface specifications result from a detailed design effort -- and that will not yet have occurred. So each team needs something it cannot have. In practice, this leads to premature attempts to freeze the interfaces in an Interface Control Document (ICD) and then interminable interface control meetings, as the shortfalls of the ICD become evident. Each team may go into an ICD meeting more focused on preserving its schedule than on finding a good technical solution.

Finally, a third problem is that modern systems require more integration than did past systems. This places more attention on internal reuse of hardware and software components, and on the ability to redeploy the components as you add more capability to the system. With all of these new demands, the architecture must be managed more closely than is possible when the effort is decomposed along requirements.

Using Architecture to Partition Effort

This second strategy assumes that the system is partitioned into parts. In other words, it assumes an architecture whose elements were chosen to achieve an optimal design while balancing stakeholder needs. Teams are assigned to build each grouping of parts.

As we noted, the requirements method implies an architecture, but not a good one. The implied architecture does not account for many factors that need to be considered in specifying a quality architecture: maintainability, extensibility, supportability, overall responsiveness, and cost of ownership. Partitioning the effort along such a quality architecture results in some managerial complexity, but the extra effort results in a superior system.

In the following sections we will address the following challenges that result from allocating along architecture lines:

• Project management needs to understand the architecture to staff the team accurately.
• Since optimal architectures are more coupled than the implicit functional-allocation architectures resulting from requirements-based project staffing strategies, optimal architectures require more team communication.
• The architecture needs to evolve along with the team's understanding of the system design and implementation. Some team members must be responsible for maintaining the integrity of the architecture throughout development.
• The requirements that each team manages are derived from system requirements, not from an allocation of system requirements. We will discuss the distinction between derived and allocated requirements below.

As we shall see below, in the end, each of these challenges sets the stage for optimizing project performance.

RUP SE Architecture and Requirements

As mentioned earlier, this article assumes some understanding of RUP SE artifacts and workflows. This section highlights RUP SE concepts pertinent to our discussion: derived requirements; maintaining traceability between system requirements and model element requirements; and separation of concerns between the logical, physical, and information aspects of the system architecture.

Probably the most important notion is that of derived requirements. For reasons alluded to above, generating requirements for analysis elements and their implementations (subsystems, localities, etc.) is not merely a matter of sorting the system requirements. Instead, these are newly derived requirements based on the roles and responsibilities of the elements and how they work together to meet the system requirements. The workflow for deriving the analysis model requirements is detailed in the RUP SE whitepaper and RUP SE Plug-In mentioned earlier.⁷

One of the RUP SE disciplines is to maintain traceability between the system requirements and the analysis model element requirements. This traceability is usually not a decomposition tree, as found in functionally decomposed architectures; it is a many-to-many mapping. As discussed below, maintaining the traceability between system and analysis model requirements is important for iteration planning.

Another important aspect of the RUP SE framework is that, at the analysis level, the decomposition is not hardware and software, but rather logical and physical, based on separation of concerns. Given the flexibility of modern technology hardware/software choices for product development (e.g., whether the logical capability is realized in VHDL, in an ASIC, in firmware driving a DSP, or code running in a CPU) are typically price/performance trade-offs that may change over the commercial life of the product.

In fact, at a given point in time, a single analysis model may be realized in a variety of products, with different choices as to how to physically provide the logical capability, meeting different price/performance points. Further, given modern embedded system development environments, the distinction between hardware and software is somewhat blurred.

Also note that the software and hardware cannot be developed in isolation. The structure of physical software components (executables, etc.) is based on the physical architecture. The workflow for determining software components based on the logical and physical architecture is provided in the same RUP SE whitepaper and RUP SE plug-in mentioned earlier.⁸

RUP SE Project Organization

In setting the organization, it is useful to keep some fundamental principles in mind. Many of these principles apply to any large RUP-based development effort:

• Cover all of the RUP core workflows.
• Balance communications by assigning developers who need to communicate frequently to the same team whenever practical.
• Maintain architectural coherence through cross-team membership.
• Plan and deploy resources so that all teams function throughout the development lifecycle.
• Ensure that implementation includes integration of the separate components throughout the lifecycle.

Note that the last two principles follow from using RUP's iterative strategy. As mentioned above, the system development activities (requirements analysis, architecture, design, implementation, integration, and test) are not serialized in RUP projects; instead, they are carried out in parallel as the team delivers the system as a series of iterations with increasing capability.

We apply these principles at the system level, using associated RUP SE artifacts as the basis for defining team deliverables. As we shall see below, the analysis model serves as the architectural basis for organizing the effort.

Next: Team Structure >>
 

More Development Cycles Articles
More By The Rational Edge

Comments On: Organizing RUP SE Projects

>>> Be the FIRST to comment on this article!