The Unified Process Elaboration Phase
Elsevier/CMP Books, March 2000 ISBN#: 1-929-62905-2
|Home | Articles | Books | IT Surveys | Podcasts | Contact Us | Announcements | Site Map|
This book is one in a four-volume series that presents
a critical review of the
Unified Process -- designed to present a
more robust software process that addresses your development and
production needs. The series provides you a balanced perspective
of the alternative design methodologies available, proposes a
synthesized software process that addresses the scope of your
real world, and presents materials from the Software Development
magazine that will flesh out each of the UP phases. In this
series you get the collective wisdom of industry luminaries such
as Larry Constantine, Martin Fowler, David Linthicum, Scott
Ambler, Mary Loomis, Steve Maguire, Steve McConnell, Clemens Szyperski, and Karl Wiegers. This book focuses on best practices
for defining, validating, and establishing the baseline
architecture for a system. A carefully selected array of articles
address the vital elements of this phase. Subjects include
developing frameworks, component architectures, designing with
interfaces, building large systems, using the Unified Modeling
Language (UML) effectively, working with legacy systems, modeling
business rules, selecting tools, building your development team,
user interface prototyping, testing your requirements, and
effectively managing metrics.
The Elaboration phase is the second of six phases -- Inception, Elaboration, Construction, Transition, Production , and Retirement -- that a system experiences throughout its complete lifecycle. This phase has several goals:
This book describes a collection of articles written by industry luminaries that describe leading-edge best practices. One goal of this book, and of this series in general, is to provide alternate, proven approaches to the techniques encompassed by the Unified Process. Another goal is to fill the gaps of the Unified Process to be fair no process can ever truly be considered complete. The Unified Process is a development process, not a software process, therefore just because of its chosen scope it's going to be missing important concepts for most software professionals. Luckily the writers appearing in Software Development have taken a much broader view of process scope.
Figure 1 depicts the augmented lifecycle of the
Enterprise Unified Process
It extends the traditional Unified Process lifecycle with the
addition of the Production phase, the Operations and Support discipline
(formerly called a workflow), and an Enterprise Management discipline. These
enhancements were made after a comparison of the Unified Process
with several leading processes, such as the OPEN Process and the Object-Oriented Software Process (OOSP). The
lifecycle of the OOSP is depicted in Figure 2 below and the
process itself is described in the books Process Patterns and More Process Patterns. For
more information about the augmented lifecycle for the EUP I highly suggest
visiting the EUP web site.
Figure 1. The Augmented Lifecycle For The Enterprise Unified Process (EUP).
Figure 2. The Lifecycle of the Object-Oriented Software Process
Lately there has been an increased focus on improving the software process within most organizations. This is in part because of the 80-90% failure of large-scale software projects and because of a growing realization that following a mature software process is a key determinant to the success of a software project. Starting in the mid-1990s Rational Corporation was purchasing and merging with other tool companies, and as they did this they consolidated the processes supported by those tools into a single development process which they named the Unified Process. Is it possible to automate the entire software process? Does Rational have a complete toolset even if it is? We're not so sure. Luckily, other people were defining software processes, the OPEN Consortium's OPEN process for one and my own process patterns of the Object-Oriented Software Process (OOSP) for another, so we have alternate views of how things should work. These alternate views can be used to drive a more robust view of the Unified Process, resulting in the EUP which more accurately reflects the real-world needs of your organization. We believe that the collected wisdom contained in Software Development over the years can be used to flesh-out the Unified Process, truly unifying the best practices in our industry.
Why is a software process important? Step back for a minute. Pretend you want to have a house built and you ask two contractors for bids. The first one tells you that using a new housing technology he can build a house for you in two weeks if he starts building first thing tomorrow and it will only cost you $100,000. This contractor has some top-notch carpenters and plumbers that have used this technology to build a garden shed in the past and they're willing to work day and night for you to make this deadline. The second one tells you that she needs to discuss what type of house you would like built, and then once she's comfortable that she understands your needs she'll put together a set of drawings within a week that you can then review and provide feedback on. This initial phase will cost you $10,000 and once you decide what you want built she can then put together a detailed plan and cost schedule for the rest of the work. Which contractor are you more comfortable with, the one that wants to start building or the one that wants to first understand what needs to be built, model it, plan it, then build it? Very obviously the second contractor has a greater chance of success at delivering a house that meets your actual needs. Now assume that you're having software built, something that is several orders of magnitude more complex and often more expensive than building a house, and assume once again you have two contractors that want to take the exact same approach. Which contractor are you more comfortable with? We hope the answer is still the second one, the one with a sensible process. Unfortunately, practice shows that the vast majority of the time organizations appear to choose the approach of the first contractor, that of hacking. Of course, practice also shows that we have roughly an 85% failure rate, do you think the two phenomena are related? We think so.
This book series is composed of four volumes, one for the Inception phase, one for the Elaboration phase, one for the Construction phase, and a fourth one for the Transition and Production phases. Each book stands on its own, but for a complete picture of the entire software process you need to read all four volumes. Because articles are not repeated between volumes you will find that each one truly does offer you great value. One side effect is that some books are weak in some process disciplines where others are very strong. For example the Inception phase volume contains a wealth of material about project planning and estimating, critical topics at the beginning of a project, resulting in the other three volumes being weak in these topics.
As an aside, I found this series significantly harder to compose than I first thought. The problem that I ran into was that I had a wealth of material to choose from, and only a limited number of pages with which to work. If my editor had allowed it, each of these books would have been close to a thousand pages in length and not around the 450 that they are now. The articles in this series truly are the cream of the crop.
For the most part this book is geared towards senior object developers,
project managers, information technology executives. Senior object developers
will find that process patterns provide a framework for organizing their work
and for increasing their productivity. Project managers will find this book an
excellent reference for managing a large-scale development effort, and
information technology executives will find it an excellent source of insight as
to how to make long-term development successful.
We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.