Disciplines and workflows

The Unified Process is based on a set of building blocks, or content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are achieved. This section of the document is intended to help in communication in latter stages of the project.

The main building blocks, or content elements, are the following:

Roles (who) – A Role defines a set of related skills, competencies, and responsibilities.
Artefacts or Work Products (what) – An artefact represents something resulting from a task, including all the documents and models produced while working through the process.
Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result.

Within each iteration, the tasks are categorised into nine Disciplines:

Engineering Disciplines:

Supporting Disciplines:

Business modelling discipline

Companies are becoming more dependent on IT systems, making it imperative that information system engineers know how the applications they are developing fit into the organisation. Businesses should only invest in IT when they understand the competitive advantage and value added by the technology.

The aim of business modelling is to first establish a better understanding and communication channel between business engineering and software engineering. Understanding the business means that software engineers must understand the structure and the dynamics of the target organisation (the client), the current problems in the organisation and possible improvements. They must also ensure a common understanding of the target organisation between customers, end users and developers.

Business modelling explains how to describe a vision of the organisation in which the system will be deployed and how to then use this vision as a basis to outline the process, roles and responsibilities.

Requirements discipline

The goal of the Requirements is to describe what the system should do and allows the developers and the customer to agree on that description. To achieve this, analysts elicit, organise, and document required functionality.

Analysis and design discipline

The goal of Analysis and Design is to show how the system will be realised in the implementation phase. We want to build a system that:

Performs—in a specific implementation environment—the tasks and functions specified in the use-case descriptions.
Fulfils all its requirements.
Is easy to change when functional requirements change.

Analysis and Design results in a design model and optionally an analysis model. The design model serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of how the source code is structured and written. The design model consists of design classes structured into design packages and design subsystems with well-defined interfaces, representing what will become components in the implementation. It also contains descriptions of how objects of these design classes collaborate to perform use cases.

Implementation discipline

The purposes of implementation are:

To define the organisation of the code, in terms of implementation subsystems organised in layers.
To implement classes and objects in terms of components (source files, binaries, executables, and others).
To test the developed components as units.
To integrate the results produced by individual implementers (or teams), into an executable system.

Systems are realised through implementation of components. The process describes how you reuse existing components, or implement new components with well defined responsibility, making the system easier to maintain, and increasing the possibilities to reuse.

Test discipline

The purposes of the Test discipline are:

To verify the interaction between objects.
To verify the proper integration of all components of the software.
To verify that all requirements have been correctly implemented.
To identify and ensure that defects are addressed prior to the deployment of the software

The Unified Process proposes an iterative approach, which means that we test throughout the project. This allows us to find defects as early as possible, which radically reduces the cost of fixing the defect. Tests are carried out along four quality dimensions: reliability, functionality, application performance, and system performance. For each of these quality dimensions, the process describes how you go through the test lifecycle of planning, design, implementation, execution and evaluation.

Deployment discipline

The purpose of deployment is to successfully produce product releases, and deliver the software to its end users. It covers a wide range of activities including:

Producing external releases of the software
Packaging the software
Distributing the software
Installing the software
Providing help and assistance to users

Although deployment activities are mostly centred around the transition phase, many of the activities need to be included in earlier phases to prepare for deployment at the end of the construction phase. The Deployment and Environment workflows of the Unified Process contain less detail than other workflows.

Configuration and Change management discipline

The Change Management discipline in The Unified Process deals with three specific areas:

Configuration management

Configuration management is responsible for the systematic structuring of the products. Artefacts such as documents and models need to be under version control and these changes must be visible. It also keeps track of dependencies between artefacts so all related articles are updated when changes are made.

Change request management

During the system development process many artefacts with several versions exist. CRM keeps track of the proposals for change.

Status and measurement management

Change requests have states such as new, logged, approved, assigned and complete. A change request also has attributes such as root cause, or nature (like defect and enhancement), priority etc. These states and attributes are stored in database so useful reports about the progress of the project can be produced. This activity has procedures to be followed.

Project management discipline

Project planning in the Unified Process occurs at two levels. There is a coarse-grained or Phase plan which describes the entire project and a series of fine-grained or Iteration plans which describe the iterations. However, this discipline of the Unified Process does not attempt to cover all aspects of project management. For example, it does not cover issues such as:

Managing people: hiring, training, coaching
Managing budget: defining, allocating, and so forth
Managing contracts, with suppliers and customers

This discipline focuses mainly on the important aspects of an iterative development process:

Risk management
Planning an iterative project, through the lifecycle and for a particular iteration
Monitoring progress of an iterative project, metrics

The project management discipline contains a number of other Plans and Artefacts that are used to control the project and monitoring its performance such Plans are:

The Phase Plan (The Software Development Plan)
The Iteration Plan

Phase plan

Each Phase is treated as a project, controlled and measured by the Software Development Plan which is grouped from a subset of monitoring plans:

The Measurement Plan defines the measurement goals, the associated metrics, and the primitive metrics to be collected in the project to monitor its progress.
The Risk Management Plan details how to manage the risks associated with a project. It details the risk management tasks that will be carried out, assigned responsibilities, and any additional resources required for the risk management activity. On a smaller scale project, this plan may be embedded within the Software Development Plan.
The Risk list is a sorted list of known and open risks to the project, sorted in decreasing order of importance and associated with specific mitigation or contingency actions.
The Problem Resolution Plan describes the process used to report, analyse, and resolve problems that occur during the project.
The Product Acceptance Plan describes how the customer will evaluate the deliverable artefacts from a project to determine if they meet a predefined set of acceptance criteria. It details these acceptance criteria, and identifies the product acceptance tasks (including identification of the test cases that need to be developed) that will be carried out, and assigned responsibilities and required resources. On a smaller scale project, this plan may be embedded within the Software Development Plan.

Iteration plan

The iteration plan is fine-grained plan with a time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the iteration.

There are typically two iteration plans active at any point in time.

The current iteration plan is used to track progress in the current iteration.
The next iteration plan is used to plan the upcoming iteration. This plan is prepared toward the end of the current iteration.

Therefore there are often two such plans: one for the current iteration and one under construction for the next iteration.

To define the contents of an iteration the following is needed:

the project plan
the current status of the project (on track, late, large number of problems, requirements creep, and so on.)
a list of scenarios or use cases that must be completed by the end of the iteration
a list of risks that must be addressed by the end of the iteration
a list of changes that must be incorporated in the product (bug fixes, changes in requirements)
a list of major classes or packages that must be completely implemented

These lists must be ranked. The objectives of an iteration should be aggressive so that when difficulties arise, items can be dropped from the iterations based on their ranks.

Therefore there is a set of supported Artefacts that help in measuring and building each iteration plan.

Artefacts or Work Products

The Artefacts used are:

The Iteration Assessment captures the result of an iteration, the degree to which the evaluation criteria were met, lessons learned, and changes to be done.
The project measurements is the project's active repository of metrics data. It contains the most current project, resources, process, and product measurements at the primitive and derived level.
The periodic Status Assessment provides a mechanism for managing everyone's expectations throughout the project lifecycle to ensure that the expectations of all parties are synchronised and consistent.
The work order is the Project Manager's means of communicating what is to be done, and when, to the responsible staff. It becomes an internal contract between the Project Manager and those assigned responsibility for completion.
The Issues List is a way to record and track problems, exceptions, anomalies, or other incomplete tasks requiring attention.

Environment discipline

The environment discipline focuses on the activities necessary to configure the process for a project. It describes the activities required to develop the guidelines in support of a project. The purpose of the environment activities is to provide the software development organisation with the software development environment-both processes and tools-that will support the development team.

The Environment discipline workflow is broken down into three main steps:

Prepare Environment for Project

Preparing the development environment for a means turning the underlying development process into an enactable project-specific development process. This involves :

defining how the project is going to use the configured development process.
developing a development case describing deviations of the underlying process.
qualifying artefact selections with timing and formality requirements.
preparing project-specific assets, like guidelines and templates, according to the development case.
producing a list of candidate tools to use for development.

Prepare Environment for an Iteration

The purpose of this workflow detail is to ensure that the project environment is ready for the upcoming iteration. This includes process and tools.

This work is focused mainly on:

Complete the Development Case to get ready for the iteration.
Prepare and, if necessary, customise tools to use within the iteration.
Verify that the tools have been correctly configured and installed.
Prepare a set of project-specific templates and guidelines to support the development of project artefacts in the iteration.
Make sure that all the changes made to the project environment are properly communicated to the project members

Support Environment During an Iteration

To support the developers in their use of tools and process during an iteration.

This includes installation of required software, ensuring that the hardware is functioning properly and that potential network issues are resolved without delays.

More Information: