The Unified Process Inception Phase
Scott W. Ambler and Larry L. Constantine (editors)
Elsevier/CMP Books ISBN#: 1929629109
|
|
The Unified Process Inception PhaseScott W. Ambler and Larry L. Constantine (editors)Elsevier/CMP Books ISBN#: 1929629109 |
|
 |
|
This book is first 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 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 Karl Wiegers, Jim Highsmith, Ellen
Gottessdiener, Lucy Lockwood, Warren Keuffel, Larry Constantine,
and myself (Scott Ambler).
The Inception phase is the first 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 collects articles written by industry luminaries that
describe best practices in these areas. One goal of this book and
of the entire series, is to provide proven alternative approaches
to the techniques encompassed by the Rational Unified Process (RUP). Another
goal is to fill in some of the gaps in the Unified Process.
Because the Unified Process is a development process, not a
software process, it inevitably misses or shortchanges some of
the concepts that are most important for software professionals.
Fortunately, the writers in Software
Development have taken a much broader view of process
scope and have filled in many of these gaps for us.
Figure 1 depicts the augmented lifecycle of the
Enterprise Unified Process
(EUP).
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 an enhanced lifecycle for the EUP that 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.
It has been a challenge selecting the material for inclusion in this compilation. With such a wealth of material to choose from and only a limited number of pages in which to work, narrowing the choices was not always easy. If our editor had allowed it, each of these books might have been twice as long. In narrowing our selections, we believe the articles that remain are truly 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.
Amazon US:
Other:
I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer. A full description of what I do, and how to contact me, can be found here.
|
|
Copyright © 2000-2007
Scott W. Ambler Last updated: March 31, 2007 |
 |