TIPSTER Text Phase III

Configuration Management Plan

Prepared by :

Architecture Committee

for the

TIPSTER Text Phase III Program

Revisions

  ------------- -------------- -----------------------------------------------
  **Version**   **Date**       **Change and reason for change**

  1.2           8 Apr 1996     Appendix B for RFC and Para 4.4 added

  1.2.1         27 June 1996   Remove organizational references, change ARPA
                               to DARPA

  1.3           25 November    Various editing changes and bring the document
                1997           into compliance with current practices

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

                               

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

TABLE OF CONTENTS

**TABLE OF FIGURES [ii](#table-of-figures)**

1.0 EXECUTIVE SUMMARY [2](#executive-summary)

1.1 Configuration Management Goals [2](#configuration-management-goals)

1.2 TIPSTER Application Conformance Assessment Document
[2](#tipster-application-conformance-assessment-document)

1.3 Configuration Management in a TIPSTER Application LifeCycle
[2](#configuration-management-in-a-tipster-application-lifecycle)

2.0 BACKGROUND [2](#background)

2.1 Need for TIPSTER Configuration Management
[2](#need-for-tipster-configuration-management)

2.2 SE/CM Role Within the Overall TIPSTER Framework
[2](#secm-role-within-the-overall-tipster-framework)

2.3 Purpose of the CM Plan [2](#purpose-of-the-cm-plan)

2.4 Scope of the CM Plan [2](#scope-of-the-cm-plan)

2.5 CM Plan Synopsis [2](#cm-plan-synopsis)

2.6 Referenced and Architecture Documents
[2](#referenced-and-architecture-documents)

3.0 ORGANIZATION [2](#organization)

3.1 Organizational Structure [2](#organizational-structure)

3.2 Roles and Responsibilities [2](#roles-and-responsibilities)

3.2.1 SE/CM Program Manager [2](#secm-program-manager)

3.2.2 Configuration Management Manager
[2](#configuration-management-manager)

3.2.3 Software Architecture Engineer
[2](#software-architecture-engineer)

3.2.4 Configuration Control Board (CCB)
[2](#configuration-control-board-ccb)

3.2.5 Engineering Review Board (ERB) [2](#engineering-review-board-erb)

3.2.6 Architecture Committee [2](#architecture-committee)

4.0 CONFIGURATION MANAGEMENT ACTIVITIES
[2](#configuration-management-activities)

4.1 TIPSTER CM Approach [2](#tipster-cm-approach)

4.2 Configuration Management Responsibilities
[2](#configuration-management-responsibilities)

4.3 Configuration Management Phasing and Milestones
[2](#configuration-management-phasing-and-milestones)

4.4 Architecture Request For Change Process
[2](#architecture-request-for-change-process)

4.4.1 The Goal [2](#the-goal)

4.4.2 Overview - Submitter/Reviewer [2](#overview---submitterreviewer)

4.4.3 Tracking of RFCs [2](#tracking-of-rfcs)

5.0 GLOSSARY AND LIST OF ABBREVIATIONS
[2](#glossary-and-list-of-abbreviations)

Appendix A TACAD OUTLINE [2](#appendix-a-tacad-outline)

Introduction [2](#introduction)

Purpose of an ERB [2](#purpose-of-an-erb)

Purpose of a TACAD [2](#purpose-of-a-tacad)

Application Overview [2](#application-overview)

A Discussion of Architectural Compliance and Support
[2](#a-discussion-of-architectural-compliance-and-support)

Fully Compliant System Components
[2](#fully-compliant-system-components)

System Components That Extend the Architecture
[2](#system-components-that-extend-the-architecture)

Unrelated Components [2](#unrelated-components)

Detailed Requirements [2](#detailed-requirements)

Suggested Architecture RFCs [2](#suggested-architecture-rfcs)

Summary Discussion [2](#summary-discussion)

Appendix B REQUEST FOR CHANGE [2](#appendix-b-request-for-change)

#  

#   {#section-1 .unnumbered}

# TABLE OF FIGURES

Figure 1-2 TIPSTER Application LifeCycle with Configuration Management
Gates [2](#__RefHeading___Toc414775595)

Figure 2-1 SE/CM Activities Related to Overall TIPSTER Framework
[2](#__RefHeading___Toc414775596)

Figure 3-1 TIPSTER and the CM Support [2](#__RefHeading___Toc414775597)

Figure 3-2 Configuration Management Functional Structure
[2](#__RefHeading___Toc414775598)

Figure 3-3 Organizational Structure of TIPSTER SE/CM Support
[2](#__RefHeading___Toc414775599)

Table 3-1 CM Responsibilities and Relationships
[2](#__RefHeading___Toc414775600)

Figure 3-4 CM Organization [2](#__RefHeading___Toc414775601)

Table 4-1 CM Events and Milestones [2](#__RefHeading___Toc414775602)

# 1.0 EXECUTIVE SUMMARY

This document presents the TIPSTER Text Phase III Configuration
Management (CM) Plan for identifying, controlling, and auditing the
TIPSTER Architecture status and configuration definition.

## 1.1 Configuration Management Goals

The CM process will support the following TIPSTER goals: use of plug and
play, component re-use and conformance to applicable standards.

The CM process will document the conformance of each TIPSTER application
to the Architecture Design Document and with any applicable APIs. The
most important affect of the CM process will be to promote plug and
play, software re-use, and reduced risk of project planning. This will
allow for the orderly upgrading of installed applications as technology
improves in the future. It will also facilitate the sharing of developed
software between Government agencies and offices.

## 1.2 TIPSTER Application Conformance Assessment Document

The CM review process, described in detail below, will result in a
document which details the ways in which an application or vendor
product conforms to the Architecture Design Document and is in agreement
with the TIPSTER Architecture design. This document is a TIPSTER
Application Conformance Assessment Document (TACAD).

In order for an application or vendor product to successfully acquire a
TACAD, the following conditions must be met:

For TIPSTER Application development:

-   The TIPSTER Application complies with the TIPSTER CM process; the
    details are contained in this document. In short, the TIPSTER
    Application must undergo a Preliminary Design Review (PDR) and a
    Final Operating Capability (FOC) review. At these reviews, any
    discrepancy or deviation from the TIPSTER Architecture must be
    documented and justified/explained. For selected applications with a
    short development cycle, only the FOC review may be used.

-   Any new code or capabilities for the TIPSTER Application must be
    developed in accordance with the TIPSTER Architecture. Failure to do
    so will be documented and justified in the TACAD.

-   To the extent possible and in the Government\'s best interest,
    existing code and capability to be incorporated into the TIPSTER
    Application will be re-engineered in accordance with the TIPSTER
    Architecture. Failure to do so will be documented and justified in
    the TACAD.

For Vendor Products:

-   If the vendor\'s product is used in a TIPSTER Application, the
    criteria stated above in \"For TIPSTER Application development\"
    will apply.

-   A vendor\'s product may be determined to be TIPSTER compliant with
    the use of a TACAD independent of actually being part of a TIPSTER
    Application. To support the development of this TACAD, the vendor
    will demonstrate, by inspection, module-by-module compliance with
    the TIPSTER Architecture.

On the basis of the TACAD, the Configurations Control Board (CCB) will
determine that a TIPSTER Application is conformant or non-conformant, if
it exhibits sufficient overlap with the Architecture Design Document.

The extent of TIPSTER Conformance will be determined on a \"per
component\" basis and documented in the TACAD. (Note: a component is
defined in the Architecture Requirements document.) As a result of the
TIPSTER Application reviews (described in section 1.2, below) a summary
matrix will be available as shown in Appendix A.

The TACAD may be used by Vendors to facilitate teaming with other
Vendors or insertions of new capability into existing TIPSTER systems.

## 1.3 Configuration Management in a TIPSTER Application LifeCycle

The TIPSTER CM process imposes two control gates, PDR and FOC, on the
TIPSTER Application development lifecycle, as shown in Figure 1-2. In
preparation for these control gates, it is expected that the developing
contractor and the SE/CM will work together to prepare the documentation
and to identify any discrepancies between the Architecture Design and
the TIPSTER Application\'s design. This cooperation will be in the form
of an Engineering Review Board (ERB).

At the PDR control gate, the following TIPSTER Application documentation
is expected to be put in the TACAD and under TIPSTER CM control:

1\. TIPSTER Application Design Documentation.

2\. Documentation detailing any design discrepancy or deviations from
the TIPSTER Architecture on a per-module basis. This document will also
justify or explain the discrepancy or deviations found.

3\. Any Requests For Change (RFC) to the TIPSTER Architecture to cover
the discrepancy or deviations in the TACAD.

![](media/image1.emf){width="5.985416666666667in"
height="4.804861111111111in"}

Note: For short development cycles only the FOC review may be used

[]{#__RefHeading___Toc414775595 .anchor}Figure 1-2 TIPSTER Application
LifeCycle with Configuration Management Gates

At the FOC control gate, the following are expected to be put in the
TACAD and under TIPSTER CM control:

1\. TIPSTER Application As-Built Documentation.

2\. Documentation detailing any as-built discrepancy or deviations from
the TIPSTER Architecture. This document will also explain the
discrepancy or deviations.

3\. Any Requests For Change (RFC) to the TIPSTER Architecture to cover
the discrepancy or deviations.

It is expected that TIPSTER Applications will require control gates at
the time of design and at the time of final delivery. The TIPSTER PDR
and FOC control gates will \'piggy-back\' on the projects control gates,
to the maximum extent possible.

The Architecture Committee will determine whether a TIPSTER Application
has successfully passed a PDR and FOC control gate ERBs. In practice,
the Architecture Committee will appoint a small group of people to sit
on the Configuration Control Board (CCB) to examine, in detail, the
documentation and justifications provided at the PDR and FOC control
gates. The CCB will then make a recommendation to the Architecture
Committee as to whether or not the control gate has been satisfied. The
specifics of how to run the CCB and the control gates are given in
Section 3.0, below.

The CCB will assign and use an Engineering Review Board (ERB) to compile
the documentation necessary for the CCB\'s review. The ERB will be
comprised of the SE/CM and the developing contractor\'s representatives.
The specifics of how to run the ERB are given in Section 3.0, below.

Discrepancies will originate from the ERB and will primarily be
presented by the developing contractor\'s representatives. The
discrepancies will be submitted to the CCB for disposition, which can be
one of the following:

-   An RFC can be initiated to incorporate the discrepancy as a change
    to the Architecture Design Document.

-   The discrepancy can be \"Noted and Documented\". This would assume
    that it is in the best interest of the Government to deviate from
    the Architecture in this particular case.

-   The discrepancy can be sent back to the developing contractor and
    the Government Contracting Officer\'s Technical Representative
    (COTR) with a request that the discrepancy be cleared up.

# 2.0 BACKGROUND

## 2.1 Need for TIPSTER Configuration Management

Phases I & II of the TIPSTER Text Program, including the Text Retrieval
Conference (TREC) and Message Understanding Conference (MUC) activities,
produced a variety of advanced methods for text handling. However,
incorporating the various algorithms and methods into usable
applications under one TIPSTER Architecture requires close control and
documentation of the constituent parts that comprise the TIPSTER
Architecture. This assumption is based on the following points:

-   The detection and extraction systems were not developed to work
    together, although many important text processing tasks require
    interaction between detection and extraction technologies.

-   Applications produced under Phases I & II have not been completely
    tested against the variety of tasks and natural languages that must
    be handled.

-   The Government cannot treat every application requirement for
    natural language processing as a separate system; deployable systems
    must be flexible enough to handle a variety of tasks and languages
    with only minor modifications.

-   Existing systems at both a component and module level implement
    similar functionality very differently. Standardizing on the
    Architecture and interfaces of a core set of such components and
    modules, so that they can be reused in many applications on many
    platforms, was the purpose of the TIPSTER Program. Text processing
    applications can have standard interfaces to operate with these core
    functions. This functional modularization will support the
    interoperability and flexibility that the Government believes is
    necessary to handle the variety and breadth of its text processing
    tasks. It will also reduce acquisition and maintenance costs and
    allow for the orderly expansion of an application\'s capability once
    deployed. Finally, functional modularization will support and
    advance the research community by making available a standardized,
    basic text handling architecture; no longer will an architecture
    have to be invented for every new experiment.

## 2.2 SE/CM Role Within the Overall TIPSTER Framework

The TIPSTER SE/CM effort involves supporting the Government in
overseeing the development of an open architecture and integration of
components and modules for comprehensive text handling capabilities.
This will allow processing of character streams and text databases from
many disparate sources through content detection and data base or
knowledge base update. In addition, tools and interfaces for configuring
architecture components to particular applications must be integrated
and managed.

Key issues in the development of the architecture requirements are
defining the functions to be performed, the specific requirements of
components and modules to perform each such function, particularly their
input, output, and interface specifications, and also specifying an open
architecture for integrating all components and modules. Key issues in
the development of the Architecture itself are standardizing,
documenting, and disseminating the component functional and interface
specifications.

The role of the SE/CM contractor is best understood within the context
of the overall TIPSTER framework. This framework includes three separate
but interrelated set of activities: the SE/CM effort; the Architecture
efforts; and the Demonstration Activities. Figure 2-1 depicts the
respective functions of each activity set, and their interrelationships.
The figure highlights the communications between SE/CM and the other
activities, which will typically be in the form of architecture
component requirements or description documents, and completed software
modules.

![](media/image1.emf){width="6.457638888888889in"
height="3.527083333333333in"}

[]{#__RefHeading___Toc414775596 .anchor}Figure 2-1 SE/CM Activities
Related to Overall TIPSTER Framework

Initially, the architecture requirements were defined from the existing
TIPSTER I & II requirements, with the addition of requirements for
integrating the most promising algorithms from that effort. The SE/CM
will assist the Government in evaluating architecture proposed by
TIPSTER contractors. When demonstration prototypes are initiated, their
requirements must be analyzed to determine the adequacy of the existing
architecture, and to define necessary or desirable enhancements.

Throughout this iterative process, the SE/CM will perform configuration
identification activities including configuration definition,
establishment of the Architecture baseline, review of applicable
documentation and processing of Architectural changes. These activities
will occur throughout the refinement effort and life of the
Architecture. The SE/CM will work with the senior technical designers
and engineers from all of the TIPSTER teams to identify the
Configuration Items (CIs). CM is responsible for gathering, storing, and
presenting the current status of each configuration item.

## 2.3 Purpose of the CM Plan

The purpose of this plan is to establish guidelines, responsibilities,
methods and procedures for CM for the TIPSTER Architecture. Specific
procedures for CM are in related Configuration Management Procedures
(CMPs). CM is intended to provide a stable and consistent definition of
the TIPSTER Architecture.

## 2.4 Scope of the CM Plan

The scope of this plan encompasses anything related to the TIPSTER
Architecture. As such, CM will be in effect during the life of the
Architecture and will be primarily concerned with the documentation
which describes the Architecture. It will not be applied to the software
produced by the developers; CM for that software is the responsibility
of the individual contractor.

The CM process is expected to become active at such time as the first
Architecture baseline is established and CM will remain active
throughout the life of the Architecture.

The CM process will monitor and control changes to the Architecture.
Normally, changes to the baseline will be initiated when a TIPSTER
Application has been designed and the PDR identifies potential
deficiencies in the Architecture.

Request For Changes (RFC) will go through the CM process and ultimately
be approved by the Architecture Committee.

It is expected that the TIPSTER Architecture will continuously be
undergoing growth and change. It is therefore vital that the CM process
be able to reconstruct the exact state of the TIPSTER Architecture at
any given date in the past.

Changes are categorized as either Class I, which is a change to the
current Architecture baseline, or Class II, which is all other changes,
such as correction of document typographical errors, resolution of
ambiguities, and changes that clearly do not qualify as a Class I.
Deviations are defined as discrepancies wherein an application does not
conform to the particular Architectural standard.

## 2.5 CM Plan Synopsis

In addition to what was already noted in Section 1.2, this CM Plan
defines the configuration management activities and philosophy required
to support the TIPSTER Architecture throughout its entire life cycle. CM
provides a means to identify, control, audit, and report on the
configuration and status of the TIPSTER Architecture.

The remaining sections of this document provide information to effect
quality change and release controls for TIPSTER:

-   Section 2.0 lists the referenced documents and the documents under
    CM which in turn define the Architecture at any time.

-   Section 3.0 describes the relevant SE/CM configuration organizations
    for TIPSTER. It also describes the CM roles and responsibilities of
    other program entities.

-   Section 4.0 describes the general approach to CM, CM
    responsibilities, and CM Phasing and Milestones.

-   Section 5.0 has a glossary of all acronyms and abbreviations used in
    this CM Plan.

## 2.6 Referenced and Architecture Documents

The following documents were referenced in preparing this document.

-   Military Standard, Configuration Management, MIL-STD-973, 1 December
    1992

-   Configuration Management Manual, Software Engineering Guideline, May
    1993, PRC, Inc.

The documents which have been placed under CM are:

-   TIPSTER Architecture Concept

-   TIPSTER Requirements Document

-   TIPSTER Architecture Design Document

-   

-   TIPSTER CM Plan

# 3.0 ORGANIZATION

The structure, roles and responsibilities of the Configuration
Management organization are defined in the paragraphs below.

## 3.1 Organizational Structure

The TIPSTER SE/CM project employs a Configuration Management
organization to establish CM procedures, oversee the application of
these procedures by all team members and provide all necessary reports
and support for the CM function. Figure 3-1, identifies the relationship
of the SE/CM support function with other TIPSTER components. This
complex structure consists of the multi-agency Executive Committee and
Architecture Committee, architecture contractors, demonstration and
project development contractors, and the SE/CM contractor. Figure 3-2
illustrates the functional structure of the CM organization.

[]{#__RefHeading___Toc414775597 .anchor}Figure 3-1 TIPSTER and the CM
Support

![](media/image1.emf){width="6.221527777777778in"
height="2.888888888888889in"}

[]{#__RefHeading___Toc414775598 .anchor}Figure 3-2 Configuration
Management Functional Structure

## 3.2 Roles and Responsibilities

The following paragraphs describe the roles and responsibilities of each
project element involved in the CM function. Figure 3-3 illustrates the
organizational structure of the SE/CM organization.

![](media/image1.emf){width="5.915972222222222in"
height="2.8881944444444443in"}

[]{#__RefHeading___Toc414775599 .anchor}Figure 3-3 Organizational
Structure of TIPSTER SE/CM Support

### 3.2.1 SE/CM Program Manager

The Program Manager (PM) assists the Chair of the Architecture Committee
in meeting the objectives of the TIPSTER Architecture with respect to
requirements definition, coordination of disparate contractors and
approaches, and supervision of the configuration management efforts.
Compliance with the guidelines and procedures specified in this plan is
the primary responsibility of the program manager along with the CM
Manager (CMM). The PM is responsible for approving the tailoring of CM
policies, practices, and procedures to ensure that adequate methods are
implemented for identification and control of the TIPSTER Architecture.

The Program Manager ensures that:

-   Adequate CM resources, including CM tools, are made available.

-   CM plans and procedures are approved by the Architecture Committee
    Chair.

-   Documented and approved CM practices and procedures are followed by
    all team members.

-   CM personnel are trained in the objectives, procedures, and methods
    for performing their assigned CM activities.

-   CM requirements, processes, and practices are conveyed to all
    TIPSTER team members for compliance.

### 3.2.2 Configuration Management Manager

The CM Manager (CMM) will report to the TIPSTER SE/CM Program Manager.
The CMM is responsible for (a) implementing a CM system which is
tailored for the unique features of the TIPSTER Program and (b)
developing CM procedures to assure control of documentation. To support
the preparation of configuration status reports, the CMM maintains a
database containing the change status of all Architecture elements and
changes.

To assure the integrity of all items placed within CM control, the CMM
establishes and maintains both electronic and hard copy libraries with
access limited to CM personnel. The CMM acts as the point of contact for
receiving and processing information from external organizations.
Incoming and outgoing shipments of CM controlled items will be handled
by the CMM. The CMM is also responsible for performing and supporting
both formal and informal audits conducted at appropriate milestones
during the Architecture life cycle.

The CMM is a regular participant in all ERB and CCB meetings. The role
of the CMM is to schedule these meetings, provide an agenda, record and
disseminate minutes, and track action items.

The CMM, in performing the foregoing responsibilities, will have the
independence and authority to coordinate and communicate CM functions
with management and technical personnel involved in the Architecture
effort. All management and technical personnel are required to be
familiar with and comply with the provisions of this CM plan, as well as
being responsible for certain configuration activities in support of CM
functions. The following Table 3-1, CM Responsibilities and
Relationships, is a matrix of the major CM functions and
responsibilities of various management and technical personnel.

![](media/image1.emf){width="5.874305555555556in"
height="4.916666666666667in"}

[]{#__RefHeading___Toc414775600 .anchor}Table 3-1 CM Responsibilities
and Relationships

### 3.2.3 Software Architecture Engineer

A software architecture engineer will assist the Architecture Committee
Chair by performing certain CM tasks. These tasks consist of
reviewing/analyzing problem reports and change requests, and preparing
recommendations to effect proposed changes or preparing a statement why
the proposed change should not be made to the Architecture.

### 3.2.4 Configuration Control Board (CCB)

The CCB is the Government review and action board comprised of key
personnel from the Architecture Committee, SE/CM, and the appropriate
contractors. The CCB provides a central point of coordination of changes
to the baseline Architecture. The CCB is the focal point and the source
of direction for implementation of Class I changes to the TIPSTER
Architecture.

The CCB reviews each Class I change and makes a decision as to the
disposition with the options of (a) approve the change, (b) disapprove
the change, or (c) defer the proposed change. Each board member is
allowed to state his/her official position on the proposed change.
However, the CCB is a non-voting board. Thus, the CCB Chairman shall
render the final decision as to the course of action to the taken. The
CCB\'s decision is recorded as a Change Directive.

The CCB\'s major responsibilities are:

-   Review all proposed change requests.

-   Assess change impacts.

-   Provide a statement that the application development which initiated
    a change is in compliance with the Architecture or represents a
    deviation from the Architecture.

-   Review modifications to all documentation .

-   The results of any actions taken by the CCB are reported to the
    Architecture Committee.

The membership of the CCB is:

-   Architecture Committee Chair (CCB Chair)

-   First Government Representative (Member)

-   Second Government Representative (Member)

-   Third Government Representative (Member)

-   TIPSTER DARPA PM (Guest Member)

-   SE/CM Project Manager (Advisor)

-   SE/CM Configuration Management Manager (Secretary)

-   Software Architecture Engineer (Advisor)

Other key personnel will be assigned to the CCB as the Chair may deem
necessary to resolve particular issues. The CCB Chair will conduct the
meeting and render the final decision to the course of action to be
taken.

The above members form the core of the CCB. If a member is unable to
attend a meeting, he/she must designate a representative to attend in
his/her place. The representative must have full authority to act on
behalf of the missing member. Additional individuals are invited to
participate, as appropriate, when their technical expertise is required.

### 3.2.5 Engineering Review Board (ERB)

The ERB is an internal TIPSTER Architecture review and action panel
comprised of personnel from all project groups. Membership of the ERB
is:

-   SE/CM Program Manager (Chair)

-   The TIPSTER Application Contracting Officer\'s Technical
    Representative (COTR)

-   Supporting Agency-Specific Representative (TIPSTER expertise)

-   CM Manager (Secretary)

-   Contractor Group Representative(s) (Member)

-   Software Architecture Engineer (Member)

The objectives of the ERB are disposition of problems, classification of
proposed changes, and disposition of Class II changes. Upon receipt and
disposition of a problem, the ERB will analyze it for type of problem,
priority, and verification of the proposed solution. When the problem is
fixed, the ERB will determine the implementation schedule of the fix
into the affected baselines. Upon review of a change request, the ERB
first determines the classification as either a Class I or Class II type
of change. For Class I changes, the ERB assigns preparation of a Request
For Change (RFC) to the responsible groups for submittal to the CCB for
their review and disposition. Class II changes are within the scope of
authority of the ERB for disposition. The ERB reviews each Class II
change and then takes appropriate action for its disposition. Each panel
member is allowed to state his/her position on the change. However, the
ERB is a non-voting board. Thus, the ERB chairman shall render final
decision as to the course of action to be taken. ERB decisions are
recorded on Change Directives, a copy of which is sent to the CCB for
information only.

### 3.2.6 Architecture Committee

The Architecture Committee has final authority over the TIPSTER
Architecture and in this role can accept or reject any Change Directive
reported by the CCB.

The Architecture Committee appoints the members of the CCB.

[]{#__RefHeading___Toc414775601 .anchor}Figure 3-4 CM Organization

# 4.0 CONFIGURATION MANAGEMENT ACTIVITIES

## 4.1 TIPSTER CM Approach

The CM organization is responsible for identifying the specific items
that define the Architecture and will be configuration controlled, as
well as when and how they are to be controlled. CM conducts audits of
the Architecture baseline to ensure conformance with the TIPSTER concept
and to verify that the configuration management library system is
functioning adequately.

## 4.2 Configuration Management Responsibilities

TIPSTER\'s CM responsibilities comprise baseline management, interface
control, and the CM aspects of quality control in each of the following
six areas which operate throughout the Architecture\'s life cycle:

-   Item and baseline identification and management

-   Configuration control

-   Configuration status accounting (CSA)

-   Configuration audits

-   Architecture file maintenance

-   Architecture delivery

In the area of item and baseline identification and management,
configuration management is responsible for baseline traceability and
integrity by retention of all versions and releases of Architecture
elements.

As stated in Section 1, once an element is part of the baseline, it is
placed under change control. In this area, configuration management has
many responsibilities. These include administrative handling of all
changes, from initial receipt and logging of Change Requests through
issuance of Change Directives indicating final disposition.
Configuration management prepares, publishes, and incorporates the
change pages in the defining documentation. Configuration management
personnel also act as the recording secretary for the two project change
review organizations: the Engineering Review Board (ERB) and the
Configuration Control Board (CCB).

Configuration management has this status accounting responsibility where
in monthly status reports for changes, problems, and action items are
reported.

Architecture files contain all written materials and documentation on
the TIPSTER Architecture. This critical area is the responsibility of
configuration management.

Finally, configuration management is responsible for formal delivery of
all TIPSTER Architecture defining documents to the Government.

## 4.3 Configuration Management Phasing and Milestones

The CM activities described in this CM Plan are initiated and completed
in accordance with the Program Master Schedule. Table 4-1 is a list of
major events/milestones and specifies the CM activities conducted and
the planned dates for initiation and completion of each event/milestone.

+---------------+--------------------------------+----------+----------+
| **Events      | **CM Activities**              | **Start  | **Finish |
| /Milestones** |                                | Date**   | Date**   |
+---------------+--------------------------------+----------+----------+
| Requirements  | Initiate status accounting for | 00/00/00 | 00/00/00 |
| Definition    | action items,                  |          |          |
|               |                                |          |          |
|               | Establish project files        |          |          |
+---------------+--------------------------------+----------+----------+
| Commence      | Establish Architecture         |          |          |
| Configuration | Baseline, Initiate change      |          |          |
| Management    | control, Initiate \"Version    |          |          |
|               | Description Document\"         |          |          |
|               | Initiate status accounting for |          |          |
|               | changes, and continue Action   |          |          |
|               | Items. Maintain project files  |          |          |
+---------------+--------------------------------+----------+----------+
| CM Setup      | Identify Configuration Items,  |          |          |
|               | Continue change control,       |          |          |
|               | Continue status accounting for |          |          |
|               | changes and action items,      |          |          |
|               | Maintain project files,        |          |          |
|               | Deliver architecture documents |          |          |
+---------------+--------------------------------+----------+----------+
| Preliminary   | Process changes, identify      |          |          |
| Design Review | Architectural Deviations,      |          |          |
| (PDR)         | Continue change control,       |          |          |
|               | Update \"Version Description   |          |          |
|               | Document\", Continue status    |          |          |
|               | accounting for changes and     |          |          |
|               | Action Items, Maintain project |          |          |
|               | files                          |          |          |
+---------------+--------------------------------+----------+----------+
| Final         | Issue Architecture Deviation   |          |          |
| Operating     | Document Continue change       |          |          |
| Capability    | control, Update \"Version      |          |          |
| (FOC)         | Description Document\",        |          |          |
|               | Continue status accounting for |          |          |
|               | changes and action items,      |          |          |
|               | Maintain project files,        |          |          |
+---------------+--------------------------------+----------+----------+

[]{#__RefHeading___Toc414775602 .anchor}Table 4-1 CM Events and
Milestones

## 4.4 Architecture Request For Change Process

### 4.4.1 The Goal

The SE/CM has five major goals with respect to the RFC process for the
TIPSTER Architecture. They are as follows:

-   Provide for consistency in the development of the Architecture.

-   Allow for changes, proposed on the basis of different versions of
    the Architecture, to be combined into a single change.

-   Provide for consideration of changes proposed by any interested
    party.

-   Encourage changes to the Architecture from anyone who has done an
    implementation.

-   Provide for independent submission and review of proposed changes.

### 4.4.2 Overview - Submitter/Reviewer

Submissions of RFCs can come from any source. It is expected that
submissions will be made by application developers, the CAWG, TWGs or
the SE/CM.

#### 4.4.2.1Application Developer Submission

Submissions from applications developers will be reviewed by the SE/CM
and approved/disapproved by the Architecture Committee. As reviewer, the
SE/CM will recommend minor modifications to the RFC to maintain a level
of consistency in names and methods. If major modifications are
necessary, the SE/CM may submit an entirely new RFC. The Architecture
Committee will then have both RFCs to approve/disapprove.

The CAWG will be able to evaluate the proposed changes and make
suggestions to the SE/CM or the Architecture Committee. Any
comments/recommendations by the CAWG will be an addendum to the formal
RFC.

As a minimum, the CAWG will receive the RFC when it is formally
submitted to the SE/CM. Under normal circumstances, however, the SE/CM
will be aware that changes are likely to be forthcoming from an
application under development. In such cases, the SE/CM will keep the
CAWG informed of the issue under discussion. In this way, the CAWG may
be able to provide timely input to the application developer as to
previously debated issues or \'known\' work-arounds for the difficulty
encountered.

#### 4.4.2.2 CAWG Submission

Submissions from the CAWG will be reviewed by the SE/CM and
approved/disapproved by the Architecture Committee. As reviewer, the
SE/CM may recommend minor modifications to the RFC to maintain a level
of consistency in names and methods.

#### 4.4.2.3 SE/CM Submission

On rare occasions, submissions may come from the SE/CM and will be
reviewed by the CAWG or other person(s) as designated by the
Architecture Committee and approved/disapproved by the Architecture
Committee. The reviewer may recommend minor modifications to the RFC to
maintain a level of consistency in names and methods.

If the reviewer is not the CAWG, the SE/CM will keep the CAWG informed
of the issue under discussion. In this way, the CAWG will be able to
provide comments and recommendations to the Architecture Committee.

### 4.4.3 Tracking of RFCs

RFCs will be formally tracked by their RFC number. The RFC will contain
the following:

-   Status/Routing Sheet

-   Submission Form

-   Review Sheet

-   CAWG Comments or Recommendations

-   Any Relevant Material Such as Email Traffic

The RFCs will be available on the internet on the TIPSTER web page

.

# 5.0 GLOSSARY AND LIST OF ABBREVIATIONS

The terms and abbreviations listed below are used within this CM Plan.
Their meanings are provided for the reader\'s convenience.

  ------------ ----------------------------------------------------------
  API          Application Program Interface

  AWG          Architecture Working Group

  CCB          Configuration Control Board

  CI           Configuration Item

  CM           Configuration Management

  CMM          Configuration Management Manager

  COTR         Contracting Officer's Technical Representative

  CSA          Configuration Status Accounting

  CSCI         Computer Software Configuration Item

  DARPA        Defense Advanced Research Projects Agency

  ERB          Engineering Review Board

  FCA          Functional Configuration Audit

  FOC          Final Operating Capability

  MET          Multilingul Entity Task

  MUC          Message Understanding Conference

  PCA          Physical Configuration Audit

  PDR          Preliminary Design Review

  PM           Program Manager

  PO           Program Office

  QA           Quality Assurance

  RFC          Request For Change

  SE           Systems Engineering

  SEC          Summarization Evaluation Conference

  SE/CM        Systems Engineering/Configuration Management

  TACAD        TIPSTER Application Conformance Assessment Document

  TBD          To Be Decided

  TREC         Text Retrieval Conference

  TWG          Technical Working Group
  ------------ ----------------------------------------------------------

#  

#  

# Appendix A TACAD OUTLINE

*This appendix includes an annotated outline of a TACAD. It should help
explain the purpose of an ERB and provide an idea of the documented
outcome. Text in italics is commentary; text in plain typeface is
suggested for inclusion in the TACAD itself.*

# Introduction

The TIPSTER Architecture provides an environment and guidelines to
facilitate the development of text processing applications. The
applications may include components for any combination of document
detection, text extraction, and summarization technology.

Part of the process in evaluating how compliant an application is with
the TIPSTER Architecture is an application review by an Engineering
Review Board (ERB). The result of an ERB is contained in a TIPSTER
Architecture Compliance Assessment Document (TACAD).

## Purpose of an ERB

An ERB provides a forum for discussing the degree to which the
Architecture supports a particular application, and the degree to which
an application draws on the Architecture to achieve its goals. It can be
used to validate that an application is TIPSTER-compliant when that is a
requirement for the application. It is also extremely valuable as an
evaluation of the Architecture itself, to help determine if the
Architecture is meeting *its* goals and to identify improvements that
should be suggested to it. An ERB does *not* consider any other
qualities of an application (e.g., whether it satisfies its customers'
goals).

In general, ERBs are conducted at two times during application
development. An initial ERB is conducted shortly after an application\'s
Preliminary Design Review (PDR) and a final ERB is conducted after the
application\'s Final Operating Capability (FOC) is established. This
provides for an \"As-Designed\" and an \"As-Built\" look at the
application.

The initial ERB identifies:

> \(a\) which components of the application are fully compliant with the
> Architecture;
>
> \(b\) which components of the application have difficulty complying
> with the Architecture and what changes to the Architecture might be
> made to improve the Architecture and enhance application compliance;
> and,
>
> \(c\) which components of the application are unrelated to the
> Architecture.

A potential Architectural change identified in (b) is reflected in a
TIPSTER Architecture Request for Change (RFC). RFCs go through a defined
Configuration Management (CM) technical review and approval process.

The final ERB examines an application to determine its final level of
Architectural compliance. Consideration is given to the initial ERB and
the inclusion of approved RFCs in the FOC version of the application.

It is not the purpose of the ERB to evaluate any other aspects of the
application.

## Purpose of a TACAD

A TACAD is the end product of an ERB. As such, it documents the level of
Architectural compliance of an application. Architectural discrepancies
and deviations are also documented and serve as the basis for RFCs.

The remainder of this document is organized as follows. Section 2
provides an overview of the application. Section 3 discusses how the
application aligns with the TIPSTER Architecture. Section 4 collects
suggestions on possible modifications to the Architecture based on the
experiences of building the application. Section 5 presents a summary. A
detailed comparison of system requirements with Architectural features
is included in the appendix.

# Application Overview

This section presents an overview of the application under review. It is
intended to give a reader unfamiliar with the application enough insight
into its purpose and design to understand the subsequent discussions.
For most applications, the purpose will be described by a flow diagram
and page or two of description, while the design will be described by a
block diagram of the architecture and descriptions of modules at the CSC
level.

# A Discussion of Architectural Compliance and Support

As previously mentioned in Section 1.1, the requirements are categorized
into three parts, depending upon their degree of Architectural
compliance. These are

> \(a\) which components of the application are fully compliant with the
> Architecture;
>
> \(b\) which components of the application have difficulty complying
> with the Architecture and what changes to the Architecture might be
> made to improve the Architecture and enhance application compliance;
> and,
>
> \(c\) which components of the application are unrelated to the
> Architecture.

The following subsections provide additional details of the various
categories mentioned above.

## Fully Compliant System Components

This section lists which components are fully compliant with the
Architecture and provides any additional relevant comments.

## System Components That Extend the Architecture

*This section lists which components are related to the Architecture,
how they are related, and suggests the impact of including them in the
Architecture.*

## Unrelated Components

This section lists and comments on the remaining components of the
system and describes why they are unrelated to the Architecture.

## Detailed Requirements

Appendix A contains a listing of all the system requirements and
categorizes them according to the level of support afforded to them by
the Architecture.

# Suggested Architecture RFCs

This section provides suggestions of changes to the Architecture that
could be submitted as future RFCs to the Architecture Committee.

The Architecture Committee would welcome RFCs submitted to address these
issues.

# Summary Discussion

*This section summarizes the document, including a summary assessment of
compliance and the insights into the Architecture provided by the
implementation and analysis of the system.*

**Appendix A: Detailed Requirements Categorization**

The following requirements, organized by the total application and
individual components, identify the scope of the application. For each
requirement it is noted whether the Architecture provides no support,
partial support, or full support.

  -----------------------------------------------------------------------------------------------
  **No**.   **Description**                            **Architectural                 
                                                       Support**                       
  --------- ------------------------------------------ ----------------- ------------- ----------
                                                       **None**          **Partial**   **Full**

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

                                                                                       

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

# Appendix B REQUEST FOR CHANGE

**TIPSTER ARCHITECTURE**

**REQUEST FOR CHANGE (RFC) FORM**

**Title:** **Page 1 of** \_\_\_\_\_\_\_\_

**Date Prepared:** **Date Needed:** **CR No:**

**Priority:**\_\_\_URGENT \_\_\_ROUTINE **Date Logged:**

**Document Affected:** **Cross References:**

Design\_\_\_ Req.\_\_\_ Concept\_\_\_ CM Plan\_\_\_

**Document Version:**

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

**Paragraphs Affected:**

**References:**

**Change Required:**

**Specific Recommendation:**

**Reason for Proposed Change:**

**Submitter Name:**

**Organization**[:]{.underline} **Title:**

**Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Phone
Number**[:]{.underline}

**Reviewer Name:**

**Organization** **Title:**

**Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Phone
Number**[:]{.underline}

**AC Change Approval: Name:**

**Date: Title:**

**TIPSTER Architecture**

Request FOR CHANGE (RFC) Form Instructions

  ---------------- ---------------------------------------- --------------------
  **Field**        **Instructions**                         **Responsibility**

  Title            Enter short (10 words or less),          Submitter
                   descriptive title for the Change         
                   Request.                                 

  Page 1 of        Enter total number of pages, including   CM
                   any supporting information and this      
                   form.                                    

  Date Prepared    Enter date requestor prepares CR,        Submitter
                   including all attachments.               

  Need Date        Enter date by which decision must be     Submitter
                   received by the requestor to avoid any   
                   or additional impact.                    

  Priority         Check appropriate selection. A CR is     Submitter
                   urgent if work cannot proceed without a  
                   decision on the request.                 

  Document         Check all documents affected by the      Submitter
  Affected         requested change                         

  Version Affected Enter the version number of the above    Submitter
                   document.                                

  Paragraph        Enter the paragraph numbers requiring    Submitter
  Affected         change. Indicate document by D, R, C, or 
                   P                                        

  Reference        Specify reference document(s), such as   Submitter
                   meeting minutes, from which the CR was   
                   initiated. If not applicable, enter N/A. 

  CR No.           Assign Change Request number in the form CM
                   of NNNNN where NNNNN is the sequence     
                   number.                                  

  Date Logged      Enter date CR is received by CM.         CM

  Cross References Internal CM use, 3 lines                 CM

  Change Required  Describe in detail [what]{.underline}    Requestor
                   change(s) is (are) required. The \"how\" 
                   of the change is covered under the next  
                   item.                                    

  Specific         Attach redlined pages from the affected  Requestor
  Recommendation   documents. Redlines must be clear,       
                   precise, and all-inclusive. Specify how  
                   the change is to be made, as applicable. 
                   For example, if an ICD module            
                   specifications is requested to be        
                   changed, the appropriate pages from the  
                   ICD would be attached and redlined with  
                   the proposed change. If the change would 
                   cause other changes, those pages must    
                   also be attached and redlined.           

  Reason for       Provide justification, in detail, for    Requestor
  Proposed Change  the proposed change. Include alternative 
                   solutions, if available, and impact if   
                   change is not implemented.               

  Subnitter        Enter organization, requestor name,      Requestor
                   title and date                           

  Reviewer         Enter name, title and date of reviewing  CM
                   official, normally SE/CM unless          
                   submitted by SE/CM; then appointed by AC 

  AC Change        Enter name, title and date of approving  AC Chairperson
  Approval         official                                 
  ---------------- ---------------------------------------- --------------------