Rational Unified Process And Extreme Programming

Abstract:

The IBM Rational Unified Process® (RUP®) is a complete software-development process framework that comes with several out-of-the-box instances. Processes derived from RUP vary from lightweight addressing the needs of small projects with short product cycles—to more comprehensive processes addressing the broader needs of large, possibly distributed project teams. Projects of all types and sizes have successfully used RUP. This white paper describes how to apply RUP in a lightweight manner to small projects. We describe how to effectively apply extreme Programming (XP) techniques within the broader context of a complete project.

Inception

Inception is significant for new development efforts, where you must address important business and requirement risks before the project can proceed. For projects focused on enhancements to an existing system, the Inception phase is shorter, but is still focused on ensuring that the project is both worth doing and possible. During Inception, you make the business case for building the software. The Vision is a key artifact produced during Inception. It is a high-level description of the system. It tells everyone what the system is, and may also tell who will use it, why it will be used, what features must be present and what constraints 1 XP defines three phases: Exploration, Commitment, and Steering. These do not map well to RUP phases so we choose to use the four RUP phases to describe the process exist. The Vision may be very short, perhaps only a paragraph or two. Often the Vision contains the critical features the software must provide to the customer.

Four essential Inception activities specified in RUP are:

• Formulate the scope of the project.

• Plan and prepare the business case.

• Synthesize candidate architecture.

• Prepare the project environment.

Elaboration

The goal of the Elaboration phase is to baseline the architecture of the system to provide a stable basis for the bulk of the design and implementation effort in the Construction phase. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risk. The stability of the architecture is evaluated through one or more architectural prototypes.
In RUP, design activities focus on the notion of system architecture and, for software-intensive systems, software architecture. Using component architectures is one of the six best practices of software development embodied in RUP, which recommends spending time developing and maintaining the architecture. The time spent on this effort mitigates the risks associated with a brittle and inflexible system. XP replaces the notion of architecture by “metaphor.” The metaphor captures part of the architecture, whereas the rest of the architecture evolves as a natural result of code development. XP assumes that architecture emerges from producing the simplest design and continually refactoring the code.

On any project, you should do at least these three activities during Elaboration:

• Define, validate, and baseline the architecture

• Refine the Vision.

• Create and baseline iteration plans for the Construction phase.

Construction

The goal of Construction is to complete the development of the system. The Construction phase is, in some sense, a manufacturing process, where you emphasize managing resources and controlling operations to optimize costs, schedules, and quality. In this sense, the management mindset undergoes a transition from the development of intellectual property during Inception and Elaboration, to the development of deployable products during Construction and Transition.

Each Construction iteration has three essential activities:

• Manage resources and control process.

• Develop and test components.

• Assess the iteration.

Transition

The focus of Transition is to ensure that software is available for its end users. The Transition phase includes testing the product in preparation for release and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback needs to focus mainly on fine-tuning the product, configuring, installing, and usability issues.

The essential Transition activities are the following:

• Finalize end-user support material.

• Test the product deliverable in a customer environment.

• Fine tune the product based upon customer feedback.

• Deliver the final product to the end user.

You can produce several artifacts during the Transition phase. If your product is one that will have future releases (and how many do not?), you will have begun identifying features and defect fixes for the next release.

The essential artifacts for any project are:

• Deployment Plan

• Release Notes

• Training Materials and Documentation.

Digest

Building software is more than writing code. A software development process must focus on all activities necessary to deliver quality to your customers. A complete process does not have to be heavy. We have shown how you can have a small, yet complete, process by focusing on the essential activities and artifacts for your project. Perform an activity or produce an artifact if it helps mitigate risk on your project. Use as much, or as little, process and formality as you need for your project team and your organization. RUP and XP are not necessarily exclusive. By incorporating techniques from both methods, you can arrive at a process that helps you deliver better quality software quicker than you do today. Robert Martin describes a process called the dX process, which he claims to be RUP compliant. It is an instance of a process built from the RUP framework.