EUP

Enterprise Agile: Lifecycle Phases

Follow @scottwambler on Twitter!



NOTE: This article will soon be updated to reflect the evolution of EUP to be based on the Disciplined Agile (DA) tool kit. Please stay tuned.

The EUP is comprised of five (or six) phases:
  1. Pre-Inception (arguably the 0th phase)
  2. The Inception Phase
  3. The Construction Phase
  4. The Transition Phase
  5. The Production Phase
  6. The Retirement Phase
Figure 1. The Lifecycle for the Enterprise Unified Process (EUP): 2013.


1. Pre-Inception

When you look at the diagram you see that the Enterprise disciplines include pre-project efforts. The major activities of this "pre-phase" include:
  1. Start the enterprise business model. This information will be used to help scope out systems.
  2. Portfolio planning. This includes the identification, and then prioritization, of potential projects to be worked on by your IT organization.
  3. Enterprise architecture modeling. Your enterprise architects may wish to put a "stake in the ground" and model some of the enterprise architecture upon which project teams should base their system-level architectures.
  4. Identification of reusable assets. Ideally project teams should be able to look into their reuse repository to see which assets are currently available for reuse.
  5. Staff allocation. Some people will potentially be hired, trained, and allocated to a project team before the project begins.
  6. Process definition. We recommend Disciplined Agile Delivery (DAD).

2. The Inception Phase

The primary goals of the Inception phase are to achieve stakeholder consensus regarding the objectives for the project and to obtain funding. The major activities of the phase include:
  1. Define project scope. This includes defining, at a high level, what is in the project. Equally important is to define what is not in the project. This establishes the boundaries within which the team will operate. This usually tales the form of a list of high-level features and/or a use case model with 80% of the total use cases identified.
  2. Estimate cost and schedule. At a high level, the schedule and cost for the project are estimated. General estimates are used for iterations in later phases, more specificity is used for the early iterations in Elaboration. This should not be construed as meaning that the entire project is planned out at this point. As with all planning, those tasks that are to be completed in the near future are detailed more accurately and with greater confidence while tasks further down the line are understood to be estimates with larger margins of error. It has (finally) been recognized by most in the industry that it is not possible to schedule an entire project at its kick-off with any acceptable degree of confidence. The best that can be done is to plan for the near term accurately and the longer term as best as you can.
  3. Define risks. The risks to the project are first defined here. Risks are an important concept in a RUP project. The list of risks is a living compilation that will change over time as risks are identified, mitigated, avoided and/or materialize and dealt with. Risks drive the management of the project, as the highest priority risks drive the scheduling of iterations. Higher priority risks, for example, are addressed in earlier iterations than lower priority risks. Putting off addressing a high priority risk puts the entire project in danger. It is therefore critical to know what your risks are and that you attack them head on.
  4. Develop the business case. A business case defines from a business perspective why the project is (or isn’t) worthwhile. If the business case shows that the project is not worthwhile, the project should be cancelled. The business case should also show how the project maps to the enterprise business model.
  5. Prepare the team environment. This includes reserving workspace for the team, requesting the people that will be needed, obtaining hardware and software that are needed immediately, and compiling a list of anticipated hardware and software that will be needed later. In addition, the software process, such as Disciplined Agile Delivery (DAD), to be followed by the project is selected here.
To exit the Inception phase your team must pass the Lifecycle Objectives (LCO) milestone. At this milestone, the stakeholders assess the state of the project. They must agree on the following: If the stakeholders agree that the project meets the above criteria, the project moves to the Elaboration phase. If the project fails in any area above, the project may be re-directed or cancelled outright.

3. The Construction Phase

The focus of the Construction phase is to develop the system to the point where it is ready for pre-production testing. In previous phases, the majority of the requirements have been identified and the architecture for the system has been baselined. Emphasis shifts now to prioritizing requirements and completing their specification, analyzing them, designing a solution to satisfy them, and coding and testing the software. If necessary, early releases of the system are be released, either internally or externally, to obtain user feedback. To exit the Construction phase your team must pass the Initial Operational Capability (IOC) milestone. At this milestone, the stakeholders must agree on the following: If the stakeholders agree, the project moves to the Transition phase. If the project fails in any area above, the project may be re-directed or cancelled.

4. The Transition Phase

The Transition phase focuses on delivering the system into production. There may be extensive testing that takes place during this phase, including beta testing. Fine-tuning of the product takes place here as well as rework to address significant defects (your stakeholders may choose to accept the existence of some known defects in the current release). The time and effort spent in Transition varies from project to project. Shrink-wrapped software entails the manufacturing and distribution of software and documentation. Internal systems are generally simpler to deploy than external systems. High visibility systems may require extensive beta testing by small groups before release to the larger population. The release of a brand new system may entail hardware purchase and setup while updating an existing system may entail data conversions and extensive coordination with the user community. Every project is different To exit the Transition phase your team must pass the Product Release (PR) milestone. At this milestone, the stakeholders must agree on the following: If the stakeholders agree, the project moves to the Production phase. If the project fails in any area above, the project may be re-directed or cancelled (some projects are such disasters that you don't want to even install them).

5. The Production Phase

The focus of the Production phase is the operations, support, and change management of new requirements and defects. The Gartner Group reports that 75% of the costs of software are incurred after systems have been developed and deployed. A complete software process must take into consideration the issues of operating and supporting software after deployment. The Production phase of the EUP defines a process to do that. The objectives of the Production phase are: The primary activities of the Production phase include: Most of these tasks occur in the Operations and Support discipline, a new discipline introduced by the EUP. Existing RUP disciplines such as Requirements, Analysis and Design, Implementation, and Configuration and Change Management are extended to support the needs of the Production phase. The Production phase ends with the Release Replacement (RR) milestone. At this milestone, you must achieve the following: The details of the Production phase will differ from system to system. Shrink wrapped software, for example, will typically not require operational support personnel but will require a helpdesk to assist users. Internally systems deployed into data centers will require an operations staff to run and monitor the system. The details of the Production phase will change from organization to organization. The EUP, like the RUP, requires each organization to tailor it to meet their specific needs.

6. The Retirement Phase

The focus of the Retirement phase is the successful removal of a system from production. This is a serious issue faced by most organizations today; as legacy systems are turned down and new systems replace them, you must complete this effort successfully and without a major interruption to their daily organizational business needs. If you have tried this in the past, you know how difficult it can be. Software systems do not last forever. Eventually, they become obsolete or superceded by other systems and must be removed (often referred to as "sunsetting”). Systems are removed from production for several reasons: The objectives of the Retirement phase are: Activities of the retirement phase include: The Retirement phase ends with the Release Retirement (RET) milestone. At this milestone, you must achieve the following: System retirement is not a simple effort; it needs a defined process, and is usually a project within its own right. Retirement of a system is a distinct possibility within all organizations today. If this is something facing your team today it should be an explicit part of the overall lifecycle. The RUP is a great start; however, it needs to be extended to meet the real-world needs of organizations – both today and in the future. The Enterprise Unified Process was developed to address this exact need.

8. Translations