In an effort to keep up with the tremendous demand for new software, the software industry is promoting various engineering processes, such as the Rational Unified Process (RUP), the OPEN process, and the Capability Maturity Model (CMM), to allow for the production of gobs of new software needed for many different reasons.

More on gantthead

Related downloads
Design Java Apps with UML

Related content

The most popular of these is the RUP, often referred to as simply the Unified Process (UP). Although some developers still practice software engineering with tools and methods from the previous generation of structured analysis, design, and programming, the UP has been gaining ground and replacing older processes, such as HP Fusion, Objectory, OMT, Method/1, and a plethora of other object-oriented software processes. The UP is a vast improvement over the cacophony of methods that came before it. At one time there were 29 competing object-oriented methodologies. The UP is slowly replacing all previous software engineering methods. But is it really a process? Hardly. The UP is based on the Unified Modeling Language (UML), which is a notation to express complex software designs. But it unifies three fundamentally different object-oriented (OO) methods: the Booch method, the Rumbaugh/OMT method, and the Jacobson/Objectory method.

Each of those methods had its own notation and purpose, and each was addressed to a different audience. Booch appealed to programmers who had to express complex software interaction between objects. Rumbaugh appealed to data and application architects who had to visualize complex object structures. Jacobson appealed to business users and analysts who saw in it a way to express the requirements and external behavior of a system. All three served their audience well and were successful in their own way, but none could stand alone as a full life-cycle process. Can they be merged together to form a unified process? Rational Software would certainly like you to believe that.

The UP is a useful first step in building your own development process. I think of it more as a “framework” on which to build a development process rather than a complete development process.

To fully benefit from the UP, you or your organization must build a custom development process, wrapped around the UP, that takes into account all those important variables.

Pluses and minuses
The UP has many pluses. Here are some of the most important ones.

  • It exists and is well documented, so there is no wheel to reinvent.
  • It was introduced with a lot of fanfare and a tremendous organization behind it, like a well-orchestrated marketing campaign.
  • It documents all the major artifacts that can be produced and used by a software development project from inception to testing of the final code.
  • It has industry-wide acceptance of the artifacts of UML that it uses for documentation; it has ended the “methodology” wars.
  • It is rapidly becoming the “lingua franca” of software developers.
  • It has several powerful tools that support artifact production.

These are balanced, however, by an equal set of minuses. Some of the most important are listed here.

  • The artifacts produced are often disjointed; they represent different views of the software, and the development team needs to use a variety of artifacts that will vary based on the type of software being produced.
  • There are few tasks to reconcile the artifacts to each other.
  • There are no management tasks.
  • There are no metrics to evaluate the quality of the artifacts.
  • There is a lack of continuity between the life-cycle steps.
  • The underlying production methodology is unclear; using the UP for waterfall projects will require a different threading of artifacts than working with the concepts of extreme programming.
  • The UP recognizes the role people play but does not recognize the essential nature of the key roles of software designer and architect.
  • The UP is quite generic and must be adapted to almost any situation.
  • There are no software implementations of the UP.
  • There are no credible code generators that input artifacts and produce working code.
  • There is a lack of recognition of the evolution of an artifact through project phases.

A work in progress
Don’t get me wrong. I think the UP is a giant leap forward and is far superior to what came before it. I would like to encourage readers to send in their comments based on their own experience in using and working with the UP.

I believe the UP will evolve over time to become a complete workable process to create software systems from accurate models. But this will take considerable time. I’d like to open the dialogue with all of you developers and project managers out there in cyberspace, so feel free to send me your comments and criticisms of the RUP or any other process you are currently using.

Andre Leclerc is the subject matter expert for gantthead’s Distributed Application Development department.

Excerpted from an article originally published on