# *OVERVIEW OF LIFE CYCLE MANAGEMENT*

# 1.1 Introduction

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

## 1.1.1 Purpose

This Life Cycle Management Manual establishes management policies,
procedures, and practices governing the initiation, definition, design,
development, deployment, operation, maintenance, enhancement, and
retirement of automated information systems[^1] (AIS) at the United
States Patent and Trademark Office (USPTO).

## 1.1.2 Objectives

Life Cycle Management (LCM) emphasizes decision processes that influence
system cost and usefulness efficiencies. These decisions must be based
on full consideration of business functional requirements and economic
and technical feasibility in order to produce an effective system. The
objectives of the LCM approach are to:

-   deliver quality systems which meet or exceed customer expectations
    when promised and within cost estimates.

-   deliver systems that work effectively and efficiently within the
    current and planned information technology infrastructure.

-   deliver systems that are cost-effective to enhance and maintain.

-   develop quality systems using an identifiable, measurable, and
    repeatable processes.

-   establish an organizational and project management structure with
    appropriate levels of authority to ensure that each AIS or
    infrastructure project is effectively managed throughout its life
    cycle.

-   Identify and assign the roles and responsibilities of all affected
    parties including functional and technical managers throughout the
    AIS or infrastructure system life cycle.

-   Ensure that AIS or infrastructure system requirements are well
    defined and subsequently satisfied.

-   Provide visibility and comprehensive information to USPTO functional
    and technical managers for all AIS or infrastructure system resource
    requirements and expenditures.

-   Establish appropriate levels of management authority to provide
    timely direction, coordination, control, review, and approval of the
    AIS or infrastructure system project.

-   Ensure project management accountability.

-   Identify project risks early and manage them before they become
    problems.

# 1.2 Intended Audience

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

The primary audience for this Manual and the supporting Technical
Standards and Guidelines (TSGs) are the functional and technical
managers responsible for defining and delivering USPTO systems, their
staff and their support contractors.

# 1.3 Types of Projects

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

AIS or infrastructure system projects vary in scope and diversity from
simple to complex. Examples of USPTO project types include:

a.  AIS Development -- AIS Development involves the development and
    deployment of an AIS to support a new or changed business function,
    replace an existing AIS which can no longer fulfill business needs,
    or to automate functions being done manually. Replacement of an
    existing AIS may include changing major components of the
    architecture.

b.  AIS Enhancement -- AIS Enhancements involve significant changes to
    the AIS design specification or architecture to ensure that new or
    changing requirements are being met.

c.  AIS or Infrastructure Maintenance -- AIS or Infrastructure
    maintenance are projects with new functionality changes or
    corrections (bug fixes) that do not impact the design or
    architecture of the AIS or infrastructure.

d.  Infrastructure Development or Enhancement -- Infrastructure
    Development or Enhancement involves the installation of new or
    replacement hardware or system software products such as the
    installation of high-speed switches or the upgrade of the network
    operating system. Infrastructure Development or Enhancement supports
    the evolution and adaptation of the USPTO Information Technology
    Infrastructure to support new systems and the increasing demands
    placed on it.

    **1.4 Life Cycle Management Phases**

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

Life Cycle Management includes six phases, during which defined AIS or
infrastructure system work products are created or modified. The tasks
and work products for each phase are described in subsequent chapters.
The LCM phases may be tailored[^2] to accommodate the unique aspects of
an AIS or infrastructure system project as long as the resulting
approach remains consistent with the primary LCM objective to deliver a
timely, quality system within cost. LCM phases may overlap and AIS or
infrastructure system projects can follow an evolutionary development
strategy that provides for incremental delivery of products and/or
subsystems. The tailoring process is described in the Automated
Information System Life Cycle Process Tailoring Technical Standard and
Guideline, IT-212.2-03.

## 1.4.1 Initiation Phase

The purposes of the Initiation Phase are to:

a.  identify and validate an opportunity to improve business
    accomplishments of the organization or a deficiency related to a
    business need,

b.  identify significant assumptions and constraints on solutions to
    that need, and

c.  recommend the exploration of alternative concepts and methods to
    satisfy the need.

This phase is completed upon agreement between the Program Sponsor and
the Chief Information Officer (CIO) to initiate an AIS or infrastructure
system project.

## 1.4.2 Concept Phase

This 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 it. The purposes of this phase are to:

a.  identify system interfaces,

b.  identify basic functional and data requirements to satisfy the
    business need,

c.  identify basic electronic records management requirements and ensure
    that the AIS or infrastructure system is compliant with the Federal
    Records Act, Privacy Act, and Paperwork Reduction Act,

d.  establish system boundaries, identify goals, objectives, critical
    success factors, and performance measures,

e.  evaluate costs and benefits of alternative approaches to satisfy the
    basic functional requirements,

f.  assess project risks,

g.  identify and initiate risk mitigation actions, and

h.  develop high level architecture, process models, data models, a
    records schedule, and a concept of operations.

This phase may include 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. Construction of
executable prototypes is encouraged to evaluate technology to support
the business process. The Program Sponsor approves requirements and the
Technical Review Board verifies that the requirements are clearly
defined. This phase is completed upon approval by the Technical Review
Board at the High Level Requirements Review and when the Program Sponsor
and the CIO agree to the system boundary.

## 1.4.3 Detailed Analysis and Design Phase

The purposes of this phase are to:

a.  further define and refine the functional and data requirements,

b.  complete a retention schedule for records and obtain approval from
    the National Archives and Records Administration and ensure that
    electronic records management requirements are incorporated into the
    design,

c.  complete reuse component selection,

d.  complete business process reengineering of the functions to be
    supported,

e.  develop detailed data and process models,

f.  define functional and system requirements that are not easily
    expressed in data and process models,

g.  further refine the high level architecture and logical design to
    support the functional and technical requirements, and

h.  continue to identify and mitigate risks, coordinating with the
    business area to ensure that new technology can be phased in.

At the end of this phase, the system is described by a completed high
level architecture and logical design. This phase is completed upon
Technical Review Board approval at the Technical Design Review. The
Technical Review Board records this approval in a record of agreement,
as described in the Technical Review Board Charter.

## 1.4.4 Development Phase

The purposes of the Development Phase are to:

a.  design, develop, integrate, and test the AIS or infrastructure
    system,

b.  update and finalize plans to deploy the AIS or infrastructure
    system, and

c.  complete business transition planning, and identify and initiate
    business transition activities.

All components of the logical design are allocated to components of the
detailed design and detailed design is completed and transformed into a
physical design. Risk identification and mitigation activities continue
to be performed to address any remaining risk. This phase is completed
when the Technical Review Board conducts the Production Readiness Review
confirming that the AIS is complete, correct, fully tested, and ready
for the Deployment Phase to begin.

## 1.4.5 Deployment Phase 

The purposes of the Deployment Phase are to:

a\. ensure that the AIS or infrastructure system is installed as planned
and specified,

b\. ensure that the users are trained,

c\. ensure that the end users and supporting organizations are prepared
to accept the

system.

In this phase, the system is installed to support the intended business
functions. Performance objectives have been identified, agreed to, and
recorded in a Service Level Agreement[^3] contained in the Operational
Support Plan prior to going into operation. Deployment occurs
incrementally when logistics do not permit all the intended end users to
receive the system at the same time. Deployment includes user
notification, user training, installation of hardware, installation of
software onto production computers, certification of data, and
integration of the system into daily work processes. The deployment
phase ends when all the intended users are first processing all the
intended workload with the system, and the Program Sponsor and the CIO
agree that the AIS or infrastructure system is fully operational.

## 1.4.6 Operations Phase

The purposes of this phase are to:

a.  operate, maintain, and enhance the AIS or infrastructure system,

b.  certify that the AIS or infrastructure system can process sensitive
    information,

c.  conduct routine data base assessment to ensure data quality and
    optimal data base performance is maintained,

d.  conduct periodic assessments of the AIS or infrastructure system to
    ensure the functional requirements are being satisfied, and

e.  determine when the AIS or infrastructure system needs to be
    modernized, replaced, or retired.

# 1.5 Tailoring the Life Cycle

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

The LCM can be tailored to fit the unique needs of an AIS or
infrastructure system project. The tailored process will be described in
the AIS or infrastructure system Concept Brief and Quality Assurance
Plan. The Concept Brief is an informational briefing presented to the
Technical Review Board in the Concept Phase that provides the project
description, life cycle tailoring agreement, schedule, and any project
issues.

As a tailoring example, LCM tasks and products can be reduced for an AIS
project to install a COTS software product on the existing USPTO
information technology infrastructure. The System Development Manager
should consider the size, complexity, and scope of the AIS or
infrastructure system project when preparing the AIS or infrastructure
system Project Management Plan. During this phase, the System
Development Manager will identify a tailored life cycle for the AIS or
infrastructure system and provide the tailoring information to the
Office of System Product Assurance for consulting purposes. The tailored
process must include the Concept Phase which bases much of the
information gathering on the information engineering planning and
analysis approach. Some of the Concept Phase tasks and work products may
be omitted as long as the resulting approach provides for delivery of a
timely, quality, system within costs. There are a few essential tasks
and work products that cannot be "tailored out" even when a COTS
software product will be used:

a.  succinct functional requirements,

b.  USPTO standard data definitions,

c.  records management,

d.  adequate testing,

e.  configuration management,

f.  user training,

g.  user manuals, and

h.  operations, maintenance, and help desk documentation.

The AIS Life Cycle Process Tailoring TSG, IT-212.2-03, provides guidance
for LCM tailoring. The tailoring information will be presented in the
Concept Brief to the Technical Review Board for approval.

# 1.6 System Development Methodology

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

## 1.6.1 General

The system development methodology supports an integrated set of
principles, procedures, practices, technical standards, and supporting
tools that the USPTO has adapted for use in developing, modifying, and
managing AISs or infrastructure systems.

USPTO's methodology is described in a series of technical standards and
guidelines publications[^4]. These technical publications describe
methods and procedures as well as documentation requirements (format and
content) associated with developing an AIS or infrastructure system
within the USPTO information technology infrastructure. The methodology
defines the activities that are needed to build a system, the interfaces
among those activities, and the products created as a result of those
activities. Much of the AIS or infrastructure system analysis and
design-level documentation will be captured and maintained in the
Computer Aided Software Engineering (CASE) tool repository, and reused
where practicable.

## 1.6.2 System Development Methodology Criteria

In order for the USPTO to build upon business process reengineering
activities, share data and processes, and develop and maintain
responsive automated information systems on time and within budget, a
rigorous and proven system development methodology is needed that:

a.  Supports an integrated set of formal techniques for the planning,
    analysis, design, and development of automated information systems
    on an enterprise-wide basis rather than on a project-wide basis.

b.  Is business-driven and firmly anchored in the strategic planning of
    the business enterprise.

c.  Supports business process reengineering and provides for storage of
    planning information relative to the business enterprise such as
    data and process models, critical success factors, process
    improvement, best practices, and business functions, goals, and
    objectives.

d.  Is supported by a set of commercially available automated tools that
    facilitate applying the methodology and provide for a rigorous
    enforcement of the methodology\'s techniques and standards.

e.  Is a data-centered design approach and provides techniques for
    formal data modeling and data administration.

f.  Imposes a rigorous discipline that enforces a good structuring of
    data and application program code.

g.  Supports techniques to identify processes and process improvements
    that are used many times in the enterprise so that designs and
    program code can be reused.

h.  Emphasizes top management involvement to provide strategic direction
    and active program sponsor/customer participation throughout the
    life cycle.

# 1.7 Policies and Guidelines for the Management of Projects

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

The following policies and guidelines apply throughout the full AIS or
infrastructure system life cycle, including maintenance, and enhancement
of AISs or infrastructure systems. Further information on these policies
and guidelines is contained in Chapters 2 through 7 of this manual.

## Manage AIS Projects as Investments

Proposed AIS or infrastructure system projects will be clearly supported
by detailed analyses of the project's expected costs and benefits;
alternative solutions considered; potential programmatic and technical
risks; and the AIS's or infrastructure systems' overall contribution to
the business area's and USPTO's mission, goals, and objectives.

## Emphasize Evolutionary Development and Incremental Delivery of Products

AISs or infrastructure systems will be developed emphasizing
evolutionary development and incremental delivery of products and
services. AIS or infrastructure system project plans should focus on
providing the end user with usable products as early as practical.

**1.7.3 Improve End-User Productivity**

AISs or infrastructure system will simplify and reduce the effort
required to handle administrative activities so that more employees can
focus on program-related workloads. Each AIS should meet the following
objectives:

a.  Emphasize user friendliness over ease of technical design and
    application software development.

b.  Provide easier, secure, reliable access to data.

c.  Tailor management information reports to customer needs.

d.  Provide automated tools to facilitate end user access to and use of
    data.

e.  Provide readily available help within the application software and
    provide for computer based training modules.

f.  Reduce the reliance on paper.

g.  Provide easier, secure access and management to electronic records.

## 1.7.4 Encourage End-User Involvement

End-user participation and involvement throughout life cycle activities
is crucial to the success of each AIS or infrastructure system and must
be encouraged. For example, end users must participate early in the AIS
project in order to obtain clear, validated functional requirements. Due
consideration must be given to ensure that all internal, external, and
legal customer requirements are adequately reflected in the automated
solution.

## 1.7.5 Ensure that Adequate End-User Training is Provided

End-user training is essential in order for the AIS or infrastructure
system to be effectively used. End-users must be provided with initial
training to support a newly installed AIS or infrastructure system, and
must receive all additional training necessary to effectively utilize
AIS or infrastructure system modifications and enhancements.

## 1.7.6 Employ Matrix Management Techniques

Matrix management techniques should be used to recognize the
complementary roles of functional users, AIS or infrastructure system
developers, and other supporting organizations. The Project Manager
reports to the Program Sponsor, and is responsible for coordinating
end-user participation and managing functional requirements. Generally,
the System Development Manager reports to the CIO and is matrixed to the
Project Manager. The System Development Manager is responsible for
coordinating development and technical support, and for managing
technical requirements.

## Comply with USPTO Information Technology Standards and Guidelines

AIS or infrastructure system projects must follow the provisions of the
USPTO Information Technology Standards and Guidelines (TSGs)[^5], which
provides up-to-date technical guidance designed to aid the System
Development Manager deliver a quality system and the System Maintenance
Manager to maintain and enhance one.

## Use USPTO Information Technology Infrastructure and Ensure Compatibility With USPTO Technical Reference Model

AIS or infrastructure system projects must be developed within the
bounds of current and planned information technology standards and
capabilities as defined in the USPTO Strategic Information Technology
Plan and USPTO Technical Reference Model[^6]. An AIS or infrastructure
system project\'s computer and network resource requirements must be
satisfied by the USPTO information technology infrastructure
capabilities whenever practicable. PTOnet and distributed processing
platforms will be exploited to provide managers and staff with needed
automated support.

A key information technology management objective is to transform the
USPTO information technology infrastructure into a standards-based open
system environment. An open system environment will allow the USPTO to
add new or replace existing products or infrastructure components as new
technologies are introduced into the marketplace. System Development
Managers will select standards and products that conform to the
Technical Reference Model in the detailed design and development of the
technical architecture. System Development Managers must adhere to
approved standards and preferred products unless other standards or
products can be clearly demonstrated to be cost-effective over the life
of the application.

The System Architect is responsible for developing, maintaining and
evolving the USPTO information technology infrastructure and the USPTO
Technical Reference Model.

## 1.7.9 Use USPTO Standard Data Definitions

Standard definitions of data will be developed and maintained so that it
will be easier for users to reliably and consistently interpret and use
data. AISs or infrastructure systems shall be developed using USPTO
standard data models and data elements. Guidance is contained in the
USPTO Data Management Technical Standard and Guideline, IT-212.2-05, and
Data Element Standardization Technical Standard and Guideline,
IT-212.3-13.

## 1.7.10 Use USPTO Standard System Development Tools

The CIO has selected a standard suite of system development tools that
support the system development life cycle. The standard tools will
reduce maintenance costs, make projects more predictable, reduce
dependence on original developers, leverage the experience of in-house
staff to work on different projects without retraining on system
development tools, and facilitate reuse of software components. System
Development Managers will use the USPTO standard system development
tools designated in the USPTO Technical Reference Model and refrain from
using other system development tools unless it can be clearly
demonstrated that other system development tools would be more cost
effective over the life of the application.

## Cost and Schedule Performance Must Be Planned and Reported

USPTO has established a project management control system to provide
visibility into actual progress of each project. The project management
control system provides for tracking actual cost and schedule
performance against project plans. This visibility will help both
functional and technical managers identify problem areas and take
corrective actions when actual results deviate significantly from plans.
Project Managers and System Development Managers will ensure that the
necessary information for each AIS or infrastructure system project is
provided in a timely manner and entered into the project management
control system. Project planning specialists from the CIO's Office of
Technical Plans and Policy will assist the Project Manager and the
System Development Manager in developing a project management plan and
project schedule. The USPTO Project Management Technical Standard and
Guideline, IT-212.2.01 provides guidance on how to prepare project
management plans and project schedules.

## Each Project Must Be Consistent with the USPTO Strategic Information Technology Plan

AIS or infrastructure system projects will be contained in the USPTO
Strategic Information Technology Plan. New projects must be consistent
with the USPTO Strategic Information Technology Plan and be agreed to by
both the business area Program Sponsor and the CIO, as described in
paragraph 1.4.1. The Program Sponsor and the CIO will identify and
allocate project resources and the new project will be included in the
next planning cycle. Project Managers shall identify in the LCM
documentation the specific key goals and objectives of the USPTO
Strategic Plan that are supported by the AIS or infrastructure system
project.

## 1.7.13 Use of COTS Software is Encouraged

Commercial-Off-The-Shelf application software products cover a broad
spectrum of capabilities. These products can satisfy USPTO business
needs and can operate on USPTO's Information Technology Infrastructure.
COTS application software products are preferred over developing new
application software. USPTO unique requirements not provided by the COTS
product will be satisfied through application program interfaces.

## 1.7.14 Business Processing Reengineering Techniques May Be Applied 

USPTO will employ reengineering and continuous quality improvement
techniques as required to help ensure that processes are as effective
and efficient as possible. Information technology is a key enabler of
process improvement. No AIS or infrastructure system project will be
undertaken before the supported process has been reviewed and, as
necessary, redesigned to its greatest possible effectiveness. If needed,
formal business process reengineering will precede application software
design and development. The business area Program Sponsor, in
consultation with the CIO, will designate AIS or infrastructure system
projects that will apply business reengineering techniques.

## 1.7.15 Secure and Protect All Sensitive Information

Security of all sensitive information must be explicitly considered
throughout the AIS or infrastructure system life cycle and documented in
an AIS security and disaster recovery plan. Program Sponsors, with the
guidance and assistance of the CIO, must ensure that their AISs or
infrastructure system and business procedures will process and handle
sensitive information and deliver critical services in a manner
compliant with all applicable laws and regulations. AISs or
infrastructure systems will be controlled with respect to access,
authority to modify, and ability to operate. Security specialists from
the CIO's Office of Technical Support Services will maintain a USPTO
Information Technology Infrastructure Security and Disaster Recovery
Plan and assist the System Development Manager develop a security and
disaster recovery plan that addresses the unique business requirements
of an AIS or infrastructure system project.

## 1.7.16 Apply Risk Management Techniques

Risk management must be applied to all LCM-AIS projects throughout the
life cycle. Risk, as used in the LCM, is associated with a lack of
resources, information, and/or control. Risk management is distinguished
from \"problem management\" in that risk management is concerned with
situations that may or may not occur, whereas problem management is
concerned with known difficulties that are a result of a risk having
occurred. An analysis of risk and any strategy adopted to control risk
should at least consider the effect of one or more of three factors:
lack of resources (such as personnel or funding); lack of information
(for example, completeness and confidence); or lack of control over the
decision-making process (such as external project decisions affecting
the project plans and assumptions). Applying risk management to
production AISs or infrastructure systems includes considering backup
and recovery in service level agreements and plans. Management
responsibility for a risk must be assigned to individuals and
organizations that can affect the risk\'s root causes. The Project
Manager shall be responsible for managing project risks over which the
Project Manager can exert direct control. Risks that affect the project,
but are not under project control, shall be explicitly assigned to
either the Program Sponsor or the CIO, as appropriate. Situations
external to the project that could be sources of risk to the project
shall be coordinated through the Project Manager. Risk shall be a
consideration in Technical Review Board and management decisions.
Project risk situations, plans, and progress against risks must be
considered at all project reviews. Guidance is contained in the USPTO
Project Management Technical Standard and Guideline, IT-212.2-01.

## 1.7.17 Focus on Software Process Improvement

The USPTO is committed to a program of continuous software process
improvement. The USPTO's software process improvement program will
enhance the USPTO's ability to deliver quality systems in a timely and
cost-effective manner. Established in January 1994 to define and
institutionalize a USPTO-standard system development life cycle
management process, the Software Engineering Process Group (SEPG) is the
CIO's focus group for capturing best practices, presenting new
technology and tools, reviewing draft guidelines and keeping the CIO
staff aware of new software process improvement opportunities. System
Development and System Maintenance Managers must stay abreast of and
contribute to process improvements in order to institutionalize LCM
within USPTO and make it work.

## 1.7.18 Manage AIS or Infrastructure System Baselines

An AIS or infrastructure system baseline is an approved set of work
products for a stage in the system life cycle. Baselines are established
at the completion of phases of the life cycle. The set of work products
designated as a baseline is managed as a unit. Changes to baselines are
approved by their designated owners. System Development and System
Maintenance Managers must establish and maintain baselines throughout
the AIS or infrastructure system life cycle to: keep successive versions
of the system synchronized with incremental service delivery promises;
keep track of the current contents of the complete systems; and maintain
complete technical data packages. Properly managing baselines will
prevent costly later rework and rediscovery, and aid reuse.
Configuration management specialists will periodically audit established
AIS or infrastructure system baselines to verify that they conform to
the documentation that defines them. The Configuration Management
Technical Standard and Guideline, IT-212.2-06, describes the baselines
and their contents in more detail. Technical reviews decide completion,
and each baseline type is described in Section 1.8.2, Conducting
Technical Reviews.

## 1.7.19 Implement Key Software Management Processes

The following policies apply to phase-independent key software process
areas that are necessary to support the definition, design, development,
deployment, operation, maintenance, and enhancement of AISs or
infrastructure systems. These key process areas are configuration
management, quality assurance, data management, and requirements
management. Other key process areas are discussed in the relevant
chapters of this Manual.

a.  [Requirements Management]{.underline}. Requirements management
    controls the identification, definition and refinement of
    requirements as analysis proceeds from high level to detail
    definition, and allocation to system and subsystem components.
    Requirements must be managed as they change and evolve throughout
    the AIS or infrastructure system life cycle. The System Development
    Manager will create and maintain a requirements database and a
    requirements traceability matrix to identify changes throughout the
    AIS or infrastructure system life cycle. Requirements management
    specialists from the Office of System Product Assurance will help
    the System Development Manager develop the requirements traceability
    matrix.

b.  [Data Management]{.underline}. The System Development Manager will
    establish plans to manage the data, data models, and databases
    required by the AIS or infrastructure system. Data management plans
    will be defined and updated to ensure that all data related issues
    are addressed throughout the life cycle and to ensure that the
    agency records management program is followed for compliance with
    records management laws and regulations. Data management specialists
    from the CIO's Office of Data Management will, in coordination with
    the System Development Manager, prepare data management plans and
    will review the data management plans and data models to ensure
    compliance with data administration policy and guidelines. Data
    management specialists will also facilitate the processes for
    developing data models and standardizing data elements. Records
    management staff from the CIO's Office of Data Management will
    assist the System Development Manager in scheduling AIS or
    infrastructure system records and ensure that the AIS or
    infrastructure system is compliant with the Federal Records, Privacy
    Act, and Paperwork Reduction Act and meets basic electronic records
    management requirements.

c.  [Quality Assurance]{.underline}. The System Development Manager will
    establish plans to provide management with appropriate visibility
    into the process being used by the software project and the products
    being built. Quality assurance specialists from the Office of System
    Product Assurance will, in coordination with the System Development
    Manager, prepare Quality Assurance plans and will attend all major
    technical reviews. Quality assurance specialists will review and
    audit the AIS or infrastructure system project work products and
    activities to help assure that the AIS or infrastructure system
    Project will deliver a quality system.

d.  [Configuration Management]{.underline}. Configuration management of
    all AIS or infrastructure system hardware, software, and
    accompanying documentation shall be performed throughout the AIS or
    infrastructure system life cycle. The Office of System Product
    Assurance, in coordination with the System Development Manager, will
    establish plans and baselines to ensure configuration
    identification, configuration control, configuration status
    accounting, and configuration audits for all configuration
    documentation, physical media, and physical parts composing the
    system. Configuration management shall also be applied to any
    resources such as compilers or CASE tools used to develop the AIS or
    infrastructure system. The configuration management process shall
    provide a means for recording, reviewing, approving, and tracking
    change requests and problem reports for all configuration
    items/units. Configuration management methods will be compatible
    with and leverage the use of standard system development tools
    designated in USPTO's Technical Reference Model. Configuration
    management specialists from the Office of System Product Assurance
    will work with the System Development Manager in preparing
    configuration management plans and performing configuration
    management and will attend all major technical reviews.

## 1.7.20 Conduct Peer Reviews

Peer reviews will be conducted on designated critical AIS or
infrastructure system projects to identify and remove defects from the
project\'s work products early and efficiently. The AIS or
infrastructure system project\'s peer review process and the specific
work products that will undergo peer review will be documented in the
quality assurance plan. Peer reviews should be led by trained peer
review leaders, and each person attending a peer review will have a
specific role that they are trained to perform. Products that undergo
peer review will have all actions identified as a result of the peer
review tracked until they are resolved. Checklists that guide the peer
reviews will be maintained by the Office of System Product Assurance,
and reviewed by the checklist\'s potential users. Results of peer
reviews will be collected and reported in a manner that leads to
positive corrective actions taken and not to evaluate the performance of
individuals.

## 1.7.21 Establish A Technical Training Program

A technical training program for the AIS or infrastructure system
project must be established to help ensure that appropriate skills and
knowledge of individuals assigned to the project are developed so that
they can perform their project roles effectively and efficiently. Each
project will evaluate its current and future skill needs and determine
how these skills will be obtained. Technical training specialists from
the CIO's Office of Technical Plans and Policies will assist the System
Development Manager in developing a training program.

## 1.7.22 Encourage Prototyping

The use of prototyping in the Concept and Detailed Analysis and Design
Phases to help define and refine requirements is encouraged. Prototypes
can enhance user and developer understanding and interpretation of
requirements or validate portions of the technical architecture against
the functional requirements and technical specifications. Executable
prototypes must be fully tested and documented and meet the minimum
criteria established in section 1.5 prior to being placed in pilot or
production status. Additional information on prototyping and pilots[^7]
is provided in chapters 3 and 4 of this document.

## 1.7.23 Reuse Software Whenever Practical

The reuse of existing system components will reduce cost and quicken
system delivery. System Development Managers will construct AISs or
infrastructure systems from previously developed system components
whenever practical. The reusable components include data and process
models, technical design specifications, plans, test suites, and program
code.

## 1.7.24 Help Ensure Software Independence

AISs or infrastructure systems will be developed, documented, and
maintained in such a manner as to reduce reliance on individuals or
organizations that operate, maintain, or enhance the AIS or
infrastructure system. Initially, this will require additional cost and
effort to collect, analyze, and enhance the life cycle documentation
necessary to ensure software independence. Once this technical knowledge
base has been firmly established, however, AISs or infrastructure
systems can be maintained and enhanced much more cost-effectively, much
faster and with far less effort.

## 1.7.25 Using Contractor Support

For contractor-supported AIS or infrastructure system projects, System
Development Managers will ensure that USPTO personnel work closely with
the contractor to ensure that tasks are accomplished in a quality,
timely, and cost-effective manner and that technology transfer occurs.
Contractors are prohibited from preparing Project Manager Charters and
related decision memoranda. Contractors are also prohibited from
assigning a role, responsibility or authority, which is documented in
the Project Management Plan.

## 1.7.26 Maintain Complete Project Records

LCM documentation developed in support of AIS or infrastructure system
projects will be retained in accordance with USPTO's record management
schedule. LCM documentation developed in support of an AIS or
infrastructure system project that is retired before successful fielding
also will be retained in accordance with USPTO's record management
schedule. All documentation related to a contract shall be retained
after contract close-out in accordance with USPTO's record management
schedule. Contract close-out is the last billing date and may be as long
as 3 years after the end of the contract.

# 1.8 AIS or Infrastructure System Project Reviews

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

Diverse and rapidly developing opportunities to employ computers to
improve mission performance have brought increased importance to the
application and management of information technology. Technical reviews
must be performed to ensure that an AIS or infrastructure system project
is progressing on schedule and within budget and is satisfying
functional requirements. The conduct of the reviews may be tailored to
address the specific needs of each project consistent with the
development plan. The Technical Review Board conducts reviews of work
products and plans for the next life cycle phase*.* The CIO conducts
in-progress reviews of cost, schedule and deliverables. The Program
Sponsor and the CIO jointly conduct a management review to decide to
initiate an AIS or infrastructure system project.

## 1.8.1 Purpose of Technical Reviews

Technical reviews are performed to provide sufficient visibility into
the AISs or infrastructure systems' functional and technical
characteristics, as well as establish management control points for
assessing project cost, schedule, and quality. The purposes of a
technical review are to:

a.  Improve the quality of intermediate AIS or infrastructure system
    work products and to correct defects as early in the life cycle as
    possible in order to prevent problems over the long run.

b.  Ensure that the AIS or infrastructure system being produced can be
    supported by the current and planned USPTO information technology
    infrastructure.

c.  Ensure that the AIS or infrastructure system project conforms to
    USPTO system development methodology and supporting tools, uses
    USPTO standard data, and adheres to the USPTO Technical Reference
    Model.

d.  Monitor the impact of an AIS or infrastructure system project on
    other USPTO AISs, AIS projects, and the USPTO information technology
    infrastructure.

## 1.8.2 Conducting Technical Reviews

The Project Manager, System Development Manager, or Technical Review
Board Chairperson may choose to convene technical reviews at any time
during the life cycle to determine the state of work products. Technical
reviews may be held as one or more events as determined by the Technical
Review Board Chairperson. Reviews may be combined. The conduct of the
reviews may be tailored to address the specific needs of each project
consistent with the AIS or infrastructure system development plan.
Tailoring guidance may be found in the Automated Information System Life
Cycle Process Tailoring Technical Standard and Guideline, IT-212.2-03. A
typical project will not require all the reviews and baselines discussed
below. Guidance is contained in the USPTO Quality Assurance Technical
Standard and Guideline, IT-212.2-04.

a.  [High Level Requirements Review]{.underline}. This review is
    conducted to confirm that a common understanding of the functional
    requirements for the AIS or infrastructure system is captured in the
    System Boundary Agreement or Requirements Specification, Part 1.
    This review is conducted at the end of the Concept Phase. This
    review approves the System Boundary Baseline, which includes the
    functional requirements and project related cost, schedule, and
    performance measures. The System Boundary Baseline contains the
    System Boundary Agreement. The developmental configuration is
    initiated after this review under the ownership of the System
    Development Manager. The developmental configuration consists of the
    design and the associated technical data that defines the components
    of the system.

b.  [Detailed Level Requirements Review]{.underline}. This review is
    conducted to confirm that a common understanding of the functional
    requirements for the AIS or infrastructure system is captured in the
    Requirements Specification, Parts 1 and 2[^8]. This review is
    conducted during the Detailed Analysis and Design Phase. This review
    approves the Requirements Specification, Parts 1 and 2.

c.  [Logical Design Review]{.underline}. This review is conducted during
    the Detailed Analysis and Design Phase to confirm the functional,
    data and other requirements of the AIS, to verify the data and
    process models of the AIS or infrastructure system, to confirm the
    ability of the High Level Architecture to satisfy the functional,
    data and other requirements and to confirm the allocation of
    requirements to components of the technical architecture. This
    review approves the logical design (allocated) baseline, which
    describes approved functional, data, interface, and other
    requirements allocated to the system or subsystem elements.

d.  [Technical Design Review]{.underline}. This review is conducted
    during the Detailed Analysis and Design Phase to evaluate the
    appropriateness of the technical design. This review verifies that
    the system conforms to the infrastructure baseline. The USPTO
    Information Technology Infrastructure is controlled separately from
    any individual AIS project. This baseline is managed by the System
    Architect.

e.  [Test Readiness Review]{.underline}. This review is conducted at the
    end of the Development Phase to determine whether unit and
    integration testing has been conducted in accordance with the test
    procedures and that the tests are complete. This review determines
    whether the system is ready for independent acceptance testing. The
    development configuration is created during the Development Phase
    and maintained under informal configuration management at the
    project level until the end of the Development Phase. The
    developmental configuration consists of the design and associated
    technical data that defines the components of the system. A version
    of the Developmental Configuration is placed under formal
    configuration management after Test Readiness Review and is used for
    acceptance testing.

f.  [Beta Readiness Review]{.underline}. This review is conducted during
    independent acceptance testing to determine whether formal testing
    is complete and the system is ready for user Beta testing. The
    review is performed during the Development Phase.

g.  [Production Readiness Review]{.underline}. This review is conducted
    at the end of the Development Phase to determine whether the system
    is adequately tested, satisfies the boundary conditions, and is
    ready for production use. The Program Sponsor participates in the
    Production Readiness Review. This review establishes that
    appropriate operational and maintenance support is available. This
    review establishes the product and operational baselines. The
    Product Baseline consists of the documentation describing all the
    necessary functional and physical characteristics of the elements
    that compose the system and the actual equipment and software. The
    Operational Baseline consists of the parameters and procedures
    needed to operate and to perform routine maintenance on the AIS or
    infrastructure system. The Operational Baseline is established to
    record changes to those items for which a review by the Technical
    Review Board prior to making the change is not required.

h.  [Post Installation Review]{.underline}. This review assesses results
    during the production trial period. The TRB or the Project Manager
    may request that a Post Installation Review (PIR) be conducted. The
    PIR is used to identify remaining discrepancy reports, deferred
    requirements for future maintenance releases, and any issues related
    to the system operation. Based upon the results of this review, the
    Technical Review Board and the business area Program Sponsor give
    permission for the AIS or infrastructure system to remain in
    production if there are no serious problems.

i.  [Functional Configuration Audit]{.underline}. This audit may be
    conducted during the Deployment Phase to ensure that all functional
    requirements specified in the System Boundary Agreement are
    satisfied.

j.  [Physical Configuration Audit]{.underline}. This audit is conducted
    during the Deployment Phase to determine whether the delivered ("as
    built") system is complete and consistent with its documentation.

## 1.8.3 In-Progress Reviews

The CIO and Program Sponsors conduct periodic in-progress reviews (IPR)
to assess progress, adherence to schedule and budget, possible impact on
other projects, and to direct corrective actions as needed. Project
Managers and System Development Managers should also hold regularly
scheduled (e.g., biweekly) project status reviews that discuss progress
against project plan as well as technical issues.

# 1.9 Roles and Responsibilities for AIS or Infrastructure System Project Management

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

The successful development, deployment, and operation of an AIS or
infrastructure system require close coordination and partnership between
the Program Sponsor and the CIO. Teamwork is essential to delivering a
quality system on time and within budget. The Program Sponsor identifies
and prioritizes business needs. The CIO determines how best to employ
technology. The Program Sponsor and the CIO provide resources and work
together to determine the project schedule and cost estimates.

## 1.9.1 Program Sponsor

The Program Sponsor is responsible for defining and validating
functional requirements, for making resources available to support
information technology program initiatives, and for reviewing the
progress of AIS or infrastructure system projects to ensure that
functional requirements are being satisfied in a timely and
cost‑effective manner. Program sponsors within their area of
responsibility will:

a.  Ensure that the goals and objectives of all information technology
    related initiatives are consistent with the goals, objectives, and
    governing strategies of the USPTO Corporate Performance Plan and the
    Business Area's Strategic Plan.

b.  Exercise management oversight of AIS or infrastructure system
    projects to ensure that business requirements are being satisfied in
    a cost-effective manner.

c.  Exercise management oversight of the evaluation and improvement of
    business processes as well as the development of business goals,
    objectives, critical success factors, and performance measures.

d.  Ensure that the necessary data for each AIS or infrastructure system
    project are provided in a timely manner and are entered into
    USPTO\'s project management control system and work with the CIO to
    ensure that corrective actions are taken when needed.

e.  Ensure, with the assistance of the CIO, that AISs or infrastructure
    systems processes handle sensitive information and deliver critical
    services in a manner compliant with all applicable laws and
    regulations.

f.  Ensure that business area transition planning and appropriate
    training are accomplished in a timely manner.

g.  Assign Project Managers to direct and coordinate the complete effort
    to achieve agency business objectives to be accomplished by the AIS
    or infrastructure system project.

h.  Assign Production Managers to direct and coordinate the maintenance
    and modifications of an operational AIS or infrastructure system
    required to keep up with changing business needs.

## 1.9.2 Chief Information Officer (CIO)

The CIO is the principal advisor to the Commissioner on the effective
application of information technology and will:

a.  Ensure that all information technology initiatives are managed in
    accordance with sound life cycle management principles and practices
    and are consistent with the USPTO Strategic Information Technology
    Plan.

b.  Perform technical reviews to ensure that an AIS or infrastructure
    system project is progressing on schedule and within budget and is
    satisfying functional requirements.

c.  Establish service level agreements to promote organized and timely
    information technology support to customers.

d.  Use the results of periodic customer focus sessions to identify
    opportunities for improvement, to determine customer needs, and to
    determine whether an AIS or infrastructure system effectively serves
    its users and meets established performance measures.

e.  Establish and administer a project management control system to
    provide visibility into the actual progress of each AIS or
    infrastructure system project.

f.  Ensure that security is adequately considered in system design and
    issue an accreditation statement that authorizes operation of the
    AIS or infrastructure system based on evidence provided by the
    certification and verified by an accreditation audit.

g.  Assign a System Development Manager to develop and deploy an AIS or
    infrastructure system.

h.  Assign a System Maintenance Manager to perform system maintenance
    and develop and deploy system enhancements as identified and
    prioritized by the Production Manager.

i.  Operate the AIS or infrastructure system according to established
    Service Level Agreements contained in the Operational Support Plan.

## 1.9.3 Steering Committee

The Steering Committee may be created to perform the duties of or assist
the Program Sponsor when an AIS or infrastructure system project crosses
organizational boundaries. The Steering Committee is composed of
functional and technical representatives appointed by the Program
Sponsor and the CIO.

## 1.9.4 Project Manager

Appointed by the Program Sponsor, the Project Manager oversees the
complete effort to achieve agency business objectives to be accomplished
by the AIS or infrastructure system project. The Project Manager, in
coordination with the Program Sponsor, the System Development Manager,
and other managers, develops the project budget and schedule, and
monitors cost and schedule performance for the project. The Project
Manager will:

a.  Provide daily direction and coordination for the business aspects of
    the design, development, and deployment of an AIS or infrastructure
    system subject to the technical direction of the CIO and the
    business direction of the Program Sponsor.

b.  Coordinate changes to the business environment brought on by the
    implementation of new business processes. The changes to the
    business environment may require resolution of labor management
    issues, legal issues, employee relations issues, and/or changes to
    the physical workplace environment.

c.  Ensure that users: (1) actively participate in the AIS or
    infrastructure system project to help identify and refine
    requirements and to test the system; and (2) are adequately trained
    before the AIS or infrastructure system is fully deployed.

d.  Under matrix management, the Project Manager directs the activities
    of the project team. The Project Management Technical Standard and
    Guideline, IT-212.2-01, describes the responsibilities of the
    Project Manager in more detail.

## 1.9.5 System Development Manager

Appointed by the CIO, the System Development Manager is responsible for
designing, developing and deploying an AIS or infrastructure system. The
System Development Manager ensures that the AIS or infrastructure system
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.2-01, describes the responsibilities of the System Development
Manager in more detail.

## 1.9.6 System Architect

A senior manager in the Office of System Architecture and Engineering
serves as the USPTO System Architect. Appointed by the CIO, the System
Architect is responsible for:

a.  Developing or approving the high level design for all USPTO AISs or
    infrastructure systems,

b.  Managing the evolution of USPTO's information technology
    infrastructure, and

c.  Developing and maintaining the USPTO's Technical Reference Model.

The Technical Reference Model provides a comprehensive set of
information technology standards, services, protocols, and preferred
products that define the target technical environment. This model is
used for the acquisition, development, and support of all USPTO AISs or
infrastructure systems.

## 1.9.7 Production Manager

Appointed by the Program Sponsor, the Production Manager, directs and
coordinates the maintenance and modification of an operational AIS or
infrastructure system required to keep up with changing business needs.
Under matrix management, the Production Manager identifies and
prioritizes functional requirements that will be incorporated into an
operational AIS or infrastructure system by the System Maintenance
Manager and coordinates the implementation of those changes in the
business environment. The Production Manager ensures that users
participate in system testing and are adequately trained before the AIS
or infrastructure system changes are fully deployed. The Production
Manager assures that the AIS or infrastructure system has been
adequately secured.

## 1.9.8 System Maintenance Manager

Appointed by the CIO, the System Maintenance Manager performs system
maintenance and develops and deploys system enhancements as identified
and prioritized by the Production Manager. The System Maintenance
Manager ensures that the operational AIS or infrastructure system is
managed according to sound life cycle management principles and
practices.

## 1.9.9 Technical Review Board

Appointed by the CIO, the Technical Review Board evaluates the progress
of each AIS or infrastructure system project by assessing the quality of
its work products and recommends action to the CIO. The Board ensures
that USPTO's Life Cycle Management methodology is followed in a
coordinated, common-sense manner for all AIS or infrastructure system
projects by conducting technical reviews described in section 1.8.
Results of the technical reviews are provided to the Commissioner of
Patents and Commissioner of Trademarks, as appropriate. The Technical
Review Board Charter defines the Board\'s authority and responsibility
in more detail.

## 1.9.10 Software Engineering Process Group

Appointed by the CIO, the Software Engineering Process Group defines,
introduces, monitors, and continuously improves system development life
cycle processes. The goal of the SEPG is to develop and institutionalize
an identifiable, measurable, and repeatable life cycle management
process that facilitates the delivery of quality systems when promised
and within cost estimates. The Software Engineering Group Charter
defines the Group's authority and responsibility in more detail.

[^1]: An automated information system (AIS) is a combination of
    functional users, information technology personnel, business
    processes and procedures, application software, system software,
    documentation, commercial off-the-shelf software, computer,
    networking and other information technology resources that collect,
    record, process, store, communicate, retrieve, display, and
    disseminate information.

[^2]: Tailoring is the process of omitting or reducing tasks and work
    products from the AIS or infrastructure system project management
    plan. In special cases, tailoring may add tasks or work products.

[^3]: Service Level Agreements are contained in the Operational Support
    Plan and describe the services OCIO provides to another USPTO
    organization. Each service description includes OCIO\'s commitments
    in regards to providing the service and the other organization\'s
    responsibilities in regards to obtaining the service. The final
    document is approved by the CIO and his peer in the other USPTO
    organization.

[^4]: The USPTO Technical Standards and Guidelines are downloadable and
    may be found at <http://ptoweb/ptointranet/tsg/tsgindex.htm>.

[^5]: USPTO Technical Standards and Guidelines may be found at
    http://ptoweb/ptointranet/tsg/tsgindex.htm.

[^6]: The USPTO Strategic Information Technology Plan documents the role
    that information technology plays in achieving the USPTO's mission,
    vision, and goals. The USPTO Technical Reference Model provides a
    comprehensive set of information technology standards, services,
    protocols, and products that define the target technical environment
    for the acquisition, development, and support of USPTO AISs.

[^7]: Pilot - A limited scope application program that satisfies most,
    if not all of the user's requirements. It normally is targeted to a
    limited user group for evaluation with the understanding that it
    will be scaled up and integrated into a fully compatible production
    system.

[^8]: The Requirements Specification organizes the requirements into
    high level (Part 1) and detailed requirements (Part 2).