The Unified Process Inception Phase

Scott W. Ambler and Larry L. Constantine (editors)

Elsevier/CMP Books   ISBN#: 1929629109

Scott W. Ambler + Associates
    Home  |  Articles  |  Books  |  IT Surveys  |  Podcasts  |  Contact Us  |  Announcements  |  Site Map
Order now!  



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.


UML Enterprise Unified Process (EUP)

The Augmented Lifecycle for the Enterprise Unified Process (EUP)

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

Why 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.

About This Series

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.


Who Should Read This Book?

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.

How to Obtain This Book

Amazon US:

     Order now!


Related Resources

Enterprise Unified Process (EUP)

Let Us Help

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