Representation Options | UML 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.
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.
|