Unified Process

Section 0: Module Objectives or Competencies

Section 1: Overview

The Unified Process is a specific methodology that maps out when and how to use the various UML techniques for object-oriented analysis and design.

• It was originally called the Rational Unified Process.

Unlike some of the previous approaches that we saw with traditional Analysis and Design, the Unified Process is not a series of steps for constructing a software product.

• It is instead an adaptable methodology that has to be modified for the specific software product to be developed.
• The Unified Process is a modeling technique, with the model being a set of UML diagrams that represent various aspects of the software product to be developed.

Section 2: Approach

Video: Rational Unified Process

The Unified Process is a two-dimensional process consisting of phases and workflows, which are standard software engineering activities.

Note that the figure depicts the Unified Process in terms of two dimensions: time and content.

• The horizontal axis represents time and shows the life cycle aspects of the process described in terms of phases and iterations.
• The vertical axis represents content and shows the workflows, which logically group the process content.

As the "humps" in the figure illustrate, the relative emphases of the workflows change over the life of the project.

• In early iterations more time is spent on Requirements, and in later iterations more time is spent on Implementation.
• Configuration and Change Management, Environment, and Project Management activities are performed throughout the project.
• All workflows are considered within every iteration.

A software development project moves through a number of phases each of which is divided into a number of iterations.

• Within each iteration, we consider the various workflows, with the activities within each workflow described in terms of workflow details.
• Workflow details describe activities that are usually performed together, the roles that perform those activities, and the resulting artifacts.

Every step performed in the Unified Process falls into

• One of the core workflows (or disciplines):
  • Workflows are the tasks that occur in each phase.
  • Workflows provide the technical context of a step.
  • The original five core workflows were Requirements, Analysis, Design, Implementation, and Test.
  • A subsequent modification listed six core workflows, including Business Modeling, Requirements, Analysis & Design, Implementation, Test, and Deployment.
  • The Configuration and Change Management, Project Management, and Environment workflows are generally referred to as Supporting Workflows.
• One of the four phases:
  • Phases are time periods in development.
  • Phases provide the business context of a step.
• Activities in both phases and workflows will overlap.

Video: Key Features of RUP

Section 3: Phases

Overview

The diagram on the previous page shows four phases or increments:

• Inception phase
  • Feasibility analyses performed
  • Workflows vary but focus is on business modeling & requirements gathering
• Elaboration phase
  • Heavy focus on analysis and design
  • Other workflows may be included
• Construction phase
  • Focus on programming (implementation)
• Transition phase
  • Focus on testing and deployment

Details

The phases of the Unified Process support an analyst in developing information systems in an iterative and incremental manner.

• The phases describe how an information system evolves through time.

Depending on which development phase the evolving system is currently in, the level of activity varies over the workflows.

• The graphs associated with each workflow in the figure in Section 2 approximate the amount of activity that takes place during the specific phase.
• For example, the inception phase primarily involves the business modeling and requirements workflows, while practically ignoring the test and deployment workflows.

Each phase contains a set of iterations, and each iteration uses the various workflows to create an incremental version of the evolving system. As the system evolves through the phases, it improves and becomes more complete.

Each phase has objectives, a focus of activity over the workflows, and incremental deliverables.

Inception

In many ways, the inception phase is very similar to the planning phase of a traditional SDLC approach.

Video: Inception Phase

In this phase, a business case is made for the proposed system. This includes feasibility analysis that should answer questions such as the following:

• Do we have the technical capability to build it (technical feasibility)?
• If we build it, will it provide business value (economic feasibility)?
• If we build it, will it be used by the organization (organizational feasibility)?

To answer these questions, the development team performs work related primarily to the business modeling, requirements, and analysis workflows.

In some cases, depending on the technical difficulties that could be encountered during the development of the system, a throwaway prototype is developed.

• This implies that the design, implementation, and test workflows could also be involved.

The project management and environment supporting workflows are very relevant to this phase.

The primary deliverables from the inception phase are a vision document that

• sets the scope of the project
• identifies the primary requirements and constraints
• sets up an initial project plan
• describes the feasibility of and risks associated with the project
• describes the adoption of the necessary environment to develop the system
• describes some aspects of the problem domain classes being implemented and tested.

Elaboration

When we typically think about object-oriented systems analysis and design, the activities related to the elaboration phase of the Unified Process are the most relevant.

Video: Elaboration Phase

The analysis and design workflows are the primary focus during this phase.

The elaboration phase continues with developing the vision document, including finalizing the business case, revising the risk assessment, and completing a project plan in sufficient detail to allow the stakeholders to be able to agree with constructing the actual final system.

• It deals with gathering the requirements, building the UML structural and behavioral models of the problem domain, and detailing how the problem domain models fit into the evolving system architecture.

Developers are involved with all but the deployment engineering workflow in this phase.

• As the developers iterate over the workflows, the importance of addressing configuration and change management becomes apparent.
• The development tools acquired during the inception phase become critical to the success of the project during this phase.

The primary deliverables of this phase include the UML structure and behavior diagrams and an executable of a baseline version of the evolving information system.

• The baseline version serves as the foundation for all later iterations.

By providing a solid foundation at this point, the developers have a basis for completing the system in the construction and transition phases.

Construction

The construction phase focuses heavily on programming the evolving information system.

Video: Construction Phase

This phase is primarily concerned with the implementation workflow.

• However, the requirements workflow and the analysis and design workflows also are involved with this phase.

It is during this phase that missing requirements are identified and the analysis and design models are finally completed.

Typically, there are iterations of the workflows during this phase, and during the last iteration, the deployment workflow kicks into high gear.

The configuration and change management workflow, with its version-control activities, becomes extremely important during the construction phase.

• At times, an iteration has to be rolled back. Without good version controls, rolling back to a previous version (incremental implementation) of the system is nearly impossible.

The primary deliverable of this phase is an implementation of the system that can be released for beta and acceptance testing.

Transition Phase

Like the construction phase, the transition phase addresses aspects typically associated with the implementation phase of a traditional SDLC approach.

Video: Transition Phase

Its primary focus is on the testing and deployment workflows.

Essentially, the business modeling, requirements, and analysis workflows should have been completed in earlier iterations of the evolving information system.

Furthermore, the testing workflow will have been executing during the earlier phases of the evolving system.

Depending on the results from the testing workflow, some redesign and programming activities on the design and implementation workflows could be necessary, but they should be minimal at this point.

From a managerial perspective, the project management, configuration and change management, and environment are involved.

Some of the activities that take place are

• beta and acceptance testing
• fine-tuning the design and implementation
• user training
• rolling out the final product onto a production platform

The primary deliverable is the actual executable information system.

The other deliverables include

• user manuals
• a plan to support the users
• a plan for upgrading the information system in the future

Section 4: Workflows

The workflows describe the tasks or activities that a developer performs to evolve an information system over time.

Workflows are sometimes grouped into two broad categories: engineering and supporting. Other sources may refer to them as Process Workflows and Supporting Workflows, or as Development Disciplines and Support Disciplines.

Engineering Workflows

Engineering workflows include business-modeling, requirements, analysis, design, implementation, test, and deployment workflows.

The engineering workflows deal with the activities that produce the technical product (i.e., the information system).

Business Modeling Workflow

The business-modeling workflow uncovers problems and identifies potential projects within a user organization.

• This workflow aids management in understanding the scope of the projects that can improve the efficiency and effectiveness of a user organization.

The primary purpose of business modeling is to ensure that both developer and user organizations understand where and how the to-be-developed information system fits into the business processes of the user organization.

This workflow is primarily executed during the inception phase to ensure that we develop information systems that make business sense.

The activities that take place on this workflow are most closely associated with the planning phase of the traditional SDLC; however, requirements gathering, and use-case and business process modeling techniques also help us to understand the business situation.

Requirements Workflow

In the Unified Process, the requirements workflow includes eliciting both functional and nonfunctional requirements.

Typically, requirements are gathered from project stakeholders, such as end users, managers within the end user organization, and even customers.

The requirements workflow is used the most during the inception and elaboration phases.

The identified requirements are very helpful for developing the vision document and the use cases used throughout the development process.

Additional requirements tend to be discovered throughout the development process. In fact, only the transition phase tends to have few, if any, additional requirements identified.

Analysis Workflow

The analysis workflow primarily addresses the creation of an analysis model of the problem domain.

In the Unified Process, the analyst begins designing the architecture associated with the problem domain; using the UML, the analyst creates structural and behavior diagrams that depict a description of the problem domain classes and their interactions.

The primary purpose of the analysis workflow is to ensure that both the developer and user organizations understand the underlying problem and its domain without overanalyzing. If they are not careful, analysts can create analysis paralysis, which occurs when the project becomes so bogged down with analysis that the system is never actually designed or implemented.

A second purpose of the analysis workflow is to identify useful reusable classes for class libraries. By reusing predefined classes, the analyst can avoid reinventing the wheel when creating the structural and behavior diagrams.

The analysis workflow is predominantly associated with the elaboration phase, but like the requirements workflow, it is possible that additional analysis will be required throughout the development process.

The analysis workflow produces a problem specification as well as a Software Project Management Plan:

• Cost estimate
• Duration estimate
• Deliverables
• Milestones
• Budget

Design Workflow

The design workflow transitions the analysis model into a form that can be used to implement the system: the design model.

Whereas the analysis workflow concentrated on understanding the problem domain, the design workflow focuses on developing a solution that will execute in a specific environment.

Basically, the design workflow simply enhances the description of the evolving system by adding classes that address the environment of the system to the evolving analysis model.

The design workflow uses activities such as detailed problem domain class design, optimization of the evolving information system, database design, user-interface design, and physical architecture design.

It is during this phase that developers determine the internal structure of the software product.

• Architectural design involves decomposing the system into modules.

The design workflow is associated primarily with the elaboration and construction phases of the Unified Process.

Implementation Workflow

The primary purpose of the implementation workflow is to create an executable solution based on the design model (i.e., programming).

• This includes not only writing new classes but also incorporating reusable classes from executable class libraries into the evolving solution.

As with any programming activity, the new classes and their interactions with the incorporated reusable classes must be tested.

Finally, in the case of multiple groups performing the implementation of the information system, the implementers also must integrate the separate, individually tested modules to create an executable version of the system.

The implementation workflow is associated primarily with the elaboration and construction phases.

Testing Workflow

The primary purpose of the testing workflow is to increase the quality of the evolving system.

• Testing goes beyond the simple unit testing associated with the implementation workflow.
• In this case, testing also includes testing the integration of all modules used to implement the system, user acceptance testing, and the actual alpha testing of the software.

Practically speaking, testing should go on throughout the development of the system; testing of the analysis and design models occurs during the elaboration and construction phases, whereas implementation testing is performed primarily during the construction and, to some degree, transition phases.

Basically, at the end of each iteration during the development of the information system, some type of test should be performed.

Deployment Workflow

The deployment workflow is most associated with the transition phase of the Unified Process.

The deployment workflow includes activities such as software packaging, distribution, installation, and beta testing.

When actually deploying the new system into a user organization, the developers might have to convert the current data, interface the new software with the existing software, and train the end user to use the new system.

Supporting Workflows

The supporting workflows include the project management, configuration and change management, and environment workflows.

The supporting workflows focus on the managerial aspects of information systems development.

Project Management Workflow

Whereas the other workflows associated with the Unified Process are technically active during all four phases, the project management workflow is the only truly cross-phase workflow.

The development process supports incremental and iterative development, so information systems tend to grow or evolve over time. At the end of each iteration, a new incremental version of the system is ready for delivery.

The project management workflow is quite important owing to the complexity of the two-dimensional development model of the Unified Process (workflows and phases).

This workflow’s activities include identifying and managing risks, managing scope, estimating the time to complete each iteration and the entire project, estimating the cost of the individual iteration and the whole project, and tracking the progress being made toward the final version of the evolving information system.

Configuration and Change Management Workflow

The primary purpose of the configuration and change management workflow is to keep track of the state of the evolving system.

• In a nutshell, the evolving information system comprises a set of artifacts (e.g., diagrams, source code, and executables).
• During the development process, these artifacts are modified. A substantial amount of work—and, hence, money—is involved in developing the artifacts.
• The artifacts themselves should be handled as any expensive asset would be handled—access controls must be put into place to safeguard the artifacts from being stolen or destroyed. Furthermore, because the artifacts are modified on a regular, if not continuous, basis, good version control mechanisms should be established.

Finally, a good deal of project management information needs to be captured (e.g., author, time, and location of each modification). The configuration and change management workflow is associated mostly with the construction and transition phases.

Environment Workflow

During the development of an information system, the development team needs to use different tools and processes.

The environment workflow addresses these needs. For example, a CASE tool that supports the development of an object-oriented information system via the UML could be required. Other tools necessary include programming environments, project management tools, and configuration management tools.

The environment workflow involves acquiring and installing these tools. Even though this workflow can be active during all of the phases of the Unified Process, it should be involved primarily with the inception phase.

Section 5: Extensions to the Unified Process

The Unified Process does not address

• Staffing
• Budgeting
• Contract management

Nor does in consider a variety of issues after product delivery, such as

• Maintenance
• Operations
• Support

As it stands, it is not a complete software process; it is only a development process.

In addition, it does not address cross- or inter-project issues

• The importance of reuse in object-oriented systems development is not factored in.
• The fact that employees often work on a variety of projects concurrently makes inter-project issues important.

Needed Features

• Add a Production Phase to address issues after the product has been deployed
• Add New Workflows
  • Operations and Support
  • Infrastructure management
• Modify existing workflows
  • Test workflow
  • Deployment workflow
  • Environment workflow
• Extend existing workflows into Production Phase
  • Project Management workflow
  • Configuration & change management workflow

Additions

Production Phase

The production phase is concerned primarily with issues related to the software product after it has been successfully deployed.

This phase focuses on issues related to updating, maintaining, and operating the software.

Unlike the previous phases, there are no iterations or incremental deliverables.

• If a new release of the software is to be developed, then the developers must begin a new run through the first four phases.

Based on the activities that take place during this phase, no engineering workflows are relevant.

The supporting workflows that are active during this phase include the configuration and change management workflow, the project management workflow, the new operations and support workflow, and the infrastructure management workflow.

Operations and Support Workflow

The operations and support workflow addresses issues related to supporting the current version of the software and daily operation.

Activities include

• creating plans for the operation and support of the software product once it has been deployed
• creating training and user documentation
• implementing necessary backup procedures
• monitoring and optimizing the performance of the software
• performing corrective maintenance on the software

This workflow becomes active during the construction phase; its level of activity increases throughout the transition and, finally, the production phase.

The workflow finally drops off when the current version of the software is replaced by a new version.

Infrastructure Management Workflow

The infrastructure management workflow’s primary purpose is to support the development of the infrastructure necessary to develop object-oriented systems.

Activities such as development and modification of libraries, standards, and enterprise models are very important.

When the development and maintenance of a problem-domain architecture model goes beyond the scope of a single project and reuse is going to occur, the infrastructure management workflow is essential.

Another very important set of cross-project activities is the improvement of the software development process.

Because the activities associated with this workflow tend to affect many projects and the Unified Process focuses only on a specific project, the Unified Process tends to ignore these activities (i.e., they are simply beyond the scope and purpose of the Unified Process).

Existing Workflow Modifications and Extensions

In addition to the workflows that were added to address deficiencies contained in the Unified Process, existing workflows must be modified and/or extended into the production phase.

These workflows include the test, deployment, environment, project management, and configuration and change management workflows.

Test Workflow

For high-quality information systems to be developed, testing should be done on every deliverable, including those created during the inception phase. Otherwise, less than high-quality systems will be delivered to the customer.

Deployment Workflow

Legacy systems exist in most corporations today, and these systems have databases associated with them that must be converted to interact with the new systems. Owing to the complexity of deploying new systems, the conversion requires significant planning.

the activities on the deployment workflow need to begin in the inception phase instead of waiting until the end of the construction phase, as suggested by the Unified Process.

Environment Workflow

The environment workflow needs to be modified to include activities related to setting up the operations and production environment.

The actual work performed is similar to the work related to setting up the development environment that was performed during the inception phase. In this case, the additional work is performed during the transition phase.

Project Management Workflow

Although the project management workflow does not include staffing the project, managing the contracts among the customers and vendors, and managing the project’s budget, these activities are crucial to the success of any software development project.

Project management should be extended to include these activities.

This workflow should additionally occur in the production phase to address issues such as training, staff management, and client relationship management.

Configuration and Change Management Workflow

The configuration and change management workflow is extended into the new production phase.

Activities performed during the production phase include identifying potential improvements to the operational system and assessing the potential impact of the proposed changes.

Once developers have identified these changes and understood their impact, they can schedule the changes to be made and deployed with future releases.

Section 6: UP and UML

Where does UML come into play?

The Unified Process is a modeling technique.

• A model is a set of UML diagrams that represent various aspects of the software product being developed.