# *CONCEPT PHASE*

# 3.1 Introduction

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

## 3.1.1 Purpose

The Concept Phase will determine whether an acceptable and
cost-effective approach can be found to address the business need with
high confidence that technology can support that approach. The purposes
of this phase are to:

a.  Establish system boundaries, identify goals, objectives, critical
    success factors, and performance measures,

b.  Evaluate costs and benefits of alternative approaches to satisfy the
    basic functional requirements,

c.  Assess project, technical, and business risks,

d.  Identify and initiate risk mitigation actions,

e.  Identify system interfaces,

f.  Identify basic high level requirements to satisfy the business need,

g.  Develop high level architecture, process models, data models, and a
    Concept of Operations[^1], and

h.  Identify high level electronic records management requirements.

For all AIS projects designated as mission critical, the Program Sponsor
must approve high level requirements defined in the Requirements
Specification[^2] validating that the high level requirements provided
therein are complete before a High Level Requirements Review can be
conducted. This phase is completed upon approval of the high level
requirements by the Technical Review Board at the High Level
Requirements Review, and when the Program Sponsor and the CIO agree to
the system boundary.

## 3.1.2 Overview

Following approval of the Business Case, the Concept Phase begins when
the Project Manager appoints the project team[^3] and the CIO appoints a
System Development Manager. The Program Sponsor, with the assistance of
the Project Manager and the System Development Manager, evaluates
realistic approaches that address the Business Case and determines which
approach will be implemented. This may involve making several trade-off
decisions such as the decision to use COTS software products as opposed
to developing custom software or reusing software components, or the
decision to use an incremental delivery versus a complete, one-time
deployment.

Unnecessary and significant costs will be incurred if too much or too
little effort is expended in planning, documenting, or reviewing an AIS
project. A key decision that must be made during the Concept Phase is
determining the appropriate level of effort for these activities given
the scope, complexity and importance of the AIS under consideration.
Project Managers and System Development Managers must develop the
project tailoring and the System Development Manager coordinates with
the Office of System Product Assurance during this phase to tailor their
life cycle processes to the specific needs of their AIS project. These
tailoring decisions will be reflected in the Concept Brief, the Project
Management Plan, and in the Quality Assurance Plan. The AIS Life Cycle
Process Tailoring TSG, IT-212.2-03, provides guidance for LCM tailoring.
The Project Manager must ensure that the Project Management, Quality
Assurance, Data Management, Operational Support, Test Plans, and the
Detailed Design all reflect appropriate levels of security operations
and administration.

Depending upon AIS size, scope, complexity, and risk, there may be as
many as ten plans and documents initiated during the Concept Phase. Of
these, only eight, the System Boundary Agreement (containing the
statement of requirements), the Project Management Plan, the
Configuration Management Plan, Data Management Plan, the Quality
Assurance Plan, the High Level Architecture, Requirements Specification,
and the Concept of Operations are absolutely required for all AIS
development projects. These are the only Concept Phase documents that
must be completed or have a baseline established before the beginning of
the Detailed Analysis and Design Phase. An Economic Analysis is required
for all AIS projects that are designated as mission critical. A Security
Plan is required if the system processes sensitive data. The Program
Sponsor, in signing the Requirements Specification, Part 1 validates
that the high level business requirements are complete. In approving the
Requirements Specification, Part 1, the Technical Review Board, with the
assistance of the Office of System Product Assurance, verifies that the
high level business requirements provided in the Requirements
Specification, Part 1 are clearly expressed.

The Project Manager, the System Development Manager, and the System
Architect should work together during this phase to estimate the extent
to which COTS products will be used in meeting functional requirements.
If significant use of COTS programming features is anticipated, then the
System Development Manager must ensure that appropriate design,
operation, testing, and maintenance documentation to adequately support
the development of this code is provided for in the Project Management
Plan. The System Development Manager will ensure that requirements,
design, development, operation, and testing reviews necessary to
adequately support the development of this code are conducted. The
Office of System Product Assurance will ensure that these reviews and
documents are specified in the Concept Brief and the Quality Assurance
Plan.

During the Concept Phase, the Project Manager and the System Development
Manager should also initiate discussions with the Office of Acquisition
Management to plan for acquisition and contractor support to the AIS
project.

## 3.1.3 Tasks

The primary tasks performed during the Concept Phase are as follows:

a.  Update the business case,

b.  Establish the system boundary,

c.  Begin project planning and develop the Project Management Plan,

d.  Develop the Concept of Operations,

e.  Determine functional requirements and informational needs,

f.  Develop the Requirements Specification, Part 1,

g.  Develop the Quality Assurance Plan,

h.  Develop the Configuration Management Plan,

i.  Investigate alternative business processes and procedures,

j.  Consider data management,

k.  Identify electronic records management requirements,

l.  Perform an economic analysis of alternatives,

m.  Select the most cost-effective alternative,

n.  Identify, estimate and allocate resources to support project plans
    and major activities,

o.  Determine the level of contractor support needed for each major
    project activity,

p.  Analyze project risk and initiate risk mitigation activities,

q.  Define the High Level Architecture[^4], and

r.  Plan acquisition needs.

Many of these tasks can be performed more effectively with the aid of
prototyping. Construction of executable prototypes is encouraged to
confirm requirements, manage risks, or to evaluate technology needed to
support the business process. Prototypes must conform to the USPTO
Technical Reference Model.

## 3.1.4 Activities and Documentation

Concept Phase activities and documentation requirements as summarized in
the following table must conform to the indicated Technical Standard and
Guidelines or other standards as noted. The Technical Review Board
establishes the System Boundary Baseline during this phase. Section 3.3
of this document and the Configuration Management TSG, IT-212.2-06,
provide additional information about the System Boundary. Published
standards and guidelines may be augmented with Tailoring Agreements.

+-------------------+--------+---------+----+----+-----+-----+------+
| Work Product      | TSG    | Who's   | Mu | M  | Sho | M   | Must |
|                   |        |         | st | ay | uld | ust |      |
|                   | /      | Resp    |    |    |     |     | Comp |
|                   | St     | onsible | Cr | Cr | Upd | Upd | lete |
|                   | andard |         | ea | ea | ate | ate |      |
|                   |        |         | te | te |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| Business Case     |        | ###     |    |    |     | X   |      |
|                   |        | Program |    |    |     |     |      |
|                   |        |         |    |    |     |     |      |
|                   |        | S       |    |    |     |     |      |
|                   |        | ponsor, |    |    |     |     |      |
|                   |        |         |    |    |     |     |      |
|                   |        | Project |    |    |     |     |      |
|                   |        | Manager |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| Project           | IT-21  | Project | X  |    |     |     |      |
| Management Plan   | 2.2-01 |         |    |    |     |     |      |
|                   |        | M       |    |    |     |     |      |
|                   |        | anager, |    |    |     |     |      |
|                   |        |         |    |    |     |     |      |
|                   |        | SDM     |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| AIS Project       | IT-21  | Office  | X  |    |     |     | X    |
| Quality Assurance | 2.2-04 | of      |    |    |     |     |      |
| Plan              |        | System  |    |    |     |     |      |
|                   |        | Product |    |    |     |     |      |
|                   |        | As      |    |    |     |     |      |
|                   |        | surance |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| Data Management   | IT-21  | Office  |    | X  |     |     |      |
| Plan              | 2.2-05 | of      |    |    |     |     |      |
|                   |        |         |    |    |     |     |      |
|                   |        | Data    |    |    |     |     |      |
|                   |        | Man     |    |    |     |     |      |
|                   |        | agement |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| AIS Configuration | IT-21  | Office  | X  |    |     |     |      |
| Management Plan   | 2.2-06 | of      |    |    |     |     |      |
|                   |        | System  |    |    |     |     |      |
|                   |        | Product |    |    |     |     |      |
|                   |        | As      |    |    |     |     |      |
|                   |        | surance |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| System Boundary   | IT-21  | Project | X  |    |     |     |      |
| Agreement         | 2.2-10 | M       |    |    |     |     |      |
|                   |        | anager, |    |    |     |     |      |
|                   |        |         |    |    |     |     |      |
|                   |        | System  |    |    |     |     |      |
|                   |        | Deve    |    |    |     |     |      |
|                   |        | lopment |    |    |     |     |      |
|                   |        | Manager |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| Requirements      |        | ##      | X  |    |     |     |      |
| Specification,    |        | # Syste |    |    |     |     |      |
| Part 1            |        | m Devel |    |    |     |     |      |
|                   |        | opment  |    |    |     |     |      |
|                   |        | Manager |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| Concept of        | IT-21  | ###     | X  |    |     |     |      |
| Operations        | 2.2-11 | Program |    |    |     |     |      |
|                   |        |         |    |    |     |     |      |
|                   |        | S       |    |    |     |     |      |
|                   |        | ponsor, |    |    |     |     |      |
|                   |        |         |    |    |     |     |      |
|                   |        | Project |    |    |     |     |      |
|                   |        | Manager |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| High Level        | IT-21  | Office  | X  |    |     |     | X    |
| Architecture      | 2.2-12 | of      |    |    |     |     |      |
|                   |        |         |    |    |     |     |      |
|                   |        | System  |    |    |     |     |      |
|                   |        | Archi   |    |    |     |     |      |
|                   |        | tecture |    |    |     |     |      |
|                   |        | &       |    |    |     |     |      |
|                   |        |         |    |    |     |     |      |
|                   |        | Engi    |    |    |     |     |      |
|                   |        | neering |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| Economic          | IT-21  | Project | X^ |    |     |     | X^1^ |
| Analysis^1^       | 2.2-13 | M       | 1^ |    |     |     |      |
|                   |        | anager, |    |    |     |     |      |
|                   |        | System  |    |    |     |     |      |
|                   |        | Deve    |    |    |     |     |      |
|                   |        | lopment |    |    |     |     |      |
|                   |        | Manager |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| AIS Security Plan | IT-21  | Project | X  |    |     |     |      |
|                   | 2.2-08 | M       |    |    |     |     |      |
| (If sensitive     |        | anager, |    |    |     |     |      |
| data)             |        |         |    |    |     |     |      |
|                   |        | System  |    |    |     |     |      |
|                   |        | Deve    |    |    |     |     |      |
|                   |        | lopment |    |    |     |     |      |
|                   |        |         |    |    |     |     |      |
|                   |        | Manager |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+
| **NOTE 1:**       |        |         |    |    |     |     |      |
| Required for AIS  |        |         |    |    |     |     |      |
| Projects          |        |         |    |    |     |     |      |
| designated as     |        |         |    |    |     |     |      |
| mission critical  |        |         |    |    |     |     |      |
| or whose life     |        |         |    |    |     |     |      |
| cycle costs are   |        |         |    |    |     |     |      |
| greater than \$25 |        |         |    |    |     |     |      |
| million.          |        |         |    |    |     |     |      |
+-------------------+--------+---------+----+----+-----+-----+------+

**Table 3.1.4 Concept Phase Activities and Documentation Requirements**

# 3.2 Technical Management

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

Appointed by the CIO, the System Development Manager is responsible for
designing, developing, and deploying an AIS. The System Development
Manager ensures that the AIS is consistent with the agency\'s strategic
information technology plans and is managed according to sound life
cycle management principles and practices. The Project Management
Technical Standard and Guideline, IT-212.02-01, describes the
responsibilities of the System Development Manager in more detail. In
addition, the System Development Manager must:

a.  Support the Project Manager,

b.  Coordinate with the Office of System Product Assurance to develop a
    Quality Assurance Plan,

c.  Ensure that technical resources are allocated within the constraints
    of the approved AIS development budget,

d.  Develop detailed technical plans and schedules, and

e.  Ensure technical performance and adherence to schedule.

Additional information regarding the roles and responsibilities of the
System Development Manager is provided in the paragraph 1.9.5 of this
Manual and in the Project Management Technical Standard and Guideline,
IT-212.2-01.

# 3.3 System Boundary

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

The system boundary established the context through which the AIS
project addresses the requirements expressed in Business Case or
equivalent document. In this sense the development of the system
boundary should be considered as a thought process involving several key
project management activities and decisions that are usually
interdependent and therefore are typically performed concurrently. These
activities include:

a.  Performing strategic planning,

b.  Documenting high level requirements,

c.  Determining feasibility,

d.  Allocating project resources, establishing a high level project
    schedule, and

e.  Stating assumptions about, and constraints imposed on the project by
    factors outside the Program Sponsor\'s or Chief Information
    Officer's control.

Depending upon project needs and tailoring agreements, system boundary
decisions may be recorded in one or several documents. When all of these
activities are treated in a single document, that document is referred
to as the "System Boundary Agreement." When these topics are treated
individually, the system boundary may be expressed in the Project
Management Plan, the Requirements Specification, Part 1, and the Concept
of Operations document. Regardless of the approach taken, the System
Boundary is developed by the Project Manager, with the assistance of the
System Development Manager, and is a signed agreement between the
Program Sponsor and the CIO affirming a mutual and sufficiently detailed
understanding of project requirements, cost, and schedule. Additional
instructions for developing a System Boundary Agreement are provided in
the System Boundary Technical Standard and Guideline, IT-212.2-10.

# 3.4 Project Planning

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

## 3.4.1 Developing the Project Management Plan

The Project Management Plan serves as a management tool to direct and
monitor the progress of system definition, design, development and
deployment. The Project Manager, with the assistance of the System
Development Manager and the Director, Office of Technical Plans and
Policy[^5] prepares the Project Management Plan at the beginning of the
Concept Phase and revises this plan as necessary, throughout this phase
and throughout the life of the project. The Project Management Plan is
approved by, and periodically reviewed by both the Program Sponsor and
the CIO. The Project Management Plan is also inspected by the Technical
Review Board as part of a technical review to ensure that it accurately
reflects technical, cost and schedule performance. A sample Project
Management Plan is provided in the Project Management Technical Standard
and Guideline, IT-212.2-01. Contractors may prepare components of the
Project Management Plan, but are prohibited from determining
requirements, and from assigning roles, responsibilities, or authority.

## 3.4.2 Developing the Concept of Operations

The Concept of Operations provides organization and business process
information. The Concept of Operations provides a high level description
of how an organization currently performs its work, how it will perform
its work in the future, what people and organizational changes will be
required, and what risks are associated with the new or modified AIS.
This document also provides a text-based description of business
processes within the system boundary and establishes a transition
process through which common definitions regarding the current and
future business process are documented and managed.

The Project Manager is responsible for developing the Concept of
Operations and may be supported by a team of business area experts, as
well as experts from other areas such as Human Resources or Facilities.
This team defines, develops and documents the current and future
business process using textual descriptions, and activity models,
process maps, or other tools as appropriate. The Program Sponsor
approves the Concept of Operations and ensures that the necessary
business policies, procedures, and resources are provided to the process
improvement effort in an adequate and timely manner. Refer to the
Concept of Operations Technical Standard and Guidelines, IT-212.2-11,
for additional details on preparing a concept of operations.

## 3.4.3 Developing High Level Requirements

High level requirements are contained in the System Boundary Agreement
and the Requirements Specification, Part 1. These requirements are based
upon opportunities identified in the Business Case or equivalent
document and represent a preliminary translation of business
requirements into logical data and logical process models. These logical
models represent only the essential concepts needed to address a
business need and, by intention, do not address technical performance or
physical design considerations. The purpose of this translation is to
ensure that the project team has a clear understanding of the over-all
business requirement that will be implemented before embarking upon
detailed analysis and technical design.

High level requirements are expressed as high level entity relationship
data models, high level business function decomposition diagrams, high
level business process models, business rules and procedures, and other
enterprise information. These requirements are deduced from documents
such as the System Boundary or the Concept of Operations, and through
focus sessions with business area experts.

In many situations it will be advantageous to use automated tools to
develop, record, and manage high level requirements. There are a variety
of tools available to assist in performing this function, ranging from
simple word processors, spreadsheets, and desktop database tools to
sophisticated integrated information engineering, and requirements
management packages, such as the Requirements Traceability Tool. In
selecting the most appropriate tools to perform this task, the System
Development Manager should consider the scale, target environment,
available resources, available skills, schedule constraints, system
integration requirements, AIS implementation tools and consistency with
the Technical Reference Model.

The standard OCIO requirements management tool must be used whenever
practical. The Office of System Product Assurance will provide technical
support to the project in the use of this tool. When it is not practical
for the AIS project to use the OCIO standard tool, the Office of System
Product Assurance will copy project requirements into the standard
requirements management tool.

The following items must be reflected both in the system boundary, the
requirements specification, and in the subsequent designs that are
derived from these requirements:

a.  The purpose of the system including goals, objectives, and critical
    success factors,

b.  Performance measures that are meaningful to the Program Sponsor and
    end user,

c.  Functional needs, as perceived by the user from the business area(s)
    supported, captured as requirements by business area experts (these
    requirements are used as the basis for determining feasible
    alternatives),

d.  Assumptions and constraints concerning the business environment
    within which the system will operate, including legal, security,
    facility, and labor or work-flow considerations,

e.  Assumptions and constraints concerning the technology that may be
    used, such as conclusions from technology impact analysis, user
    interfaces, use of the information technology infrastructure, and
    waivers, and

f.  Assumptions and constraints concerning execution of the project,
    including the budget, schedule, project facilities, acquisition
    considerations, completion criteria, and the system development
    process.

High level requirements initially appear in the System Boundary
Agreement and are more fully represented in the Requirements
Specification, Part 1. Guidance for documenting high level requirements
is provided in several Technical Standards and Guidelines including the:

a.  System Boundary , IT-212.2-10,

b.  Requirements Management, IT-212.3-11, and

c.  AIS Life Cycle Process Tailoring, IT-212.2-03.

## 3.4.4 Developing the Quality Assurance Plan

The purpose of quality assurance planning is to ensure that project
activities are visible and appropriately supported, and that project
plans and work products, including information engineering models and
diagrams, contribute to the delivery of an AIS product that is fit for
use and meets customer expectations. The Quality Assurance Plan is
initially developed, approved and implemented during the Concept Phase
to support this objective. This plan identifies the standards and
polices that will apply, identifies the specific work products to be
delivered, and establishes the type and schedule of reviews to be
conducted in developing or enhancing an AIS.

The Quality Assurance Plan is developed based on the Concept Brief,
System Boundary, and the Project Management Plan. These documents
determine project size and scope and allocate project resources
including support for quality assurance activities. These documents also
serve as the basis for tailoring decisions and agreements that are
recorded in the Concept Brief and Quality Assurance Plan. These
decisions and agreements are intended to establish and document, at an
appropriate level of detail, project management, design, development,
testing, and support activities. Analysts within the Office of System
Product Assurance will assist the System Development Manager by
preparing the Quality Assurance Plan. The Project Manager addresses
specific quality assurance issues relating to the customer workforce.
These issues are outside the scope of the Quality Assurance Plan. The
Quality Assurance Plan is prepared by the Office of System Product
Assurance, reviewed by the System Development Manager, and is approved
by the Technical Review Board as part of the High Level Requirements
Review. This plan is updated and reviewed at each phase of the life
cycle. Additional guidance on tailoring is provided in the AIS Life
Cycle Process Tailoring Technical Standard and Guidelines, IT-212.2-03.
Additional guidance on quality assurance planning is provided in the
Quality Assurance Technical Standard and Guideline, IT-212.2-04.

**3.4.5 Developing Electronic Records Management Requirements**

It is appropriate at this stage for the system development manager and
appropriate business users to begin assessing high level requirements in
13 electronic records management areas. Not all areas of consideration
apply to all AISs. When this is the case, the particular Electronic
Records Management (ERM) requirement area should be noted as not
applicable to those AISs.

a.  *Records Acquisition*, which includes capture of complete electronic
    records, links to notes and annotations, hyperlinks, and working
    files, conversion of paper records to electronic form, quality
    control, quality assurance, and audits of the document capture
    process.

b.  *Record Metadata*, which addresses metadata management and record
    profile metadata.

c.  *File Management*, which covers physical and referential integrity
    protection.

d.  *Preserve Integrity*, which addresses protection against alteration
    and validating integrity.

e.  *Protect Confidentiality*, to ensure that information is not
    disclosed or revealed to unauthorized persons.

f.  *Access Controls and Authentication*, which covers identification
    and validation of identity.

g.  *Search, Retrieval and Reproduction*, which covers such issues as
    search and retrieval, storing search results, displaying and
    printing records with indices and annotations, and access
    privileges.

h.  *Audit Trail*, to address use history profiles, their creation and
    update, and links to other information system tracking or event
    logging systems.

i.  *Vital Records Backup and Recovery,* to cover policies and
    procedures for disaster recovery.

j.  *Records Retention*, which covers retention content, periods,
    schedules, and disposal procedure.

k.  *Migration*, to address the accessibility and transferability of
    electronic records despite changes in information technology and
    including copy, reformat, and transfer procedures as well as media
    management.

l.  *Transfer to Permanent Archival Storage*, which describe policy and
    procedure for long-term retention.

m.  *Records Hold*, which covers steps for holding records when
    litigation, audit or investigation is foreseen.

More detail describing these electronic records management requirement
areas can be found in the technical note, "Electronic Records
Management: Checklist for Automated Information Systems."

# 3.5 Defining the High Level Architecture \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

## 3.5.1 The System Architect's Role

The Office of System Architecture and Engineering (OSAE) defines and
evolves the USPTO-wide information technology infrastructure
architecture, ensuring the proper development of that infrastructure
while continuing to implement necessary upgrades and integrate
applicable new technology. OSAE evaluates and incorporates emerging
technologies, standards, and products into the infrastructure Technical
Reference Model and develops and/or reviews and approves technical
architectural designs for automated information systems. Principal focus
areas include controlling the migration to an open systems environment,
implementing adequate security measures, upgrading the performance and
reliability of infrastructure components, establishing information
technology standards, leveraging internet technologies to support USPTO
business functions, and establishing remote access capabilities.
Additional information regarding the role of the system architect, AIS
high level architecture, and detailed design can be found in the High
Level Architecture TSG (IT-212.2-12).

## 3.5.2 Evaluating Commercial Off-the-Shelf Software

"COTS" or "off-the-shelf" software, if used effectively, can
significantly reduce AIS delivery time and development costs. System
Development Managers should use COTS software whenever feasible. In
determining feasibility, AIS managers must make several difficult
trade-off decisions in selecting and using a COTS approach. These
decisions will have significant, long-term impact on the cost for
developing and operating the AIS. The Project Manager, the System
Development Manager, and the Systems Architect must carefully consider
the benefits and disadvantages of using COTS software products when
preparing an economic analysis or designing a high level architecture.

The benefits and costs associated with using COTS software must be
identified in terms of several key characteristics including uses,
packaging, and acquisition agreements. This will allow managers to
better understand the costs associated with acquiring a COTS solution,
and will also assist in determining the costs of activities associated
with the integration, maintenance, and operational support of COTS
products.

There are at least five major ways COTS can be characterized according
to use:

a.  Office automation systems (e.g., word processing, spread sheets,
    presentation tools, electronic mail).

b.  Application systems (e.g., human resources, financial management,
    payroll, project management).

c.  AIS production support packages (e.g., data base management systems,
    document management systems, report generators, search tools, work
    flow).

d.  System and network management (e.g., operating systems, help desk
    tools, software distribution tools, system performance monitors,
    security tools, network monitors).

e.  System analysis, design, and development and maintenance tools
    (e.g., I-CASE tools, compilers, test tools, configuration
    management, requirements management, and data modeling).

There are at least three ways COTS can be classified in terms of
packaging:

a.  Highly specialized software modules (e.g., image viewers, bar code
    printing drivers),

b.  Groups of interrelated software functions that the manufacturer
    integrates into software environments (e.g., windows, desk-tops),
    and

c.  Turnkey products (e.g., high speed image capture scanners and
    software, point of sales registers and software).

It is also important to consider the terms and costs for COTS
acquisition such as:

a.  Types of support service vendor provides (e.g., training, special
    modifications, consulting, remote diagnostics),

b.  Pricing structure (e.g., site licensing, upgrade pricing, support
    costs, volume discounts),

c.  Composition (e.g., incremental acquisition of functional components,
    bundling/unbundling of options), and

d.  Product format (e.g., source code, executable code, or network
    service provider).

## 3.5.3 Benefits of Using COTS Software

A major advantage of COTS software products is that these products come
already developed and tested. Frequently, a large number of commercial
customers are able to use and evaluate specific COTS products in an
operational environment, and based upon their experiences, provide
constructive comments to the manufacturer. As a result, COTS products
come with many practical, user-driven, enhancements included. This
translates into an immediate gain in functionality, usability, and
reliability. Also, because a large number of commercial users share in
the total costs to develop, market, distribute, and support COTS
products, vendors are able to keep unit costs to a level that is
affordable to the individual customer.

## 3.5.4 Disadvantages of Using COTS Software

No COTS solution provides all, or the exact business functionality that
the user needs. A comprehensive solution to a business area requirement
may require that integrated COTS approaches be supplemented with
in-house software. Generally, COTS products are difficult to modify
internally. When the only alternative is to modify a COTS product, it is
usually at significant risk to the vendor and, as a result, great cost
to the customer. The System Development Manager must be aware of the
costs, time, and level of effort necessary to select and integrate COTS
software into the overall AIS. Due to issues relating to the cost of
flexibility, compatibility, functionality, or control over source code,
the System Development Manager may determine that the most economically
feasible way to address a requirement is through in-house development.

## 3.5.5 Selecting an Approach

The System Development Manager must be aware of several key factors when
deciding whether to develop software in-house or whether to purchase and
integrate a COTS product.

a.  Business Focus and Potential for Reuse \-- if there is a reasonable
    chance that the needed AIS functionality is reusable on several
    other applications then it may become very practical to develop this
    functionality in-house. Reuse provides almost all the benefits
    expected of COTS products such as labor and development cost
    savings, and rapid implementation, plus many of the benefits
    expected from software developed in-house including flexibility and
    controllability. The System Development Manager must ensure that all
    reusable components, including requirements, specifications, and
    designs are placed in a CM repository for reuse.

b.  Compatibility with the Technical Reference Model \-- if the only
    COTS products needed and currently available are incompatible with
    the Technical Reference Model, then the System Development Manager
    should consider developing an in-house approach that is compatible
    with the Technical Reference Model.

c.  Cost of Integration and Maintenance \-- Integration costs may be
    higher for COTS products, while maintenance cost will be higher for
    in-house development. However, both in-house developed functionality
    and COTS provided functionality will have full life cycle costs.
    Poor performance by the manufacturer in designing, developing,
    testing, and supporting COTS products will result in higher costs to
    the AIS development organization.

d.  Reputation, Market Share, and Quality of Manufacturer Services \--
    System Development Managers must consider the long term viability of
    COTS software. Software firms that stand behind their products, look
    to establishing a long term presence in their markets, and look to
    increasing market share will provide COTS products to their
    customers that are less costly to operate, enhance, and maintain.
    This does not mean that there will not be problems from time to
    time. It just means that software firms that do not live up to
    customer expectations will eventually suffer loss of credibility in
    the market. This in turn provides some indication of the long-term
    costs the AIS project will incur for COTS maintenance, enhancement,
    integration, and support.

**3.6 Assessing the Information Technology Investment**

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

When the USPTO spends money on information technology, it is an
investment in improving the quality and value of the agency's business
performance. Senior management must assess the business worth of an AIS
project in terms of the changing needs of the business, and in terms of
advances or changes in technology or services. Moreover, each AIS
project must be evaluated in the context of the portfolio of all AIS
projects during the strategic information technology planning process to
ensure that there is a strong business case for developing and deploying
the new capability.

When making an information technology investment, the Program Sponsor
and CIO must be in agreement that project expectations are realistic and
achievable. This agreement, documented as part of the system boundary,
must be revisited and reaffirmed several times throughout the life of an
AIS project. If there are any significant changes in business
requirements, project resources, or project schedule, the system
boundary and supporting economic analysis must be revised.

To help determine whether the AIS project is a worthy investment and to
identify the preferred approach, the Project Manager, with the
assistance of the System Development Manager, identifies and evaluates
various alternative approaches. This systematic process, called an
economic analysis, compares the costs and benefits of alternatives that
are potentially feasible. An economic analysis must be prepared for each
AIS project designated as mission critical. There must be at least two
feasible alternatives considered in the economic analysis - the current
system and the proposed system(s). The Economic Analysis Technical
Standard and Guideline, IT-212.2-13, provides guidance for preparing an
economic analysis.

# 3.7 Project Risk Management

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

The Project Manager must continually identify AIS project risks and
identify ways to reduce these risks to acceptable levels. During the
Concept Phase these risks are primarily concerned with establishing a
realistic commitment to addressing AIS project requirements and
obtaining the resources necessary to achieve project goals. The Project
Manager will advise the Program Sponsor, the CIO, and the Systems
Development Manager on matters of significant risk and will coordinate
risk management activities with key managers and analysts based upon
their ability to control risk.

## 3.7.1 Project Risk Assessment

Continual analysis[^6] of the existing project situation will be
conducted to identify significant AIS project risks. Primary
consideration will be given to identifying business and project risks,
including major uncertainties in specifying or satisfying system
boundaries (i.e., requirements, costs, and schedule). Some of the most
common business and project risks encountered in the Concept Phase are
associated with:

a.  Replacement of key managers or loss of sponsorship,

b.  Loss of funding,

c.  Change in mission,

d.  Reorganization, and

e.  Unclear leadership structure and back-up process for key personnel.

The Project Manager and the System Development Manager will identify all
significant business and project risks to the best of their ability.
These managers will estimate and evaluate significant business and
project risks, and will provide some brief discussion of pragmatic
approaches they might take should any of these risks materialize into a
situation that could adversely impact the project. There are three major
sources of project risk that the Project Manager must consider:

a.  Availability of detailed and complete project information,

b.  Sufficient project time and project resources, and

c.  Sufficient project control.

> The intent of this guideline is to establish a level of project risk
> assessment, planning, and management that is appropriate to the nature
> of the work that is expected to be performed using the AIS. Excessive,
> duplicative, or unnecessary risk management should be avoided. Project
> Managers and System Development Managers are encouraged to reuse or
> adopt already existing risk management practices, policies,
> procedures, and mechanisms whenever practical. It is vitally important
> that the Project Manager is fully aware of business and project risks
> in terms of actual damage, cost of prevention, and cost of corrective
> measures. Information used to identify, estimate, and evaluate
> significant risks will be documented.

## 3.7.2 Project Risk Review and Mitigation

The Project Manager presents project risk assessment findings to the
Program Sponsor, Technical Review Board, or the CIO, as needed during
the course of the AIS project.

Risk considerations will be part of normal business and will reaffirm
the significance of risks. To illustrate, risks associated with the High
Level Architecture should be identified and presented during the High
Level Requirements Review. The Project Manager should solicit management
support for addressing significant risks. Based upon the recommendations
of the Project Manager, the Program Sponsor or the CIO may assign
additional staff or allocate additional resources to reduce or avoid
significant risks. Additional guidance for managing project risk can be
found in the risk management section within the Project Management TSG
(IT-212.2-01).

# 3.8 AIS Security

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

While USPTO, OCIO, and issue-specific security policies address security
from a broad perspective, the formulation and full implementation of
these policies is independent of the life cycle and generally beyond the
control of any individual project manager. As a rule, these
organizational security policies do establish general security goals and
objectives, but they do not provide sufficient information or direction
necessary to implement specific AIS security measures. For this reason,
the Project Manager must consider project level security planning for
each AIS project and/or PTOnet infrastructure project. The Project
Manager must work closely with the security analysts in the Office of
Information Systems Security (OISS) to accomplish project level security
planning.

The processes of security planning and risk management share many common
activities and purposes. For example, a collateral benefit derived from
analyzing and managing risks, is that project managers are aware of AIS
assets (e.g., data, hardware, software, facilities, etc.) and are able
to anticipate specific events that could compromise the integrity of
those assets, render those assets unavailable to the end-user, or render
those assets unfit for service. Risk assessment and management also
provides project managers with an understanding of functional and
technical management's willingness to accept a broad range of risks,
including security risk. Based upon this knowledge, project managers are
able to develop cost-effective project-level security plans, policies,
and procedures that meet business needs.

Some of the most commonly thought-of AIS security issues include:

a.  AIS back-up, contingency, and disaster recovery,

b.  Data center security planning,

c.  Security test and evaluation, and

d.  Security certification and accreditation or interim authority to
    operate[^7].

## 3.8.1 Concept Phase Security Activities

Like most other aspects of AIS life cycle management, security is most
effective and efficient if planned and managed throughout the AIS life
cycle. During the Concept Phase, the System Development Manager develops
early conceptual designs of anticipated AIS security features.
Typically, due to the fact that the AIS is early in its life cycle,
these designs are not supported by detailed requirements but are based
upon a common sense understanding or "sensitivity assessment" of the
business and the underlying security needs[^8].

## 3.8.2 Sensitivity Assessment

A sensitivity[^9] assessment looks at the value of AIS data/information
and the AIS itself to USPTO. This assessment should consider financial
impact, legal implications, USPTO policy (including federal and
Department of Commerce policy), and the functional needs of the
business. Sensitivity is normally expressed in terms of integrity,
availability, and confidentiality. Project management must consider such
factors as the importance of the AIS to USPTO's mission and the
consequences of unauthorized modification, unauthorized disclosure, or
unavailability of AIS information when assessing sensitivity. To address
these types of issues, it is essential that those USPTO business
partners who will use the AIS participate in this assessment.

In performing a sensitivity assessment, project management must address
the following questions:

a.  What information is handled by the system?

b.  What kind of potential damage could occur through error,
    unauthorized disclosure or modification, or unavailability of
    information or use of the AIS?

c.  What laws or regulation affect security (e.g., The Privacy Act or
    the Fair Trade Practices Act)?

d.  To what threats is the AIS or AIS information particularly
    vulnerable?

e.  Are there significant environment considerations (e.g., hazards
    associated with AIS location - for example, next to an airport or
    railroad office)?

f.  What are the security-relevant characteristics of the AIS end-user
    community (e.g., level of computer or AIS sophistication and
    training, security clearances, etc.)?

g.  What internal security standards, regulations, or guidelines apply
    to this AIS?

The sensitivity assessment starts an analysis of security that continues
throughout the life cycle. The assessment helps determine if the AIS
project needs special security considerations, if further analysis is
needed before committing to begin the next phase of the LCM (to ensure
feasibility and reasonable cost), or in rare instances, whether the
security requirements are so strenuous and costly that system
development or acquisition will not be pursued. The sensitivity
assessment can be another planning document or may be combined with the
System Boundary Agreement, Requirements Specification, or Project
Management Plan according to tailoring agreements reached between AIS
project management and the Office of System Product Assurance.

# 3.9 Acquisition of Information Technology Resources

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

Acquiring information technology resources is often a difficult task
that requires knowledge, experience, the ability to work effectively
with people, good judgment, and common sense. The process is mandated by
regulations designed to ensure that USPTO acquires only what is needed,
and that USPTO considers and makes use of existing resources, including
Department of Commerce and other agency programs and contracts. When a
procurement action is determined to be appropriate, the acquisition
process attempts to ensure full competition among vendors and to prevent
abuses. USPTO strategies for acquiring information technology products
and services are contained in the most recent version of the Strategic
Information Technology Plan. All AIS managers should have a fundamental
grasp of federal, departmental, and USPTO Information Resource policies
and procedures.

AIS project managers must coordinate with the Office of Acquisition
Management throughout the AIS life cycle to acquire information
technology products and services. The goals of acquisition management
are to ensure that:

a.  The information technology is appropriate to the needs of the
    organization,

b.  Procurements are consistent with the Technical Reference Model and
    the overall architectural concept,

c.  Information technology components are interchangeable and
    interoperable,

d.  Information technology procurements are performed according to
    Federal acquisition laws and regulations,

e.  Information technology procurement plans are well documented,

f.  Information technology procurement plans encourage small business
    participation,

g.  Procurements rely on GSA schedules and government-wide contracts,
    and

h.  Procurements enable contractor end-to-end responsibility.

The Office of Acquisition Management directs the acquisition of
information technology hardware, software, and support services. This
office ensures that information technology acquisitions are conducted in
a manner that is consistent with USPTO\'s strategic information
technology plans. The Office of Acquisition Management provides
acquisition management support services, including Contracting
Officers\' Technical Representatives functions for USPTO-wide
information technology support service contracts. The Office of
Acquisition Management also advises and assists in the administration of
other information technology contracts.

# 3.10 Project Management Plan Update

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

The Project Manager must update the Project Management Plan in
preparation for the High Level Requirements Review. This update will
include a refinement of the project schedule with special emphasis on
the Detailed Analysis and Design Phase. This update must also include
completion of initial plans for AIS development, configuration
management, quality assurance, security, risk management, and data
management prepared in accordance with the applicable Technical
Standards and Guidelines. The Technical Review Board must review and
approve the updated Project Management Plan before the System
Development Manager can officially begin the Detailed Analysis and
Design Phase.

# 3.11 Concept Approval

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

## Project Manager and System Development Manager

####  Evaluate Documentation

The Project Manager and the System Development Manager evaluate the
System Boundary Agreement, Project Management Plan, Quality Assurance
Plan, Concept of Operations, Security Plan, Data Management Plan,
Configuration Management Plan, Requirements Specification, Part 1, High
Level Architecture, and all supporting initiatives and plans and assess
the following:

a.  Conformance to requirements and business needs,

b.  Conformance to standards and guidelines, and

c.  Technical and economic feasibility.

Based upon the findings of this evaluation, the Project Manager and the
System Development Manager will submit these plans to the Technical
Review Board for approval at the High Level Requirements Review.

## 3.11.2 High Level Requirements Review

Before beginning analysis to elaborate detailed requirements, the
Project Manager will ensure that the project team and the users who
generated those requirements reach consensus on their interpretation. A
technical review will be conducted in accordance with procedures in
IT-212.2-04, Quality Assurance, to provide a basis for support planning
in the Detailed Analysis and Design Phase and to establish the
foundation for technical reviews throughout the remainder of the AIS
life cycle. The Concept Phase is completed upon approval by the
Technical Review Board at the High Level Requirements Review and the
Program Sponsor and CIO agree to the system boundary.

[^1]: The Concept of Operations is prepared by the Project Manager and
    summarizes business structure, policies, procedures, and anticipated
    changes to the business organization. This document describes how
    the business area organization is currently structured, how it
    currently performs work, and how this organization may be structured
    in the future. The Concept of Operations also describes what new
    processes will be used to perform work in the future, and compares
    business process alternatives in terms of impact and risk to the
    organization.

[^2]:  The Requirements Specification is organized into high level and
    detailed level requirements. Part 1 of the Requirements
    Specification (Sections 1, 2, 3.2, 3.2.1, 3.2.2, 3.3, and 3.3.1)
    documents the high level requirements and Part 2 (the remaining
    sections of the specification), documents the detailed level
    requirements.

[^3]: The project team is responsible for assisting the Project Manager
    in identifying detailed business requirements, and addressing
    end-user issues regarding planning, requirements validation,
    training, logistics, facilities, and end-user acceptance testing.

[^4]: A High Level Architecture (HLA) defines the integration of
    business processes, data models, application software, and common
    information technology infrastructure components. The AIS High Level
    Architecture is a refinement of the Concept of Operations that
    symbolically describes the business functions, activities, and
    information flows that the AIS will provide or support. The HLA also
    describes the implementation of the AIS within the operational
    environment by providing textual and graphical descriptions of AIS
    hardware, software, and network components, and by illustrating the
    interconnections between these components. The HLA is refined during
    the Detailed Analysis and Design Phase and is the basis for
    preparing the Detailed Design. Additional information regarding
    technical architecture can be found in the Technical Architecture
    TSG (IT-212.2-12).

[^5]: The Office of Technical Plans and Policy coordinates project
    planning, project reviews, and associated program oversight and
    project monitoring activities; administers baseline project plans;
    and manages the automated Project Control and Analysis Tool for
    project tracking; coordinates the development and implementation of
    agency-wide information technology policy; annual strategic and
    operational technology plans; and supporting budget submissions.

[^6]: The Project Manager should exercise care to differentiate between
    *project risk analysis* and *security risk assessment*. Many AIS
    projects analyze the risk of failing to successfully complete the
    project \-- a different activity from security risk assessment.
    Though both activities share many common traits and underlying
    principles, *security risk assessment* focuses more upon ensuring
    the integrity, availability and confidentiality AIS components
    including business information and business processes.

[^7]: Based upon the recommendation of the Project Manager and the
    System Development Manager, the CIO may grant a security
    certification and accreditation or an interim authority to operate
    at the end of the Development Phase.

[^8]: These early conceptual designs are informal and are simply used to
    facilitate the development process in much the same manner that
    prototypes are used. These designs will be further modified,
    refined, and formalized as firm requirements are identified and
    developed.

[^9]: The definition of *sensitive* is often misconstrued. *Sensitive*
    is synonymous with *important* or *valuable*. Some information is
    sensitive because it must be kept confidential. Much more
    information, however, is sensitive because its integrity or
    availability must be assured. The Computer Security Act and OMB
    Circular A-130 state that information is sensitive if its
    unauthorized disclosure, modification (i.e., loss of integrity), or
    unavailability would harm the agency. In general, the more important
    a system is to the mission of the agency, the more sensitive it is.