TIPSTER Text Phase II Configuration Management Plan 
Version 1.2p 3June 1996 
Architecture Committee 
tipster@tipster.org 
1.0 EXECUTIVE SUMMARY 
This document presents the TIPSTER Text Phase II 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 API's, modular substitution, 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 modular substitution, 
software re-use, and reduced risk of project planning. This will allow for the orderly upgrading of installed systems 
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 development complies with the TIPSTER CM process, the details which 
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. 
• 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 module" basis and documented in the TACAD. 
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, Figure A-I, below. 
345 
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. 
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. 
346 
Fee \] 
AC 
B 
System i System t System System l lnitiation Design Implementation O & M 
Preliminary Final Design Operating 
Review Capability Review 
TIPSTER Program 
Can Provide 
Architecture Design 
and Specifications 
TIPSTER Program 
Can Support the 
Integration of New 
Technology and 
Algorithms 
Figure 1-2 TIPSTER Application LifeCycle with Configuration Management Gates 
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. 
347 
• 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. 
348 
2.0 BACKGROUND 
2.1 Need for TIPSTER Configuration Management 
Phase I 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 II 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 Phase I have not been 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, is the purpose of the 
TIPSTER Text Phase II Program. Specialized functions 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 II 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 module 
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. 
349 
  rchitecture Rqmts"~ Definition ..) 
. B -- 
SE/CM m./f V&V Common~'~-~"~ .... 
fArchitecture Rqmts'~ ~ Modules* J I I=.TTOr'\[ 
Definition J *If Applicable ("-C M Common~ 
L Module,~. J 
_ Demonstration Demonstration Prototype Implementation 
,..)-- Activities 
Figure 2-1 SE/CM Activities Related to Overall TIPSTER Framework 
Initially, the architecture requirements will be defined from the existing TIPSTER I requirements, with the addition 
of requirements for integrating the most promising algorithms from that effort. The SE/CM will assist the 
Government in evaluating architectures proposed by TIPSTER II contractors. Later, as 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 II 
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 Text Phase II 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 an TIPSTER Application has been designed and the PDR identifies potential deficiencies in the 
Architecture. 
350 
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 Text Phase II 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 II: 
• 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 II. 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 CM Documents 
The following documents were referenced in preparing this document. 
• TIPSTER Configuration Management Procedure, CMP-I: Configuration Identification, TBD, PRC, 
Inc. 
• TIPSTER Configuration Management Procedure, CMP-2: Change Control, TBD, PRC, Inc. 
• TIPSTER Configuration Management Procedure, CMP-3: Configuration Auditing, TBD, PRC, Inc. 
• TIPSTER Configuration Management Procedure, CMP-4: Configuration Status Accounting, TBD, 
PRC, Inc. 
• Military Standard, Configuration Management, MIL-STD-973, 1 December 1992 
• Configuration Management Manual, Software Engineering Guideline, May 1993, PRC, Inc. 
The documents which will be placed under CM are: 
• TIPSTER Requirements Document 
• TIPSTER Architecture Design Document 
• TIPSTER Architecture Interface Control Document 
• TIPSTER Architecture Concept 
• TIPSTER CM Plan 
• TIPSTER Validation and Verification Plan 
• TACAD 
351 

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 II 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. The overall TIPSTER Text Phase II program organization, depicted in 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 
prototype development contractors, COTRs and the SE/CM contractor. Figure 3-2 illustrates the functional 
structure of the CM organization. 
\[ Executive \[ \[ Committee \[ 
Dr~qs~ \] cA°r~~tt~e \] I SE/CM I 
L~.J~ ~ \[ I Contractor I 
DraftDesign~ \ I Architecture I I I N \ \[ Working Group I 
Integrated De~ ~'~/~"~'~...~J~\] 
W°rk~"~ '~"/~"-L~J~'--M- t r~--t ....... ~ ~"11 ~ Draft ; * *r--~u'q~ '~---~L~n~Jd \[R&D Project 7 ~J Architecture Architecture 
i R&D Project~- t~===~lates ~ ~ L~._.l-~ates 
I~,o ~ro~ec~ °r ,~o V ,,~o , Lo hero "%°o I~'° ~ro~eo, ~l I ~ro~o' ~ll~ro~eo~ ~1 I ~o~ec' ~11 ~ro~c~ '1 I~ro~e~' ~1 
Figure 3-1 TIPSTER Text Phase II Organization 
353 
cM I Manager 
Identify Configuration 
Items 
\[ Control Configuation 
Changes 
I I 
I Documentation 
ii sta'us' \[ Report on Changes Conduct & Support Audits I i i CCB & ERB 
I I I I ° are I I'n'or  'll For a' I 
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. 
I Academic Text Handling Authority 
~.y..ste.~_ E n_Ln e e r_i n g 
I 
Software Architecture 
Engineer 
I 
t 
Ted I Handling 
Expert 
Program Manager 
Program Associate I 
Configur_.~tion Management 
I I 
Configuration Management 
Manager 
Validation and 
Verification Testing Engineer 
Figure 3-3 Organizational Structure of TIPSTER II SE/CM Support 
354 
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 and Demonstration programs, with respect to requirements definition, coordination of 
disparate contractors and approaches, and supervision of the configuration management and verification/validation 
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 Text Phase II 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. 
355 
Program Configuration 
Managment Functions/ 
Responsibilities 
Baselines: Functional 
Allocated 
Development 
Product 
Configuration Identification 
Change Requests 
Client 
Program 
Office (PO) 
Approve, 
Control & 
Review 
Approve, 
Control & 
Review 
Approve & 
Review 
Approve, 
Control & 
Review 
Control 
Control 
PM 
Monitor 
Monitor 
Establish & 
Manage 
Monitor 
Submit to 
Client PO 
Submit to 
Client PO 
Site Responsibilities 
Technical 
Manager 
Comply 
Comply 
Comply 
Comply 
Review 
Inputs 
Originate 
Subcontractors 
Comply 
Comply 
Comply 
Comply 
Provide 
Inputs 
Provide 
Inputs 
CMM Technical 
Staff 
Administer! Comply 
Administer Comply 
Administer Comply 
Administer Comply 
Perform Provide 
Inputs 
Administer Provide 
Inputs 
Administer Prepare 
Documents 
Manage Provide 
Inputs 
Implement Approved Control Manage Perform Support Perform Perform 
Changes I 
Program Change Control Review Chair Member : Administer Attend ! Attend 
Panel i 
Configuration Library Review Review Support Manage Support Support 
Review & 
Approve 
Review 
Review 
Review 
Reports 
Documents/Deliverables 
Status Accounting 
Submit to 
Client PO 
Review 
Reports 
Prepare 
Documents 
Provide 
Inputs 
Configuration Reviews & Review ' Chair Prepare Administer Provide Provide 
Audits Inputs Inputs 
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 Verification and Validation Testing Engineer 
The Verification and Validation (V&V) Testing Engineer will develop and implement tests to determine if modules 
in TIPSTER Applications are consistent with the Architecture Design Document by ensuring that they conform to 
the specifics in the Architecture Design Document. 
Additionally, if necessary, the V&V Test Engineer will determine that shared components and modules interface as 
required, both in isolation and in combination with the other components and modules. Specifically, the interfaces 
must be as described in the TIPSTER Interface Control Document. Internal component processing capabilities do 
not come under the scope of V& V Testing. (See V&V Test Plan). The V&V Testing Engineer controls formal 
CSCI test procedure development prior to those components being placed under formal CM control, reports 
problems identified during formal CSCI testing to CM, and actively participates in ERB and CCB meetings. 
3.2.5 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 
356 
baseline Architecture. The CCB is the focal point and the source of direction for implementation of Class I changes 
to the TIPSTER II 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) 
• DIA Representative (Member) 
• NSA Representative (Member) 
• CIA Representative (Member) 
• TIPSTER ARPA 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.6 Engineering Review Board (ERB) 
The ERB is an internal TIPSTER II 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 
357 
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.7 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. 
Architecture 
Committee 
Architecture 
Working Group 
Configuration 
Control Board 
Engineering \[ 
Review Board 
I Project I Control Panel 
Figure 3-4 CM Organization 
3.2.8 Architecture Working Group (AWG) 
Since the CM function does not start until the Architecture baseline has been released by the Architecture Working 
Group (AWG), it will have no CM responsibility. 
3.2.9 Evaluation Working Group 
The TIPSTER Phase II evaluation working group (EWG) is tasked with designing, implementing, and coordinating 
evaluations intended to demonstrate the effectiveness of TIPSTER architectural approaches; thus, the EWG will be a 
user of the results of the CM process by using the appropriate Architectural version in their evaluations. 
The membership of the EWG is composed of the following core personnel: 
• Chairperson 
• SE/CM Representative 
• 2 NSA Representatives 
358 
• 2 CIA Representatives 
• 1 BBN/UMass Representative 
• 1 MMC/GE Representative 
• Representatives from the other contractors 
The membership of the EWG is composed of the following adjunct participants: 
• Evaluation Representatives (TREC, MUC) 
• Demonstration Representatives (Sponsor/Contractor - 2 persons) 
359 

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 II Architecture. This critical area 
is the responsibility of configuration management. 
Finally, configuration management is responsible for formal delivery of all TIPSTER II 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. 
361 
Events/Milestones 
Requirements 
Definition 
Commence 
Configuration 
Management 
CM Setup 
Preliminary Design 
Review (PDR) 
Final Operating 
Capability (FOC) 
CM Activities 
Initiate status accounting for action items, 
Establish project files 
Establish Architecture Baseline, Initiate change 
control, Initiate "Version Description Document" 
Initiate status accounting for changes, and continue 
Action Items Maintain project files 
Identify Configuration Items, Continue change 
control, Continue status accounting for changes and 
action items, Maintain project files, Deliver 
architecture documents 
Process changes, identify Architectural Deviations, 
Continue change control, Update "Version 
Description Document", Continue status accounting 
for changes and Action Items, Maintain project files 
Issue Architecture Deviation Document Continue 
change control, Update "Version Description 
Document", Continue status accounting for changes 
and action items, Maintain project files, 
Start Date 
00/00/00 
Finish Date 
00/00/00 
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. 
follows: 
4.4.2 Overview - Submitter/Reviewer 
Submissions of RFCs can come from any source. 
developers, the CAWG, or the SE/CM. 
4.4.2.1 Application Developer Submission 
Submissions from applications developers will be 
They are as 
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. 
It is expected that submissions will be made by application 
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. 
362 
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 
363 

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 
ARPA 
AWG 
BBN 
CCB 
CI 
CIA 
CM 
CMM 
CMP 
COTR 
CSA 
CSCI 
DIA 
ERB 
EWG 
FCA 
FOC 
GE 
ICD 
MMC 
MUC 
NSA 
PCA 
PDR 
PM 
PO 
QA 
RFC 
SE 
SE/CM 
TACAD 
Application Program Interface 
Advanced Research Projects Agency 
Architecture Working Group 
Bolt Beranek and Newman 
Configuration Control Board 
Configuration Item 
Central Intelligence Agency 
Configuration Management 
Configuration Management Manager 
Configuration Management Procedures 
Contracting Officer's Technical Representative 
Configuration Status Accounting 
Computer Software Configuration Item 
Defense Intelligence Agency 
Engineering Review Board 
Evaluation Working Group 
Functional Configuration Audit 
Final Operating Capability 
General Electric 
Interface Control Document 
Martin Marietta Corporation 
Message Understanding Conference 
National Security Agency 
Physical Configuration Audit 
Preliminary Design Review 
Program Manager 
Program Office 
Quality Assurance 
Request For Change 
Systems Engineering 
Systems Engineering/Configuration Management 
TIPSTER Application Conformance Assessment Document 
365 
TBD 
TREC 
UMass 
V&V 
To Be Decided 
Text Retrieval Conference 
University of Massachusetts 
Verification and Validation 
366 
APPENDIX A TACAD DESCRIPTION 
TIPSTER Design Application Module Comment 
Module 
Get Document Next Message Fully Compliant 
Find Name Namer Partially Compliant - see section 13.4 for details. 
Figure A-1 TIPSTER Compliance Based on Modules 
367 

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 ICD Req. _, Concept CM Plan 
Document 'Version: 
Paragraphs Affected: 
References: 
Change Required: 
Specific Recommendation: 
Reason for Proposed Change: 
Submitter Name: 
Organization: Title: 
Date: Phone Number: 
Reviewer Name: 
Organization Title: 
Date: Phone Number: 
AC Change Approval: Name: 
Date: Title: 
369 
REQUEST FOR CHANGE (RFC) FORM INSTRUCTIONS 
Instructions Responsibility 
Enter short (10 words or less), descriptive title for the Submitter 
Change Request. 
CM 
Field 
Title 
Page 1 of 
Date Prepared 
Need Date 
Priority 
Enter total number of pages, including any supporting 
information and this form. 
Enter date requestor prepares CR, including all 
attachments. 
Enter date by which decision must be received by the 
requestor to avoid any or additional impact. 
Check appropriate selection. A CR is urgent if work 
cannot proceed without a decision on the request. 
Submitter 
Submitter 
Submitter 
Document Check all documents affected by the requested change Submitter 
Affected 
Version Affected Enter the version number of the above document. Submitter 
Paragraph Enter the paragraph numbers requiring change. Indicate Submitter 
Affected document by D, I, R, C, or P 
Reference Specify reference document(s), such as meeting minutes, Submitter 
from which the CR was initiated. If not applicable, enter 
N/A. 
CR No. Assign Change Request number in the form of NNNNN CM 
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 Requestor 
Specific 
Recommendation 
Describe in detail what change(s) is (are) required. The 
"how" of the change is covered under the next item. 
Attach redlined pages from the affected 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. 
Provide justification, in detail, for the proposed change. 
Include alternative solutions, if available, and impact if 
change is not implemented. 
Reason for 
Proposed Change 
Requestor 
Requestor 
Subnit~r 
Reviewer 
AC Change 
Approval 
Enter organization, requestor name, title and date 
Enter name, title and date of reviewing official, normally 
SE/CM unless submitted by SE/CM; then appointed by AC 
Enter name, title and date of approving official 
Requestor 
CM 
AC Chairperson 
370 
