The EUP Production Phase
|The Rational Unified Process (RUP) project lifecycle ends with the Transition phase's Product Release (PR) milestone when the release of a system has been deployed to users. However, There is more to information technology (IT) than just building and deploying systems; they must be operated and supported after they are deployed. The Enterprise Unified ProcessTM (EUP) extends the RUP to include a Production phase, as you can see in Figure 1.|
The goal of the Production phase is to keep systems useful and productive after they have been deployed to the user community. This process will differ from organization to organization and perhaps even from system to system, but the fundamental goal remains the same: keep the system running and help users to use it. Shrink-wrapped software, for example, will not require operational support but will typically require a help desk to assist users. Organizations that implement systems for internal use will usually require an operational staff to run and monitor systems. The Production phase, like the rest of the EUP, requires each organization to tailor it to meet their specific needs.
The Production phase ends when the release of a system has been slated for retirement or when support for that release has ended. The latter may occur immediately upon the release of a newer version, some time after the release of a newer version, or simply on a date that the business has decided to end support. The Release Retirement milestone, described in detail in a later section, is the final approval for a release to exit the production phase.This phase typically has one iteration because it applies to the operational lifetime of a single release of your software. There may be multiple iterations, however, if you defined multiple levels of support that your software will have over time. Figure 1. The EUP lifecycle: 2013.
Other activities, in disciplines other than Operations and Support, that take place during Production include:
The Production phase for a release does not necessarily end when a new development project for a subsequent release of that product begins. You will have to operate and support earlier releases in parallel to development efforts. In fact, you may have multiple releases in production at the same time. For example, the operations and support for both versions 1.0 and 1.1 continues for a short period after version 1.1 is released. It is not until version 2.0 is released that support for version 1.0 is discontinued.
|In reality, you will probably have multiple releases in development concurrently. It is not uncommon to begin the software development for release N+1 before release N has been completed and deployed. This may speed up the rate at which new releases are deployed and retired but will complicate your development efforts because you will have two teams updating the same code base. When you release a new version of a product, support for the older version(s) does not normally end immediately. When you release version 2.0 of your Whizbang product to the general public, for example, you will still support Whizbang v1.1 for a period of time (say eighteen months) and Whizbang 1.0 for a lesser period (say six more months). You will dedicate more resources to supporting v2.0 than the older versions, and you may even charge for support for the really old version, but you can't cut off support for clients who haven't upgraded until they've had a reasonable period of time to do so (or are willing to pay for continued support).|
Supporting multiple versions of a system can become messy if it's not managed properly. In most cases, subsequent releases of a product evolve from the work products of earlier release. Older versions often need to be supported and updated separately from the new release effort. This is often accomplished with a technique called "branch and merge," which starts when the project team for the new release selects its development base for the new effort. You create a copy of all the relevant artifacts (use cases, design model, code, test cases, etc.) that they will work on. This is known as the "branch." You base all their efforts on evolving their copy of these artifacts to create the new release; for example, updating or adding use cases, evolving the design, or updating the code. The original artifacts are maintained separately. This needs to happen to allow the original release to be supported independently of the development effort.
Operations and support of the current version of the product must still happen while new development is progressing. If a critical error is found in production customers will want it fixed. The support team must be able to make and deploy fixes to the current version without impacting the development effort (and vice versa). For a period of time, there are two copies of the code base and other artifacts as the two efforts support different goals.At some point, a "merge" takes place. When the development effort for the new release nears completion you must merge in the changes that the support team has done to incorporate as many fixes as possible. It may be done late during the Construction phase when new code is being written, or it may happen during the Transition phase. They do this by reviewing the changes that were made to the artifacts after the branch occurred and merging them into their base code. The old code base can be archived and removed if support for the older version is being discontinued,; otherwise both code bases must continue to be supported and evolved.
As you see in Figure 3 the Production phase ends with the Release Replacement (RR) milestone. The RR milestone determines whether the operations and support for a release of a system are to be ended. At this milestone, you must answers to the following questions:
During this milestone review, the stakeholders determine if the functionality provided by the release of the system is no longer going to be provided. This may be due to any of several reasons: replacement by a later version of the system, replacement by another system, the business moving in a different direction, and so on. To pass this milestone, the stakeholders must agree that this functionality should be removed. Transition to the Retirement phase may be postponed if the project fails to pass the milestone review.
Figure 3. The phases and milestones of the EUP.
|Copyright © 2003-2012 Scott W. Ambler||
This site owned by Ambysoft Inc.