United States Department of Agriculture (USDA) eGovernment Program

#########  {#section .unnumbered}

#########  {#section-1 .unnumbered}

######### Management and Planning Profile -- Project Plan {#management-and-planning-profile-project-plan .unnumbered}

######### eDeployment Business Case {#edeployment-business-case .unnumbered}

***DRAFT***

May 2004

![](media/image1.jpeg){width="1.75in" height="1.2666666666666666in"}

#########  {#section-2 .unnumbered}

Table of Contents

[Revision History iii](#revision-history)

[Previous Change History iii](#previous-change-history)

[Document Sign-off iii](#document-sign-off)

[1 Introduction 1](#introduction)

[2 Staffing Plan 2](#staffing-plan)

[2.1 Purpose 2](#purpose)

[2.2 Government and Contracted Resources
2](#government-and-contracted-resources)

[2.3 The Project Team 3](#the-project-team)

[2.3.1 eGovernment Advisory Teams 4](#egovernment-advisory-teams)

[2.3.2 eGovernment Program Management Office
5](#egovernment-program-management-office)

[2.3.3 eDeployment Project Team 5](#edeployment-project-team)

[3 Quality Assurance Plan 13](#quality-assurance-plan)

[3.1 Purpose 13](#purpose-1)

[3.2 Application Standards and Policies
13](#application-standards-and-policies)

[3.3 Configuration Management 14](#configuration-management)

[3.4 Testing 14](#testing)

[3.4.1 Component (Unit) Testing 15](#component-unit-testing)

[3.4.2 Assembly Testing 16](#assembly-testing)

[3.4.3 Product (System) Testing 16](#product-system-testing)

[3.4.4 Test Plan Quality Assurance 17](#test-plan-quality-assurance)

[3.5 Reviews, Walkthroughs, and Audits
17](#reviews-walkthroughs-and-audits)

[3.5.1 Reviews 17](#reviews)

[3.5.2 Walkthroughs 17](#walkthroughs)

[3.5.3 Audits 18](#audits)

[3.6 Verification and Validation 18](#verification-and-validation)

[3.7 Issue Tracking Process 18](#issue-tracking-process)

[4 Project Schedule 20](#project-schedule)

[4.1 Purpose 20](#purpose-2)

[4.2 eDeployment Tasks and Milestones
20](#edeployment-tasks-and-milestones)

[4.3 Plan for Progress Updates 26](#plan-for-progress-updates)

[4.4 Assessing and Managing Schedule Changes
26](#assessing-and-managing-schedule-changes)

[5 Costs 27](#costs)

[5.1 Purpose 27](#purpose-3)

[6 Project Deliverables 29](#project-deliverables)

[6.1 Purpose 29](#purpose-4)

[6.2 eDeployment Project Deliverables
29](#edeployment-project-deliverables)

[7 Assumptions 31](#assumptions)

[8 Appendix A -- eGovernment Advisory Teams
32](#appendix-a-egovernment-advisory-teams)

[9 Appendix B -- Description of Deliverables
34](#appendix-b-description-of-deliverables)

#   {#section-3 .unnumbered}

# Revision History {#revision-history .unnumbered}

## Previous Change History {#previous-change-history .unnumbered}

Table a -- Previous Change History

  --------------------------- ------------------------ -------------------------- ---------------------------
  **[Version]{.smallcaps}**   **[Date]{.smallcaps}**   **[Author]{.smallcaps}**   **[Comment]{.smallcaps}**

  1.0                         04/30/04                 Elfije Salihu              Initial Draft Review
  --------------------------- ------------------------ -------------------------- ---------------------------

## Document Sign-off {#document-sign-off .unnumbered}

Table b -- Document Sign-off

  ------------------------ ---------------------------- ----------------------------
  **[Date]{.smallcaps}**   **[Name]{.smallcaps}**       **[Title]{.smallcaps}**

                                                        
  ------------------------ ---------------------------- ----------------------------

# Introduction

The Project Plan is the comprehensive plan for delivering the
eDeployment solution. It delineates the who, what, why, when, where, and
how aspects of the project. It is the road map for achieving the program
objectives and realizing the project benefits. The Project Plan is a
critical communication tool and is at the heart of the planning and
management processes.

Ongoing project planning is crucial to a successful investment. The
Project Plan provides the starting position for project mobilization. It
provides a baseline workplan and identifies the key components of the
project such as the project team, the tasks that will be completed, and
the timeframe for completing the tasks. The Project Plan will guide
eDeployment team members, management, and stakeholders throughout the
phases of the project. During the course of the project, it may be
necessary to update the plan to accommodate approved change requests.

The Project Plan for eDeployment includes the following sections:

-   **Staffing Plan:** Describes the project team's organizational
    structure and their respective roles, responsibilities, and desired
    skills.

-   **Quality Assurance Plan:** Addresses the quality management
    activities for the duration of the project.

-   **Project Schedule:** Identifies the timeline the project will
    follow to achieve its stated objectives.

-   **Costs:** Describes the estimated cost to complete project tasks.

-   **Deliverables:** Defines all deliverables that will be created
    during the project.

-   **Assumptions**: Identifies assumptions made while writing the
    project plan, which may affect the estimates in each section of the
    Project Plan.

# Staffing Plan

## Purpose

Managing staff resources properly is crucial to the success of the
eDeployment initiative. The staffing plan will provide an overview of
the teams, roles and responsibilities that will be required during
various phases of the project to implement eDeployment.

The staffing plan for eDeployment is written to allow for changes in the
number and type of staff and/or contracted resources, depending on the
project phase and the types of tasks being conducted. For example, early
phases of the project will require a large number of implementation
resources such as designers, developers, and testers. During later
phases of the project, the team composition will shift to favor
operational roles such as maintenance, administration, and support.

The staffing plan will address the following components:

-   Government and Contracted Resources; and

-   eDeployment Project Team.

## Government and Contracted Resources

The recommended project team will be a mixture of USDA employees and
contracted resources. Personnel resources will be scaled according to
project demands at a given phase. Initial phases of the project will
require a high number of contractors while USDA employees undergo the
pre-requisite training and exposure to new technologies. As the
organization's familiarity and knowledge of the technologies becomes
integral to daily business operations, the ratio of contractors to USDA
employees will decrease.

It is anticipated that USDA employees will focus in the following areas:

-   Coordinating with USDA eGovernment initiatives on an ongoing basis;

-   Documenting roles and responsibilities;

-   Developing and maintaining a USDA taxonomy;

-   Identifying metadata standards;

-   Conducting business process re-engineering efforts;

-   Defining workflows and associated business rules, roles, and
    responsibilities;

-   Identifying USDA customers and analyzing their needs;

-   Developing templates for improved workflow within the solution;

-   Managing USDA web presence and content templates;

-   Creating educational and marketing materials; and

-   Promoting enterprise-wide and Agency communications.

Contracted resources will likely focus in the following areas:

-   Designing, developing, installing, and integrating systems;

-   Designing and developing shared data sets such as data warehouses;

-   Providing program and project management;

-   Developing User Interface (UI) standards and associated templates;

-   Providing communications support;

-   Performing data conversion; and

-   Facilitating vendor relationships and procurement activities.

## The Project Team

The project team is comprised of personnel resources with a variety of
skill sets. Throughout the lifecycle of the project, the quantity and
type of personnel resources on the project team will fluctuate depending
on the phase of the project and the task at hand.

The project team is founded based on the following tenets:

-   Focus on cross-Agency participation to continuously and correctly
    represent requirements from Agencies;

-   Focus on a structure that provides governance due to executive
    sponsorship;

-   Apply dedicated USDA full-time resources to build and run the
    initiative;

-   Embody a mixed structure of both contractors and USDA employees; and

-   Address the need for business expertise to ensure technology
    correctly supports the initiative.

The project team hierarchy is organized into three levels to support all
USDA enabling initiatives. The first level consists of executive
leadership from the Deputy Secretary, Chief Information Officer (CIO),
Associate Chief Information Officer (ACIO) for eGovernment, and
eGovernment Advisory Teams.[^1] The second level is the eGovernment
Program Management Office, which provides program and project management
to the project teams. The third level consists of the enabling and
strategic initiatives' project teams. Each project team (e.g.,
eAuthentication, eDeployment, eLearning, Strategic project teams, etc.)
will have a project manager or multiple project managers depending on
the scope of work.

![](media/image2.wmf){width="5.996527777777778in"
height="3.3680555555555554in"}

Figure 2.3 -- Project Organizational Hierarchy

### eGovernment Advisory Teams

The eGovernment Advisory Teams, led by USDA's eGovernment Executive and
supported by the Program Management Office, articulate the big ideas and
instill the vision to turn the ideas into reality. The Advisory Teams
also provide leadership and issue resolution for the Enabling Project
Teams, including eDeployment. The Advisory Teams are:

-   eGovernment Executive Council;

-   eGovernment Working Group;

-   eGovernment Steering Committee; and

-   Agency eGovernment Team.

The eGovernment Advisory Teams will be responsible for periodically
monitoring Agency initiatives for adherence to USDA's eGovernment
Strategic Plan, existing laws and regulations, OMB requirements,
National Archives and Records Administration retention schedules, and
business requirements. They will also be responsible for mediating any
conflicts that arise among the Agencies and resolving them in the best
interest of USDA in upholding or modifying existing standards. Detailed
descriptions of each of the Advisory Teams are located in Appendix A of
this document.

### eGovernment Program Management Office

An eGovernment Program Management Office (PMO) will organize and guide
the delivery of the enabling initiatives (eDeployment, eAuthentication,
and eLearning) while maintaining alignment with USDA's overall strategic
vision for eGovernment. In addition to spearheading the enabling
initiatives, the PMO will also support and partner with USDA's strategic
initiatives[^2]. This will ensure that all eGovernment initiatives are
planned and implemented in a consistent, integrated manner under the
auspices of the eGovernment executive leadership and advisory teams. The
Program Management Office will require the following processes to
support the program:

-   Contract management;

-   Communications management;

-   Configuration management;

```{=html}
<!-- -->
```
-   Financial management;

-   Issue management;

-   Performance reporting;

-   Quality management;

-   Release management;

-   Resource management; and

-   Vendor management.

Members of the Program Management Office require the skills to work
effectively with others and provide both leadership and support to the
team in their respective areas. The Program Management Office will also
be responsible for coordinating overall PMO tasks with the Project
Manager for eDeployment.

### eDeployment Project Team

The eDeployment project team is responsible for conducting all
eDeployment implementation tasks and ensuring that the eDeployment
solution meets the needs of all of its users. The project team is
organized into the following groups:

-   Implementation Team; and

-   Support Team.

USDA Agencies will work closely with the Implementation Team, the
Support Team, and various subject matter experts when they are ready to
implement eDeployment capabilities. The Program Management Office will
define a formalized process that outlines the guidelines and
expectations for early adopter Agencies working with the eDeployment
project team.

![](media/image3.wmf){width="6.5in" height="3.314583333333333in"}

Figure 2.3.3 -- eDeployment Project Team

#### Implementation Team

The eDeployment solution consists of distinct technical capabilities.
Therefore, it is recommended that separate implementation teams be
created under the auspices of the eGovernment Program Management Office.
The implementation teams will include, but are not limited to, the
following:

-   Web Content Management;

-   Document Management; and

-   Portal Services / [www.usda.gov](http://www.usda.gov/).

Each Implementation Team is responsible for designing, developing,
testing, and deploying the technology capability. Each implementation
team will be structured as follows:

-   Project Management;

-   Application Design/Development;

-   Business Process/Quality Assurance; and

-   Change Management/Training.

Personnel resources on the Implementation Team will fluctuate depending
on the task at hand or the phase of the project. For example, the
project may have a high composition of designers/developers during early
phases, but then may transition to a majority of testers and trainers in
later phases of the project.

The Implementation Team will require the following roles and
responsibilities:

-   **Project Manager:** Project managers ensure that all areas of the
    project match the scope and schedule identified at the beginning of
    the project. If issues arise that affect these areas, they work with
    staff and management to resolve the issues efficiently and
    effectively. Ideally, these risks are either avoided with a
    well-developed project plan and timely and effective communication
    with staff about deliverables and schedules, or seen very early and
    mitigated with the lowest impact on the project. Project Managers
    also serve as liaisons with management on all areas of the project,
    such as in the Program Management Office (PMO).

```{=html}
<!-- -->
```
-   **Application Designer/Developer:** The Application
    Designer/Developer is responsible for designing, building, testing,
    deploying, and maintaining the application components. The
    Application Designer/Developer will also ensure that developed or
    modified application components align with the application
    architecture and meet application performance goals.

```{=html}
<!-- -->
```
-   **Business Process/Quality Assurance:** The Business Process
    designer is responsible for identifying current eDeployment
    processes, documenting changes to these processes, and defining the
    processes that are required to manage new eDeployment activities.
    The Business Process designer ensures that any changes to existing
    policies and standards are identified and documented. Additional
    responsibilities include refining existing eDeployment requirements
    and documenting new requirements (such as functionality
    enhancements).

> During later phases of the project, it is logical for the process
> designer to transition into a quality assurance/testing role. This
> role consists of test planning and test execution to verify that
> project quality requirements are met. Related tasks include writing
> test scripts, documenting expected results, and validating test
> results to ensure that they meet entry and exit criteria.

-   **Change Management/Training Specialist:** The Change
    Management/Training Specialist is responsible for planning and
    implementing the workforce transition to the new eDeployment
    capability. Responsibilities include identifying critical roles for
    evolving and sustaining the eDeployment capability and developing
    the detailed design of the new organization (roles,
    responsibilities, reporting relationships, rewards, and career
    management). It is critical that roles and responsibilities be
    defined for both the Department and Agency organizations in USDA.

> During later phases of the project, the Change Management/Training
> Specialist will be responsible for preparing training materials and
> logistics, conducting training, and customizing training/education
> design to meet ongoing needs.

#### Support Team

In addition to tasks performed by the Implementation Team, there are
also many tasks that will be required universally across all
implementation teams. A support team will be created to conduct these
"core" implementation tasks and to ensure that all activities are
consistent, integrated and performed in a collaborative manner. This
team is the "glue" that holds USDA's enterprise capabilities together
and ensures that all tasks are completed in an integrated fashion with
an enterprise-wide perspective. The support team will be comprised of
the following groups:

-   Project Management;

```{=html}
<!-- -->
```
-   Technical Architecture;

-   Data/Migration;

-   UI/Web Presence; and

-   Production Support.

##### Project Management

-   **Project Manager:** The Support Team will require its own project
    management. During initial project mobilization only one project
    manager will be required, but as the Support Team grows larger and
    the scope of work increases, additional project management support
    will be needed.

##### Technical Architecture

-   **Network Engineer:** The Network engineer is responsible for
    configuring the network development, production, and test
    environments for implementation efforts (e.g., Content Management,
    Document Management, Portal Services.)

-   **System Administrator:** The system administrator installs,
    configures, and maintains the software and hardware development,
    production, and test environments for implementation projects. This
    includes installing and configuring Enterprise Application
    Integration (EAI) and Content Aggregation (CA) components.

```{=html}
<!-- -->
```
-   **System Developer:** The System Developer is responsible for the
    design, development and testing of custom Enterprise Application
    Integration (EAI) components and custom Content Aggregation (CA)
    components.

-   **Technical Architect:** The Technical Architect is responsible for
    designing the enterprise-wide eDeployment physical architecture.
    This resource will work with other architects to ensure that the
    developed and deployed capabilities align with specific application
    components and enterprise-wide architecture objectives. In addition,
    the Architect will identify and resolve cross-capability issues that
    affect the business architecture integrity.

##### Data/Migration

-   **Content/Document Migrater:** The Content/Document Migrater is
    responsible for leading the content/document migration effort. This
    includes managing the preparation of content/documents as well as
    the transition of content/documents into new tool. Other
    responsibilities include identifying and resolving content/document
    ownership and deployment issues. The Migrater will work closely with
    the implementation teams to ensure that all components interact to
    meet performance goals. Following implementation, the Migrater will
    coordinate change requests to taxonomy, workflow, etc.

```{=html}
<!-- -->
```
-   **Database Administrator:** The Database Administrator (DBA)
    supports the application Designer/Developer and Production Support
    by applying and implementing data models, administering user
    management of databases, and performing data backup and recovery.

-   **Data Architect:** Data Architects are responsible for designing
    and developing eDeployment databases and data stores such as data
    warehouses. In addition to working with eDeployment, Data Architects
    will also work with other USDA implementation teams (e.g., eLoans,
    eGrants) to provide subject matter expertise in data design and
    development. Data Architects will also coordinate with Taxonomy
    Specialists to ensure that the data model for the content management
    system is designed to support the taxonomy. Data Architects will
    ensure that consistent communication and coordination exists with
    the Enterprise Architecture group in OCIO.

```{=html}
<!-- -->
```
-   **Database Developer:** Database Developers are primarily
    responsible for writing database scripts for eDeployment
    applications. Another key responsibility is to provide data
    development support for the Production Support team and other
    application development teams.

##### UI/Web Presence

-   **Graphic Designer:** Graphic Designers develop the visual
    presentation of Agency publications, Web pages, Agency branding
    elements, and user interfaces. Graphic Designers are primarily
    responsible for developing graphical content, including prototypes
    and storyboards.

```{=html}
<!-- -->
```
-   **Multimedia Specialist:** Multimedia Specialists create original
    multimedia (such as streaming audio/video and digital imagery) and
    ensure that the files meet industry, USDA, and Government standards
    (such as captioning for video) for use and availability.

```{=html}
<!-- -->
```
-   **UI Designer / Developer:** The UI Designer/Developer is
    responsible for ensuring that application user interfaces are
    designed effectively to meet the needs of all users. The UI
    Designer/Developer will conduct focus groups and/or audience
    analysis tasks to aid in the design of presentation elements,
    content templates, and content standards and guidelines. This
    resource will collect and analyze user needs to determine the
    content that users find to be most valuable and what might need to
    be revised or discarded. The UI Designer/Developer will work closely
    with graphic artists to ensure that all elements of the interface
    work together and have a consistent look-and-feel.

-   **Usability Tester:** The Usability Tester ensures that web
    applications, forms, and content comply with usability best
    practices and standards, especially those mandated by Section 508.
    The usability tester will prepare and conduct usability tests to
    document how usable and navigable a page is, as well as resolve any
    issues associated with the integration of text, media, graphic
    design, and branding with the UI.

##### Production Support

-   **Application Support and Maintenance:** The Application Support and
    Maintenance role is required once eDeployment applications are
    deployed to users. This task consists primarily of responding to
    customer queries and working with customers to troubleshoot and
    solve issues related to eDeployment applications. This will entail
    updating the application(s) to incorporate enhancements and to fix
    defects

```{=html}
<!-- -->
```
-   **Environment Installation and Maintenance:** The Environment
    Installation and Maintenance team will exist within the selected
    hosting facility. This team is responsible for designing,
    installing, configuring, and updating the technology
    infrastructure/physical environment. Other tasks would include
    management of local area networks, data connectivity, site-wide
    software and other technology-based services in the operating
    environment.

```{=html}
<!-- -->
```
-   **Training and Documentation Specialist:** Training and
    Documentation Specialists will be required following deployment of
    the eDeployment solution. These specialists ensure that all system
    users are properly and adequately trained and provide follow-on
    training as the system is upgraded. In addition, they will develop
    ongoing training (such as hands-on training and online training) for
    system users and technical staff.

#### USDA Subject Matter Expertise 

####  {#section-4 .unnumbered}

Teams of subject matter experts in USDA will be formed on an as-needed
basis to perform more specialized roles. These types of roles may
include Business Analysts, Content Managers, Production Managers,
Digital Assets/Rights Managers, Records Managers, and Taxonomy
Architects/Analysts. It is expected that USDA employees will perform
these roles on a part-time, as-needed basis. Specialized eDeployment
roles may include:

-   **Business Analysts:** Business Analysts develop and follow all
    levels of the business strategy, including strategic plans, existing
    Federal laws and regulations, OMB requirements, and other
    Agency-specific business requirements. They see the big picture of
    how these systems fit into the overall strategy of the organization,
    identify and manage project sponsors, preside over the project
    mandate process, devise an overall workload and budget strategy, and
    work with the project teams to ensure that the project mandate is
    fully integrated into the organization. They understand the
    business, know how to negotiate, understand the concepts and
    complexities of the initiatives, and can motivate staff and
    management.

```{=html}
<!-- -->
```
-   **Content Managers:** Content Managers are experienced in
    content/information development and management and fully understand
    the business requirements of both USDA and its Agencies. They lead
    the planning and execution of USDA/Agencies' content/information
    initiatives through teaching, negotiating, and coordinating with all
    areas within and outside of the organization. Content Managers
    should be knowledgeable of web technologies, editorial and
    cataloging processes, information technology infrastructure, and
    abstract thought.

-   **Production Managers:** Production Managers ensure that
    content/information flow through the system(s) at an established
    rate and acceptable degree of quality. They manage production staff,
    design production workflow, create and enforce production schedules,
    and create and enforce quality.

```{=html}
<!-- -->
```
-   **Digital Assets/Rights Managers:** Digital Assets/Rights Managers
    understand the complexities of trademark and copyright law for
    digital assets and ensure that USDA/Agencies do not violate existing
    U.S. and international laws. They oversee the workflow in any
    Digital Rights/Digital Asset management system.

```{=html}
<!-- -->
```
-   **Records Managers:** Records Managers already exist within
    USDA/Agencies. They must ensure that all Federal laws and
    regulations about content/document/records management are followed
    within the system(s).

```{=html}
<!-- -->
```
-   **Taxonomy Architects/Analysts:** Taxonomy Architects/Analysts
    develop and maintain taxonomies that relate to the business
    processes and functions of the organization. They also assure that
    metadata usage follows established standards and/or guidelines. It
    is ideal for editorial/indexing staff, preferably with library
    science experience, to be included in this role. The Taxonomy
    Architect/Analyst should coordinate with content
    designers/developers and workflow process teams to provide input
    into processes such as approval, deletion, archival, updates, etc.

# Quality Assurance Plan

## Purpose

The Quality Assurance Plan for eDeployment outlines the methods and
procedures that will ensure that stakeholder expectations and
performance objectives are met, that project staff and business partners
perform in accordance with metrics set forth in the requirements
documents, and that measurable indicators are systematically tracked to
assess progress and promote accountability. It helps to ensure that the
project is focused on improving delivery capability in terms of people,
processes, and technology.

Although the approach for the Quality Assurance Plan is created in the
early stages of the project, it will be updated and managed throughout
the project lifecycle. The Quality Assurance Plan describes:

-   Application standards and policies;

-   Configuration management;

-   Testing;

-   Reviews, walkthroughs, and audits;

-   Verification and validation; and

-   Issue tracking process.

## Application Standards and Policies

Application standards and policies consist of the standards, rules, and
guidelines to be followed during the application development process for
programming and documenting programs. Application standards and policies
are not meant to be used for training purpose, but rather, as a
reference manual for the standards set by the development architecture.

Application standards and policies will provide a consistent way of
designing, documenting, and programming over the different areas of
work, such as user interface design, database design, and application
development. Quality reviews may be derived from these standards and
policies.

The application standards and polices will consist of the following:

-   Programming standards;

-   Performance design guidelines;

-   File/Directory naming standards;

-   Application program interface (API) description and use;

-   Procedures for using the development architecture and its operations
    support components (e.g., checking in and out code, when backups
    occur and how to retrieve archived files, compiling programs);

-   Data standards; and

-   UI standards.

## Configuration Management

Configuration management is the process for controlling changes that
occur during the project. This includes managing changes to several
types of project deliverables, including the work agreement/ arrangement
letter, project plan, design documents, application modules, and other
components of the business capability.

Configuration management relies on a systematic approach for controlling
the changes that occur during the project. The process defines the
configuration management activities to be completed, how they are to be
accomplished, who is responsible for performing specific activities,
when the activities are to happen, and what resources are required.

The configuration management process is determined during project
planning. The process enforces the integrity of the project's work
products throughout all stages of development and maintenance. The
cornerstone of configuration management is the change control process to
manage and track changes to all work products. The change control
process will be coordinated with issue tracking processes.

## Testing

Testing is the primary step for evaluating compliance with requirements
and ensuring overall quality. Testing for the eDeployment initiative
will be conducted at several levels. There are three generic test
phases, which will be conducted for both application development and
technology infrastructure delivery. These phases include:

-   Component or Unit Testing;

-   Assembly Testing;

-   Product or System Testing.

The same basic steps are followed for each phase of testing. The driver
of every test phase is a specification, and the output of every test
phase is an executed test model that includes test conditions and
expected results, a cycle control sheet, test scripts, and actual
results. This allows the testing activities to be described generically
throughout this section of the Quality Assurance Plan, with unique
considerations or techniques listed in the tasks related to each test
phase.

Specifically, the activities common to all phases of testing in the
application and architecture segments are as follows:

-   **Develop test approach** -- provides the objectives, schedule,
    environment requirements, and entry and exit criteria for the test
    stage.

-   **Plan test** -- identifies test conditions and test cycles for the
    test stage.

-   **Prepare test** - defines input data and expected results, scripts
    the test cycles, defines stubs and job streams, and prepares the
    cycle control calendar.

-   **Establish test environment** - ensures that the environment is
    established and tested before test execution.

-   **Execute test** - performs the scripts contained in the test model,
    compares the actual results to the expected results, and identifies
    and resolves discrepancies.

### Component (Unit) Testing

A component test is the test of an individual component of the solution.
The objective of a component test is to ensure that the component
correctly implements the design specifications.

All components of a business capability including technology
infrastructure, application programs, conversion programs, input/output
(I/O) modules, and job control language are subject to component test.
Some human performance and business process components may need to be
tested with other components of the business capability. All of the
capabilities of the component should be exercised during component test
to ensure that the component meets the functional and quality
requirements of the specification.

It is important that the driver of a component test be the detailed
design specification documents and not the component itself. If, for
instance, one sets out to exercise all of the paths through a particular
component as written, the component may pass the tests successfully and
yet not implement the specifications from which it was supposed to be
created.

### Assembly Testing

The assembly test verifies the interaction of related components to
ensure that the components function properly when integrated. As in the
case of component testing, this can occur at different levels depending
upon ones perspective. Considering the business capability as a whole,
assembly testing occurs when all of the business capability elements are
brought together for the first time in the business capability release
test. Within each business capability element (business process,
technology and application), the assembly tests are a function of
integrating individually developed components and making sure they work
together properly.

In testing either the technology infrastructure or applications,
assembly test ensures data is passed correctly between screens in a
conversation or batch process and messages are passed correctly between
a client and a server(s). The application flow diagram within the
application architecture will depict the assemblies---either online
conversations or batch assemblies---that will be assembly tested.

By the completion of assembly testing, the object of the test should be
technically sound and the information flow throughout should be correct.
Component and assembly testing ensures that all transactions, database
updates, and conversation flows function accurately.

### Product (System) Testing

The product or system test ensures that all requirements have been met.
Like the aforementioned tests, product testing may also occur at
multiple levels. However, within these multiple levels, the purpose of
testing is the same: to ascertain that the requirements have been met.

The product test verifies the actual functionality of the solution as it
supports the various cycles of transactions, the workflow within
organizational units and among these units. The specification against
which the product test is run is the specification of all applicable
requirements.

User Acceptance Testing, or focused user verification of capabilities,
is accomplished through a final iteration of product (system) test
execution. In this test, users execute a sub-set of the system test
scenarios that represent more end-to-end capabilities. A simulated
production environment with production data is used for this iteration
of testing.

### Test Plan Quality Assurance

Designated reviewers will participate in all formal testing and
qualification activities. These activities include the following
verifications:

-   Ensure that test plans adequately verify the software requirements;

-   Confirm test environment has a controlled configuration;

-   Validate that test data supports all test cases;

-   Maintain the integrity of and adherence to test plans during
    testing; and

-   Ensure accurate documentation of test results.

## Reviews, Walkthroughs, and Audits 

The goal of the Quality Assurance Program is to deliver an error-free
system that meets all requirements and satisfies the needs of the
stakeholders and users. As part of that goal, the quality of the project
will be subjected to review, audits, and walkthroughs. Both processes
and technical solutions will be reviewed for quality assurance. Within
the Quality Assurance Plan, objective measures of quality will be used
to:

-   Monitor compliance;

-   Identify deficiencies;

-   Correct problems; and

-   Avoid repetition of errors by identifying and eliminating their
    causes.

All reviews, walkthroughs, and audits will be documented. If an issue is
identified, it will be entered into the issue management process and
formal project documentation will be updated.

### Reviews

Full reviews will be conducted to verify eDeployment system
functionality. To comply with the issue management process, any issues
that are identified will initiate the creation of a system change order.
Functionality reviews will begin at the end of the development phase and
any issues or concerns will be identified and corrected during the
product test phase.

### Walkthroughs

The eDeployment technical implementation team will be responsible for
conducting walkthroughs to support the development and change process.
Walkthroughs consist of a structured series of peer reviews to enforce
standards, detect errors, and improve system quality. The final
responsibility of the walkthroughs lies with the eDeployment project
management.

### Audits

A technical advisor or other designated technical auditor may be
requested to conduct internal audits of the processes for development,
issue management, and integration activities to verify compliance with
USDA standards. The project management will create an audit schedule and
coordinate the schedule with the auditor. Detailed results will be
reported to management and appropriate team members in a written report.

## Verification and Validation

Verification and validation are performed to ensure that the total
collection of deliverables is consistent with the specifications. The
deliverables are verified against the requirements, facilitating
stakeholder sign-off. This process helps ensure that the current and
future design work products are produced as planned. In some cases, a
separate contract for independent verification and validation may be
considered.

The outcomes of this process are:

-   Reconciled gaps between design and intent;

-   Documented stakeholder buy-in; and

-   Verified and validated application design.

## Issue Tracking Process

The issue tracking process documents any issues, open points, or
decisions that will have a significant effect on the project. It also
records design rationale for later stages of development, particularly
maintenance.

An issue tracking process along with issue management is used to ensure
that all issues are tracked and resolved. This deliverable provides a
framework to structure discussion of project issues from assessment to
resolution. It also helps provide an audit trail of discussion and
decisions on all project issues.

A separate issue entry will be created for each issue. These entries
will be used as a reference for use by those working and reviewing
issues. When creating an issue entry, the following information should
be incorporated:

-   **A general description of the problem to be resolved.** A brief and
    a full description, the issue class (e.g., management), and the
    items and areas of the project affected by the issue are all
    included here. Also noted are those groups and individuals that have
    a stake in the solution of this problem: management, development
    teams, and business representatives. Other information defined
    includes the issue\'s priority, status, date created, author, date
    due for resolution, and the responsible party for resolving the
    issue.

-   **A list of possible, proposed, and final solutions to the
    problem**. In the sample, the process by which the staffing
    shortfall issue was resolved has been documented. Listed here are
    several possible alternative solutions to the problem and a brief
    description of the final resolution of the problem. A brief timeline
    of the resolution process is also provided.

# Project Schedule 

## Purpose

The Project Schedule details all of the tasks required for accomplishing
project objectives and satisfying requirements. It shows the target
start and stop dates for activities associated with the accomplishment
of significant project milestones. The Project Schedule is a
task-oriented decomposition of the total work scope of the project from
planning through implementation.

The Project Schedule contains a listing of tasks related to planning,
design, development, testing, management, and quality control tasks. The
Project Schedule for eDeployment will discuss the following:

-   eDeployment Project Tasks and Milestones;

-   Plan for Progress Updates; and

-   Assessing and Managing Schedule Changes.

The Project Schedule is a key component of the Project Plan as it serves
as a basis for performance measurement, analysis, and reporting. It will
be updated continually throughout the project to reflect any changes.

## eDeployment Tasks and Milestones

The eDeployment project has been scheduled within a phased approach.
Those Agencies who want to immediately utilize some or all aspects of
the eDeployment solution are called "Early Adopters". A phased approach
will provide flexible options for implementation to accommodate the
early adopters as well as other Agencies that are not prepared for
implementation.

A phased approach to implementing this initiative is beneficial because
it will provide scalability and extendibility. *Scalability* means that
hardware and software can be purchased to accommodate the needs of the
early adopters. As Agencies throughout the Department are ready to
implement eDeployment, hardware, software, and support services can be
scaled to accommodate them. *Extendibility* means that early adopter
Agencies have the ability to implement basic services covering a large
subset of eDeployment functionality in a relatively quick timeframe.
Agencies then have the option to extend the functionality provided to
meet their specific needs in subsequent phases.

![](media/image4.wmf){width="5.9944444444444445in"
height="3.5395833333333333in"}

Figure 4.2: eDeployment Project Milestones

[]{.mark}

[]{.mark}

eDeployment Project phases, as depicted in Figure 4.2, include:

-   **Ongoing eDeployment Project Tasks (Q2 FY03-Q4 FY07) --** Ongoing
    eDeployment Project Tasks consist primarily of program management
    and project management tasks that will be applied consistently to
    all eDeployment initiatives throughout the lifecycle of the project.
    Project management will originate and be coordinated from the
    eGovernment Program Management Office (PMO). eDeployment will
    require ongoing operations, support, and maintenance tasks following
    the Early Adopters Capability Release.

```{=html}
<!-- -->
```
-   **Phase 1: eDeployment Pre-Implementation Tasks (Q2 FY03-Q4
    FY03)--** Phase 1 consists of the tasks that must be performed prior
    to implementation. These initial tasks include the vendor analysis
    and selection process as well as creating and configuring the
    technology infrastructure and the physical network required for
    implementation.

-   **Phase 2: eDeployment Early Adopter Implementation (Q2 FY03--Q2
    FY04)--** Phase 2 consists of early adopter Agencies' full
    implementation of the eDeployment solution. This includes project
    planning, design, build, test, conversion, pilot, and workforce
    transition activities. It is estimated that early adopter Agencies
    will have completed the first eDeployment capability release by the
    fourth quarter (Q4) of fiscal year 2003 (FY2003). Early adopters'
    continued deployment activities, which may include enhancements to
    the solution or extensions of functionality, would be conducted over
    the remainder of FY04.

-   **Phase 3: eDeployment Enterprise-wide Implementation (Q2 FY04-Q4
    FY07)--** Agencies that did not participate in early adopter
    implementation activities are expected to deploy the enterprise-wide
    capability during the time period ranging from Q2 of FY2005 through
    Q4 of FY2007. USDA-wide utilization of the eDeployment solution will
    be realized in Q4 of FY2007. This, of course, hinges on Agencies'
    ability and willingness to participate in implementation activities.

The following timeline shows the project tasks outlined in phases
against a quarterly schedule:

![](media/image5.wmf){width="8.0in" height="1.167361111111111in"}

Table 4.2a -- Ongoing eDeployment Project Tasks

Table 4.2b -- Phase 1: eDeployment Pre-Implementation Tasks

![](media/image6.wmf){width="8.0in" height="3.0055555555555555in"}

Table 4.2c -- Phase 2: eDeployment Early Adopter Implementation

![](media/image7.wmf){width="8.0in" height="5.125694444444444in"}

![](media/image8.wmf){width="8.0in" height="3.7125in"}Table 4.2d --
Phase 3: eDeployment Enterprise-wide Implementation

## Plan for Progress Updates

All members of the eDeployment Implementation Team will be responsible
for providing weekly status reports to document their progress against
the schedule. Progress on all tasks will be monitored, documented on the
overall project schedule, distributed to the team members and
communicated to executive stakeholders.

## Assessing and Managing Schedule Changes

Deviations from the schedule will be assessed on a weekly basis by the
eDeployment Project Management to determine impact on the project. If
there is a delay, management will assess its potential impact and decide
on a process to address and correct the issue.

Once agreed upon, the project schedule at the beginning of the project
will represent the baseline against which progress will be measured.
Weekly updates to the baseline will be made based on the process
discussed in the previous section.

# Costs

## Purpose

The eDeployment initiative requires adequate funding to be successful.
Funding support will ensure that adequate resources and the necessary
subject matter experts are in place to complete this effort. Funds may
come from one of three sources or a combination thereof:

-   USDA will fund the eDeployment initiative;

```{=html}
<!-- -->
```
-   eGovernment initiatives using eDeployment services will reimburse
    the project on a fee-for-service basis; or

-   Managing Agencies will help subsidize the eDeployment initiative.

A summary of costs incurred in implementing this project is included in
the table on the following page; a full description of the assumptions
used to calculate these costs is located in the eDeployment cost benefit
analysis.

Table 5.2 -- Cost Assessment

  -------------------------------- ---------------------------- --------------------- ------------------------
  **[Task                          **[Schedule]{.smallcaps}**                         **[Cost]{.smallcaps}**
  Description]{.smallcaps}**                                                          

                                   **[Start date]{.smallcaps}** **[End                
                                                                Date]{.smallcaps}**   

  Project Initiation/Planning      1/01/03                      9/30/03               \$305,720

  Project Management               1/01/03                      9/30/03               \$2,066,707

  Data Requirements Definition     3/31/03                      9/30/03               \$1,308,259

  Data Design                      3/31/03                      9/30/03               \$2,265,099

  Software Acquisition             3/31/03                      9/30/03               \$13,846,665

  Hardware/Infrastructure          3/31/03                      9/30/03               \$9,904,062
  Acquisition                                                                         

  System Build, Integrate & Test   3/31/03                      9/30/03               \$5,443,629

  Rollout                          3/31/03                      9/30/03               \$75,000

  System Operations                3/31/03                      9/30/03               \$260,550

  Adaptive and Corrective          3/31/03                      9/30/03               \$35,000
  Maintenance                                                                         

  Project Initiation/Planning      10/01/03                     9/30/04               \$252,000

  Project Management               10/01/03                     9/30/04               \$1,894,756

  Data Requirements Definition     10/01/03                     9/30/04               \$3,230,327

  Data Design                      10/01/03                     9/30/04               \$1,696,609

  Software Acquisition             10/01/03                     9/30/04               \$16,044,374

  Hardware/Infrastructure          10/01/03                     9/30/04               \$10,000
  Acquisition                                                                         

  System Build, Integrate & Test   10/01/03                     9/30/04               \$2,807,974

  Rollout                          10/01/03                     9/30/04               \$400,194

  System Operations                10/01/03                     9/30/04               \$260,550

  Adaptive and Corrective          10/01/03                     9/30/04               \$1,091,026
  Maintenance                                                                         

  Project Initiation/Planning      10/01/04                     9/30/05               \$343,300

  Project Management               10/01/04                     9/30/05               \$1,787,936

  Data Requirements Definition     10/01/04                     9/30/05               \$136,000

  Data Design                      10/01/04                     9/30/05               \$285,492

  Software Acquisition             10/01/04                     9/30/05               \$20,335,740
  -------------------------------- ---------------------------- --------------------- ------------------------

  -------------------------------- ---------------------------- --------------------- ------------------------
  **[Task                          **[Schedule]{.smallcaps}**                         **[Cost]{.smallcaps}**
  Description]{.smallcaps}**                                                          

                                   **[Start date]{.smallcaps}** **[End                
                                                                Date]{.smallcaps}**   

  Hardware/Infrastructure          10/01/04                     9/30/05               \$3,731,892
  Acquisition                                                                         

  System Build, Integrate & Test   10/01/04                     9/30/05               \$2,162,552

  Rollout                          10/01/04                     9/30/05               \$2,596,581

  System Operations                10/01/04                     9/30/05               \$288,150

  Adaptive and Corrective          10/01/04                     9/30/05               \$1,091,026
  Maintenance                                                                         

  Project Initiation/Planning      10/01/05                     9/30/06               \$355,100

  Project Management               10/01/05                     9/30/06               \$1,605,656

  Data Requirements Definition     10/01/05                     9/30/06               \$142,000

  Data Design                      10/01/05                     9/30/06               \$215,492

  Software Acquisition             10/01/05                     9/30/06               \$24,703,257

  Hardware/Infrastructure          10/01/05                     9/30/06               \$6,435,272
  Acquisition                                                                         

  System Build, Integrate & Test   10/01/05                     9/30/06               \$1,296,892

  Rollout                          10/01/05                     9/30/06               \$3,371,970

  System Operations                10/01/05                     9/30/06               \$339,900

  Adaptive and Corrective          10/01/05                     9/30/06               \$1,151,026
  Maintenance                                                                         

  Project Initiation/Planning      10/01/06                     9/30/07               \$367,300

  Project Management               10/01/06                     9/30/07               \$1,622,756

  Data Requirements Definition     10/01/06                     9/30/07               \$147,240

  Data Design                      10/01/06                     9/30/07               \$215,492

  Software Acquisition             10/01/06                     9/30/07               \$25,632,344

  Hardware/Infrastructure          10/01/06                     9/30/07               \$40,000
  Acquisition                                                                         

  System Build, Integrate & Test   10/01/06                     9/30/07               \$1,296,892

  Rollout                          10/01/06                     9/30/07               \$3,371,970

  System Operations                10/01/06                     9/30/07               \$339,900

  Adaptive and Corrective          10/01/06                     9/30/07               \$1,091,026
  Maintenance                                                                         
  -------------------------------- ---------------------------- --------------------- ------------------------

# Project Deliverables

## Purpose

A deliverable reflects the documented information and knowledge produced
as a result of executing the project. The major project deliverables,
along with the phase where the deliverable will be completed and the
team who is responsible for producing the deliverable, is listed in the
table below.

Some of the deliverables will be continuously updated throughout the
project lifecycle and many will be delivered for each implementation of
the solution.

## eDeployment Project Deliverables

Table 6.2 -- eDeployment Project Deliverables

  ---------------------------------------------------------------------------------------------------
  **[Deliverable Name]{.smallcaps}**     **[Phase]{.smallcaps}**   **[Responsibility]{.smallcaps}**
  -------------------------------------- ------------------------- ----------------------------------
  Request for Proposal                   Phase 1                   Program Management Office

  Project Plan                           Phase 1                   Project Manager

  Vendor Evaluation                      Phase 1                   Project Manager, Application
                                                                   Design/Development Team

  Vendor Comparison Matrix               Phase 1                   Project Manager, Application
                                                                   Design/Development Team

  Application Interaction Model          Phase 1                   Application Design/Development
                                                                   Team

  Application Process Model              Phase 1                   Business Process/Quality Assurance
                                                                   Team

  Application Architecture               Phase 1                   Application Design/Development
                                                                   Team

  Technology Infrastructure Design       Phase 1                   Technical Architecture Team

  Project Plan                           Phase 2                   Project Manager

  Refined Functional Requirements        Phase 2                   Business Process/Quality Assurance
                                                                   Team

  Business Process Design                Phase 2                   Business Process/Quality Assurance
                                                                   Team

  Business Performance Model             Phase 2                   Change Management/Training Team

  User Interaction Model                 Phase 2                   UI/Web Presence Team

  Application Architecture               Phase 2                   Application Design/Development
                                                                   Team
  ---------------------------------------------------------------------------------------------------

  ----------------------------------------------------------------------------------------------------
  **[Deliverable Name]{.smallcaps}**      **[Phase]{.smallcaps}**   **[Responsibility]{.smallcaps}**
  --------------------------------------- ------------------------- ----------------------------------
  User Interface Design                   Phase 2                   UI/Web Presence Team

  User Interface Standards and Guidelines Phase 2                   UI/Web Presence Team

  Data Model                              Phase 2                   Data/Migration Team

  Data Flow Diagram                       Phase 2                   Data/Migration Team

  Product/Assembly/Component/Acceptance   Phase 2                   Business Process/Quality Assurance
  Test Plan                                                         Team

  Database Design                         Phase 2                   Data/Migration Team

  Usability Test Model                    Phase 2                   UI/Web Presence Team

  Media Content Design                    Phase 2                   UI/Web Presence Team

  Application Training Materials          Phase 2                   Change Management/Training Team

  Product/Assembly/Component/Acceptance   Phase 2                   Business Process/Quality Assurance
  Test Deliverables                                                 Team

  Project Plan                            Phase 3                   Project Manager

  Functional Requirements                 Phase 3                   Business Process/Quality Assurance
                                                                    Team

  Business Performance Model              Phase 3                   Change Management/Training Team

  Business Process Design                 Phase 3                   Business Process/Quality Assurance
                                                                    Team

  User Interaction Model                  Phase 3                   UI/Web Presence Team

  Application Architecture                Phase 3                   Application Design/Development
                                                                    Team

  User Interface Design                   Phase 3                   UI/Web Presence Team

  User Interface Standards and Guidelines Phase 3                   UI/Web Presence Team

  Product/Assembly/Component/Acceptance   Phase 3                   Business Process/Quality Assurance
  Test Plan                                                         Team

  Database Design                         Phase 3                   Data/Migration Team

  Usability Test Model                    Phase 3                   UI/Web Presence Team

  Media Content Design                    Phase 3                   UI/Web Presence Team

  Application Training Materials          Phase 3                   Change Management/Training Team

  Product/Assembly/Component/Acceptance   Phase 3                   Business Process/Quality Assurance
  Test Deliverables                                                 Team

  Data Flow Diagram                       Phase 3                   Data/Migration Team

  Data Conversion Design                  Phase 3                   Data/Migration Team
  ----------------------------------------------------------------------------------------------------

#   {#section-5 .unnumbered}

# Assumptions 

Assumptions made within the Project Plan regard the scope and approach
to be taken for a project. The assumptions should be used to review the
estimate with management and as a basis for understanding when to
re-estimate**.**

Assumptions should continue to be documented throughout the development
of the Project Plan; management will review the assumptions during the
Project Plan approval process. The assumptions apply to all projects,
including those that address the management functions, such as quality
management or configuration management.

Table 7 -- Project Plan Assumptions

+--------+--------------------------------------------------------------+
| **[Num | **[Assumption]{.smallcaps}**                                 |
| ber]{. |                                                              |
| smallc |                                                              |
| aps}** |                                                              |
+--------+--------------------------------------------------------------+
| > 1    | Costs are based on the assumptions in the CBA.               |
+--------+--------------------------------------------------------------+
| > 2    | Skilled resources are available as planned.                  |
+--------+--------------------------------------------------------------+
| > 3    | USDA resources are available to assist with specific project |
|        | tasks as defined by the project manager.                     |
+--------+--------------------------------------------------------------+

# Appendix A -- eGovernment Advisory Teams

This section describes the eGovernment Advisory Teams.

-   **eGovernment Executive Council:** The eGovernment Executive Council
    is an interagency management structure established to lead USDA's
    transformation to a citizen-centric electronic service delivery
    provider in accordance with customer and industry expectations. It
    is also intended to provide guidance delineated in mandates such as
    the Federal Records Act, the Paperwork Reduction Act, the Government
    Performance and Results Act, the Clinger-Cohen Act, Government
    Paperwork Elimination Act, Freedom to E-File Act of 2000, OMB
    Circular A-130, and President Bush's Management Agenda. The Council
    strives to champion the use of eGovernment technologies as an
    enabler for delivering enhanced USDA products and services more
    effectively and efficiently.

> The eGovernment Executive Council is comprised of Senior Executive
> Program Leaders representing each USDA Mission Area. The Council is
> chaired by USDA's eGovernment Executive.

####  {#section-6 .unnumbered}

-   **eGovernment Working Group:** The eGovernment Working Group
    represents individuals who will coordinate activities related to
    eGovernment on behalf of their respective Agencies. The members of
    the eGovernment Working Group are Executive Sponsors, designated by
    an Agency Head, from either the business or information technology
    area of each Agency. The Working Group is chaired by USDA's
    eGovernment Executive.

Members from the eGovernment Working Group will serve as liaisons to
other working groups in USDA such as the Cyber-Security and
Telecommunications Advisory Councils and the USDA Webmasters group as
well as external committees such as those connected to the Federal CIO
Council eGovernment Committee.

-   **eGovernment Steering Committee:** The USDA eGovernment Steering
    Committee will undertake the task of providing organization-wide
    guidance and coordination of Agency activities necessary to
    implement an enterprise-wide eDeployment solution. The eGovernment
    Steering Committee, comprised of subject area leads that represent
    each of the eGovernment strategic and enabling initiatives, will
    make every effort to support interoperability among the USDA
    Agencies as well as among other Federal government Agencies taking
    part in the overall eGovernment initiative.

-   **Agency eGovernment Teams:** Each Agency will form an internal
    Agency eGovernment Team, chaired by the Agency's eGovernment Working
    Group member, to work in conjunction with and support of the broader
    enterprise Working Group and to develop Agency-specific initiatives.
    The Agency eGovernment Teams will be comprised of program or
    business leaders as well as specialists who represent the Web team,
    capital planning and investment control, public affairs, information
    technology, security, privacy, forms management, and records
    management. The Agency Head and associated eGovernment Executive
    Council member will also serve as ex-officio members on the Agency
    eGovernment Teams.

> Agency liaisons to the eGovernment team and Agency business managers
> will be responsible for the following tasks:

-   Ensuring that USDA receives regular reports on the implementation of
    the initiative;

-   Ensuring that Agencies adhere to existing laws, regulations, and
    standards;

-   Ensuring that any requests for additional resources are made
    according to existing rules;

-   Ensuring that requests for cross-Agency services (such as portal
    services or B-to-B extranets with Agency or USDA partners) are
    managed; and

-   Overseeing that all efforts are coordinated internally with Agency
    management, including CIO's and Agency administrators.

# Appendix B -- Description of Deliverables

This section includes explanations of the eDeployment Project Plan
deliverables that are delineated in Table 6.2.

-   **Application Architecture:** The Application Architecture
    represents a set of overall decisions that are documented by mapping
    the functional requirements of the application to its internal
    architecture (i.e., decomposing the application into sub-components
    and specifying the interactions between them) and to a set of design
    standards.

```{=html}
<!-- -->
```
-   **Application Interaction Model:** The Application Interaction Model
    represents the business processes from a user/application point of
    view. It describes a level of workflow analysis that focuses on the
    user\'s business goal. Typically, a series of application
    interactions will define an entire workflow. In other words, all
    user and application tasks in a workflow will be part of an overall
    Application Interaction Model.

```{=html}
<!-- -->
```
-   **Application Process Model:** The Application Process Model,
    created as part of a requirement analysis, describes the conceptual
    data process flows of the future application. It documents the
    application as a hierarchical organization of processes. It is used
    to document the new application\'s data flows on different levels of
    detail and/or different levels of process decomposition, supported
    by elementary process definitions where required. The process
    hierarchy can be optionally supplemented with data flow descriptions
    that document the information that flows between the processes.

```{=html}
<!-- -->
```
-   **Business Performance Model:** The Business Performance Model
    contains the performance targets and indicators for the business
    architecture and for each business capability. The model includes
    the definitions of metrics as well as the methods of measurement,
    presentation, and communication that monitor the performance of each
    business capability during implementation. The Business Performance
    Model is an iterative document that can be updated and refined as
    the delivery effort progresses through planning and analysis, to
    designing, building, deployment, and eventually operation.

```{=html}
<!-- -->
```
-   **Business Process Design:** This deliverable contains all
    supporting information for Business Process Designs including
    workflow diagrams and other related information.

```{=html}
<!-- -->
```
-   **Cost and Benefit Analysis of Vendor Finalists:** This deliverable
    contains a comparison of the costs and benefits associated with all
    of the vendor finalists. It is created after collecting vendor
    information regarding capabilities and contract terms. The document
    is used as input for selecting one vendor finalist. It ensures that
    important costs and benefits, both economical and intangible, are
    considered in the finalist decision.

```{=html}
<!-- -->
```
-   **Current Business Capability Assessment:** This document is a
    detailed analysis of the existing capability in terms of human
    performance, business processes, physical environment, application,
    and technology infrastructure. The objective of the analysis is to
    establish a detailed understanding of not only the boundaries,
    operational implications, and rationale behind the current
    capability, but also the stimuli for change. This type of analysis
    is applicable when specific requirements and the impact of the
    proposed changes need to be defined before detailed design begins.

-   **Data Conversion Design:** This deliverable defines the issues and
    resolutions involved in converting the data from the current
    application (if applicable) to the new application. It is useful for
    documenting the requirements, manual and automatic procedures, and
    programs needed to extract data from the current application(s),
    cleanse it, and load it into the new application.

-   **Data Flow Diagram:** The Data Flow Diagram is a common, convenient
    way to represent an information processing application as a series
    of data flows between application processes and entities. It
    graphically represents processes as transformations of inputs into
    outputs by showing a series of application processes connected by
    the required data flows.

-   **Data Model:** The Data Model is a description of the data
    requirements for the future application that is utilized during the
    requirements analysis process. This document is critical for query
    and reporting applications, as well as tracking modifications to the
    data requirements over the course of the application\'s life cycle.

-   **Database Design:** This deliverable addresses the logical view
    (programmers and users) and the physical view (database
    administrators) of the database. It models the logical and physical
    aspects of the future database prior to its construction.

-   **Functional Requirements:** Functional Requirements detail what the
    application must do to satisfy the business needs of the customers
    and stakeholders, including details such as categorization,
    importance, and clear descriptions. Functional requirements do not
    include specific technical details related to implementation that
    are determined through the design process.

-   **Media Content Design:** This deliverable contains a detailed
    description of the media content. The Media Content Conversion
    Procedures, as well as the Media Content Standards and Guidelines,
    are also documented within the Media Content Design deliverable.
    Ultimately, the Media Content Design will serve as the basis for the
    work to be done by the media content developers.

-   **Vendor Evaluation:** A Vendor Evaluation documents the software
    selection process and its resulting decisions, including any
    recommendations for installation and contract negotiations. This
    deliverable addresses vendor performance, software references,
    costs, benefits, risks, and the strategy for vendor contract
    negotiations.

> **Project Plan:** The Project Plan is a detailed schedule that
> documents the baselines mutually agreed to by the program and project
> managers. It is an inherently flexible document that can accommodate
> any modifications to the schedule as the project progresses. It
> consists of all project-planning documents needed to effectively
> perform and control project activity, such as the Project Schedule and
> Milestones, the Project Work Plan, the Project Resource Plan, etc.

-   **Request for Proposal:** This deliverable prepares a request to
    submit a quote or proposal for providing goods or services to a
    candidate supplier. The request describes the item(s) being procured
    and all associated requirements (e.g., quantities, delivery dates,
    packaging and shipping instructions, warranties, etc.). Quotes are
    typically requested for procurement of goods, while proposals are
    requested for procurement of services, or a combination of goods and
    services.

-   **Product/Assembly/Component/Acceptance Test Plan:** The
    Product/Assembly/Component/Acceptance Test Plan is developed
    concurrently with the specification it is testing. It accurately and
    completely documents the test\'s conditions and expected results.
    The test plan also contains the list of test cycles: logical groups
    of test conditions that facilitate the preparation and execution of
    the test model.

-   **Product/Assembly/Component/Acceptance Test Deliverables:** The
    Product/Assembly/Component/Acceptance Test deliverables define the
    steps, input data, and expected output for a number of test
    conditions. These deliverables provide detailed instructions to the
    test executor in a clear, unambiguous, and repeatable manner.

-   **Technology Infrastructure Design:** This deliverable consolidates
    the designs for the development, execution, and operations
    architectures as well as physical network and computing.

-   **Training Materials:** This deliverable outlines the plan for the
    eDeployment training program. Guidelines for using the eDeployment
    solution will be documented for the workforce transition to the new
    capability. Training materials could include instructor-led
    training, self-study training, and/or computer-based training. If
    possible, eDeployment will leverage the eLearning solution.

-   **Usability Test Model:** This deliverable is a composite
    deliverable that contains the test plan, test scripts, and evaluator
    profiles for a particular usability test.

-   **User Interaction Model:** This deliverable describes how the users
    will interact with the future application and how the application
    will be integrated into their work. This deliverable is used to
    support decisions on how the users will interact with the
    application by designing the high-level user interface and primary
    methods for interaction.

-   **User Interface Design:** This deliverable outlines the procedures
    and guidelines for the application user interface. User interface
    design also includes planning the usability evaluations and
    determining the number of design iterations needed. This deliverable
    is developed before finalizing the work plan for human-computer
    interaction-oriented tasks. This aids the project planner in
    allocating resources in a way that can maximize the usability of the
    system.

-   **User Interface Standards and Guidelines:** This deliverable is
    used to document the user interface standards that must be followed,
    and the less strict user interface guidelines. The guidelines are
    general design principles that should be followed by user
    interaction designers, based on the user population and their tasks.
    Their main purpose is to provide an appropriate level of user
    interface consistency throughout the application. Develop initial
    user interface standards and guidelines early in the project, but be
    careful to provide a process for updating them as the project learns
    more about the business representatives and the tasks they perform.

-   **Vendor Comparison Matrix:** This deliverable compares how each
    vendor scores on each of the requirements groupings. This
    deliverable can be used to summarize and compare the vendors\'
    responses to screening criteria and to select two to three
    finalists. Refer to it again when selecting one vendor finalist and
    while negotiating contract terms.

[^1]: eGovernment Advisory Teams are as follows: eGovernment Executive
    Council, eGovernment Working Group, eGovernment Steering Team, and
    Agency eGovernment Teams. A detailed explanation of these teams and
    their functions can be found in [Appendix
    A](#appendix-a-egovernment-advisory-teams) of this document.

[^2]: USDA's strategic Smart Choice initiatives are: eLoans, eGrants,
    Online Trade Assistance, Food Safety and Security, and Supply Chain
    Management.