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