BT

The Various Flavors of Unified Process

by Shane Hastie on Feb 20, 2010 |

The Rational Unified Process® (RUP®) was developed through the 1990's as a framework for software engineering best practices. Key features such as iterations, simplicity, focusing on value and regular feedback were identified as being important for successful software engineering. With the RUP as a starting point a number of authors have built methodologies that adapt UP to different project domains. 

 Background to the Rational Unified Process®    
 
The Rational Unified Process® (RUP®) was originally designed to provide a framework for software engineering. By 1997 Rational Software had articulated a set of seven best practices:
  1. Develop iteratively, with risk as the primary iteration driver
  2. Manage requirements
  3. Employ a component-based architecture
  4. Model software visually
  5. Continuously verify quality
  6. Control changes
  7. Customization
 
Rational built a framework of processes and practices which were embodied in a commercial product that provided three components:
  • a tailorable process that guided development
  • tools that automated the application of that process
  • services that accelerated adoption of both the process and the tools
 
The RUP is based around an iterative approach that defines a set of core and supporting disciplines that are applied over the life of the project. The figure below (referred to as the Hump Chart) shows the likely focus and intensity of the core disciplines across the four phases. 
 
Hump Chart 

Image source: http://en.wikipedia.org/wiki/File:Development-iterative.gif

As well as the core disciplines the RUP® defines supporting the disciplines of Configuration & Change Management, Project Management and Environment Support.  More detail about the RUP® can be found here  

IBM acquired Rational Software in 2003, and continues the commercial development and packaging of the RUP®.
 
In a 2002 paperPhilippe Kruchten, the original architect of the RUP framework, wrote a paper titled “Agility with the RUP”. In the paper he stated
Agility, for a software development organization, is the ability to adapt and react expeditiously and appropriately to changes in its environment and to the demands imposed by this environment. An agile process is one that readily embraces and supports this degree of adaptability. So, it is not simply about the size of the process or the speed of delivery; it is mainly about flexibility. In this article, I will explain how the Rational Unified Process® (RUP®) is a process framework that allows this flexibility.
He states that in addition to the seven core practices, the RUP® is based on a core set of principles, including:
·         Develop only what is necessary.
·         Focus on valuable results, not on how the results are achieved.
·         Minimize the production of paperwork.
·         Be flexible.
·         Learn from your mistakes.
·         Revisit your risks regularly.
·         Establish objective, measurable criteria for progress.
·         Automate what is human intensive, tedious, and error prone.
·         Use small, empowered teams.
·         Have a plan.
 
He concludes that the RUP® provides a framework that aligns well with Agile techniques and methods.
 
Since leaving IBM, Kruchten has gone on to become a Professor of Software Engineering in the Department of Electrical and Computer Engineering at University of British Columbia 

The Essential Unified Process

Ivar Jacobson, one of the original founders of Rational Software, offers the Essential Unified Process (ESSUP):
The Essential Unified Process (EssUP) is a collection of practices that together form the essential knowledge of a complete software development lifecycle. This practice-centric approach to software development incorporates and builds on established best practices. The practices in EssUP integrate successful principles from the unified process, agile and process maturity camps, capitalizing on their different capabilities: structure, agility and process improvement

The ESSUP is delivered as a set of Essential Practices, freely downloadable documents describing each of the practices as a set of Things to Produce, Things to Do and Key Competencies, with descriptions and guidelines for each one.

OpenUP - a lean Unified Process

OpenUP also defines a set of Processes, Practices, Roles, Work Products and Tasks that are needed for delivery of a software project. OpenUP is deployed as an Eclipse Process Framework (EPF) 

OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types.

 According to an article in Methods & Tools describing OpenUP by Bjorn Gustafsson

EPF is an open-source initiative that was started in 2006 with contributions by IBM Rational of parts of their RUP content and technology. Since its inception the project has actively involved more than 20 companies, and the first release was made available in September of 2007. Despite being an Eclipse project, EPF can be used to create process descriptions for any type of development, including J2EE on Eclipse or .NET using Microsoft Visual Studio. 

In the article he explains the background to the EPF and how OpenUP is deployed. He concludes: 

The new OpenUP process synthesizes the best practices from RUP and Agile methods into a light-weight and agile alternative to both. Given its RUP roots, it provides a process that is iterative and incremental, use-case driven, risk-driven, and architecture-centric, which at the same time supports the work habits of agile projects. The OpenUP process features practices suitable for many projects right out-of-the-box, but it also provides the basis for adding 3rd party and proprietary practice extensions, using the EPF Composer tool, to tailor the most appropriate process for each project

Enterprise Unified Process

Another derivative of the RUP® is Scott Ambler’s Enterprise Unified Process  

The Enterprise Unified Process (EUP) extends the RUP into additional phases both before the software development project starts and beyond the project into Production and Retirement.  The intent of the EUP is to enable the delivery of projects in more formal environments where governance and support processes are well defined and must be adhered to.
 
According to the EUP website:
Whereas the RUP defines a software development lifecycle, the EUP extends it to cover the entire information technology (IT) lifecycle. The extensions include two new phases, Production and Retirement, and several new disciplines: Operations and Support and the seven enterprise disciplines (Enterprise Business Modeling, Portfolio Management, Enterprise Architecture, Strategic Reuse, People Management, Enterprise Administration, and Software Process Improvement). 
Agile Unified Process
 
At the other extreme, Ambler also defines the Agile Unified Process, focused on lightweight approaches and a minimal set of practices that are driven by the Agile principles and values.  The Agile Unified Process website says that the AgileUP
is a simplified version of the Rational Unified Process (RUP).  It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP.  I've tried to keep the Agile UP as simple as possible, both in its approach and in its description.  The descriptions are simple and to the point, with links to details (on the web) if you want them.  The approach applies agile techniques include test driven development (TDD), Agile Model Driven Development (AMDD), agile change management, and database refactoring to improve your productivity.

On the website he explains the differences between the RUP disciplines and the AgileUP disciplines.

The whole Agile UP product is freely available as a downloadable ZIP file that installs a set of HTML pages that describe the Phases, Disciplines, Milestones, Roles and Deliverables, it also provides Guidance on the technical practices.

These are some of the variations and derivatives of the Unified Process. 

Do you use one of these products, what have your experiences been, and how do they fit in the Agile world?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Clear explanation... by Mark Levison

...but I'm still confused. I've helped a few teams recover from RUP implementations gone bad. Yes it is possible to good RUP but why would anyone do it? We've Scrum, Crystal, Open Agile, Lean, Kanban - all of these are innovative, why would anyone start with a RUP/ARUP etc. project today?

I open to hearing good reasons.

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: Clear explanation... by Julian Holmes

Mark,
I sympathise with your experiences of "RUP gone bad", but equally I have seen many "Agile gone bad" scenarios too.

We all know that we need to maintain a focus on people and their interactions over any process and tools, but your statement that "We've Scrum, Crystal, Open Agile, Lean, Kanban - all of these are innovative" highlights the most common issue:
People don't know what's good for them, and sometimes there is just too much choice.

This is what RUP originally set out to overcome, by providing a customisable framework of practices for people to choose from. Unfortunately, it became so large that few people knew how to scale-back to what they really needed. Hence the numerous "RUP gone bad" examples.

However, in the world of Unified Process described above there has been one particular "flavor" that has tried to address these issues: OpenUP.
Being a "lean" approach that also includes the best of Scrum, XP, and other Agile methods, OpenUP gives you an essential "kernel" and some optional practices for your project team.

So, and in answer to your question, I would suggest that OpenUP is an excellent starting point for a project, particularly if they are inexperienced in process selection, and they want to benefit from the opportunities to scale Agile practices to the challenges that many projects face, such as distribution, regulation, and size.

Cheers,
Julian Holmes
Unified Process Mentors

Re: Clear explanation... by Mark Levison

Julian - interesting points

I sympathise with your experiences of "RUP gone bad", but equally I have seen many "Agile gone bad" scenarios too.


Good point about "Agile Gone Bad", I have seen Agile gone well, my problem I've never seen RUP gone well and was associated with one attempt to implement it that created way too many work products that where write only. I've no doubt that RUP has been well I've just never seen it - even when I was inside IBM.

We all know that we need to maintain a focus on people and their interactions over any process and tools, but your statement that "We've Scrum, Crystal, Open Agile, Lean, Kanban - all of these are innovative" highlights the most common issue:
People don't know what's good for them, and sometimes there is just too much choice.


Yes but that's why you hire a good coach or consultant. Realistically most people pick Scrum by default (because they don't about the others), so I don't buy the claim of too much choice.


This is what RUP originally set out to overcome, by providing a customisable framework of practices for people to choose from. Unfortunately, it became so large that few people knew how to scale-back to what they really needed. Hence the numerous "RUP gone bad" examples.

However, in the world of Unified Process described above there has been one particular "flavor" that has tried to address these issues: OpenUP.
Being a "lean" approach that also includes the best of Scrum, XP, and other Agile methods, OpenUP gives you an essential "kernel" and some optional practices for your project team.

So, and in answer to your question, I would suggest that OpenUP is an excellent starting point for a project, particularly if they are inexperienced in process selection, and they want to benefit from the opportunities to scale Agile practices to the challenges that many projects face, such as distribution, regulation, and size.


I will have to look into it - although I'm interested in knowing why it offers more than Vodde and Larman.

Cheers
Mark Levison
Agile Pain Relief Consulting

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT