OpenUP - The Best of Two Worlds

Bjorn Gustafsson, GOOD Software Inc, www.goodsoftware.ca

Abstract

Software organizations looking to adopt an iterative and incremental process have found themselves left with less than ideal options. While RUP, the IBM Rational Unified Process was the first mainstream iterative software process, its complexity and size makes it difficult to adopt. Agile processes like Scrum and XP, on the other hand, are leaner, but their different culture and lack of documentation often meet resistance from management.

This dilemma is perfect soil for the new OpenUP process which packages the best RUP and agile practices in a light-weight open source process framework. The result makes management happy, since they get a stable and well-defined governance process, is easy to adopt, and serves the team a smorgasbord of software best practices right in their web browsers.

This article gives an overview of OpenUP and explains how it relates to both RUP, from which it received its foundation, and agile methods, from which it incorporates their best practices.

Introduction

Software development today is radically different than it was only ten years ago, and the software process landscape is changing too.

Since its creation ten years ago, RUP [11] has become the de facto process in many software organizations. With a knowledge base of thousands of pages it offers guidance to a wide range of industries and systems. However, RUP is also "complex" and can be difficult to implement in an organization because of its size, complexity and learning curve.

More recently, enabled and fuelled by new conditions and initiatives in our industry, the Agile Manifesto [2] established a philosophy in 2001 that brought some ground-breaking new ideas to the software process landscape, which materialized in methods like XP [3] and Scrum [4]. Even though replacing RUP never was the primary motivation, 'agility' seemed like a good idea to many, including those that struggled with RUP.

Now, a few years later, we know that agility is not the cure-all for our software process pains, and software teams still keep failing. "Being agile" requires a change of mindset and attitudes throughout the whole organization and not all organizations are ready for this cultural change.

Some common problems can be observed in troubled projects:

• The project team doesn't share a clear vision of how the system will appear to its users. Without a clear vision of the final system, there is no guiding framework for the work in the project. The team's analysts have no means to calibrate their requirements to the scope and effort of the project, which results in ill-fitting requirements statements; and the development team can not properly prioritize their work.
• Requirements do not drive development work. Some development cultures regard requirements as "incidental" input to the project only, and drive the development work based on other, internal and technical, conditions. This is commonly found in "silo" organizations where there are separate teams for requirements capture and development.
• The system's architecture has not been articulated. Although projects that only evolve and maintain existing systems may not need to pay much attention to architecture, there are many projects that do. As Dean Leffingwell [7] points out: "... how much architecture a team needs depends in large part on what the team is building".
• Plans are not connected to the engineering reality. Plans are often created and maintained separately from the actual project work. We have all seen nebulous Gantt charts that project managers spent days or even weeks creating, with hundreds of line items in nifty breakdown structures, purportedly believed to bring the project to "completion" at some well-defined point in time. Of course, these plans become outdated even before they are pinned on the wall.
• Risks are ignored. All projects run the risk of building the wrong product or not being able to build the product as envisioned, yet very few projects acknowledge this uncertainty and actively try to reduce it.

Whether your process is RUP, agile, or something else, and whether you are a programmer, architect, designer, tester, analyst or manager, you may recognize these problems in your own project. If you do, you are not alone. In fact, the majority of software projects are still problem-riddled.

Why is this?

First and foremost, software development is complex matter and orchestrating dozens or more individuals to build a complete software system is down-right hard work. Every project is unique and most projects have some parameters that just aren't "ideal" for their process or they have a less than ideal process.

Many software organizations ask "How can we fix these problems?"

Both RUP and agile methods certainly have the solutions. The problem with RUP, though, is that they can be hard to find and put to practice; the problem with agile methods is that their advice and guidance can be difficult to translate to a particular project situation since they are based on tacit knowledge and textbooks only.

With OpenUP the situation is different. It packs short and concise guidance into a small number of pages, which are always just a couple of clicks away. Adopting OpenUP takes you a long way towards solving these and other problems.

Go to part 2   Back to the archive list

This article was originally published in the Spring 2008 issue of Methods & Tools