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
extends the RUP to include a Production phase, as you can see in
Table of Contents
- Major activities
- Release management
- The release retirement milestone
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
Figure 1. The EUP lifecycle: 2013.
Figure 2 depicts the workflow for the
Production phase. Most of these tasks occur in the
Operations and Support discipline. A brief description of the activities
Figure 2. The Production Phase
- Operators monitor the system to make sure it is running properly, to
start jobs and process as appropriate, to back up and restore data, and to
generally look after the system and operating environment.
- A support manager is responsible for managing the overall support
efforts. The support manager prioritizes work, schedules and assigns tasks,
ensures that support personnel have the resources to complete their tasks,
and ensures that work is completed in a timely fashion.
- Customer service representatives directly communicate with users and
assist them in the use of the system. They provide advice and guidance to
users and record enhancement requests and problem reports. They maintain
contact with users who have reported problems and keep them informed of
- System support representatives investigate problem reports and act on
them. If they are caused by the system behaving improperly, they create
defect reports that are then handled by support developers. If they are enhancement
requests, they create enhancement requests that go to the
Enterprise Change Control Board for consideration.
- Support developers address critical defects (errors) in system behavior.
They are responsible for making changes to the system to correct incorrect
behavior. They are also responsible for packaging fixes to be applied and,
if fixes are applied internally, for applying those fixes to deployed
- Preparations are made for recovery from a disaster such as a power
outage of hardware or network error that disrupts processing. If a disaster
occurs, the disaster recovery plan is executed.
Other activities, in disciplines other than
Operations and Support, that take place during Production include:
- Requirements. During the Production phase, user enhancement
requests are received. These new requests must be documented and analyzed.
- Analysis and Design. Initial analysis of user enhancement
requests takes place, as well as analysis and design required to resolving
- Test. Testing of fixes must be done before they are
deployed. These may take the form of hot fixes (a code update to address a
specific problem) or service packs (a collection of individual fixes).
Regression tests that can be rerun when a fix has been made are crucial to
the continuity of deployed software.
- Configuration and Change Management. Change requests and
defect reports will be accepted and managed during the Production phase.
Configuration of the system needs to be tracked and updated as fixes are
created and applied.
- Project Management. Activities in the production are
managed, just like any other activities. Operational activities are managed
by an Operations Manager; support activities are managed by a Support
Manager. They are responsible for assigning tasks and monitoring and
- Environment. Support environments are modified as needed
during the Production phase, as are operational monitoring tools, run-time
environments, backup and recovery setups, etc.
- Enterprise Administration. While systems are running,
enterprise administrators maintain networks and hardware and also ensure
that the underlying security and data infrastructure is stable. When
necessary, they troubleshoot any problems that arise with capacity and
upgrades, and they assist in testing and applying fixes.
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
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
4. The Release Retirement Milestone
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:
- Is the functionality provided by this release of the system no longer
- Are the stakeholders ready for the retirement of the release?
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.