Integration Build Plan - Farm Service Agency



[See the last page for template assistance.]

Build Plan

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 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 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 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

Integration Build Plan

1. Introduction

The purpose of this document is to describe the plan for integrating the software components of the . This forms the software baseline for the 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.

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 |

| | | |

| | | |

| | | |

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.]

2.1

2.1.1 Basic Functionality

This build will enable the following basic functionality:

•

•

•

[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. ]

2.1.2 Subsystems and Components

This build includes the following Subsystems and Components:

Table 2: Build Subsystems

|Subsystem |Processes |Components |

| | | |

| | | |

| | | |

2.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.]

2.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]

2.2

2.2.1 Basic Functionality

This build will enable the following basic functionality:

•

•

•

[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. ]

2.2.2 Subsystems and Components

This build includes the following Subsystems and Components:

Table 3: Build Subsystems

|Subsystem |Processes |Components |

| | | |

| | | |

| | | |

2.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.]

2.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]

2.3

2.3.1 Basic Functionality

This build will enable the following basic functionality:

•

•

•

[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. ]

2.3.2 Subsystems and Components

This build includes the following Subsystems and Components:

Table 4: Build Subsystems

|Subsystem |Processes |Components |

| | | |

| | | |

| | | |

2.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.]

2.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 Tools>Options, 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 File>Properties 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 Edit>Select 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 (View>Header and Footer, Ctrl+A, F9). See MS Word help for more information on working with fields.]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download