Artifact: System Development Plan
The System Development Plan is a comprehensive, composite artifact that gathers all information required to manage the project. It encloses a number of artifacts developed during the Inception phase, as well as providing its own content, and is maintained throughout the project.
Domain:  Systems Engineering
Work Product Kinds:  Plan
Purpose

The purpose of the System Development Plan is to gather all of the information necessary to control the project. It describes the approach to the development of the system, and is the top-level plan generated and used by the managers to direct the development effort. It deals with all aspects of management - technical, organizational and financial. It is a composite artifact, having content of its own, as well as logically or physically containing other artifacts.

The following people use the System Development Plan:

  • Project manager - to plan the project schedule and resource needs, and to track progress against the schedule.
  • Project team members - to understand what they need to do, when they need to do it, and what other activities they are dependent upon.
  • Other stakeholders - to understand (and sanction when appropriate) the schedules, resources, planned deliverables, development and deployment progress, and dependencies (some of which might be expectations of their participation).
  • Subcontractors - to the extent that this top-level plan is flowed-down to them (and thus becomes part of their contract).
  • Associate contractors - to understand and agree the specified organizational interface (points of contact, method of interaction, and so on) and dependencies.
  • Independent  verification and validation agents - to understand and agree to the specified organizational interface and dependencies.
Relationships
Illustrations
Tailoring
Representation OptionsUML Representation:

In certain situations, a standard is called out in a contract that stipulates the outline and contents of a System Development Plan. In this case, use that instead of the proposed outline shown in the HTML template, but you need to form a clear mapping of the information requirements of that standard to the outline in the template provided.

The supplied System Development Plan is comprehensive in its coverage and must be modified to suit the organization's and project's needs; for example, not all projects use V&V or IV&V (this is a choice based on perceived risk and complexity) and, in this case, the associated plan can be omitted. The System Development Plan can also vary widely in physical form: those enclosed artifacts that might be complex in their own right or which address a separate discipline, have been delineated as separate artifacts which are referenced from the System Development Plan. This does not preclude them from being physically bound with the System Development Plan (if this is produced on paper), or inserted in-line, in an electronic version.

Additional information

General

The System Development Plan is periodically updated (it is not stagnant shelfware), and it is understood and embraced by managers and engineers.

The System Development Plan is the defining document for the project's process. Prepare a single System Development Plan that:

  • complies with organizational standards for content
  • complies with the contract (if any)
  • provides traceability to, or waivers from, contract and organization requirements
  • is reviewed and updated (if necessary) with each iteration
  • evolves along with the design and requirements

A standard format promotes:

  • reuse of processes, methods, experience, and people
  • accountability for organizational expectations
  • homogeneous process objectives

A key discriminator of a good System Development Plan is its conciseness, pragmatism, and focus on meaningful standards and procedures.

Systems Engineering

It is intended that the System Development Plan fulfill the requirements of the Systems Engineering Management Plan (SEMP), for example, as called out in IEEE Std 1220-1998 "IEEE Standard for Application and Management of the Systems Engineering Process." The documentation of the systems engineering process, as required by the SEMP, is not repeated in the System Development Plan because it is described in the RUP itself (and so can be referenced), and the tailoring of that part of the process, to suit the particular needs of the organization and project, is described in the  Work Product: Development Case, which is referenced from the System Development Plan. Other requirements of the SEMP, for example, engineering specialty requirements, have been made explicitly part of the System Development Plan.

The reader, particularly one who has worked in the mil/aerospace sector, might also be familiar with the notion of a Test and Evaluation Master Plan (TEMP). As the US DoD Defense Acquisition Deskbook states (see http://web2.deskbook.osd.mil), "The Test and Evaluation Master Plan (TEMP) documents the overall structure and objectives of the test and evaluation program. It provides a framework to generate detailed test and evaluation plans and it documents schedule and resource implications associated with a test and evaluation program that supports the acquisition strategy." 

The TEMP is owned and kept by the customer (and can cover the acquisition of several systems as a program), and so is not exactly equivalent to the System Integration, Evaluation and Test Plan, which is a subordinate plan describing how the development organization intends to perform integration, and so forth, at the System level.

More Information