IBM Rational Unified Process

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.

Overview

The Rational Unified Process is a software process product, originally developed by Rational Software, and now available from IBM. The product includes a hyperlinked knowledge base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RMC) product which allows customization of the process.

The Unified Process was designed from the very start to include both a generic, public domain process (known as the Unified Process), and a more detailed specification known as the "Rational Unified Process" which could be marketed as a commercial product.

The creators and developers of the process focused on diagnosing the characteristics of different failed software projects; by doing so they tried to recognize the root causes of these failures. They also looked at the existing software engineering processes and their solutions for these symptoms.

Project failure is caused by a combination of several symptoms, though each project fails in a unique way. The outcome of their study was a system of software best practices they named the Rational Unified Process.

The Process was designed with the same techniques the team used to design software; it has an underlying object-oriented model, using Unified Modeling Language (UML).

History

The roots of Rational Process go back to the original spiral model of Barry Boehm. The Rational Approach was developed at Rational Software in the 1980s and 1990s.

Rational Unified Process topics

RUP building blocks

RUP is based on a set of building blocks, or content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are achieved. The main building blocks, or content elements, are the following:
* Roles (who) – A Role defines a set of related skills, competences, and responsibilities.
* Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process.
* Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result.

Within each iteration, the tasks are categorized into nine disciplines, six "engineering disciplines" (Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment) and three supporting disciplines (Configuration and Change Management, Project Management, Environment).

Four project lifecycle phases

The RUP has determined a project lifecycle consistent of four phases. The first is the inception phase, which should establish baseline by which to compare actual expenditures versus planned expenditures. If the project does not pass this milestone, called the "Lifecycle Objective Milestone", it can either be cancelled outright or it can repeat this phase after being redesigned to better meet the criteria.

The second elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form. This phase must pass the "Lifecycle Architecture Milestone". If the project cannot pass this milestone, there is still time for it to be canceled or redesigned. After leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made. The key domain analysis for the elaboration is system architecture.

The third phase is the construction phase , which main focus goes to the development of components and other features of the system being designed. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes. This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone'.

The forth and last is the transition phase. In the transition phase, the product has moved from the development organization to the end user. The activities of this phase include training of the end users and maintainers and beta testing of the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase. If it does not meet this level, or the standards of the end users, another iteration of the phase begins. If all objectives are met, the "Product Release Milestone" is reached and the development cycle ends.

Six engineering disciplines

;Business modeling discipline : Organizations are becoming more dependent on IT systems, making it imperative that information system engineers know how the applications they are developing fit into the organization. Businesses invest in IT when they understand the competitive advantage and value added by the technology. The aim of business modeling is to first establish a better understanding and communication channel between business engineering and software engineering. Understanding the business means that software engineers must understand the structure and the dynamics of the target organization (the client), the current problems in the organization and possible improvements. They must also ensure a common understanding of the target organization between customers, end users and developers.

:Business modeling explains how to describe a vision of the organization in which the system will be deployed and how to then use this vision as a basis to outline the process, roles and responsibilities.

;Requirements discipline : This discipline explains how to elicit stakeholder requests and transform them into a set of requirements work products that scope the system to be built and provide detailed requirements for what the system must do.

; Analysis and design discipline : The goal of analysis and design is to show how the system will be realized. The aim is to build a system that :*Performs—in a specific implementation environment—the tasks and functions specified in the use-case descriptions. :*Fulfills all its requirements.:*Is easy to change when functional requirements change.

:Design results in a design model and analysis optionally an analysis model. The design model serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of how the source code is structured and written. The design model consists of design classes structured into packages and subsystems with well-defined interfaces, representing what will become components in the implementation. It also contains descriptions of how objects of these design classes collaborate to perform use cases.

;Implementation discipline : The purposes of implementation are :*To define the organization of the code, in terms of implementation subsystems organized in layers. :*To implement classes and objects in terms of components (source files, binaries, executables, and others). :*To test the developed components as units. :*To integrate the results produced by individual implementers (or teams), into an executable system. :Systems are realized through implementation of components. The process describes how you reuse existing components, or implement new components with well defined responsibility, making the system easier to maintain, and increasing the possibilities to reuse.

;Test discipline: The purposes of the Test discipline are: :*To verify the interaction between objects. :*To verify the proper integration of all components of the software.:*To verify that all requirements have been correctly implemented. :*To identify and ensure that defects are addressed prior to the deployment of the software:*Ensure that all the defects are fixed, retested and closed.:The Rational Unified Process proposes an iterative approach, which means that you test throughout the project. This allows you to find defects as early as possible, which radically reduces the cost of fixing the defect. Tests are carried out along four quality dimensions: "reliability, functionality, application performance, and system performance". For each of these quality dimensions, the process describes how you go through the test lifecycle of planning, design, implementation, execution and evaluation.

;Deployment discipline : The purpose of deployment is to successfully produce product releases, and deliver the software to its end users. It covers a wide range of activities including producing external releases of the software, packaging the software and business application, distributing the software, installing the software and providing help and assistance to users. Although deployment activities are mostly centered around the transition phase, many of the activities need to be included in earlier phases to prepare for deployment at the end of the construction phase.The "Deployment and Environment" workflows of the Rational Unified Process contain less detail than other workflows.

Three supporting disciplines

; Configuration and Change management discipline : The Change Management discipline in RUP deals with three specific areas configuration management, change request management, and Status and measurement management:* Configuration management : Configuration management is responsible for the systematic structuring of the products. Artifacts such as documents and models need to be under version control and these changes must be visible. It also keeps track of dependencies between artifacts so all related articles are updated when changes are made.:* Change request management : During the system development process many artifacts with several versions exist. CRM keeps track of the proposals for change.:* Status and measurement management : Change requests have states such as new, logged, approved, assigned and complete. A change request also has attributes such as root cause, or nature (like defect and enhancement), priority etc. These states and attributes are stored in database so useful reports about the progress of the project can be produced. Rational also has a product to maintain change requests called ClearQuest. This activity has procedures to be followed.

;Project management discipline : Project planning in the RUP occurs at two levels. There is a coarse-grained or Phase plan which describes the entire project, and a series of fine-grained or Iteration plans which describe the iterations. This discipline focuses mainly on the important aspects of an iterative development process: Risk management, Planning an iterative project, through the lifecycle and for a particular iteration, and Monitoring progress of an iterative project, metrics. However, this discipline of the RUP does not attempt to cover all aspects of project management. ;Environment discipline : The environment discipline focuses on the activities necessary to configure the process for a project. It describes the activities required to develop the guidelines in support of a project. The purpose of the environment activities is to provide the software development organization with the software development environment-both processes and tools-that will support the development team.

The IBM Rational Method Composer product

The IBM Rational Method Composer product is a tool for authoring, configuring, viewing, and publishing processes. See IBM Rational Method Composer and an open source version Eclipse Process Framework (EPF) project for more details.

Certification

In January 2007, the new RUP certification examination for "IBM Certified Solution Designer - Rational Unified Process 7.0" was released which replaces the previously called "IBM Rational Certified Specialist - Rational Unified Process". cite web|url=http://www-128.ibm.com/developerworks/rational/library/jan07/krebs/index.html |title=The value of RUP certification |accessdate=2008-05-13 |last=Krebs |first=Jochen |date=2007-01-15 |publisher=IBM ] The new examination will not only test knowledge related to the RUP content but also to the process structure elements. cite web|url=http://www-03.ibm.com/certify/certs/38008003.shtml |title=Spacer IBM Certified Solution Designer - IBM Rational Unified Process V7.0 |accessdate=2008-05-13 |publisher=IBM ]

To pass the new RUP certification examination, a person must take IBM's "Test 839: Rational Unified Process v7.0". You are given 75 minutes to take the 52 question exam. The passing score is 62%. cite web|url=http://www-03.ibm.com/certify/tests/ovr839.shtml |title=Test 839: Rational Unified Process v7.0 |accessdate=2008-05-13 |publisher=IBM ]

Limitations

If the users of RUP do not understand that RUP is a process framework, they may perceive it as a weighty and expensive process. RUP was not intended, not envisioned and not promoted to be used straight “out of the box.” The IBM Rational Method Composer product has been created to address this limitation and help process engineers and project managers customize the RUP for their project needs. OpenUP/Basic, the lightweight and open source version of RUP, is another attempt to address this limitation.

As the RUP must be customized for each project by a RUP process expert, the project's overall success is highly dependent on the abilities of this one person.

Criticisms

Wolfgang Hesse is a vocal critic of RUP, one of his most famous papers on the subject is "Dinosaur Meets Archaeopteryx?" cite web|url=http://www.mathematik.uni-marburg.de/~hesse/papers/Hes_01b.pdf |title=Seven Theses on Rational's Unified Process (RUP) |accessdate=2008-05-13 |last=Hesse |first=Wolfgang |format=PDF ]

Common criticisms of RUP include:
* it is overly complicated and difficult to apply to software engineering projects [Wagner 2003] [Graham 2000] [http://www.tara.tcd.ie/bitstream/2262/3558/1/NewPhDv53.pdf "Designing Telecommunication Service Management Systems"]
* it is very costly to implement cite web|url=http://portal.acm.org/citation.cfm?id=1292498&coll=Portal&dl=GUIDE&CFID=4246361&CFTOKEN=71991811 |title=Assessment of a framework to compare software development methodologies |accessdate=2008-05-13 |last=Klopper |first= Riaan |coauthors=Stefan Gruner, Derrick G. Kourie |date=2007 |work=ACM International Conference Proceeding Series; Vol. 226 |publisher=ACM ]

A recent academic paper, "Assessment of a framework to compare software development methodologies" , rates a relatively new methodology URDAD above RUP for the purposes of business analysis, but there are numerous others that compete with RUP to differing degrees - see the "Competing frameworks and methodologies" section below.

See also

Refinements and variations

*Agile Unified Process
*Open Unified Process (OpenUP) - An open source software development process, created as part of the Eclipse Process Framework (EPF) project.
*OpenUP/Basic - The most agile and lightweight form of OpenUP, targets small and collocated teams interested in agile and iterative development.
*Enterprise Unified Process
*Essential Unified Process (EssUP)
*IBM Tivoli Unified Process (ITUP)
*Unified Process - The generic Unified Process
*UPEDU - The Unified Process for Education

Competing frameworks and methodologies

The referenced methodologies and / or frameworks below do not necessarily compete with RUP on all fronts, but do so to differing degrees
*Cleanroom Software Engineering
*Dynamic Systems Development Method (DSDM)
*ICONIX Process is a lightweight, agile subset of the RUP practices
*Extreme Programming
*Harmony Process from [http://www.ilogix.com/whitepaper-overview.aspx Telelogic (was Ilogix)] covers both software engineering and system engineering
*Microsoft Solutions Framework (MSF)
*Tenstep Project Management
*OpenUP is an OpenSource lightweight agile version of RUP supported by IBM Rational, Number Six Software and others
*Personal Software Process (PSP)
*Scrum
*URDAD, the Use Case Driven Analysis and Design methodology is a methodology for technology neutral design.

oftware engineering

*Agile Software Development
*Software engineering
*Software development process
*Software component
*Project lifecycle
*Computer programming
*Quality assurance
*Extreme programming
*Agile Modeling
*Test-driven development
*Feature Driven Development
*Software Architecture

Books

*2007: RUP Reference and Certification GuideAhmad Shuja, Jochen Krebs [cite web|url=http://search.barnesandnoble.com/booksearch/results.asp?WRD=jochen+krebs&z=y&cds2Pid=9481 |title=Barnes & Noble.com - Book Search: jochen krebs |publisher=Search.barnesandnoble.com |date= |accessdate=2008-09-06]

*2006: Agility and Discipline Made Easy: Practices from OpenUP and RUPPer Kroll, Bruce MacIsaac [cite web|url=http://www.awprofessional.com/title/0321321308 |title=InformIT: Agility and Discipline Made Easy: Practices from OpenUP and RUP - $35.99 |publisher=Awprofessional.com |date= |accessdate=2008-09-06]

* 2003: Rational Unified Process Made Easy, The: A Practitioner's Guide to the RUPPer kroll [cite web|url=http://www.awprofessional.com/title/0321166094 |title=InformIT: Rational Unified Process Made Easy, The: A Practitioner's Guide to the RUP - $39.99 |publisher=Awprofessional.com |date= |accessdate=2008-09-06]

* 1999: The Unified Software Development Process
Ivar Jacobson, Grady Booch, and James Rumbaugh [cite web|url=http://www.amazon.com/gp/product/0201571692/ |title=Amazon.com: The Unified Software Development Process (Addison-Wesley Object Technology Series): Ivar Jacobson, Grady Booch, James Rumbaugh: Books |publisher=Amazon.com |date= |accessdate=2008-09-06]

* 1998: The Rational Unified Process: An Introduction
Philippe Kruchten [cite web|url=http://www.amazon.com/gp/product/0201604590/ |title=Amazon.com: The Rational Unified Process: Philippe Kruchten: Books |publisher=Amazon.com |date= |accessdate=2008-09-06]

2003: 3rd ed: [cite web|url=http://www.amazon.com/gp/product/0321197704/ |title=Amazon.com: The Rational Unified Process: An Introduction (3rd Edition) (Addison-Wesley Object Technology Series): Philippe Kruchten: Books |publisher=Amazon.com |date= |accessdate=2008-09-06]

References

External links

* [http://www.rational.com/ Rational Software at IBM] .
* [http://www.rational-ug.org/ Global Rational User Group Community] .
* [http://jdbv.sourceforge.net/RUP.html RUP Word document templates]
* [http://www.ibm.com/developerworks/rational/products/rup/?S_TACT=105AGY59&S_CMP=WIKI&ca=dtl-18dwrup Information from developerWorks on Rational Method Composer and Rational Unified Process]
* [http://www-306.ibm.com/software/awdtools/rup/?S_TACT=105AGY59&S_CMP=WIKI&ca=dtl-08rupsite IBM Rational Unified Process Web Site] .
* [http://www-306.ibm.com/software/awdtools/rmc/features/index.html?S_TACT=105AGY59&S_CMP=WIKI&ca=dtl-08ibmrmcsite IBM Rational Method Composer Web Site] .
* [http://www.ibm.com/developerworks/rational/library/06/0228_houston/?S_TACT=105AGY59&S_CMP=WIKIKIT&ca=dtl-08rmckit Rational Method Composer Migration Kit]
* [http://www.ibm.com/developerworks/downloads/r/rup/learn.html?S_TACT=105AGY59&S_CMP=WIKIDL&ca=dtl-08rupdl Free trial: Trial: Rational Method Composer V7.1]
* [http://www.ibm.com/developerworks/rational/downloads/06/rmc_plugin7_1/?S_TACT=105AGY59&S_CMP=WIKI&ca=dtl-08rmcplugin IBM Rational Method Composer (RMC) 7.1 Plug-ins] .
* [http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf What Is the Rational Unified Process] - The Rational Edge, Jan 2001. (pdf)
* [http://www.ibm.com/developerworks/rational/library/oct05/kroll/?S_TACT=105AGY59&S_CMP=WIKITU&ca=dtl-08kroll Key principles for business-driven development] - The Rational Edge, Oct 2005.
* [http://miraline.com/docs/pm/RUP/RUPUPIn10EasySteps.doc Implementing RUP/UP in 10 Easy Steps] (doc).
* [http://www.methodsandtools.com/archive/archive.php?id=32 Understanding the Unified Process] .
* [http://www.ibm.com/developerworks/rational/library/nov05/kroll/index.html?S_TACT=105AGY59&S_CMP=WIKITU&ca=dtl-08krollnov Introducing IBM Rational Method Composer] - The Rational Edge, Nov 2005.
* [http://www.ibm.com/developerworks/rational/library/dec05/haumer/index.html IBM Rational Method Composer: Part 1: Key concepts] - The Rational Edge, Dec 2005.
* [http://www.ibm.com/developerworks/rational/library/jan06/haumer/index.html IBM Rational Method Composer: Part 2: Authoring method content and processes] - The Rational Edge, Jan 2006.
* [http://www.ibm.com/developerworks/rational/library/aug05/peraire-pannone/index.html The IBM Rational Unified Process for COTS-based projects: An introduction] - The Rational Edge, Aug 2005.
* [http://www-128.ibm.com/developerworks/rational/library/05/1011_kroll/index.html The Eclipse Process Framework project] - The Rational Edge, 2005.
* [http://www.eclipse.org/epf/ Eclipse Process Framework (EPF) Web site] .
* [http://www.fromthetrench.com/2007/01/21/iterative-development-and-the-leaning-tower-of-pisa/ Iterative Development and The Leaning Tower of Pisa] - [http://www.fromthetrench.com/ From The Trench]
* [http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/papers/rup_best_practices/rup_bestpractices.html A good introduction to RUP]
* [http://cmcons.com/solutions/our_solutions/ Transfer UML diagrams from IBM Rational Software Architect to IBM Rational ClearQuest Designer's states]