<Project/Sub-project Title>
[See the last page for template assistance.]
Build Plan
<Project/Sub-project Title>
<Office/Group>
Prepared for
USDA Farm Service Agency
6501 Beacon Drive
Kansas City, MO 64133-4676
File Name: Integration Build Plan.dot
Table of Contents
1. Introduction 3
2. Subsystems 3
3. Builds 3
3.1 <Integration Build A> 4
3.1.1 Basic Functionality 4
3.1.2 Subsystems and Components 4
3.1.3 Construction 4
3.1.4 Evaluation Criteria 4
3.2 <Integration Build B> 5
3.2.1 Basic Functionality 5
3.2.2 Subsystems and Components 5
3.2.3 Construction 5
3.2.4 Evaluation Criteria 5
3.3 <Integration Build C> 6
3.3.1 Basic Functionality 6
3.3.2 Subsystems and Components 6
3.3.3 Construction 6
3.3.4 Evaluation Criteria 6
<Project/Sub-project Title> Integration Build Plan
- Introduction
The purpose of this document is to describe the plan for integrating the software components of the <Project/Sub-project Title>. This forms the software baseline for the <xxx> release. This Integration Build applies to all components needed to receive content, approve it, and enable users to view content. The Test and Development Teams use this document to determine the subsystems and components that comprise each build and the ordering of the various builds.
2. Subsystems
[State which subsystems to implement in this release. Also state the preferred order in which the subsystems will be implemented to be ready in time for integration.]
The subsystems, processes, and components that are to be integrated for this release are shown in the table below:
Table 1: Subsystems Summary
Subsystem / Processes / Components /3. Builds
The release is divided into a number of increments, each resulting in a build, which is integration-tested. This section specifies which builds to create and which subsystems will be part of each. Build integration includes the following steps:
· Assembling the specified components into the build directories,
· Creating the compile and link command files,
· Compiling & linking the components into executables,
· Initializing the database,
· Transferring the executables, data, and test drivers to the target machines, and
· Running integration tests.
[Modify the above steps as necessary for your project.]
3.1 <Build A
3.1.1 Basic Functionality
This build will enable the following basic functionality:
· Function A.1
· Function A.2
· Function A.3
[List the capabilities against which the build will be judged. This may contain a subset of the evaluation criteria in the corresponding Use Case Model and other build specific evaluation criteria (particularly when, for example, the build is an architecture build which does not deliver much, if any capability that is visible to the end-user.
Examples
· Login Use Case: Remote or local logon.
· Register for Courses Use Case: Query course catalog database and submit course registration. ]
3.1.2 Subsystems and Components
This build includes the following Subsystems and Components:
Table 2: Build Subsystems
Subsystem / Processes / Components /3.1.3 Construction
The following information is used to construct this build:
[Specify how the build is constructed in particular:
· Build scripts and any other instructions that describe how the build is constructed.
· Baseline records that define the versions of the configuration items used to construct the build.]
3.1.4 Evaluation Criteria
The following evaluation criteria will be used to evaluate this build:
[Specific the Test cases and test scripts the will be used to evaluate the build]
3.2 <Build B
3.2.1 Basic Functionality
This build will enable the following basic functionality:
· Function B.1
· Function B.2
· Function B.3
[List the capabilities against which the build will be judged. This may contain a subset of the evaluation criteria in the corresponding Use Case Model and other build specific evaluation criteria (particularly when, for example, the build is an architecture build which does not deliver much, if any capability that is visible to the end-user.
Examples
· Login Use Case: Remote or local logon.
· Register for Courses Use Case: Query course catalog database and submit course registration. ]
3.2.2 Subsystems and Components
This build includes the following Subsystems and Components:
Table 3: Build Subsystems
Subsystem / Processes / Components /3.2.3 Construction
The following information is used to construct this build:
[Specify how the build is constructed in particular:
· Build scripts and any other instructions that describe how the build is constructed.
· Baseline records that define the versions of the configuration items used to construct the build.]
3.2.4 Evaluation Criteria
The following evaluation criteria will be used to evaluate this build:
[Specific the Test cases and test scripts the will be used to evaluate the build]
3.3 <Build C
3.3.1 Basic Functionality
This build will enable the following basic functionality:
· Function C.1
· Function C.2
· Function C.3
[List the capabilities against which the build will be judged. This may contain a subset of the evaluation criteria in the corresponding Use Case Model and other build specific evaluation criteria (particularly when, for example, the build is an architecture build which does not deliver much, if any capability that is visible to the end-user.
Examples
· Login Use Case: Remote or local logon.
· Register for Courses Use Case: Query course catalog database and submit course registration. ]
3.3.2 Subsystems and Components
This build includes the following Subsystems and Components:
Table 4: Build Subsystems
Subsystem / Processes / Components /3.3.3 Construction
The following information is used to construct this build:
[Specify how the build is constructed in particular:
· Build scripts and any other instructions that describe how the build is constructed.
· Baseline records that define the versions of the configuration items used to construct the build.]
3.3.4 Evaluation Criteria
The following evaluation criteria will be used to evaluate this build:
[Specific the Test cases and test scripts the will be used to evaluate the build]
Revision History
Version / Date / Summary of Changes / Author / Revision Marks(Yes/No) /
0.1 / Initial revision.
[Note: This template is provided to assist authors with the FSA SDLC.
Blue or black text within arrow brackets (< >) should be customized before publishing this document. Be sure to change the color of the text to black before publishing this document.
Blue text within square brackets ([ ]) provides instructions and guidance and should be deleted before publishing this document.
This document uses automatic fields:
Viewing Automatic Fields
If you cannot see the automatic fields in this document, select ToolsOptions, and then choose the View tab; in the Field Shading drop-down list, choose Always.
Customizing Automatic Fields
To customize the automatic fields in this document, select FileProperties and then replace the information in brackets (< >) with the appropriate information for this document; be sure to also customize the Custom properties by choosing the Custom tab, selecting a property, changing its value, and then clicking Modify. Repeat this for each custom field. Click OK to close the dialog.
Updating Automatic Fields
You can update the automatic fields with new, customized information by selecting EditSelect All (or Ctrl+A) and then pressing F9, or by simply clicking on a field and pressing F9. This must be done separately for Headers and Footers (ViewHeader and Footer, Ctrl+A, F9). See MS Word help for more information on working with fields.]
Build Plan Page 1 of 7 February 23, 2005