Object oriented software development process framework
Profile of a typical project showing the relative sizes of the four phases of the Unified Process.
The
unified software development process
or
unified process
is an
iterative and incremental
software development process
framework. The best-known and extensively documented refinement of the unified process is the
rational unified process
(RUP). Other examples are
OpenUP
and
agile unified process
.
Overview
[
edit
]
The unified process is not simply a process, but rather an extensible framework which should be customized for specific organizations or projects. The
rational unified process
is, similarly, a customizable framework. As a result, it is often impossible to say whether a refinement of the process was derived from UP or from RUP, and so the names tend to be used interchangeably.
The name
unified process
as opposed to
rational unified process
is generally used to describe the generic process, including those elements which are common to most refinements. The
unified process
name is also used to avoid potential issues of trademark infringement since
Rational Unified Process
and
RUP
are trademarks of
IBM
. The first book to describe the process was titled
The Unified Software Development Process
(
ISBN
0-201-57169-2
) and published in 1999 by
Ivar Jacobson
,
Grady Booch
and
James Rumbaugh
. Since then various authors unaffiliated with
Rational Software
have published books and articles using the name
Unified Process
, whereas authors affiliated with
Rational Software
have favored the name
Rational Unified Process
.
In 2012 the
disciplined agile delivery
framework was released, a hybrid framework that adopts and extends strategies from unified process,
scrum
,
extreme programming
, and other methods.
Unified process characteristics
[
edit
]
Iterative and incremental
[
edit
]
Diagram illustrating how the relative emphasis of different disciplines changes over the course of the project.
The unified process is an
iterative and incremental development
process. The elaboration, construction and transition phases are divided into a series of
timeboxed
iterations. (The inception phase may also be divided into iterations for a large project.) Each iteration results in an
increment
, which is a release of the system that contains added or improved functionality compared with the previous release.
Although most iterations will include work in most of the process disciplines (
e.g.
requirements, design, implementation, testing) the relative effort and emphasis will change over the course of the project.
Architecture-centric
[
edit
]
The unified process insists that architecture sits at the heart of the project team's efforts to shape the system. Since no single model is sufficient to cover all aspects of a system, the unified process supports multiple architectural models and views.
One of the most important deliverables of the process is the executable architecture baseline which is created during the elaboration phase. This partial implementation of the system serves to validate the architecture and act as a foundation for remaining development.
Risk-focused
[
edit
]
The unified process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.
Use case driven
[
edit
]
Use cases are the primary modeling tools to define the system functionalities. It also acts as straightforward communication means for technical and non-technical team members.
Project lifecycle (phases of unified process)
[
edit
]
The unified process divides the project into four phases:
- Inception
- Elaboration (milestone)
- Construction (release)
- Transition (final production release)
Each phase will generally contain multiple iterations (named I1, E1, E2, C1, etc. in the UP phase illustration). The exact number of iterations in each phase depends on the scale and nature of the project. The UP phase illustration here contains exactly 1, 2, 4 and 2 iterations in the four phases, but this is merely an example of how a specific project could look.
Inception phase
[
edit
]
Inception is the smallest phase in the project, and ideally, it should be quite short. If the inception phase is long then it may be an indication of excessive up-front specification, which is contrary to the spirit of the unified process.
Develop an approximate vision of the system, make the business case, define the scope, and produce a rough cost estimate and project schedule.
Elaboration phase
[
edit
]
During the elaboration phase, the project team is expected to capture a healthy majority of the system requirements. However, the primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture. Common processes undertaken in this phase include the creation of
use case diagrams
, conceptual diagrams (
class diagrams
with only basic notation) and
package diagrams
(architectural diagrams).
The architecture is validated primarily through the implementation of an executable architecture baseline. This is a partial implementation of the system which includes the core most architecturally significant components. It is built in a series of small time-boxed iterations. By the end of the elaboration phase, the system architecture must have stabilized and the executable architecture baseline must demonstrate that the architecture will support the key system functionality and exhibit the right behavior in terms of performance, scalability, and cost.
The final elaboration phase deliverable is a plan (including cost and schedule estimates) for the construction phase. At this point the plan should be accurate and credible since it should be based on the elaboration phase experience and since significant risk factors should have been addressed during the elaboration phase.
Construction phase
[
edit
]
Construction is the largest phase of the project. In this phase, the remainder of the system is built on the foundation laid in elaboration. System features are implemented in a series of short, time-boxed iterations. Each iteration results in an executable release of the software. It is customary to write full-text use cases during the construction phase and each one becomes the start of a new iteration. Common
Unified Modeling Language
(UML) diagrams used during this phase include
activity diagrams
,
sequence diagrams
,
collaboration diagrams
,
state transition diagrams
and
interaction overview diagrams
. Iterative implementation for the lower risks and easier elements are done. The final construction phase deliverable is software ready to be deployed in the transition phase.
Transition phase
[
edit
]
The final project phase is transition. In this phase the system is deployed to the target users. Feedback received from an initial release (or initial releases) may result in further refinements to be incorporated over the course of several transition phase iterations. The transition phase also includes system conversions and user training.
Refinements and variations
[
edit
]
Refinements of the unified process vary from each other in how they categorize the project
disciplines
or
workflows
. The
rational unified process
defines nine disciplines:
business modeling
,
requirements
,
analysis and design
,
Implementation
,
test
,
deployment
,
configuration
and
change management
,
project management
, and
environment
. The
enterprise unified process
extends RUP through the addition of eight "enterprise" disciplines. Agile refinements of UP such as
OpenUP/Basic
and the
agile unified process
simplify RUP by reducing the number of disciplines.
Refinements also vary in the emphasis placed on different project
artifacts
. Agile refinements streamline RUP by simplifying workflows and reducing the number of expected artifacts.
Refinements also vary in their specification of what happens after the transition phase. In the rational unified process the transition phase is typically followed by a new inception phase. In the
enterprise unified process
the transition phase is followed by a production phase.
The number of unified process refinements and variations are countless. Organizations utilizing the unified process invariably incorporate their own modifications and extensions. The following is a list of some of the better known refinements and variations.
References
[
edit
]
- Kroll, Per; Kruchten, Philippe (2003).
The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP
.
ISBN
0-321-16609-4
.
- Kruchten, Philippe (2004).
The Rational Unified Process: An Introduction
(3rd Ed.).
ISBN
0-321-19770-4
.
- Ambler, Scott
(2002).
Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process
. J. Wiley.
ISBN
0-471-20282-7
.
- Scott, Kendall (2002).
The Unified Process Explained
.
ISBN
0-201-74204-7
.
- Bergstrom, Stefan; Raberg, Lotta (2004).
Adopting the Rational Unified Process: Success with the RUP
.
ISBN
0-321-20294-5
.
- Ambler, Scott
;
Constantine, Larry
(2002).
The Unified Process Transition and Production Phases
. CMP Books.
ISBN
1-57820-092-X
.
- Larman, Craig (2004).
Agile and Iterative Development: A Manager's Guide
.
ISBN
0-13-111155-8
.
|
---|
Fields
| |
---|
Concepts
| |
---|
Orientations
| |
---|
Models
| Developmental
| |
---|
Other
| |
---|
Languages
| |
---|
|
---|
Related fields
| |
---|
|