ScrumUP: Introducing RUP

In the late 80s and early 90s Ivar Jacobson, James Rumbaugh and Grady Booch, also called the three amigos, were each working on combining object oriented modeling and iterative development. The Rational Software Corporation, a software vendor specialized in tooling to support software development, brought them together. Their mission was to unify their methods.

Their modeling practices were brought together in UML (Unified Modeling Language), a language for software related modeling in the form of diagrams. UML is now an official OMG (the Object Management Group) standard. The process part of their practices resulted in the Rational Unified Process or RUP. Since Rational has been taken over by IBM in 2003, RUP is now owned and further developed by IBM. Since that time a number of adaptations of their process have been made like the Essential Unified Process by Ivar Jacobson, the Enterprise Unified Process by Scott Ambler and the Agile Unified Process by the same author. We will use the term RUP to mean any implementation of this process. The term IBM RUP will be used to reference IBM’s implementation of this process as packaged with the IBM Rational Method Composer product.

RUP was developed mainly with substantial green-field projects in mind. Its process is focused on new teams building new software with new technologies. It is an iterative approach with iterations spanning 2 to 6 weeks. It has an extensive collection of method content covering almost all areas of software development including business modeling, requirements, software architecture and design, implementation, testing, deployment (into the business) and team management.

RUP is not meant as a prescriptive process but as an adaptable process framework. It is intended to be tailored by development organizations and software project teams to their specific characteristics and needs. Tailoring of the process can encompass adding or removing roles, tasks and work products. It can also mean changing templates for work products or even the process descriptions, method content and guidance within the framework itself. This is especially true for IBM RUP with close to 5000 web pages of documentation, 128 available work products and 33 possible roles to make up a team. No project we saw or heard of ever needed all of that, so you are supposed to pick those elements of RUP that are appropriate for your situation (says the first key principle within IBM RUP ‘Adapt the Process’).

In 2005 IBM donated a basic part of IBM RUP to the open source community, along with a tool to maintain its process and method content. The part of RUP they donated is now called OpenUP/basic and is further developed by the open source community. It’s designed as a lightweight, adaptable Unified Process implementation that works very well in an Agile (see 2.4 Introducing Agile) environment.

OpenUP/basic is a good example for tailoring RUP. Most aspects of RUP have been retained but its amount of process has been greatly reduced. It is made up of only 6 roles producing 17 work products, focusing mainly on requirements and implementation. This is a huge contrast to IBM RUP with its 33 roles and 128 work products. Whereas the IBM RUP process should be downscaled to fit the needs of an organization and a particular project, the OpenUP/basic process is meant to be extended.

The tool to maintain OpenUP is called the Eclipse Process Framework or EPF. It is a content management tool especially developed to document software development processes using concepts like roles, tasks and work products and bringing them together in processes. This tool has also been used to document other software development methods like Scrum and XP. We (the authors of this book) have used these process descriptions as an important inspiration for the process we used in some of our projects (wherever we got the chance) and for this book.

An overview of events surrounding the introduction of the development methods used in this book, Scrum, XP and RUP is shown in Figure 2.