Work Product Descriptor (Artifact): Software Distribution Plan
This artifact describes the way software releases will be distributed to the computer platforms on which they must be installed, a cost justification of any investment needed to implement the approach, and a plan for the implementation.
Purpose

A Software Distribution Plan is used to:

  • Allow the sponsor to understand the cost associated with the software distribution process before investing in hardware and software to automate software distribution
  • Assist the development team and test team in verifying the solution, in an iterative but controlled fashion, by targeting the IT system elements and user groups identified in the plan
  • Assist the development team in building the deployment plan by having identified users, nodes, and components
  • Identify the linkages to other systems management processes. Systems management design requires identification of managed elements (nodes and components). Data collected in the Software Distribution Plan will feed the systems management design process.
  • Ensure that all users identified in the User Profile work product have a corresponding set of software
  • Enable the procurement of software licenses and hardware to provide software distribution
  • Provide a planning document for the network designers in order to plan appropriate bandwidth
  • Establish a basis for the software distribution operational process and related change management and problem management processes (which include help desk support, purchased package integration, software upgrades, etc.). The overall change management process prevents introduction of unwanted changes into the IT operational environment.
Relationships
RolesResponsible: Modified By:
Input ToMandatory:
  • None
Optional: External:
  • None
Main Description

A Software Distribution Plan is part of a systems management project or part of an IT system architecture Operational Model. The Software Distribution Plan includes the data required to allow the operations department to perform the software configuration, installation, and distribution (CID) process.

Generating a Software Distribution Plan is a way to avoid significant adverse impact on end users and IT infrastructure due to changes and the overall cost of distributing the solution. The plan, when implemented, will provide end users, who are accepting a new application and possibly new hardware, with the ability to restore their systems to a known state on short notice. Downtime, due to user error or system disruption, cannot be tolerated in mission critical applications, such as a call center for a telephone company or other utility.

Full automation of the software distribution process is not always necessary, but the plan will identify the cost benefit of automation. The information collected in the plan will be valuable for any mixture of manual and automated processes.

Properties
Optional
Planned
Tailoring
Impact of not having

Not having a Software Distribution Plan can:

  • Increase the cost of piloting the software due to rework of faulty installations
  • Increase the number of installation problem reports the team will have to deal with, thus increasing the perception of bad software quality
  • Prevent accurate procurement of software licenses
  • Increase the Help Center workload due to errors in installations
  • Lead to underestimates of the network bandwidth needed in production
Reasons for not needing

You do not need to create a Software Distribution Plan when:

  • The number of users and applications is small enough that the distribution plan can be integrated into other systems management plans.
  • A plan already exists for other solutions, and the IT system being built can easily integrate into it.
Representation OptionsThe most frequently used notation is a set of matrices that the project sponsor can read to decide whether to automate the CID process and that the operations staff can use to plan for software configuration, installation, distribution, and support. In practice spreadsheets, a configuration database should be used. The database is populated progressively during the engagement. It starts from the user profile, operational model physical diagram, and deployment units work product descriptions.