The Unified Process (UP) is a software engineering process (SEP) that traces its roots back to the Unified Software Development Process (USDP), commonly referred to as the Unified Process (UP), created by the authors of the Unified Modeling Language (UML). So in order to understand the UP, we must first go through some basics.

The best definition I found regarding a SEP is stated by Jim Arlow in "UML2 and the Unified Process." He says, "a software engineering process defines the who, what, when and how of developing software. In its simplest form, a SEP is the process in which we turn user requirements into software." This basically captures the essence of why we use and implement software processes in our development life cycles; we want to give the customer the product that he ordered in the first place. However, we also want to do it in an organized, cost effective way that helps us complete the development of the product in the least time possible. 

It is worth while to note that RUP and the UP, although very similar in nature, are two different things. The UP is an open standard from the authors of the UML, made available through OMG (The Object Management Group). The RUP, on the other hand, is a commercial version of the UP made offered from IBM, which acquired Rational Corp in 2003. It supplies all the standards, templates, tools and other necessities that are not included in the UP, things that make the implementation of the UP in your project much easier. In Object Oriented terms, RUP is a subclass of UP, that both extends and overrides the features and artifacts found in UP.

To understand UP, we must first go through some basic concepts that are the foundations of UP. UP defines 4 basic semantics in its lifecycle.

1.    Roles: This describes a role played by an individual or a team within a project. Each role can include many individuals and multiple teams. Examples of roles are QA officer, developer, project manager, tester, etc.

2.    Activities: This describes the tasks that are performed by the different roles in the life cycle.

3.    Artifacts: This describes the things that act as input to the project or as an output from it. This includes source code, executables, different forms of documentation, coding standards, company forms and so on.

4.    Workflows: These are sequences of related activities performed by specific roles. These are sometimes referred to as disciplines. This is the corner stone concept behind UP. We will discuss the workflows present in UP in later sections.

In addition to the above semantics, UP is characterized by being:

1.    Requirements - Centric: UP thoroughly focuses on the user requirements collected at the beginning of the project and refined throughout the life cycle. We will discuss in brief this topic later in the article and in more detail in a later article.

2.    Architecture driven: At the core of the UP is developing robust system architecture of the software we are building.

3.    Iterative and incremental: This means that the UP breaks the project into small sub projects (iterations) and delivers the software in parts (the increments).  This is where the UP varies from the old waterfall model of software development. We will indulge in this concept in more detail in the next section.

This is the fundamental concept behind UP. The idea is fairly simple: divide a big project into smaller easier to manage sub projects. This is sort of like Legos, the toy building blocks. A single block alone is nothing but a rectangular piece of plastic, but put together, you can make large, complex structures. Likewise, in UP these small, easy to complete, sub-projects are put together to form the whole project. Each of these subprojects is an iteration.

Each iteration contains the elements of any normal software project: planning, analysis, development, testing and deployment. Each iteration forms the basis for the next iteration and constitutes a partially complete aspect of the system. What you add in the next iteration of your project to the existing basis is called an increment.

The UP distinguishes between two types of concepts: workflows and phases. As we will see later, work flows can span phases; let us first tackle the two concepts and how they relate.

As stated earlier, work flows are sequences of related activities performed by specific roles. UP defines five core workflows in its life cycle:

1.    Requirements: Figuring out (from the customer) what the system should do.

2.    Analysis: Refining, elaborating and describing in utmost detail the requirements collected from the requirement workflow.

3.    Design: Planning the system architecture to reflect the requirements of the customer.

4.    Implementation: Coding and development of the software.

5.    Test: Verifying the quality of the product to be delivered.

The project life cycle in UP is divided into four phases (They are described in more detail in the next section):

1.    Inception: During the inception phase the requirements are gathered and analyzed and the functional and non-functional needs are established. Technical proofs of concepts are conducted and details of the hardware infrastructure and software architecture are drafted.

2.    Elaboration: During the Elaboration phase detailed analysis of the requirements is made and the solution is designed. Tests plans are built.

3.    Construction: During the Construction phase the actual solution is developed. This involves software development, but also specification & development of the test data and finally tests executions.

4.    Transition: During the Transition phase the solution is rolled out to a limited number of users, piloted and enhanced if need be. Then it is rolled out to all the end users.

Phases and Workflows in Iterations -- Bring it together

Figure 1 best describes the essence of UP. As you can see, in the row headers we have the UP phases, in the column headers we have the UP workflows, and in the row footers we have the iterations planned throughout the project. The curves determine the relative amount of work needed in each phase throughout each workflow.

Figure 1

 

           

As you can see, one phase can have multiple iterations. For example, you can see that the inception phase is mostly concerned with requirements, where as the elaboration phase is more into analysis and design with a hint of implementation. The interesting curve is the testing workflow. As you can see, this curve spikes in every phase. Hence, we can conclude that testing is involved in all phases of UP, ensuring worthwhile quality.

In this section we will discuss the properties that define the different phases of UP. We will leave the workflows to subsequent articles.

It is worth mentioning that each phase has a set of deliverables and a milestone indicating its finalization with respect to a specific iteration.

Inception

The purpose of the inception phase is to "kick off" the project. As you can see from figure 1, it mostly involves gathering requirements and initiating the project.

Goals

·         Feasibility study: Determines the overall technical feasibility of the project. May involve some basic prototyping to validate the requirements.

·         Capturing essential requirements: Help in defining the overall scope of the system.

·         Identifying risks

Milestone

UP focuses on achieving multiple goals as an indicator of achieving the milestone in any phase, rather than creation of key artifacts, as many SEP's do. The milestone in the inception phase is the Life Cycle Objectives. Certain conditions must be attained in order to achieve this milestone. These are listed in the table given below.

Table 1: Life Cycle Objectives milestone

Condition	Deliverable
Stakeholders agree on project objectives and scope	Vision document, initial use case model
Key requirements captured	Use case model, SRS
Cost and schedule estimates agreed upon	Initial project plan
Risk  assessment conducted	Risk assessment document
Feasibility confirmed	One or more throw away prototypes
Architecture has been outlined	Initial Architecture document

 

Note that the key point is that you only create a document if you deem it useful to your project. Never write any document for the sake of documentation itself. If it has no use, do not create it.

Elaboration

The primary purpose of the Elaboration phase is to create an architectural base. This is a real system built on the actual specification and not a prototype which is a throwaway system. This is the first executable version of the system. The base system produced here is built upon in later phases, until the project terminates. So, this is the most crucial phase of the UP.

Goals

·         Create an architectural baseline.

·         Refine the risk assessment.

·         80% of the use cases of must be captured. Details of requirements gathering will be discussed in upcoming articles.

·         Plan for the construction phase (development) is put in place.

·         Project plan produced.

The following activities are done in the Elaboration phase in each of the five core workflows:

·         Requirements: Refines scope and overall use cases of the system.

·         Analysis: Establishes detailed system requirements.

·         Design: Creates stable baseline architecture.

·         Implementation: Code the architecture outlines in the design phase.

·         Test: Tests the system built in the implementation phase.

Milestone

The milestone for the Elaboration phase is the Life Cycle Architecture. As before, the conditions that have to be met are outlined in Table 2.

Condition	Deliverable
Robust Architectural baseline has been developed	Executable architecture Software Architecture Document
Risks identified fully	UML static, use case and dynamic diagrams
Vision of the product has been stabilized	Vision document
Business case of the project stabilized	Vision document
Project Plan agreed upon, stake holders are on board with the project plan	Project Plan
Agreement with stake holders to continue the project	Sign-off document

 

Construction

Goals

The primary purpose of this phase is to completely finalize the requirements, analysis and design of the system. This involves transforming the architectural design, placed and worked on in the pervious phases, to the final workable system. The utmost important issue of this phase is to maintain the integrity and uniformity of the architectural design. It is a very crucial issue to resist the deadline pressure, and to maintain this integrity. If this concept is not followed, a collapse of the architectural vision will take place, leading to a system with low quality and high maintenance costs.

Milestone

The milestone of the Construction phase is Initial Operational Capability. In essence this milestone is very simple: the software is operational and ready for beta testing at the user site. The conditions to achieve this milestone are outlined in table 3.

Table 3: Initial Operational Capability milestone

Condition	·         Deliverable
The software is of enough quality to be deployed at the user site and beta tested	The software product Testing platform The UML model
Stake holders ready for the beta deployment at their site	User manuals Description of the release
Cost analysis	Project plan

         

Transition

This phase is the last phase in an UP lifecycle. It starts when the beta testing of the software ends at the end of the previous phase, and the software is finally deployed. This involves taking care of any bugs that came out of the beta testing, and rolling out the software to all the user sites.

Goals

·         Fixing defects.

·         Create user manuals, guides and any end user documentation.

·         Prepare the user sites for the rollout.

·         Provide support and consultancy (as per the agreement signed).

·         Conduct a post project analysis.

As you can see from figure 1, the emphasis in this phase is on the implementation and test workflows. Sufficient time is considered in the design work flow to correct any last minute design flaws. Having stated that, these corrections should be kept down to a minimum at this stage.

·         The following activities are done in the Elaboration phase in each of the five core workflows:

·         Requirements: not applicable.

·         Analysis: not applicable.

·         Design: minor design changes to include bug fixes that were done during beta testing.

·         Implementation: minor user customizations and bug fixes.

·         Test: beta testing and user acceptance testing at the user site.

Milestone

The milestone of this phase is the Product Release. As the name says, this is basically the Go-Live of the final production system at the user site. After this phase the support contract that you have with your customer kicks in. The conditions to achieve this milestone are stated in table 4.

Table 4: Product Release milestone conditions

Condition	Deliverable
Project closure document	Beta testing finished, necessary changes to the system have been made, and agreement is reached among the stake holders that the system has been successfully deployed.
Updated user manuals	Product support strategies, pipelines and contracts are agreed upon and signed by both parties.  Final updated user manuals are delivered.

In this article you have learned about the concept of Unified Process (UP) in Software Engineering. I will provide a detailed explanation of the individual processes in follow up articles.