The Unified Process Transition and Production Phases
Scott W. Ambler and Larry L. Constantine (editors)
Elsevier/CMP Books, December 2001 ISBN#: 1-578-20092-X
|
|
The Unified Process Transition and Production PhasesScott W. Ambler and Larry L. Constantine (editors)Elsevier/CMP Books, December 2001 ISBN#: 1-578-20092-X |
|
 |
|
Overview
This book is the fourth 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 with 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, Bertrand Meyer, Johanna Rothman, Warren
Keuffel, Larry Constantine,
and myself (Scott Ambler).
The Transition phase is the fourth of six phases -- Inception,
Elaboration, Construction,
Transition, Production , and Retirement -- that a system
experiences throughout its complete lifecycle. During the Transition phase
your project team will focus on testing and validating your
complete system, operating the system in parallel with any legacy systems that
you are replacing (if applicable), converting legacy databases and systems to
support your new release, training
the customers of your system, and deploying your system into
production. As you perform these activities you will create and/or evolve a wide variety of
artifacts:
Final product baseline (also known as a production baseline) of your system
Training materials for your system
Documentation, including user manuals, support documentation, and operations documentation
The phase is concluded with the Product Release milestone. To pass this milestone you must show that your users are satisfied with the system and that show that the actual expenditures versus the planned expenditures are still acceptable.
The Production phase is the fifth of six phases -- Inception, Elaboration, Construction, Transition, Production , and Retirement -- that a release of software experiences throughout its complete lifecycle. During the Production phase you will focus on operating your system and supporting your users working with it. This includes monitoring the system and acting appropriately to ensure continued operation; operating and maintaining relevant jobs, logs, and supporting systems; responding to help requests, error reports, and feature requests by users; and managing your change control process so that defects and new features may be prioritized and assigned to future releases. As you perform these activities you will create and/or evolve a wide variety of artifacts:
Software problem reports summarizing potential defects or new features for future releases
Problem resolution strategies to be followed by users requiring support
Appropriate metrics summarizing system usage, system performance, and user satisfaction
The Production phase is concluded with the Product Retirement Objectives milestone. To pass this milestone you must achieve one of:
A new version of the system is deployed into production
The system is replaced by a new one
The system is removed completely from production, an event called retirement or sunsetting
Your organization ceases operation
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 Unified Process. 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.
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 this 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.
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:
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: February 24, 2007 |
 |