Unified process

Last updated
Profile of a typical project showing the relative sizes of the four phases of the Unified Process. UnifiedProcessProjectProfile20060708.png
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.

Contents

Overview

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

Iterative and incremental

Diagram illustrating how the relative emphasis of different disciplines changes over the course of the project. Unified Process Model for Iterative Development.svg
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

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

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

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)

The unified process divides the project into four phases:

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

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

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

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

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

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.

Related Research Articles

The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development.

<span class="mw-page-title-main">Spiral model</span> Software development process model

The spiral model is a risk-driven software development process model. Based on the unique risk patterns of a given project, the spiral model guides a team to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping.

<span class="mw-page-title-main">Iterative and incremental development</span> Development methodology

Iterative and incremental development is any combination of both iterative design and incremental build model for development.

A software company is a business entity that specializes in the development, distribution, and maintenance of software products and services. These companies create a variety of software solutions, including commercial software, custom software, Software as a Service (SaaS), open-source software, and embedded software. They range from small startups to large corporations, engaging in activities such as software development, testing, deployment, and support.

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

Agile software development is the mindset for developing software that derives from values agreed upon by The Agile Alliance, a group of 17 software practitioners in 2001. As documented in their Manifesto for Agile Software Development the practitioners value:

<span class="mw-page-title-main">Philippe Kruchten</span> Canadian software engineer

Philippe Kruchten is a Canadian software engineer, and Professor of Software Engineering at University of British Columbia in Vancouver, Canada, known as Director of Process Development (RUP) at Rational Software, and developer of the 4+1 Architectural View Model.

Microsoft Solutions Framework (MSF) is a set of principles, models, disciplines, concepts, and guidelines for delivering information technology services from Microsoft. MSF is not limited to developing applications only; it is also applicable to other IT projects like deployment, networking or infrastructure projects. MSF does not force the developer to use a specific methodology.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles that can be applied on an (agile) software development project. This methodology is more flexible than traditional modeling methods, making it a better fit in a fast-changing environment. It is part of the agile software development tool kit.

The Enterprise Unified Process (EUP) is an extended variant of the Unified Process and was developed by Scott W. Ambler and Larry Constantine in 2000, eventually reworked in 2005 by Ambler, John Nalbone and Michael Vizdos. EUP was originally introduced to overcome some shortages of RUP, namely the lack of production and eventual retirement of a software system. So two phases and several new disciplines were added. EUP sees software development not as a standalone activity, but embedded in the lifecycle of the system, the IT lifecycle of the enterprise and the organization/business lifecycle of the enterprise itself. It deals with software development as seen from the customer's point of view.

Agile unified process (AUP) is a simplified version of the rational unified process (RUP) developed by Scott Ambler. It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test-driven development (TDD), agile modeling (AM), agile change management, and database refactoring to improve productivity.

Internet-Speed development is an Agile Software Development development method using a combined spiral model/waterfall model with daily builds aimed at developing a product with high speed.

The UPEDU or Unified Process for Education is a software development process specialized for education, developed by Pierre-N. Robillard, Philippe Kruchten and Patrick d'Astous.

Scott W. Ambler is a Canadian software engineer, consultant and author. He is an author of books about the Disciplined Agile Delivery toolkit, the Unified process, Agile software development, the Unified Modeling Language, and Capability Maturity Model (CMM) development.

<span class="mw-page-title-main">RUP hump</span>

A RUP ‘hump’ is a plot of effort spent over time during a particular Rational Unified Process (RUP) discipline. The RUP hump chart consists of a collection of humps for all RUP disciplines. This diagram was created in 1993 during a workshop on architecture and process and was inspired by work by Grady Booch and Boehm. It has been part of the Rational Objectory Process after reviews by Dyrhage and Bylund and moved on to play a more important role in the RUP in 1998 when it served as the initial page for using the digital version of the process. Its final form was published by Philippe Kruchten in 1998. An older version as later used by Jacobson, Booch and Rumbaugh and an altered version was used by Royce.

In software engineering, a software development process or software development life cycle is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others.

Agile architecture means how enterprise architects, system architects and software architects apply architectural practice in agile software development. A number of commentators have identified a tension between traditional software architecture and agile methods along the axis of adaptation versus anticipation.

References