by Conrad Weisert
March 24, 2013
© 2013 Information Disciplines, Inc.
This document may be reproduced and distributed freely, as long as the copyright credit is included.
Over a decade ago I attended a vendor's presentation on the so-called Unified Process for software development. In the question period that followed I asked how an organization following the UP could effect the make or buy decision. Is there a point in this life cycle, I inquired, where we've specified exactly what the proposed new application must do without having invested in actual design and construction? Can we then evaluate commercial software products trying to find at least one that satisfies the user community's requirements?
The speaker acknowledged that what he had just presented didn't lend itself to projects that might end up purchasing application software products. He assured us, however, that "we're working on it", and predicted that we would soon see an updated version of the UP that would cater to such projects.
That was a decade ago.
But for more than the past couple of decades the enlightened policy in most user organizations has been
We will develop custom software only after we've determined that no suitable packaged application software product exists.
The Unified Process is therefore applicable only to projects where we're certain from the start that we won't consider packaged application software. So, unless we're a software vendor ourselves or we're doing original research, that's no projects at all!
I refrained from asking the speaker which UP work products would be reviewed and thoroughly understood by unsophisticated representatives of the sponsoring users. What corresponds to the understandable "structured specification" described in dozens of books and articles in the 1970s and 1980s? And how would we know when those documents were complete and consistent? The answers were obvious from the vague claim that UP is "use-case driven" and "architecture centric".
We've known for a long time that one of the major causes of failure in software development projects is unclear specifications1 that have not been understood and thoroughly reviewed and approved by the sponsoring users. Users' objections that first arise in the late stages of testing are almost always a major setback resulting in huge cost overrun, schedule slippage, and lasting user dissatisfaction.
The most valuable contribution of the "structured revolution" was the system specification that could be understood by executives and business-oriented people without specialized training. A life-cycle that never produces such a rigorous specification is hardly likely to yield successful projects.
We first heard of the UP (not part of Michigan) in books about object-oriented technology, such as the Addison-Wesley series by the so-called "three amigos"2. That was puzzling at first, and even more puzzling today as more and more authors try to blend those two concepts.
Actually UP and object-oriented systems analysis (OOA) are entirely independent of each other. You can practice either one while ignoring the other.
You not only can but you should! Structured systems analysis with object technology remains the most effective methodology for specifying a system, while the UP is a seriously flawed distortion of the life-cycle concept having little to do with object technology.
Return to Technical articles
IDI home page
Last modified March 25, 2013