Capability Pattern: Deployment
This capability pattern covers the activities and workflow for the Deployment discipline.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage

To explain the work involved in the Deployment discipline, the activities and work products are organized into a capability pattern for the discipline.

Deployment is about making the software product available to the end-user and is the culmination of the software development effort. 

Deployment planning (Activity: Plan Deployment) starts early in the project lifecycle and addresses not only the production of the deliverable software, but also the development of training material and system support material to ensure that the end-user can successfully use the delivered software product.

Support material (Activity: Develop Support Material) covers the full range of information that will be required by the end-user to install, operate, use and maintain the delivered system. It also includes training material for all the various positions that will be required to effectively use the new system.

The Deployment Discipline places a great emphasis on ensuring the product is well tested prior to its release to the customer base. The activity Manage Acceptance Test covers to two kinds of test environments. Firstly, the build needs to be sufficiently tested in the development test environment (Activity: Manage Acceptance Test), and then re-tested at the target site (Activity: Manage Acceptance Test for Custom Install). The 'test environment' should be an 'instance' of the target environment. 

Once the product has been tested at the development site it needs to be prepared for delivery to the customer. The release can created for the purposes of beta-testing, a test deployment to the final users, or depending on it level of maturity for the final product. Activity: Produce Deployment Unit describes the logistics of creating a product release that consists of the software, and the necessary accompanying work products required to effectively install and use it. 

A beta-program refers to the process used by an organization to solicit feedback from a subset of users on products that are under development. The feedback is used to augment the product. Activity: Beta Test Product describes the activities to enable iterative deployment of a product, and systematic customer engagement in creating the final product.

For 'shrink wrap' software, Activity: Package Product describes the activities to take the software product, installation scripts and user manuals, and package them for mass production like any other consumer product.

You could have your software installed for you by the developing contractor, or you could buy the software over the counter, or download it over the internet. Activity: Provide Access to Download Site refers to the product being made available for purchase and download over the internet as a software distribution channel.


Event Driven
Multiple Occurrences
Usage Notes

Decide How to Perform the Workflow

The following decisions should be made regarding the Deployment discipline's workflow:

  • Decide how to perform the workflow by looking at the activities in this workflow. Study the diagram with its guard conditions and the guidelines. Decide which activities to perform and in which order. The most significant decision you need to make is what kind of deployment you will do:
    • Custom install
    • 'Shrink wrap' product offering
    • Access to software over the internet
  • Decide what parts of the Deployment activities to perform. The following are some parts that are more or less optional and can be introduced relatively independently from the rest.

Part of workflow


Developing end-user materials This includes Role: Technical Writer, Task: Develop Support Materials, and Artifact: User Support Material
Developing training materials This includes Role: Course Developer, Task: Develop Training Materials, and Artifact: Training Materials.  
Beta testing Only introduce Activity: Beta Test Product if you do beta testing. 

  • Decide when, during the project lifecycle, to introduce each part of the workflow.
More Information