The RUPA Well-Defined Software Engineering Process

The RUP ”A Well-Defined Software Engineering Process

The Rational Unified Process itself was designed with techniques similar to those used in software design. In particular, it is modeled using the Software Process Engineering Metamodel (SPEM) ^[3] ”a standard for process modeling based on the Unified Modeling Language (UML). ^[4] Figure 1.2 shows the overall architecture of the Rational Unified Process. The process has two structures or, if you prefer, two dimensions:

^[3] See OMG 2001.

^[4] A standard for specifying, visualizing, and documenting models of software systems, including their structure and design. The standard is managed by the Object Management Group (www.omg.org).

• Dynamic structure. The horizontal dimension represents the dynamic structure or time dimension of the process. It shows how the process, expressed in terms of cycles, phases, iterations, and milestones, unfolds over the lifecycle of a project

• Static structure. The vertical dimension represents the static structure of the process. It describes how process elements ”activities, disciplines, artifacts, and roles ”are logically grouped into core process disciplines (or workflows).

Figure 1.2. Two Dimensions of the RUP. The Rational Unified Process is organized along two dimensions: The dynamic aspect (horizontal) expresses cycles, phases, iterations, and milestones; the static aspect (vertical) expresses activities, disciplines, artifacts, and roles.

These dimensions are discussed in the following sections.

The Dynamic Structure of the Rational Unified Process

The dynamic structure deals with the lifecycle or time dimension of a project. The RUP provides a structured approach to iterative development, dividing a project into four phases: Inception, Elaboration, Construction, and Transition (see Figure 1.3). ^[5] Chapters 6 through 9 discuss these phases in detail. The objectives and milestones of the phases are listed in the sidebar RUP Lifecycle Phases, Objectives, and Milestones.

^[5] See Kruchten 2000a.

Figure 1.3. Milestones for the RUP Lifecycle Phases. Each of the RUP's four phases has a milestone and a well-defined set of objectives. Use these objectives as a guide for deciding which activities to carry out and which artifacts to produce.

Each phase contains one or more iterations , which focus on producing the technical deliverables necessary to achieve the business objectives of that phase. There are as many iterations as it takes to address the objectives of that phase sufficiently, but no more . If objectives can't be addressed within the planned phase, another iteration should be added to the phase ”which will delay the project. To avoid this, make sure that each iteration is sharply focused on just what is needed to achieve the business objectives of that phase. For example, focusing too heavily on requirements in Inception is counterproductive. Chapter 12 discusses project planning.

• Inception. Establish a good understanding of what system to build by getting a high-level understanding of all the requirements and establishing the scope of the system. Mitigate many of the business risks, produce the business case for building the system, and get buy-in from all stakeholders on whether to proceed with the project.

• Elaboration. Take care of many of the most technically difficult tasks : Design, implement, test, and baseline an executable architecture, including subsystems, their interfaces, key components , and architectural mechanisms, such as how to deal with inter-process communication or persistency. Address major technical risks, such as resource contention risks, performance risks, and data security risks, by implementing and validating actual code.

• Construction. Do most of the implementation as you move from an executable architecture to the first operational version of your system. Deploy several internal and alpha releases to ensure that the system is usable and addresses user needs. End the phase by deploying a fully functional beta version of the system, including installation and supporting documentation and training material (although the system will likely still require tuning of functionality, performance, and overall quality).

  RUP Lifecycle Phases, Objectives, and Milestones

  Inception Phase

  Objectives:

  • Understand the scope of the project

  • Build the business case

  • Get stakeholder buy-in to move ahead

  Milestone: Lifecycle Objective Milestone (LCO)

  Elaboration Phase

  Objectives:

  • Mitigate major technical risks

  • Create a baselined architecture

  • Understand what it takes to build the system

  Milestone: Lifecycle Architecture Milestone (LCA)

  Construction Phase

  Objective:

  • Build the first operational version of the product

  Milestone: Initial Operational Capability Milestone (IOC)

  Transition Phase

  Objective:

  • Build the final version of the product and deliver it to the customer

  Milestone: Product Release Milestone (PR)

• Transition. Ensure that software addresses the needs of its users. This includes testing the product in preparation for release and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback focuses mainly on fine-tuning the product, configuration, installation, and usability issues; all the major structural issues should have been worked out much earlier in the project lifecycle.

The Static Structure of the Rational Unified Process

The static structure deals with how process elements ”activities, disciplines, artifacts, and roles ”are logically grouped into core process disciplines. A process describes who is doing what , how , and when . As shown in the sidebar Four Key Modeling Elements of the RUP and Figure 1.4, the Rational Unified Process is represented using four key modeling elements.

Figure 1.4. Roles, Activities, and Artifacts. A role expresses who (an individual or a group) is doing the work; an activity describes how the work is done; and an artifact captures what is done.

Four Key Modeling Elements of the RUP

• Roles. The who

• Activities. The how

• Artifacts. The what

• Workflows. The when

Roles

A role is like a "hat" that an individual (or group) wears during a project. One individual may wear many different hats. This is an important point because it is natural to think of a role as an individual on the team, or as a fixed job title, but in the RUP the roles simply define how the individuals should do the work, and they specify the competence and responsibility that the individual(s) playing that role should have. A person usually performs one or more roles, and several people can perform the same role.

Activities

An activity of a specific role is a unit of work that an individual in that role may be asked to perform. The activity has a clear purpose, usually expressed in terms of creating or updating some artifacts, such as a model, a component, or a plan. Each activity is assigned to a specific role. An activity generally takes a few hours to a few days to complete, usually involves one person, and affects one or only a small number of artifacts. An activity should be usable as an element of planning and progress; if it is too small, it will be neglected, and if it is too large, progress would have to be expressed in terms of an activity's parts . Activities may be repeated several times on the same artifact ” especially when going from one iteration to another, refining and expanding the system ”by the same role, but not necessarily by the same individual.

Steps

Activities are broken down into steps, which fall into three main categories:

• Thinking steps, where the person playing the role understands the nature of the task, gathers and examines the input artifacts, and formulates an outcome

• Performing steps, where the role creates or updates some artifacts

• Reviewing steps, where the role inspects the results against some criteria

Not all steps are necessarily performed each time an activity is invoked, so steps can be expressed in the form of alternate flows.

Artifacts

An artifact is a piece of information that is produced, modified, or used by a process. Artifacts are the tangible project elements: things the project produces or uses while working toward the final product. Artifacts are used as input by roles to perform an activity and are the result or output of other activities.

Artifacts may take various shapes or forms:

• A model, such as the Use-Case Model or the Design Model

• A model element, that is, an element within a model, such as a class, a use case (UC), or a subsystem

• A document, such as the Vision or Business Case

• Source code

• Executables, such as an executable Prototype

An artifact can be documented formally (using a tool) or informally (captured in an e-mail message or on a whiteboard). This will be discussed in more detail in Chapter 3 and Chapters 6 “9.

Workflows

A mere listing of all roles, activities, and artifacts does not quite constitute a process. You need a way to describe meaningful sequences of activities that produce some valuable result and to show interactions between roles ”this is exactly what workflows do.

Workflows come in different shapes and forms; the two most common workflows are Disciplines, which are high-level workflows (see the section Disciplines that follows ), and Workflow Details, which are workflows within a discipline.

In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram. Figure 1.5 shows an example workflow. Note that it is not always possible or practical to represent all of the dependencies between activities. Often two activities are more tightly interwoven than shown, especially when carried out by the same individual. People are not machines, and the workflow cannot be interpreted literally as a program for people to be followed exactly and mechanically.

Figure 1.5. The Workflow of the Requirements Discipline. A workflow shows in what order to carry out activities to accomplish something of measurable value. RUP workflows typically show only the most essential dependencies between activities to avoid cluttering the view.

Additional Process Elements

Roles, activities (organized in workflows), and artifacts represent the backbone of the Rational Unified Process static structure. But there are some other elements added to activities or artifacts that make the process easier to understand and use and that provide more complete guidance to the practitioner. These additional process elements are

• Guidelines, to provide rules, recommendations, or heuristics that support activities, steps, and artifacts.

• Templates, for the various artifacts.

• Tool mentors, to establish a link with and provide guidance on using the development tools.

• Concepts, to introduce key definitions and principles.

• Roadmaps, to guide the user into the RUP from a given perspective.

Figure 1.6 shows how these elements enhance the primary elements.

Figure 1.6. Adding Templates, Tool Mentors, and Guidelines. Templates jump-start the production of an artifact; tool mentors provide detailed guidance for carrying out an activity, or step, using the tools at hand; and guidelines provide detailed guidance on activities, steps, or artifacts.

Disciplines

Finally, all process elements ”roles, activities, artifacts, and the associated concepts, guidelines, and templates ”are grouped into logical containers called Disciplines. There are nine disciplines in the standard RUP product (see the RUP Disciplines sidebar).

RUP Disciplines

• Business modeling

• Requirements management

• Analysis and design

• Implementation

• Deployment

• Test

• Project management

• Change management

• Environment

This list is not definitive, and any company doing extensions to the RUP product could introduce additional disciplines.