CHANGE PAGES TO FBIS DOCUMENTS

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP91-01355R000300100006-0
• Release Decision: RIPPUB
• Original Classification: K
• Document Page Count: 70
• Document Creation Date: December 23, 2016
• Document Release Date: August 7, 2013
• Sequence Number: 6
• Publication Date: March 15, 1988
• Content Type: MEMO

Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
' 0
MEMORANDUM FOR: Distribution
THROUGH:
FROM:
SUBJECT:
REFERENCE:
Change Pages to FBIS Documents
ESG Memo dated 3 March 1988
Subject - Results of I March 1988 CCB
SES-046-88
15 March 1988
1. The Reference memo reported the CCB approval of HU-RFC-C-002-87,
CO-RFC-C-002-87, HU-RFC-C-001-88, HU-RFC-C-002-88, as modified by the
CCB. The SI (SES) was instructed (Reference) to update the AFS System
Specification (MPD-900-001C), the FBIS CM Plan (MPD-000-801), and the FBIS
Operational CM Plan (MPD-000-811) in accordance with the changes produced
by these RFCs and provide change pages to holders of these documents.
2. The attached change pages to the AFS System Specification are the
current versions of the pages affected and should be inserted into the
document, replacing the corresponding pages. The other attachments are
revised versions of the FBIS CM Plan, and the FBIS Operational CM Plan.
3. This action completes the fo'rmal distribution of the
documentation changes resulting from the I March 1988 CCB.
4. For more information or additiral copies of the attachments,
please contact
Attachments:
A. Change Pages to the AFS System Specification (MPD-900-001C)
B. Revision A of the FBIS CM Plan (MPD-000-801A)
C. Revision A of the FBIS Operational CM Plan (MPD-000-811A)
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
STAT
STAT
STAT
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
SUBJECT: Change Pages to FBIS Documents
FBIS/ESG/ADD/SES
Distribution:
Original - C/ESG
1 - DC/ESG
1 - C/UPS
1 - C/OPS
1 - C/DRD
1 - C/PROD
1 - C/AG
1 - SAM/AG,
1 - SAM/PROD
1 - SA/OPS,
1 - C/FED
1 - C/HED
1 - C/ADD
1 - DC/ADD
1 - ADD Staff
COTR
1
1
1 - LEC
1 - GE/SES Staff '
1 - GE/SES Chrono
1 - GE/SES CCB Chrono
1 - FBIS Registry
1 - Originator
2
(15MAR88)
SES-046-87
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
STA
STAT
STAT
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rirm-7vv-vult, rosa orrAgirskinsivri A ndLcu 1700
CHANGE LOG
TITLE: FBIS SYSTEM SPECIFICATION DOCUMENT MPD-900-001C
REV
DATE
PAGES AFFECTED
RFC NO.
2/6/87
2/6/87
2/6/87
6/29/87
11/23/87
11/23/87
11/23/87
11/23/87
11/23/87,
3/1/88
vii, 6, 22, 34, 35
vii, 5, 11, 20,
33, 36, 41
vi, viii, 6,
44, 45, 46, 47, 48,
24, 26, 27, 28, 29,
40
17
21
vi, 21, 23
21, 22, 23, 24, 25,
7, 37, 38, 42, 43,
49, 50, 51, 52, 53
30, 31, 32, 33, 34
iii, iv, v, vii, 1, 3, 7, 42, 43,
44, 45, 46, 47, 48, 49, 50, 58
vii, 6, 8, 12, 13, 37, 38, 40, 50
GE-012-86
GE-018-86
GE-019-86
GE-020-86R1
C0-RFC-C-001-87
HU-RFC-C-001-87
HC-RFC-C-001-87
HC-RFC-C-002-87
FS-RFC-C-001-87
C0-RFC-C-002-87
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rbib brECillUATIUN I march 19158
SECTION TITLE
3.3 System Interface Definition
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
3.3.6
3.3.7
3.3.8
3.3.9
AUTODIN
Telex
Dedicated Line
Wire Service Subscribers
Independent Contractors
P&PD
Agency Classified Communications System
Selected Press Agency
3.4 System Availability/Reliability
3.4.1 Allocation
3.4.2 Lifetime Requirements
3.4.3 Single Point Failure
3.4.4 Mean-Time-To-Restore
3.5 System Maintainability
3.5.1 Fault Isolation
3.5.2 Human Factors
3.5.3 Maintenance
3.5.4 Equipment Packaging
3.5.5 Equipment Checkout
3.5.6 Non-Interruptive Maintenance
3.5.7 Marking and Interchangeability
3.5.8 Accessibility
3.5.9 Fault Detection and Correction
3.5.10 Environmental Conditions
3.5.11 Transportability and Handling
3.5.12 Security
3.5.13 Safety
3.5.14 Operability
3.5.14.1 Degree of Automation
3.5.14.2 Use of Redundancy Features
3.5.15 Design and Construction Practices
3.5.15.1 General
3.5.15.2 Controls
3.5.15.3 Control Panel Identification
3.5.15.4 Metal Parts
3.5.15.5 Workmanship
3.5.15.6 Reliability
iii
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
ISTA
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
MPD-900-QUIC IBIS SIEULYLUATION I narcn ivue
TBD/TBR/TBS LIST
Paragraph(s) Description
3.2.4.1.1.2.2 The Field Communications Function ... receive
... Telex at 50 to 4800 (TBR) Baud.
3.2.4.1.1.2.5 The Field Communications Function from the
BBC (Interface and Format TBD)
3.2.4.1.1.6 ' The Field Communications Function ...30 (TBR)
seconds of receipt.
3.2.4.1.2.6.3 The Field Communications Function send ...
Telex at 50 to 4800 (TBR) Baud.
3.2.4.1.2.6.6 The Field Communications Function to the BBC
(Interface and Format TBD)
3.2.4.1.3.2 The Field Communications Function ...ten (TBR)
mailboxes per entries ...
3.2.4.1.4.2 The Field Communications Function ... collecting
defined (TBD) statistics...
3.2.4.1.4.3 The Field Communications Function ...outgoing
message automatically within 10 (TBR) seconds
...., ....new packages of addresses within 120
(TBR) seconds.
3.2.4.2.6
3.2.4.3.7
3.2.4.5.1
3.3.8
3.3.9
The Press Agency Collection Function shall be
capable of handling the load of 16 (TBR)
distinct lines.
Field Segment ...versions shall be stored for 60
(TBR) days.
The Field Configuration shall support up to 50
(TBR) concurrent users.
Selected Press Agency "TBS"
"TBS"
5.2 Field Locations Facility Requirements (TBD)
vii
I Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
ISTAT
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
nru-7VV-VVIl. ['Dia armariwiiivn 1 marcn ivo8
Page 6
3.1.2.4 Composition Function
The Headquarters Classified Segment shall have the capability
to perform automated composition of text and graphics for
"local" hardcopy printing and reproduction by P&PD.
3.1.3 Communications Segment Functional Description
The Communications Segment shall handle all communications and
message traffic as it enters or leaves the Automated FBIS
System. The Communications Segment shall be divided into the
following major functions: Headquarters Unclassified
Communications Function, and Headquarters Classified
Communications Function.
3.1.3.1 Headquarters Unclassified Communications Function
The Headquarters Unclassified Communications Function shall
process unclassified communications and message traffic for
FBIS Headquarters. Headquarters Unclassified Communications
shall:
a) provide automated support to receive, verify, 17,_1
store, and route incoming message traffic from
AUTODIN, Telex, and Dedicated Line,
b) provide automated support to retrieve, format, log,
store transmit, and verify outgoing message traffic
via AUTODIN, Telex, and Dedicated Line,
c) accept Wire Service output from the Headquarters
Unclassified Segment and transmit this data to 32 Wire
Service consumers, with a capability to expand to 128
consumers,
d) accept simultaneous electronic inputs of word
processing documents via modem and commercial dial-up
telephone circuits.
3.1.3.2 Headquarters Classified Communications Function
The Headquarters Classified Communications Function shall
process classified communications and message traffic for FBIS
Headquarters. This function shall provide automated support to
receive, verify, log, store, and route incoming message
traffic.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
STAT
STAT
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
MIU-7W-UUIL rnib brMIYILAILUN I march 19U8
Page 8
3.2 Segment Functional and Performance Description
3.2.1 Headquarters Unclassified Segment
The functional elements of the Headquarters Unclassified
Segment are depicted in Figure 3.2.1-1.
3.2.1.1 Daily Report and Wire Service Function
3.2.1.1.1
3.2.1.1.1.1
3.2.1.1.1.2
3.2.1.1.1.3
3.2.1.1.1.4
3.2.1.1.1.5
3.2.1.1.1.6
The Daily Report and Wire Service Function shall support the
compilation and editing of both the FBIS Wire Service and Daily
Report. It shall be comprised of Atex Editorial System
processor(s), disk storage devices, peripherals, workstations
and associated software. The Atex shall be a standard
commercially supported configuration and shall not include any
hardware or software modifications that would preclude
incorporation of future vendor software enhancements.
Message Processing Function
The Daily Report and Wire Service Function shall have the
capability to process incoming message traffic received from
the Communications Segment, 24 hours a day, 7 days a week.
The Daily Report and Wire Service Function shall provide all
users with a procedure to support the assembly of the segments
of a multi-part message into a single message.
The Daily Report and Wire Service Function shall provide the
capability for all users to generate output messages in special
formats (see the FBIS Editorial Handbook) for subsequent
transmission to field bureaus via the Communications Segment
and to assign the precedence and the addressees of the
messages. In addition, the capability for the users to specify
the outgoing link for message transmission shall also be
provided.
The Daily Report and Wire Service Function shall store the last
30 days of all incoming and outgoing field bureau message
traffic. This message file shall be structured to facilitate
search and retrieval of messages.
The Daily Report and Wire Service Function shall provide the
capability for all users to search all header fields and the
text sections of the last 30 days of all incoming and outgoing
field bureau message traffic and to display in softcopy and
hardcopy formats all or parts of the headers and text sections
of a retrieved message.
The Daily Report and Vire Service Function shall provide the
capability for all users to purge messages and those related
directories assigned to that user. In addition the capability
for the system to automatically purge messages based on age
criteria shall also be provided.
Declassified in Part- Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
MIU-VVV-UVIU this SIMAYIUATIUN 1 March 1988
Page 12
3.2.1.1.3.10
The Daily Report and Wire Service Function shall provide the
Wire Service the capability to process an average of 2100 input
messages a day and 250 output messages a day. The peak hourly
input rate shall be 300 messages with an average message length
of 133 words. The peak hourly output rate for Wire Service and
- AUTODIN messages shall be 20 and 100 respectively.
3.2.1.1.3.11 The Daily Report and Wire Service Function shall provide the
capability for Wire Service editors to create messages, modify
the text of messages, generate messages in a wire output
format, assign precedence, assign type of message, assign
addresses from pre-stored tables/files, and further route them
to pre-defined destinations.
3.2.1.1.3.12 The Daily Report and Wire Service Function shall provide the
capability for Wire Service editors to move any message in a
"transmission" mailbox from its current position to a position
of first in line less one in that same mailbox (queue).
3.2.1.1.3.13 The Daily Report and Wire Service Function shall have the
capability to transmit outgoing messages to the Communication
Segment.
3.2.1.1.3.14 The Daily Report and Wire Service Function shall provide the
capability for designated Wire Service editors to command the
system to transmit messages to the Communication Segment.
3.2.1.1.3.15 The Daily Report and Wire Service Function shall provide the
capability to route a copy of outgoing messages that are of
Immediate and Flash precedence to a designated Wire Service
mailbox after its release for transmission.
3.2.1.1.3.16 The Daily Report and Wire Service Function shall store the last
thirty days of all outgoing Wire Service messages and provide
separate directories to that file based on message type (i.e.
operational, administrative, wire consumer).
I Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
STAT
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
MPD-900-(R)1C FEIS SPECIFICATION 1 March 1988
Page 13
3.2.1.1.4 Daily Report Function
3.2.1.1.4.1 The Daily Report shall have a total of 50 Atex editorial work-
stations.
3.2.1.1.4.2 The Daily Report and Wire Service Function shall provide the
capability to disseminate incoming AUTODIN traffic to the STAT
appropriate mailbox for each of the eight Daily Report
book-sections. There is a minimum of 175 book-sections for the
entire Daily Report. There shall be an average of 2100
incoming messages containing a total of 840,000 words per day.
3.2.1.1.4.3
3.2.1.1.4.4
3.2.1.1.4.5
3.2.1.1.4.6
3.2.1.1.4.7
3.2.1.1.4.8
The Daily Report and Wire Service Function shall provide the
capability to automatically alert designated Daily Report
editors of the receipt of an Immediate precedence message with
a visual alert at his workstation.
The Daily Report and Wire Service Function shall provide the
capability to automatically alert designated Daily Report
editors of the receipt of a Flash precedence message with a
visual alert at his workstation.
The Daily Report and Wire Service Function shall provide the
capability for a Daily Report editor to access the disseminated
messages stored in mailboxes. There shall be a minimum of 175
mailboxes, one for each book section. After accessing a
message, an editor shall be able to review it in softcopy and
further route it to any one of a set of 5 pre-defined work
mailboxes related to a particular book section. Each of the
175 book sections shall have its own set of related work
mailboxes. Any one editor shall have access to a minimum of 10
of the book section mailboxes and their related work mailboxes.
The time to select a message via a directory, transfer it to
the workstation, and have it available for softcopy review
shall be no more than 3 seconds. The time to copy or further
route any message from one mailbox to any other shall not be
more than 3 seconds. This scenario assumes the mailboxes are
related to the book or book sections with which the editor
normally works.
The Daily Report and Wire Service Function shall provide the
capability for Daily Report editors to process an average of
1550 input messages (620,000 words) during an 8 hour shift for
inclusion in the Daily Report. A maximum of 2500 messages are
queued for processing at the beginning of the shift.
The Daily Report and Wire Service Function shall provide the
capability for a Daily Report editor to organize edited
messages into a book section.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
nru-7uu-VVil. . raia Drnta.ritsanun I maren 19a8
Page 37
3.2.3 Communications Segment
The Communications Segment shall consist of the Headquarters
Unclassified Communications Function, and the Headquarters
Classified Communications Function. The functions and
interfaces supported by the Communications Segment are depicted
in Figure 3.2.3-1.
3.2.3.1 Headquarters Unclassified Communications Function
The Headquarters Unclassified Communications Function shall be
that portion of the Communications Segment that shall handle
unclassified communications. The following paragraphs describe
the requirements for the Headquarters Unclassified
Communications Function.
3.2.3.1.1 Field Traffic
The Headquarters Unclassified Communications Function shall
support two-way communications with bureaus via AUTODIN, ISTAT
Telex, and Dedicated Line (London only) in accordance with the
respective Interface Control Documents for these interfaces.
Telex shall be used as a backup to and AUTODIN. There
shall be a Dedicated Line between FBIS Headquarters and the
London Bureau to provide backup to AUTODIN for this bureau.
[STAT
The Headquarters Unclassified Communications Function shall
support two dedicated interfaces to AUTODIN switching centers
at Andrews AFB and Ft. Detrick via standard Telecommunications
Line Controllers and modems within Headquarters Unclassified
Communications (see FBIS/AUTODIN-FBIS interface Control STAT
Document MPD-900-200A).
3.2.3.1.1.1 Incoming Communications
3.2.3.1.1.1.1 Receiving
3.2.3.1.1.1.1.1 AUTODIN
STAT
The Headquarters Unclassified Communications Function shall be
capable of automatically receiving an average of 2100 messages
(840,000 words) per 24 hour day, 7 days a week from STAT
AUTODIN. The peak input rate per hour shall be 300 messages a
with an average of 133 words per message.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
nru-/tiv-vvit, nub b1"561.1(13,1411VINI 1 !Jaren 19d8
Page 38
COMMUNICATIONS FUNCTIONS
HCCF = HEADQUARTERS CLASSIFIED
HUCF= HEADQUARTERS UNCLASSIFIED
AGENCY
CLASSIFIED
COMMUNICATIONS
AUTODIN
-I RCA TELEXTRA
-I DEDICATED LINE
COMMUNICATIONS
SEGMENT
3. 2. 3. 2
I.
?
[HCCF
-HUCF
3.2.3.1.1.1.1.1
IP
3. 2. 3.1.1. 2. 5.1
3. 2. 3. 1. 1. 1.1. 1
4
3. 2. 3.1.1. 2. 5.1
3. 2. 3. 1.1. 1:1. 2
4
10-
I,
3. 2. 3. 1. 1. 2. 5. 2
3.2. 3. 1.1.1. 1. 3
4
3.2.3.1.1.2.5.3
3.2.3.1.2
ii
e?
te\\NON-ELECTRICALT??i
1
4-1
4
3. 2.
3.
WIRE SERVICE
SUBSCRIBERS
INDEPENDENT
CONTRACTORS
4
DEDICATED LINE
3.
TELEX
3.
3.
AUTODIN
ENGLISH LANG
PRESS
3.
HQ CLASS SEG
STAT
HQ UNCLASS SEG
3.
2.
4.
1. 1.
2.
3
2. 4.
1.
2.
6.
3
3.
2.
4.
1. 1.
2.
2
2. 4.
1.
2.
6.
2
3.
2.
4.
1. 1.
2.
4
STAT
FIELD SEGMENT
2. 4.
1.
2.
6.
4
0=
3.
2.
4.
1. 1.
2.
1
2. 4.
1.
2.
6.
1
3.
2.
4.
2
FBIS COMMUNICATIONS SEGMENT INTERFACES
(LOGICAL FLOW)
FIGURE 3. 2. 3-1
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
ILLY-7VV?VVW rasa OrEA...1.r.Llettl-LVIIi narcn iva8
Page 40
3.2.3.1.1.1.7 Modem Interface
The Headquarters Unclassified Communications Function shall be
capable of accepting 10 simultaneous electronic inputs of word
processing documents via modem and cbmmercial dial-up telephone
circuits. The number of simultaneous inputs shall be capable
of being increased to 20 circuits as required. This interface
shall be electronically separated from the remainder of the
Headquarters Unclassified Communications Function. The data
received shall be automatically captured on magnetic media for
subsequent transfer to the JPRS Editorial Function.
3.2.3.1.1.2 Outgoing Communications
3.2.3.1.1.2.1 Accepting Messages
The Headquarters Unclassified Communications Function shall
automatically accept outgoing messages from the Daily Report
and Wire Service Function.
3.2.3.1.1.2.2 Formatting
The Headquarters Unclassified Communications Function shall
automatically format the transmission header and add it to
messages in accordance with ACP 127, JANAP 128 and the FBIS
Editorial Handbook. It shall automatically format messages
that exceed the JANAP 128 line length limitation into
multi-take messages and shall break those messages at the end
of a sentence and preferably at the end of a paragraph. The
JANAP 128 requirements shall apply to ACP 127 messages for the
line length limitations.
3.2.3.1.1.2.3 Logging
The Headquarters Unclassified Communications Function shall
automatically log (softcopy) each outgoing message and retain
this log for a period of 30 days.
3.2.3.1.1.2.4 Storing
The Headquarters Unclassified Communications Function shall
have the capability to automatically store each outgoing
message on-line for a period of 30 days.
3.2.3.1.1.2.5 Transmitting
3.2.3.1.1.2.5.1 AUTODIN
The Headquarters Unclassified Communications Function shall be
capable of transmitting outgoing message traffic via and
AUTODIN, 24 hours a day. It shall support a maximum output of
300 messages per day, averaging at least 333 words per message,
totalling 100,000 words, with a peak output rate of 100
messages per hour.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
TAT
Declassified in Part - Sanitized Copy Approved for Release
nru-7vv-vvit. nos?
3.3 System Interface
The following interfaces
FBIS System.
3.3.1 AUTODIN
This interface shall
2013/08/07: CIA-RDP91-01355R000300100006-0
arMoiriLdillW I narcn not)
Page 50
Definition
shall be supported by the Automated
be as specified in the
FBIS/AUTODIN-FBIS
Interface Control Document, MPD-900-200A.
STAT
3.3.2
Telex
This interface shall be as specified in the FBIS/Telex
Interface Control Document, MPD-900-201.
3.3.3
Dedicated Line
This interface shall be as specified in the FBIS/Dedicated Line
Interface Control Document, MPD-900-202.
3.3.4
Wire Service Subscribers
This interface shall be as specified in the FBIS/Electronic
Subscribers Interface Control Document, MPD-900-203A.
3.3.5
Independent Contractors
This interface shall be as specified in the FBIS/Independent
(
Contractors Interface Control Document, MPD-900-206.
3.3.6
P&PD
This interface shall be as specified in the FBIS/P&PD Interface
3.3.7
Control Document, MPD-900-205A.
Agency Classified Communications System
This interface shall be as specified in the FBIS Headquarters
Classified Communications/Agency Communications Interface
Control Document, MPD-900-207.
3.3.8
Selected Press Agency
(TBS)
3.3.9
STAT
(TBS)
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
?
FOREIGN BROADCAST INFORMATION SERVICE
CONFIGURATION MANAGEMENT PLAN
MPD-000-801A
1 March 1988
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
wpn_non_anie finta4TrilIDATTANI MAMAIIPMAMT DTAM 1 Mn.-.41 1000
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
CHANGE LOG
TITLE: FBIS CONFIGURATION MANAGEMENT PLAN MPD-000-801A
REV DATE PAGES AFFECTED RFC NO.
A
10/4/85
1/15/86
10/2/86
3/1/88
iii, iv, 3, 4, 5, 6, 7, 10, 11, 14,
17, 18, 22, 23, 24
3, 6, 7, 17
1, 2:3, 4, 7, 10, 11, 15, 18
Ii, 1, 2, 3, 4, 5, 6, 7, 8, 9 10,
11, 14, 15, 16
GE-007-85
GE-016-85
GE-013-86
HU-RFC-C-001-88
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in-P;rt-:agaraiiiiZed Copy Approvea-i;ki;cii i08i07?-61A-RDP91-01355R000300100006-0
TABLE OF CONTENTS
? 1.0 INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 Applicable Documents
1.4 Glossary
2.0 FBIS ORGANIZATION AND RESPONSIBILITIES
2.1 Engineering Support Group
2.2 Configuration Control Board
2.2.1 CCB Membership
2.3 CCB Member Responsibilities
2.3.1 CCB Chairman/Deputy Chairman
2.3.2 CCB Members
2.3.3 CCB Secretariat
2.4 CCB Meetings
2.5 Contractor Responsibilities
2.5.1 Configuration Management Responsibilities
2.5.2 Contractual Changes
3.0 FBIS BASELINE CONFIGURATION IDENTIFICATION
3.1 Documentation under Configuration Control
3.1.1 Documentation Identification
3.1.2 CM Documentation Library
3.2 Software under Configuration Control
3.2.1 Software Identification
3.2.2 Vendor Proprietary Software
3.3 Hardware under Configuration Control
3.3.1 Hardware Identification
3.3.2 Vendor Off-the-Shelf Hardware
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified inti3a?rter ganniiiz4ed Copy ApprovWF;iiliesa7a-261RiiciFZIK-bp9i -0135Mbooeo6-166006-0
TABLE OF CONTENTS
4.0 FBIS CONFIGURATION CONTROL
4.1 Request for Change
4.2 Change Classification
4.2.1
4.2.2
Class I Changes
Class II Changes
4.3 RFC Processing
4.3.1 Class I Changes
4.3.1.1 Engineering Change Proposal
4.3.2 Class II Changes
4.4
4.5
4.6
4.7
RFC Closure
Discrepancy Report
DR Processing
DR Closure
5.0 FBIS CONFIGURATION STATUS ACCOUNTING
5.1 Status Reports
6.0 FBIS CONFIGURATION AUDITS
APPENDIX A FBIS CCB MEETING PROCEDURES
1.0 FBIS CCB Meeting Procedures
APPENDIX B FBIS DOCUMENTATION IDENTIFICATION
1.0 Documentation Identification
ii
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
unn Ann 0111A
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R0003001660 06-0
rage a.
' 1.0 INTRODUCTION
1.1 Purpose
In order to ensure that the procurement, installation, and integration
of new systems proceeds smoothly and satisfies the user requirements, a
discipline known as Configuration Management (CM) will be exercised. The
purpose of this Configuration Management Plan is to define policy and
procedures regarding configuration management activities for FBIS. It
describes the organization which is responsible for Configuration Management,
the documentation which identifies the baseline configuration to be controlled,
and the process of control. Major upgrades will take place through contract
procurement. These procurements will involve separate but parallel
configuration management activities on the part of the contractors which will
be consistent with this CM Plan. Whenever there is a conflict between
overlapping configuration management responsibilities, this plan shall apply.
1.2 Scope
This plan establishes the configuration management requirements for
documenting and controlling changes to the FBIS Baseline Configuration in order
to ensure proper: (a) identification and documentation of the functional and
physical characteristics, (b) control of changes to those characteristics, and
(c) recording and reporting of approved changes and the status of their
implementation.
The configuration management process requires a management structure
with the responsibility and sufficient authority to ensure compliance. This
plan delineates the management structures and positions which will be involved
in the various configuration management activities.
1.3 Applicable Documents
The following documents are guidelines for this plan and are applicable
only to the extent cited. In the event of a conflict between this plan and the
referenced documents, this plan shall apply.
D/FBIS MEMO on Configuration Management dated 22 Feb 1985
MPD-000-811 MIS Operational CM Plan
DOD-STD-480A
MIL-STD-481A
MIL-STD-490
Configuration Control -
Deviations, Waivers
Configuration Control -
Deviations, Waivers
Specification Practices
Engineering Changes,
Engineering Changes,
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
mpn_nnn_Rnie r/111112172TIDATTM MANACIPM2MT DTAM 1 14,rah 1000
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
1.4 Glossary
(- The acronyms which are used in this plan are listed below with their
definitions for convenient reference.
C/ADD Chief, Advanced Development Division
C/AG Chief, Analysis Group
C/ESG Chief, Engineering Support Group
C/E&PS Chief, Executive and Planning Staff
C/FED Chief, Field Engineering Division
C/HED Chief, Headquarters Engineering Division
C/OPS Chief, Operations Group
C/PROD Chief, Production Group
CCB Configuration Control Board
CM Configuration Management
CO Contracting Officer
COTR Contracting Officer's Technical Representative
D/FBIS Director, Foreign Broadcast Information Service
DC/ADD Deputy Chief, Advanced Development Division
DC/ESG Deputy Chief, Engineering Support Group
DD/FBIS Deputy Director, Foreign Broadcast Information Service
DR Discrepancy Report
ECP Engineering Change Proposal
ERR Engineering Review Board
ESG Engineering Support Group
FBIS Foreign Broadcast Information Service
FOC Final Operating Capability
CFE Government Furnished Equipment
GFP Government Furnished Property
ICD Interface Control Document
RFC Request for Change
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
unn AAA 0A1A flrOarltflflTAMTAIVI VAATAMMT,M714 MAP.?
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage .3
2.0 FBIS ORGANIZATION AND RESPONSIBILITIES
The Director, FBIS, has overall authority and control of all FBIS
resources. To assist in this task, Group Chiefs are given authority to manage
those resources within their functional areas.
2.1 Engineering Support Group
The Engineering Support Group is managed by the Chief, Engineering
Support Group (C/ESG). This organization has the responsibility for the FBIS
Modernization Program which has been initiated to increase the timeliness and
responsiveness of FBIS operations, increase the coverage of open sources, and
to improve availability and quality of finished products. This responsibility
includes the development of technical and programmatic aspects of the
Modernization Program.
2.2 Configuration Control Board
A Configuration Control Board (CCB) has been established, under the
direction of the Chief, Engineering Support Group, by the Director, FBIS, to
exercise Configuration Management for FBIS. The CCB shall consider and control
all proposed facility, hardware and software changes at Headquarters and in the
Field, including ROSET, INTERNET and AUTOMATION, as well as all changes to
pilot projects, requests for Office of Information Technology support,
engineering or communications upgrades, and other implementation activities
which could affect the Modernization Program. The CCB shall also ensure that
all approved changes are incorporated into the FBIS Baseline Configuration
documentation.
In order to exercise operational configuration management of FBIS
automated and technical systems, the FBIS CCB Chairman may establish
.subordinate Engineering Review Boards (ERBs). Each ERB will be tasked with
exercising operational configuration management for specific FBIS automated or
technical system(s). Refer to the FBIS Operational CM Plan, MPD-000-811, for
specific information on Engineering Review Boards.
2.2.1 CCB Membership
The membership of the CCB shall be composed of the following FBIS
management personnel:
Chief, Engineering Support Group (Chairman)
Deputy Chief, Engineering Support Group (Deputy Chairman)
Chief, Executive and Planning Staff
Chief, Operations Group
Chief, Production Group
Chief, Analysis Group
Chief, Advanced Development Division
Deputy Chief, Advanced Development Division
Chief, Field Engineering Division
Chief, Headquarters Engineering Division
Contracting Officer
Secretariat
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage 4
2.3 CCB Member Responsibilities
2.3.1 CCB Chairman/Deputy Chairman
The CCB Chairman has absolute responsibility for the Configuration
Management and control of the FBIS Baseline Configuration, through the
authority of the Director, FBIS. In the absence of the Chairman, the Deputy
Chairman shall assume the responsibilities of the Chairman. The CCB Chairman
shall:
Convene the CCB as necessary.
Approve, disapprove, or defer Requests for Change (RFCs) based on the
recommendations of the CCB members.
Approve, disapprove, or defer System Level Discrepancy Reports (DR)
based on the recommendations of the CCB members.
If the RFC or DR is approved, ensure that the appropriate implementing
organization is tasked.
If the RFC or DR is disapproved, document the reason.
If the RFC or DR is deferred, indicate required actions, if any.
2.3.2 CCB Members
The CCB Members shall assume responsibility for those activities
described below which are within their regular areas of management
responsibility. CCB Members shall:
Ensure that operational systems are consistent with the CCB authorized
FBIS Baseline Configuration.
Ensure that each RFC or DR is in consonance with operational
requirements.
Provide operational guidance for each RFC or DR's technical approach,
evaluation and implementation.
Evaluate the adequacy of each RFC for translation into detailed designs
from which hardware, software or facilities are to be procured or
produced.
Evaluate the engineering and scientific aspects of each RFC, including
the similarity to other research and development that may be in
progress.
Evaluate the affects of each RFC or DR on interfaces with other
equipment and facilities of the system as represented in system
tests, technical manuals, installation drawings, performance
documents and interface control documents.
Evaluate the affects of each RFC or DR on overall system performance and
compatibility requirements, including overall system operational and
environmental compatibility.
Evaluate the total impact of each RFC on costs, including all aspects of
cost growth or cost savings, such as engineering retrofit, support,
development and production cost changes.
2.3.3 CCB Secretariat
The CCB Secretariat is responsible for providing administrative support
to the CCB on matters pertaining to configuration, documentation and program
management. This includes:
Preparation and distribution of CCB Meeting agendas and minutes.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
mun_nnn_onIA PAMOTrTMAMTAM MAMAflOUVMT TIT Am
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage J
2.3.3 CCB Secretariat (cont'd)
Receiving, recording, and distributing all RFCs and DRs submitted for
CCB approval.
Monitoring RFC and DR related activities.
Issuing Status Reports.
Maintaining CCB records and files.
Maintaining CCB controlled documents as assigned by the CCB Chairman.
Ensuring the evaluation of all RFCs and DRs prior to presentation to the
CCB.
Ensuring that the RFC or DR evaluation is coordinated, as needed, with
all affected offices.
Consolidating evaluations into packages for distribution to the CCB
Members prior to the CCB Meeting.
Ensuring that follow-up action on CCB decisions is completed.
Ensuring that all approved RFCs and DRs are integrated into the FBIS
Baseline Configuration in a timely fashion.
Ensuring that RFCs and DRs are closed when CCB directed action is
completed.
Ensuring that adequate controls and safeguards have been established and
implemented for proper configuration control.
2.4 CCB Meetings
The CCB will meet at the discretion of the Chairman to evaluate new RFCs
and DRs. Each CCB Member will assist in this effort by providing the Chairman
with their advice and recommendation concerning the RFC or DR, adequacy of the
RFC or DR to accomplish the intended objective, the technical acceptability,
and any cost and schedule impacts. The decision authority to approve,
disapprove, or defer judgment on any RFC or DR rests solely with the CCB
Chairman. After approving an RFC or DR, the Chairman will, if necessary,
authorize the appropriate Contracting Officer's Technical Representative (COTR)
to implement the directed changes through the FBIS Contracting Officer (CO),
who will provide the corresponding contractual direction to the affected
contractor(s). Unless otherwise stated, CCB Meetings are open to all members
of FBIS and their contractors when their areas of interest are on the agenda.
Refer to Appendix A for a description of the FBIS CCB Meeting Procedures.
2.5 Contractor Responsibilities
2.5.1 Configuration Management
Any contractor developing or procuring; hardware, software or
facilities, is required to have a Configuration Management Plan. Where
appropriate, the contractor must provide FBIS with their Configuration
Management Plan detailing the control procedures to be invoked during
development, the milestone activities in the schedule when government
review/approval should be obtained, and the reporting mechanisms that will
ensure adequate government visibility during the development cycle.
2.5.2 Contractual Changes
Any change in the scope, as defined by the controlled documentation,
must be submitted as an RFC to the CCB. Based on CCB review, the requested
change may be approved for implementation, disapproved, or deferred.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part-SanitizedCopyApprov;EITo71-4;le;;c2013/0670T ZIK-RDP91-0135-5R0003001-66006-0
rage
c_
3.0 FBIS BASELINE CONFIGURATION IDENTIFICATION
To facilitate maintaining change control records, status accounting and
documentation control, an identifier will be assigned to all controlled items,
including all technical, administrative and management documentation. The FBIS
Baseline Configuration will contain a set of technical documents (e.g.,
specifications, drawings, plans, and manuals) which define current FBIS
operational capabilities, and specified documents which describe new or
modified capabilities under development. Since the actual hardware, software
and facilities reflect the implementation of the technical documentation, they
are, by extension, included as configuration controlled items.
3.1 Documentation Under Configuration Control
The FBIS Baseline Configuration Documentation is identified in the FBIS
Baseline Configuration Document Index and will be subject to configuration
control when issued. The FBIS Baseline Configuration Document Index itself
will also be subject to configuration control when issued. Changes to this
documentation will require CCB or ERR approval prior to being incorporated into
the FBIS Baseline Configuration.
3.1.1 Documentation Identification
Each document under configuration control will be identified by a Title,
Identification Number and Date of Issue on the title page, beginning with the
original issue. Refer to Appendix B for a description of the FBIS document
Identification Number assignment system. Thereafter, when a document is
updated, ESG or the responsible organization will reissue the document or
publish a set of change pages to the document. The Identification Number and
Date of Issue on the document will be updated only when the document is
reissued. When a set of change pages is published, the approval date of the
initiating RFC or DR will be placed on each change page, and change
identification marks will be placed in the right-hand margin. These change
identification marks will remain until the next time that page is modified, at
which time new markings will be drawn for that page.
3.1.2 CM Documentation Library
The CCB Chairman will establish a CM Documentation Library. This
library will be the repository for the FBIS Baseline Configuration
Documentation. The CCB Secretariat will have custody and control of that
portion of the CM Documentation Library assigned by the CCB Chairman. The CCB
Chairman may assign custody and control of'other portions of the CM
Documentation Library to other FBIS organizations or contractors at his
discretion.
The CCB Chairman will assign responsibility for the maintenance of a
portion of the CM Documentation Library to the CCB Secretariat. This
maintenance activity will consist of incorporating changes and updates into the
master copy of the document, producing new versions or change pages, and
disseminating these new versions or change pages to the holders of the
document. The CCB Chairlan will assign responsibility for the maintenance of
other portions of the CM Documentation Library to other FBIS organizations or
contractors at his discretion.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355140003061-66006-0
rage /
3.2 Software Under Configuration Control
All software contained in the FBIS Baseline Configuration will be
documented in the FBIS Baseline Configuration Documentation and will be subject
to configuration control when delivered. Changes to this software will require
CCB or ERB approval.
3.2.1 Software Identification
All software will be identified and tracked by Name and Version
Identifier. The Version Identifier will consist of a sequentially rising
version number beginning with V1.0. The FBIS Baseline Configuration
Documentation will list the Name, Version Identifier, date of installation,
specifications, functionality, Interface Control Documents (ICDs) and software
maintenance manuals.
3.2.2 Vendor Proprietary Software
The internal configuration of vendor proprietary software will be under
the configuration control of the vendor. The CCB or ERB will control and
specify the Name and Version Identifier of the vendor proprietary software to
be used, its date of installation, all update media, instructions and
documentation, and the date of software update installation. The CCB or ERB
will also monitor and control the licensing status of all vendor proprietary
software.
3.3 Hardware Under Configuration Control
All hardware contained in the FBIS Baseline Configuration will be
documented in the FBIS Baseline Configuration Documentation and will be subject
to configuration control when delivered. Changes to this hardware will require
CCB or ERB approval.
3.3.1 Hardware Identification
All hardware will be identified and tracked by the manufacturer, and
model name/number. The FBIS Baseline Configuration Documentation will list the
manufacturer, model, revision level, number of units, installed location, and
date of installation. The physical dimensions, weight, power/cooling
requirements, functionality, ICDs, maintenance manuals, drawings and parts
lists for the hardware will also be included where appropriate.
3.3.2 Vendor Off-the-Shelf Hardware
The internal configuration of off-the-shelf hardware will be under the
configuration control of the manufacturer. The CCB or ERB will control and
specify the manufacturer, model and revision level of all off-the-shelf
hardware to be used, its date of installation, all upgrade instructions and .
documentation, and the date of hardware upgrade installation.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
unn nnn aniA PrO.117Tf,TITIATT/Ma IJ A kTA "TftlIMAT m AM
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage o
4.0 FBIS CONFIGURATION CONTROL
Configuration Control is the process by which changes to the FBIS
Baseline Configuration are initiated, evaluated, approved, implemented and
verified. This process ensures analysis of changes that affect requirement,
satisfaction and provides for controlled changes to the FBIS Baseline
Configuration. Configuration Control requires that no changes be made to any
FBIS baseline under configuration control, without the approval of the FBIS CCB
or cognizant ERB. The Request for Change (RFC) and the Discrepancy Report (DR)
are the two control mechanisms, initiated by any program participant, which
drive the entire change process.
4.1 Request For Change
The Request for Change (RFC) is prompted by a desire or a requirement
for a change to the current FBIS Baseline Configuration, one topical area per
RFC. Refer to the FBIS Operational CM Plan, MPD-000-811, Appendix D for a
detailed discusion of RFC preparation.
4.2 Change Classification
There are two levels of changes to the FBIS Baseline Configuration,
Class I and Class II Changes. The definitions of Class I and Class II Changes
are given below. The final decision as to whether or not a proposed change
will be considered a Class I Change rests with the CCB Chairman.
4.2.1 Class I Changes
'Class I Changes are any changes to the FBIS Baseline Configuration that:
Result from anticipated or actual failure to meet requirements.
Result from new requirements.
Delete requirements or capabilities.
Affect the functional, physical or performance characteristics of a
configuration controlled item.
Affect contract cost and/or schedule.
Affect Government furnished Equipment (GFE) or Government Furnished
Property (GFP).
Make any change to the System Level FBIS Baseline Configuration
Documentation.
All Class I Changes require CCB approval-prior to implementation.
4.2.2 Class II Changes
Any change to the FBIS Baseline Configuration that is not classified as
a Class I Change, is a Class II Change. Class II Changes do not require FBIS
CCB approval prior to implementation. Examples of Class II Changes are
modifications to contractor specifications which do not directly impact System
Level documentation under FBIS CCB control. Such changes are handled at the
contractor's CCB during system development, and at the cognizant FBIS ERB
during system operations.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
unn AAA OAIA ^^MUTrIMAMT^M VAMArtUDMM ntAm I u---t. 'non
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rub= 7
4.3 RFC Processing
4.3.1 Class I Changes
Class I Change RFCs will be forwarded to the CCB. ESC will contact and
coordinate with any affected organizations, as necessary, to ensure that a
complete and comprehensive evaluation of each RFC is performed. For contractor
initiated RFCs, the COTR will ensure the development of a recommendation for
review by the CCB. For government initiated RFCs, the ESG will ensure the
development of a recommendation, with contractor support as required, for
review by the CCB.
The CCB Secretariat will log, maintain status and ensure that
evaluations are received on each RFC. The Secretariat will also ensure the
provision of coordinated recommendations and rationale on each RFC for
consideration by the CCB.
The CCB will review each RFC to determine whether to approve,
disapprove, or defer implementation of the RFC. If the RFC is approved, the
CCB will direct the development and incorporation of the Class I Change into
the FBIS Baseline Configuration in accordance with the procedures established
by the ERR responsible for that portion of the FBIS Baseline Configuration. If
an existing contract will be affected, the CCB may direct the preparation of an
Engineering Change Proposal (ECP) for submission to the CCB.
4.3.1.1 Engineering Change Proposal
An ECP is a request to change the scope of an existing contract.
This request must be approved by the contractor's program management and issued
by their Contracting Officer through the COTR. If an RFC is approved by the
CCB Chairman contingent upon the receipt of an ECP not exceeding the Rough
Order of Magnitude (ROM) cost provided in the RFC by more than 15%, then the
ECP may be implemented without further CCB action. If the cost of the ECP
exceeds the RFC ROM cost by more than 15%, then the ECP will be returned to the
CCB. The FBIS CCB will then determine whether to approve, disapprove, or defer
implementation of the ECP.
4.3.2 Class II Changes
Class II Change RFCs will also be provided to the CCB Chairman.
Development and incorporation of Class II Changes into the FBIS Baseline
Configuration, in accordance with the procedures established by the ERR
responsible for that portion of the FBIS Baseline Configuration, may proceed
under implied concurrence. However, the CCB Chairman reserves the perogative
to intervene in this process as deemed necessary. Contractor initiated Class
II Change RFCs are subject to the contractor's internal configuration control
procedures, and are subject to review and concurrence by the COTR.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
unn AAA 0A1A flAMDTrIIMAMT^M UAMA^nUMAM INTAM 1A00
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
ra8c iv
4.4 RFC Closure
Each approved RFC is tracked in the RFC database. RFCs will remain in
an OPEN state until the modification and documentation associated with the RFC
is formally approved by the ERB responsible for that portion of the FBIS
Baseline Configuration, and successfully implemented. Only those RFCs which
are successfully implemented may be CLOSED. An RFC that has been CLOSED will
be included in the next Status Report with a closure notification and will not
be listed in subsequent reports. Status Accounting and the Status Reports are
discussed further in the next chapter.
4.5 Discrepancy Report
The Discrepancy Report (DR) is prompted by a problem or failure in the
baseline configuration, one topical area per DR. Refer to the FBIS Operational
CM Plan, MPD-000-811, Appendix C for a detailed discusion of DR preparation.
4.6 DR Processing
DRs will be forwarded to the CCB when the ERB responsible for the
affected portion of the FBIS Baseline Configuration determines that a change to
CCB controlled software, databases, hardware, facilities or documentation is
required. ESG will contact and coordinate with any affected organizations, as
necessary, to ensure that a complete and comprehensive evaluation of each DR is
performed. ESG will ensure the development of a recommendation, with
contractor support as required, for review by the CCB.
The CCB Secretariat will log, maintain status and ensure that
evaluations are received on each DR. The Secretariat will also ensure the
provision of coordinated recommendations and rationale on each DR for
consideration by the CCB.
The CCB will review each DR to determine whether to approve, disapprove,
or defer implementation of the corrective action. If the corrective action is
approved, the CCB will direct the development and incorporation of the
correction into the FBIS Baseline Configuration in accordance with the
procedures established by the ERB responsible for that portion of the FBIS
Baseline Configuration.
4.7 DR Closure
Each DR is tracked in the DR database. DRs will remain in an OPEN state
until the correction and documentation associated with the DR is formally
approved by the ERB responsible for that portion of the FBIS Baseline
Configuration, and successfully implemented. Only those DRs which are
successfully implemented may be CLOSED. A DR that has been CLOSED will be
included in the next Status Report with a closure notification and will not be
listed in subsequent reports. Status Accounting and the Status Reports are
discussed further in the next chapter.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
unn_nnn_aniA rnmwrruptimrnm MAMACIRMAMT WAN 1 Morrh 1ORR
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
5.0 FBIS CONFIGURATION STATUS ACCOUNTING
In order to assist all personnel involved in configuration management,
the CCB Secretariat will maintain status records with sufficient detail so that
the history of each configuration controlled item is available.
5.1 Status Reports
The CCB Secretariat will provide all CCB Members and affected program
participants with a Status Report on a monthly basis. For each OPEN RFC or DR,
the Status Report will provide:
Number
Title
Priority
Status
Actionee
Expected Completion Date
Required Completion Date (if any)
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - ganiiized Copy Approv;21-K;TIele;;e-26187087157-TEIA:RbP91-0135-5R0003001-50006-0
rage iz
6.0 FBIS CONFIGURATION AUDITS
Periodically, at the direction of the CCB Chairman, the CCB Secretariat
will conduct audits of element configuration management efforts to ensure
compliance with this plan. The audits will consist of an announced measurement
of conformance of personnel, product, or standards comprising the configuration
management system. The audits will be performed to assess the following:
Status and traceability of the implementation of approved changes into
the documentation and the related configuration controlled items.
Compliance with configuration management policies, procedures, and
practices.
At the conclusion of the audit a report will be sent to the organization
audited, outlining the specific items audited, findings of the audit, and
agreed-to corrective action, if any. Copies will also be distributed to
appropriate levels of FBIS management.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy ed fore - -01355 iibooicx3165006-0
ApprorniRiellekarns--361 CIA' lib P91
rage Ls
APPENDIX A
FBIS CCB MEETING PROCEDURES
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in"P'a-rter Slannilizted Copy ApprovenCifo-r-WeleAarnswen20.1370670V7 nolA"-Ri5P91-0135blibooi06155006-0
rage 14
1.0 FBIS CCB MEETING PROCEDURES
All CCB Members should be present or represented by a cognizant,
designated alternate. The CCB Chairman, or the Deputy Chairman in the absence
of the Chairman, may elect to proceed without full attendance.
The CCB Chairman will call the meeting to order and briefly reiterate
the CCB meeting procedures;
a) only topics on the announced agenda will be discussed, unless the
CCB Chairman agrees to entertain other topics;
b) the CCB Secretariat will announce each RFC or DR in turn, each will
be presented by its proponent, and the floor will be opened for CCB
Member discussion;
c) CCB discussion of each RFC of DR will cease when the CCB Chairman
determines that there has been sufficient discussion;
d) the CCB Chairman has the ONLY vote to approve, disapprove or defer
an RFC or DR.
The CCB Secretariat will have custody of the original copies of all RFCs
and DRs. The Secretariat or a designated alternate will announce the RFC or DR
and hand the original to the Chairman.
After an RFC or DR is announced the proponent should begin with a short
description of what the RFC or DR is about (description of change, need for
change, and any other information that pertains to why it was written). This
short synopsis insures that all persons in attendance know and understand the
facts which led to the RFC or DR being submitted. The proponent should include
the results of Technical Exchange Meetings (TEM's), the recommendations or
requests of any other party, and a final recommendation, based on the summation
of the data and circumstances associated with the RFC or DR.
At this point, the floor will be opened for CCB Member discussion, and
other parties can agree with what been has reported or recommended, or they can
recommend an alternative action.
When the CCB Chairman determines that there has been sufficient
discussion of the RFC or DR, the CCB Chairman will call a stop to the
discussion and make a decision to:
a) approve the RFC or DR as is, or
b) approve the RFC or DR with modifications, or
c) defer the RFC or DR until more data is available or issues can be
researched and resolved (must designate due date and actionee), or
d) reject the RFC or DR with the CCB Secretariat recording the reason.
The CCB Chairman will announce the decision to the CCB and then pass
around the original copy of the RFC or DR so that the CCB Members can record
their recommendations on the coverpage.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
%inn AF Ar m esAtterrAtm en
?watt ?it ? ??? A...intern n? ? .? I ,
Declassified in Part :Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage io
Appendix B
FBIS DOCUMENTATION IDENTIFICATION
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
unn AAA OAIA ninreme? An,-,... nAnsmnivanni m a ty 1 va___k innn
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage so
1.0 DOCUMENTATION IDENTIFICATION
Each document under Configuration Control will be identified by a Title,
Identification Number and Date of Issue on the title page, beginning with the
original issue. The Identification Number and Date of Issue on the document
will be updated only when the document is reissued. When a set of change pages
is published, the approval date of the initiating RFC or DR will be placed on
each change page, and change identification marks will be placed in the
right-hand margin. These change identification marks will remain until the
next time that page is modified, at which time new markings will be drawn for
that page.
1.1 Title of the Document
Each document will be given a unique descriptive title.
1.2 Identification Number
All Modernization Program Documents will be assigned a unique
Identification Number using the following format:
MPD-ABB-CCCD
where A is the one character Segment Identifier, BB is the two character
Subsystem Identifier, CCC is the three character Document Identifier and D is
the one character Revision Letter. These Identifiers shall be used as assigned
below:
A = Segment Identifier
0
= Overall
3
= Communications 6 = Unassigned
1
. Headquarters
4
. Transmission 7 = Unassigned
2
= Bureau
5
= Unassigned 8 . RFP
9 = Program Control
BB = Subsystem Identifier
00
= N/A
04
= Data Management 08 = Collection
01
= Unassigned
05
= Publications 10 = INTERNET
02
= Unassigned
06
= Processing 09 = ROSET
03
= User
07
= Monitoring/Editing 11-99 = Unassigned
CCC = Document Identifier
001-099 = Specifications
100-199
200-299
300-399
400-499 =
Concept of Operations
ICDs
Functional Designs
Test & Verification
D Revision Letter
No letter indicates
A = First Revision
B = Second Revision
etc.
500-599
600-699 .
700-799
800-899
900-999
the original version.
Installation Plans &
Procedures
Test Reports
Facilities
Management
Engineering
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
FOREIGN BROADCAST INFORMATION SERVICE
OPERATIONAL CONFIGURATION MANAGEMENT PLAN
MPD-000-811A
1 March 1988
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Fa i; ftman'iltizled Copy Approved for R-e-Inenare"2-013/0FOTCIA-RDP91-013561R0003b0I55606-0
CHANGE LOG
TITLE: PHIS OPERATIONAL CONFIGURATION MANAGEMENT PLAN MPD-000-811A
REV DATE
PAGES AFFECTED
RFC NO.
A
3/1/88
i, 2, 3, 6, 7, 8, 9, A-2, Appendices B,
CI D, E, F
HU-RFC-C-002-88
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
mtm_nnn_ollA . 'an^
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
TABLE OF CONTENTS
1.0 INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 Reference Documents
1.4 Overview
2.0 ORGANIZATION AND RESPONSIBILITIES
2.1 Engineering Review Board
2.2 ERB Membership
2.3 ERB Meetings
2.4 ERB Secretariat
3.0 OPERATIONAL BASELINE CONFIGURATION IDENTIFICATION
3.1 Operational Software and Database System Baseline
Identification
3.2 Operational Hardware and Facility Baseline
Identification
3.3 Operational Documentation and Procedures Baseline
Identification
4.0 OPERATIONAL BASELINE CONFIGURATION CONTROL
4.1 Configuration Control
4.2 Discrepancy Report Management
4.3 Request for Change Management
4.4 Prioritization of DR and RFC Effort
4.5 Coordination of System Level Impacts
4.6 Baseline Change Implementation
4.7 Emergency Corrective Action
5.0 OPERATIONAL BASELINE CONFIGURATION AUDITS
6.0 TRANSITIONAL BASELINE CONFIGURATION CONTROL
6.1 Transition ERBs
6.2 Transition ERB Membership
APPENDIX A
APPENDIX B
APPENDIX C
APPENDIX D
APPENDIX E
APPENDIX F
ERB Charters and Membership
ERB Meeting Procedures
Discrepancy Report Processing
Request for Change Processing
Priority System
Build Request Processing
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
--.----..
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-0135.5kookerf66006-0
Fage
1.0 INTRODUCTION
(1 1.1 Purpose
C.
c_
The purpose of this document is to define and establish the
organizations, functions, and procedures required to implement Configuration
Management for operational FBIS automated and technical systems.
1.2 Scope
This plan encompasses the management structures and procedures required
to exercise Configuration Management (CM) for all operational FBIS automated
and technical systems.
1.3 Reference Documents
This plan is derived from the following documents and is a subordinate,
supporting document. In the event of a conflict between this plan and the
referenced documents, the referenced documents will prevail.
D/FBIS MEMO on Configuration Management, dated 22 Feb 1985
FBIS Configuration Management Plan, MPD-000-801
1.4 Overview
FBIS automated and technical system life cycle configuration management
concepti and procedures are presented in the FBIS Configuration Management
Plan, MPD-000-801. This Operational CM Plan is subordinate to MPD-000-801, and
expands the concepts and procedures of MPD-000-801 to address the delivery,
transition, operation, maintenance, and enhancement of systems during their
operational life cycle. The fundamental concepts addressed are:
a. Operational Engineering Review Board Functions
b. Identification of Operational Baselines
c. Configuration Control of Operational Baselines
Configuration Management disciplines essential to low risk implementation and
transition of system deliveries and upgrades are also addressed.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355140003001-66006-0
rage z
2.0 ORGANIZATION AND RESPONSIBILITIES
As established in MPD-000-801, the FBIS CCB has responsibility and
authority to exercise configuration management of all FBIS automated and
technical systems during all phases of their specification, development,
installation, transition, operation, maintenance and enhancement. In order to
exercise operational configuration management of FBIS automated and technical
systems, the FBIS CCB Chairman may establish subordinate Engineering Review
Boards (ERBs). Each ERR will be tasked with exercising operational
configuration management for specific FBIS automated or technical system(s).
The identity, area of responsibility, and specific membership of each ERR will
be prescribed by the FBIS CCB Chairman and will be published in Appendix A of
this plan. The following paragraphs describe an ERB and other supporting
organizations.
2.1 Engineering Review Board
Each established ERR will have primary responsibility for providing
day-to-day technical and management oversight of its assigned system
operational baseline configuration. Each ERR will function as a technical and
operational arm of the FBIS CCB. As such, it will be tasked with ensuring that
the identity and integrity of the system operational baseline configuration is
maintained and that all system facility, software, hardware, documentation, and
procedure changes are thoroughly evaluated and properly documented before
implementation. Each ERR performs the following functions:
a. Software and Database System Baseline Configuration Identification
and Change Control,
b. Hardware and Facility Baseline Configuration Identification and
Change Control,
c. Documentation and Procedures Baseline Identification and Change
Control,
d. Discrepancy Report Management,
e. Request for Change Management,
f. Build Request Management,
g. Prioritization of DRs and RFCs, and
h. Coordination of impacts to CCB controlled baselines.
2.2 ERR Membership
Refer to Appendix A for the charter and membership of each ERR.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
mnn AAA 011A
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-013561R00030 -
0155606-0
rage .5
2.3 ERB Meetings
Each ERB will meet regularly at the discretion of the ERB Chairman.
Unless otherwise stated, ERB meetings are open to all members of FBIS and their
consultants when their areas of interest or responsibility are on the agenda.
Refer to Appendix B for a description of the specific ERB Meeting Procedures.
2.4 ERB Secretariat
The ERB Secretariat will be responsible for providing administrative
support to each ERB in order to facilitate its functions and to implement its
directives. The ERB Secretariat reports to the Chairman of each ERB. The ERB
Secretariat will:
a. administer the FBIS Discrepancy Report (DR) system,
b. administer the FBIS Request for Change (RFC) system,
c. administer the FBIS Build Request (BR) system,
d. administer the FBIS Change Control Approval and Tracking System for:
-- Facilities and Hardware
-- Software and Database Systems
-- Documentation and Procedures
e. prepare agendas and minutes of the meetings, and
f. track the status of action items.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
ulIT AAA 011A AMDflAMT0MAT /MS fly AM
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage 4
3.0 OPERATIONAL BASELINE CONFIGURATION IDENTIFICATION
As directed by the cognizant ERB Chairman, the ERB Secretariat, in
concert with appropriate FBIS elements and contractors, is responsible for
generating an accurate and complete identification of each system technical
operational baseline configuration using contractually deliverable
documentation, to the extent possible. This baseline configuration will
include all operational facilities, hardware, software, database systems,
documentation, and procedures which fall under the ERB.
3.1 Operational Software and Database System Baseline Identification
All operational software and database systems baselines will be
identified and controlled. These baselines will include:
a. operating system vendor products and installation-specific
parameters,
b. vendor provided layered products and associated installation
procedures and parameter sets,
c. job/procedure control language files used to initiate and/or control
processing or utility functions,
d. source and executable files and all procedural and support files
required to create each executable element from its component source
elements,
e. database definition files and related information including DDL,
schema, sub-schema definitions etc.,
f. fixed data sets, structured or unstructured, necessary to support
system operations or to restore the system to a default or restart
configuration, and
g. other elements as necessary or directed by the ERB Chairman.
All operational software and database systems baselines identified in
the baseline configuration will be documented in the FBIS Baseline
Configuration Document or its component contractually deliverable
documentation. The software and database baselines will be subject to
configuration control when delivered. Changes to these baselines will require
FBIS CCB or ERB approval.
3.2 Operational Hardware and Facility Baseline Identification
All operational hardware and facility baselines will be identified and
controlled. These baselines will include:
a. the hardware manufacturer, model, revision level, number of units,
installed location, and date of installation,
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part-Sanitized Copy Approved for lieleZ.2-0.1.3/66/07:.elA-RDP91-01 355R000306166-006-0
rage D
3.2 Operational Hardware and Facility Baseline Identification (cont'd)
b. the physical dimensions, weight, power/cooling requirements,
functionality,
c. the as-built system diagrams (e.g., system power grids, system
signal cabling, communications, system HVAC and UPS connections,
etc.), and
d. the as-built facility blue prints, electrical grids, signal cabling
grids, phone lines, communications lines, HVAC systems, UPS systems,
etc.
All operational hardware and facility baselines identified in the
baseline configuration will be documented in the FBIS Baseline Configuration
Document or its component contractually deliverable documentation. This
documentation will include schematics, interface specifications, maintenance
manuals, drawings and parts lists, where appropriate. The hardware and
facility baselines will be subject to configuration control when delivered.
Changes to these baselines will require FBIS CCB or ERB approval.
3.3 Operational Documentation and Procedures Baseline Identification
All operational documentation and procedures baselines will be
identified and controlled. These baselines will include:
a. procedural and management documentation,
b. technical documents (e.g., specifications, drawings, plans, and
manuals) which define current FBIS operational capabilities, and
specified documents which describe new or modified capabilities
under development, and
c. the system baseline configuration document and its component
contractually deliverable documentation.
All operational documentation and procedures baselines identified in the
system baseline configuration will be documented in the FBIS Baseline
Configuration Document or its component contractually deliverable
documentation. The documentation and procedures baselines will be subject to
configuration control when delivered. Changes to these baselines will require
FBIS CCB or ERB approval.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
'inn AAA 011A 0111,11ATTAMAT AU TI? ALT
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
nage o
4.0 OPERATIONAL BASELINE CONFIGURATION CONTROL
Configuration Control is the process by which changes to the FBIS
baseline configuration are initiated, evaluated, approved, implemented and
verified. This process ensures analysis of changes that affect requirement
satisfaction and provides for controlled changes to the FBIS baseline
configuration. The functions and mechanisms essential to implement operational
baseline configuration control of FBIS automated and technical systems are
described below. The specific detailed procedures to perform these functions
are described in the referenced Appendices to this plan.
4.1 Configuration Control
Configuration Control requires that no changes be made to any FBIS
baseline under configuration control, without the approval of the FBIS CCB or
cognizant ERB. There are two control mechanisms, initiated by any program
participant, which drive the entire change process. The Discrepancy Report
(DR) is prompted by a problem or failure in the operational baseline
configuration. The Request for Change (RFC) is prompted by a desire or a
requirement for a change to the operational baseline configuration.
4.2 Discrepancy Report Management
All problems encountered in the operation, test or analysis of FBIS
operational hardware, software, database, facility, documentation, or procedure
baselines will be documented in an FBIS Discrepancy Report (DR). The DR serves
as the mechanism for reporting and resolving all operational and technical
system problems. Each ERB exercises technical review and decision authority
for the disposition of all DRs submitted for its system.
The ERB processes each DR from initial review and prioritization,
assignment and review of the technical analysis, review of the proposed
corrective action, certification of the correctness of maintenance action,
authorization of the implementation of corrections, to final closure of the DR.
The ERB Secretariat is responsible for the orderly flow, correctness
status accounting, and quality assurance for all DR processing. The ERB
Secretariat is responsible to the ERB Chairman for the timely and accurate
processing of all DRs and related information. The ERB Secretariat will ensure
that required documentation changes are completed and distributed before the DR
is closed.
Refer to Appendix C for a detailed description of Discrepancy Report
Processing.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-013561R000300160.006-0
rage /
4.3 Request for Change Management
All upgrades and enhancements to the FBIS operational hardware,
software, database, facility, documentation, or procedures baselines will be
documented in a FBIS Request for Change (RFC). The RFC serves as the mechanism
for requesting and incorporating all upgrades and enhancements to the
operational system. Each EKE exercises technical review and decision authority
for the disposition of all RFCs submitted for its system.
The ERB.processes each RFC from initial review and prioritization,
assignment and review of the technical analysis, review of the proposed change
(including estimated cost and schedule), certification of the correctness of
the change, authorization of the implementation and/or installation of the
change, to final closure of the RFC.
The ERB Secretariat is responsible for the orderly flow, correctness,
status accounting, and quality assurance for all RFC processing. The EKE
Secretariat is responsible to the EKE Chairman for the timely and accurate
processing of all RFCs and related information. The EKE Secretariat will
ensure that required documentation changes are completed and distributed before
the RFC is closed.
Refer to Appendix D for a detailed description of Request for Change
Processing.
4.4 Prioritization of DR and RFC Effort
The ERR Secretariat will administer a priority assignment and review
system for DRs and RFCs on behalf of each ERR. This system accomplishes two
major goals:
a. It discriminates between DRs and RFCs having an immediate and direct
impact upon the ability of FBIS organizations to perform their
respective missions, Category I; and those that do not have such an
impact, Category II.
b. It provides for the timely review of DRs and RFCs based on their
criticality, and a mechanism to upgrade or downgrade priorities on
the basis of EKE review and decisions.
Refer to Appendix E for a detailed description of the DR and RFC
Priority System.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified M Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-013551i000300100006-0
rage
4.5 Coordination of System Level Impacts
Each ERB has the responsibility to determine whether a proposed RFC
would impact any system level specification. In this context, system level
specifications include System Requirements specifications, and system level
ICDs. If these or other CCB controlled items, such as CCB approved program
schedules or budgets, would be affected, the proposed RFC must be reviewed and
approved by the FBIS CCB before implementation. Any such change must include
identification of all necessary changes to system level documentation.
4.6 Baseline Change Implementation
No change will be made to the controlled version of any FBIS operational
baseline configuration without a properly authorized Build Request (BR). BRs
are used by the FBIS CCB or the cognizant ERB to authorize the implementation
of one or more RFCs or DRs which have been approved by the FBIS CCB or the
cognizant ERB. Each BR must also include a description of the procedures to be
followed to generate, install, and verify the correctness of the change.
Additionally, specific instructions for removing the change, in the event that
problems are encountered, must be included. Refer to Appendix F for a detailed
description of Build Request Processing.
4.7 Emergency Corrective Action
Emergency corrective action, approved by the cognizant senior FBIS
Operations Supervisor, may be taken without a properly authorized Build Request
when it is operationally necessary.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
unn nnn 011A pin in a at
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-013561R000306100006-0
rage
5.0 OPERATIONAL BASELINE CONFIGURATION AUDITS
Throughout the system life cycle, the ERR will conduct audits of the
baseline configuration to ensure compliance with this plan and with the
procedures established to support configuration management of the operational
baseline configuration. These audits will consist of a periodic measurement of
the conformance of personnel and practices to the established policies,
procedures, and instructions comprising the Configuration Management system.
These periodic audits will be conducted on a two year cycle and will assess the
following:
a. Verify that the system operational baseline configurations in use
agree with the ERR approved system operational baseline
configurations, i.e., hardware, software, database systems,
facilities, documentation and procedures.
b. Verify the status of the implementation of approved changes to the
system operational baseline configurations.
c. Verify that configuration management policies, procedures and
practices are being followed.
At the conclusion of the audit, a report will be written detailing the
specific items audited, findings of the audit, and corrective action required.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
unn AAA 011A AnnnAmTnuAT nu TIT AM
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage IV
6.0 TRANSITIONAL BASELINE CONFIGURATION CONTROL
Major system deliveries and upgrades will normally be accomplished
following the typical sequence of development, site integration and testing,
formal test and readiness demonstrations, and transition to operations. The
system development baseline configuration must be smoothly transitioned to the
operational phase. This transition may be complicated by system testing and
correction efforts, as well as by any differences between the development
contractor's CM procedures and those of FBIS.
6.1 Transition ERBs
The FBIS CCB Chairman may establish Transition ERBs which will be
responsible for the oversight of configuration management activities for major
system deliveries and upgrades, in order to ensure the technical quality of
each delivery, a smooth and orderly transition to operations, and to facilitate
the transition to FBIS operational configuration management. The Transition
ERB is formed during the site integration and testing activity. Initially it
exercises oversight of the development organization's integration and test
activity. If the progress of the integration and test activity is nominal, no
intervention in the management or conduct of the activity occurs in its early
phases. As the development organization begins formal system tests, interface
tests, and operational demonstrations, the Transition ERB, in concert with the
development organization, ensures that the system baseline for these tests has
been properly identified prior to the test. DRs arising from these testing
activities are reviewed and prioritized by the Transition ERB based on its
assessment of their potential operational impact. The Transition ERB also
ensures that subsequent changes to the system baseline are NOT made without
appropriate DRs, RFCs, and BRs approved by the Transition ERB. Those changes
essential to a successful transition are given top priority and the integrity
of the system baseline, as well as the prior test results, will be preserved.
6.2 Transition ERB Membership
A Transition ERB will be chaired by the appropriate ESG Development
Manager. The Transition ERB will have membership from appropriate ESG
divisions and other FBIS groups. The ERB Secretariat will perform secretariat
functions for the Transition ERB.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
?
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-0135-5R000306166006-0
Page A-1
Appendix A
ERR CHARTERS AND MEMBERSHIP
A1.0 AFS Operational Engineering Review Board
Pursuant to the provisions of the FBIS Operational Configuration
Management Plan, MPD-000-811A, the Operational Engineering Review Board is
hereby established, effective 29 June 1987. The 0/ERB will be responsible for
implementing and enforcing baseline configuration identification, management,
and change control for all facilities, hardware, software, database systems,
documentation and procedures which are a part of the operational Automated FBIS
System, from the point in time when these elements first transition to support
of FBIS operations until they are retired from active service. The 0/ERB will
have the authority, subject to review/approval by the FBIS CCB, to identify any
AFS element as being part of the AFS operational baseline and as such, under
its configuration control.
A1.1 AFS Operational ERR Membership
C/HED will serve as the Chairman of the 0/ERB. The C/AFS Branch will be
the 0/ERB Deputy Chairman and will serve as the Chairman in the absence of the
C/HED. The 0/ERB Chairman may designate another 0/ERB member to act as the
Chairman in the absence of both regular Chairmen. The senior FBIS AFS
Operations Supervisor will have the authority to act on behalf of the 0/ERB
when it is operationally necessary to take 0/ERB action outside normal working
hours. In these cases the 0/ERB Chairman will be advised of such actions as
soon as possible so that these actions can be reviewed and acted upon at the
next 0/ERB meeting.
The membership of the 0/ERB will be as follows:
Chairman: C/HED
D/Chairman: C/AFS Branch
Members:
HED C/USB
HED C/EB /
ADD DC/ADD
ADD AFS COTR
FED Representative
OPS Representative
AG Representative
PROD Representative
AFS Contractor Representative
SI Representative
ERR Secretariat
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
mon_Ann_olle ADVDATTAMAT rm WATT 1 Month 10212
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
A2.0 FBA Engineering Review Board
Pursuant to the provisions of the FBIS Operational Configuration
Management Plan, MPD-000-811A, the FBA Engineering Review Board is hereby
established, effective 12 January 1987. The FBA ERB will be responsible for
implementing and enforcing baseline configuration identification, management,
and change control for all facilities, hardware, software, database systems,
documentation and procedures which are a part of the operational Field Bureau
Automation System, from the point in time when these elements first transition
to support of FBIS operations until they are retired from active service. The
FBA ERB will have the authority, subject to review/approval by the FBIS CCB, to
identify any FBA element as being part of the FBA operational baseline and as
such, under its configuration control.
A2.1 FBA ERB Membership
DC/ADD will serve as the Chairman of the FBA ERB. The AFS Bureau
Segment Manager will be the FBA ERB Deputy Chairman and will serve as the
Chairman in the absence of the FBA ERB Chairman. The FBA ERB Chairman may
designate another FBA ERB member to act as the Chairman in the absence of both
regular Chairmen. FBIS Bureau Chiefs will have the authority to act during
emergency situations. When necessary, Bureau Chiefs will take whatever action
is required in order to maintain bureau operations. In these cases the FBA ERB
Chairman will be advised of such actions as soon as possible so that these
actions can be reviewed and acted upon at the next FBA ERB meeting.
The membership
Chairman:
D/Chairman:
Members:
of the FBA ERB will be as follows:
DC/ADD
AFS Bureau Segment Manager
AFS COTR
FED Representative
HED Representative
OPS Representative
PROD Representative
AFS Contractor Representative
SI Representative
ERB Secretariat
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
LIDA AAA 011A 1-1131711 ATT"MA TIT AM
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage 1:1A
Appendix B
B1.0 ERB MEETING PROCEDURES.
B1.1 Purpose
Each ERB will be tasked with exercising operational configuration
management for specific FBIS automated or technical system(s). Each ERB will
have primary responsibility for providing day-to-day technical and management
oversight of its assigned system operational baseline configuration. Each ERB
will ensure that the identity and integrity of the system operational baseline
configuration is maintained and that all system facility, software, hardware,
documentation, and procedure changes are thoroughly evaluated and properly
documented before implementation. Each ERB serves as the focal point for
resolving conflicts between operational priorities and the availability of
staff or contract resources to support proposed or required maintenance
activities.
31.2 Applicability and Scope
All ERBs established by the FBIS CCB Chairman will follow these general
procedures. Specific procedures unique to each ERB will be established by each
ERB Chairman within these general procedures. '
31.3 Procedures
The ERB will meet regularly at the discretion of the Chairman. All ERB
Members should be present or represented by a cognizant, designated alternate.
The ERB Chairman, or the Deputy Chairman in the absence of the Chairman, may
elect to proceed without full attendance. The ERB Chairman will call the
meeting to order and announce the ERB agenda. The agenda will normally consist
of a review of new DRs and RFCs, a review of the status of DRs and RFCs being
worked by ERB Members or a contractor, a review of ERs submitted to the ERB, a
review of the status of ERB action items, and a period of open discussion.
Each ERB will review and prioritize new DRs and RFCs, and assign the DRs
and RFCs for technical investigation based upon the priority of the DR or RFC.
The results of the technical investigation will be reviewed by the ERB on or
before the assigned due date.
The ERB Members or contractors will present the status of assigned
DR/RFC investigation or corrective action efforts. The presenter should begin
with a short description of what the DR/RFC is about (description of the
problem/change, and any other information that pertains to why the DR/RFC was
submitted). This short synopsis insures that all persons in attendance ?
understand the facts which led to this DR/RFC being submitted. The presenter
should include the recommendations or requests of any other party, and a final
recommendation, based on the summation of the data and circumstances associated
with the DR/RFC. Each ERB Member will assist in this effort by providing the
ERB Chairman with their advice and recommendation concerning the DR or RFC,
adequacy of the corrective action to accomplish the intended objective, the
technical acceptability, and any cost or schedule impacts.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
ADVDAMTAMAT PM IMAM 1 U........t. 1(100
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rag= reg.
B1.3 Procedures (cont'd)
When the ERR Chairman determines that there has been sufficient
discussion of the DR or RFC, the ERR Chairman will stop the discussion, make a
decision on the disposition of the DR or RFC, and announce the decision to the
ERR. The ERR Chairman, subject to CCB Chairman budget, schedule, and policy
guidlines, may approve completion of these efforts, alter due dates to reflect
changing priorities, and direct follow-up investigation and due dates. The
decision authority to approve, disapprove, or defer disposition of any DR or
RFC rests solely with the ERR Chairman. The ERR Secretariat will track the
status of DR/RFC investigation or corrective action efforts.
The Contracting Officer's Technical Representative (COIR), as a member
of the ERR, advises the ERR Chairman as to the availability and adequacy of
program maintenance support resources. After approving the corrective or
maintenance action, the ERR Chairman will authorize the COTR to provide the
corresponding contractual direction to the appropriate contractor.
The ERR requires that the results of all approved DRs or RFCs to the
FBIS systems software, database, hardware, facility, procedures or
documentation baselines must be documented on a Build Request. ERs will be
submitted to the ERR for each resolved DR or RFC prior to implementation. A BR
may contain the documentation of more than one resolved DR or RFC. The ERR
will review each new BR, verify the priority, and assess the implementation
impact on the FBIS systems. If the BR is complete, accurate and ready for
implementation, the ERB will approve the BR and authorize implementation of the
BR. The ERR will assign an implementation date for the BR based upon the
priority of the BR and the system impact entailed in the implementation of the
BR. If the BR is not considered to be ready for implementation, the ERR will
document the required changes to the BR. The ERR will defer approval of the
BR.
The completion of BR implementation will result in ERR closure of the
BR. The formal closure of a BR by the ERR will include a listing of the
approved DRs or RFCs resolved by the implementation of the BR. Formal closure
of the BR will constitute formal closure of these DRs or RFCs. The ERR
Secretariat will process the formal BR closure and the ERR will report the
closure of the BR in the ERR meeting report.
The ERR Members or contractors will present the status of assigned ERR
Action items. The ERR Chairman will approve completion of action items, alter
action item due dates to reflect changing priorities, assign follow-up action
items and due dates and assign new action items and due dates. The ERR
Secretariat will track the status of ERR action items.
Each ERR will provide a period of open discussion to provide a forum for
general topics of interest to the ERR, such as, ERR policies, provision of
maintenance spares, or installation and training schedules.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
talitT nnn 011A et nn tn. n- a s ? ens 1%?.
v sT t? I la
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage u-s
Appendix C
DISCREPANCY REPORT PROCESSING
.C1.0 DISCREPANCY REPORT (DR) PROCESSING
C1.1 Purpose
Standardized discrepancy reporting procedures have been created to
enable each ERB to provide efficient and timely technical assistance and
support to the FBIS systems. These proceduresiwill provide the FBIS users with
a standardized means of reporting problems.
C1.2 Applicability and Scope
The requirements of this appendix apply to the operational FBIS systems
which are the responsibility of the ERBs chartered in Appendix A. Personnel
involved in the preparation and processing of DRs for the operational FBIS
systems are required to follow the procedures in this appendix.
C1.3 Procedures
C1.3.1 Discrepancy Report Submissions
Each ERB requires that all problems encountered in the operation of
each FBIS system must be documented on a Discrepancy Report. DRs will be
submitted for ERB information and tracking even if the problem has already been
corrected. DRs will be submitted for the following conditions:
a. Any software or database related problem.
b. Any hardware failure or facility problem.
c. Any procedure or documentation problem.
The ERB will review DRs, assign priorities and actionees to investigate and
resolve discrepancies, review engineering analysis of discrepancies, approve
corrective action and authorize implementation of corrective action. The ERB
will be responsive to the FBIS system users in the resolution of DRs, but it is
incumbent upon the users to initiate the process by submitting the DR.
CJ.3.2 Discrepancy Report Format
Each originator is responsible for preparing the DR using the form
shown in Figure C1.3.2-1. This form should be filled out as completely and
accurately as possible. DRs which do not contain sufficient information can
not be processed by the ERB.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
linn Art0 011A nem ? inn-raw ra nt A at It
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage kri.
C1.3.2.1 Discrepancy Report Number
All DRs will be assigned a DR Number by the ERB Secretariat. This
number will uniquely identify the DR for reference in correspondence and the DR
database. The DR Number will be specified as follows:
VV-DR-X-YYY-ZZ
where VV is the FBIS Segment digraph, X is the ERB or CCB designator, YYY is a
three digit sequential number for each Segment, and ZZ is the two digit year
number. Examples of these identifiers are detailed below:
VV = FBIS Segment Digraph
CO AFS Communications Segment
HU AFS Headquarters Unclassified Segment
HC AFS Headquarters Classified Segment
FC AFS Facilities
FS AFS Field Segment
X = FBIS Board Designator
ERB
FBIS CCB
YYY = Sequential Number
A rising sequential number for the FBIS Segment affected by the DR,
ranging from 001 to 999. This number is reset at the beginning of a new
calendar year.
ZZ = Year Number
The calendar year during which the DR is initiated.
Examples: C0-DR-E-002-87 Second DR for the Commo Segment submitted to the
ERB during 1987.
HU-DR-C-033-87 33rd DR for the Headquarters Unclassified Segment
submitted to the CCB during 1987.
C1.3.2.2 Discrepancy Report Categories
DRs will be designated as either Category I or Category II depending
on their impact to the operational FBIS system. Category I DRs are defined as
having an immediate and direct impact upon the FBIS system or the ability of
FBIS organizations to perform their respective missions. Category II DRs do
not have such an impact.
C1.3.2.3 Discrepancy Report Priority
Refer to Appendix E for a description of ERB DR priorities.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-0135-5R900300155006-0
Page C-3
C1.3.2.4 Discrepancy Report Instructions
The DR will be completed using the instructions below, which are
keyed to Figure C1.3.2-1.
a. A short descriptive title of the problem.
b. DR Number (ERB Secretariat use only).
c. Date Submitted (ERB Secretariat use only).
d. Category of the DR.
e. Date and time the problem occurred.
f. Priority of the DR.
g. Identify the System and subsystem, such as, AFS HUCS - ATEX.
h. Identify the Hardware Configuration, if applicable.
i. Identify the Software Configuration, if applicable.
j. Identify the Database, if applicable.
k. If a procedural problem, identify the procedure.
1. Documents which would be affected by correction of the DR.
m. Describe operations in progress when the problem occurred.
it. Identify the workstation or terminal where the problem occurred.
o. Describe operations completed prior to the problem occurrence.
p.
Originator's name and phone number.
q. Approval signature of the originator's division chief and date.
r. Describe the problem completely and concisely.
s. Describe any trouble shooting/investigation done.
t. Describe any corrective action taken or work arounds used.
u. List any references used in trouble shooting the problem.
v. Describe the level of impact to the system/operations.
w. List similar occurrences, if any, including DR#.
x. Name of person who corrected the DR.
y. ERB Chairman approval of corrective action implementation.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
mun_nnn_ollA etlIDTIAMTAVIAT nj fly an
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-013&5R000300160006-0
rage U-4
FBIS
Discrepancy Report
Problem Identification: a
DR Number: b
Problem Date: e
Date Submitted: c
Problem Time: e
Category: d
Priority: f
System: g Subsystem: g
Hardware Configuration: h
Software Configuration: i
Database: j
Procedure: k
Affected Documents: 1
Title:
Scenario: m
Prior Ops: o
Originator: p
Approval for Submittal: q
Model #:
Serial
Application:
Version:
Number:
Location: n
Phone: p
Date: q
Problem Description: r
Analysis: s
Corrective Action: t
References/Documentation: u
Impact: v
Related Problems: w
Action Completed by: x
Approval: y
Status: Date Due: Date Closed:
Status Msg: Actionee:
Figure C1.3.2-1
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in"F;art - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-0135-5kooao6i66006-0
rage U-D
C1.3.3 Discrepancy Report Processing
DRs will be submitted to the ERB Secretariat, where they will be
reviewed for completeness, assigned a DR Number, and entered into the DR
database. The ERB Secretariat will make any pre-ERB meeting distribution
required and add the DR to the ERB agenda. The ERB Secretariat will track the
status of DRs and provide periodic and ad hoc reports as required.
The ERB will review each new DR, assign a priority and an actionee
to investigate the DR. As part of the review process, the ERB will review the
category and priority of the DR to verify that it is appropriate to the
criticality of the problem. The actionee will provide the results of the
technical investigation of the DR to the ERB by the due date assigned. The ERB
will assign the due date based upon the priority of the DR. The ERB will
review the results of the technical investigation of the DR and determine the
corrective action required. The technical investigation of a DR may indicate
that:
a. Although the system is not exhibiting the desired behavior, it is
performing in accordance with specifications. The ERB will declare
the DR to be non-discrepant. However, the ERB may decide that the
desired system behavior or attribute is a highly desirable new
system capability for ERB controlled software, databases, hardware
or facilities. In this case, a Request for Change (RFC) is the
appropriate mechanism. The ERB will direct the originator to submit
an RFC requesting the desired change. The RFC will be processed in
accordance with Appendix D of this plan.
b. A change is required to an ERB controlled operational procedure or
an ERB controlled document (e.g., non-system level specifications).
ERB approval of the corrective action for the DR will result in ERB
direction to the appropriate contractor or FBIS organization to
update and distribute the required procedure or document changes.
c. A change to CCB controlled software, databases, hardware, facilities
or documentation is required. The ERB will forward the DR to the
FBIS CCB for processing.
d. A change is required to ERB controlled software, databases,
hardware, or facilities to correct the DR and may also require a
change to ERB controlled documentation or procedures. ERB approval
of the corrective action for the DR will result in ERB direction to
the appropriate contractor or FBIS organization to develop, test and
implement the required changes as well as update and distribute any
required documentation or procedure changes.
The ERB will assign a due date for the completion of the corrective
action based upon the priority of the DR and the effort required to complete
the corrective action.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
'Ann nnn 011A AnDnATTnUAT nU t,. AM
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage tro
C1.3.4 Discrepancy Report Closure
The completion of DR processing will result in satisfying one of the
ERB DR closure requirements listed below.
a. The DR is non-discrepant and no corrective action is required. The
ERB will close the DR. If the ERB directed the originator to submit
an RFC, the ERB will close the DR upon receipt of the RFC.
b. The appropriate contractor or FBIS organization
update and distribute the procedure or document
correct the DR. The ERB will close the DR when
approved and implemented.
has provided a BR to
changes required to
the BR has been
c. The ERB has forwarded the DR to the FBIS CCB for processing and
closed the DR.
d.
The appropriate contractor or FBIS organization has developed and
tested the software, database, hardware, or facility changes
required to correct the DR, updated any required documentation or
procedure changes, and submitted a BR to the ERB for approval. The
ERB will close the DR when the BR has been approved and implemented.
The completion of BR implementation will result in ERB closure of the BR. The
formal closure of a BR by the ERB will include a listing of the approved DRs
resolved by the implementation of the BR. Formal closure of the BR will
constitute formal closure of these DRs. The ERB Secretariat will process the
formal BR closure and the ERB will report the closure of the BR in the ERB
meeting report.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release2013/08/07: CIA-RDP91-01365140001300160006-0
rage u-
Appendix.D
REQUEST FOR CHANGE PROCESSING
D1.0 REQUEST FOR CHANGE (RFC) PROCESSING
D1.1 Purpose
Standardized Request for Change procedures have been created to enable
each ERB to provide efficient and timely technical assistance and support to
the FBIS systems. These procedures will provide the FBIS users with a
standardized means of requesting a change.
D1.2 Applicability and Scope
The requirements of this appendix apply to the operational FBIS systems
which are the responsibility of the ERBs chartered in Appendix A. Personnel
involved in the preparation and processing of RFCs for the operational FBIS
systems are required to follow the procedures in this appendix.
D1.3 Procedures
D1.3.1 Request for Change Submissions
Each ERB requires that all desired changes to the operational FBIS
systems must be documented on a Request for Change. RFCs will be submitted for
all desired changes to the following parts of the FBIS systems.
a. Any software or database baseline.
b. Any hardware or facility baseline.
c. Any procedure or documentation baseline.
The ERB will review RFCs, assign priorities and actionees to investigate the
RFCs, review engineering analysis of the requested changes, approve development
action and authorize implementation of approved changes. The ERB will be
responsive to the FBIS system users in the processing of RFCs, but it is
incumbent upon the users to initiate the process by submitting the RFC.
D1.3.2 Request for Change Format
Each originator is responsible for preparing the RFC using the form
shown in Figure 0I.3.2-1. This form should be filled out as completely and
accurately as possible. RFCs which do not contain sufficient information can
not be processed by the ERB.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
ADVDATTAMAT OM DTAM 1 ma....- moo
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Laisc Ao-c
D1.3.2.1 Request for Change Number
All RFCs will be assigned an RFC Number by the ERB Secretariat.
This number will uniquely identify the RFC for reference in correspondence and
the RFC database. The RFC Number will be specified as follows:
VV-RFC-X-YYY-ZZ
where VV is the FBIS Segment digraph, X is the ERB or CCB designator, YYY is a
three digit sequential number for each FBIS Segment, and ZZ is the two digit
year number. Examples of these identifiers are detailed below:
VV = FBIS Segment Digraph
CO AFS Communications Segment
HU AFS Headquarters Unclassified Segment
HC AFS Headquarters Classified Segment
FC AFS Facilities
FS AFS Field Segment
X = FBIS Board Designator
ERB
FBIS CCB
YYY . Sequential Number
A rising sequential number for the FBIS Segment affected by the RFC,
ranging from 001 to 999. This number is reset at the beginning of a new
calendar year.
ZZ = Year Number
The calendar year during which the RFC is initiated.
Examples: CO-RFC-E-002-87 .Second RFC for the Commo Segment submitted to the
ERB during 1987.
HU-RFC-C-033-87 33rd RFC for the Headquarters Unclassified Segment
submitted to the CCB during 1987.
DI.3.2.2 Request for Change Priority
Refer to Appendix E for a description of ERB RFC priorities.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
UDTAVIA_011A ADVDAMTAMAT Ff1 n? An 1 17_1_ It-inn
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
rage U-.3
D1.3.2.3 Request for Change Instructions
The RFC will be completed using the instructions below, which are
keyed to Figure D1.3.2-1.
a. A short descriptive title of the desired change.
b. RFC Number (ERB Secretariat use only).
c. Contract Number of affected contract, in any.
d. Date Logged (ERB Secretariat use only).
e. Priority of the RFC.
f. Organization requesting the change.
g. Approval signature of the originator's division chief and date.
h. Originator's name and phone number.
i. Documents which would be affected by implementation of the RFC.
j. Description of the factors causing the need for the change.
k. Description of the proposed change.
1. Estimated cost and schedule impacts if the RFC is implemented, if
known.
m. Date Closed (ERB Secretariat use only).
n. Result (ERB Secretariat use only).
o. Engineering Review Board Comments (ERB Secretariat use only).
p.
q?
Status (ERB Secretariat use only).
Due Date (ERB Secretariat use only).
r. Actionee (ERB Secretariat use only).
s. Status Msg (ERB Secretariat use only).
t. Date Closed (ERB Secretariat use only).
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
mpn-000-aliti1 March 1988
OPERATIONAL CM PLAN
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
FBIS
Request for. Change
Title: a
RFC No.: b
Contract No.: c
Date Logged: d
Priority: e
Proponent of RFC: f
Approval for Submittal: g
Date: g
Originator: h
Telephone Number: h
Affected Documents: i
Title:
Number:
Need for Change: j
Description of Change: k
Cost/Schedule Impact: 1
Date Closed: m
Result: n
Board Comments: o
Status: p
Status Msg: s
Date Closed: t
Due Date: q Actionee: r
Figure D1.3.2-1
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
nnm nnn nIIA a.. -....
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300166006-0
rage LI-)
FBIS -
Request for Change
Member Recommendations:
Member Name I Approve Disapprove Defer I Date
C/ESG, CHAIRMAN
DC/ESG
C/ADD
C/E&PS
C/OPS
C/PROD
C/AG
DC/ADD
C/FED
C/HED
C.O.
ERB Chairman
Segment Mgr.
COTR
* Only these signatures required for ERR action.
Figure D1.3.2-1
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355k000.300105006-0
rage U-b
D1.3.3 Request for Change Processing
RFCs will be submitted to the ERR Secretariat, where they will be
reviewed for completeness, assigned an RFC Number, and entered into the RFC
database. The ERR Secretariat will make any pre-ERE meeting distribution
required and add the RFC to the ERR agenda. The ERR Secretariat will track the
status of RFCs and provide periodic and ad hoc reports as required.
The ERR will review each new RFC, assign a priority and an actionee
to investigate the RFC. As part of the review process, the ERR will review the
priority of the RFC to verify that it is appropriate to the criticality of the
change. The actionee will provide the results of the technical investigation
of the RFC to the ERR by the due date assigned. The ERR will assign the due
date based upon the priority of the RFC. The ERR will review the results of
the technical investigation of the RFC. The technical investigation of an RFC
may indicate that:
a. A change to ERR controlled operational procedures or documentation
(e.g., non-system level specifications) is desired. ERR approval of
the RFC would result in ERR direction to the appropriate contractor
or FBIS organization to update and distribute the required procedure
or documentation changes.
b. A change to ERR controlled software, databases, hardware, or
facilities is desired. Approval of the RFC may also require a
change to ERR controlled documentation or procedures. ERR approval
of the RFC would result in ERR direction to the appropriate
contractor or FBIS organization to develop, test and implement the
desired change as well as update and distribute any required
procedure or documentation changes.
c. A change to CCB controlled software, databases, hardware, .
facilities, or documentation is desired. The ERR will forward the
RFC to the FBIS CCB for processing.
If ERR approval of the RFC results in ERR direction to a contractor,
the ERR will direct the contractor to submit a proposal providing cost and
schedule estimates for the development of the desired change. The ERR will
also assign a due date for submission of the proposal. If the cost and
schedule estimates are approved by the ERR and the COTR, the contractor will be
directed to develop, test, and implement the desired change, as well as update
and distribute any required procedure or documentation changes. The ERR will
assign a due date for the completion of the change development action based
upon the priority of the RFC and the effort required to complete the change
development action.
The ERR, subject to CCB Chairman budget, schedule, and policy
guidlines, may approve, disapprove, or defer the RFC for consideration at a
later date.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
tint' nnn 011A a on
a a.aa a ..
.... .. a.. .
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355kookerf66006-0
rage 0-I
D1.3.4 Request for Change Closure
The completion of RFC processing will result in satisfying one of
the ERB RFC closure requirements listed below.
a. The appropriate contractor or FBIS organization has provided a BR to
update and distribute the procedure or document changes required to
implement the RFC. The ERB will close the RFC when the BR has been
approved and implemented.
b. The appropriate contractor or FBIS organization has developed and
tested the software, database, hardware, or facility changes
required to implement the RFC, updated any required procedure or
documentation changes, and submitted a BR to the ERB for approval.
The ERB will close the RFC when the BR has been approved and
implemented.
c. The ERB has forwarded the RFC to the FBIS CCB for processing. The
ERB will close the RFC.
d. The ERB has disapproved the RFC. The ERB will close the RFC when
disapproved.
The completion of BR implementation will result in ERB closure of the BR. The
formal closure of a BR by the ERB will include a listing of the approved RFCs
resolved by the implementation of the BR. Formal closure of the BR will
constitute formal closure of these RFCs. The ERB Secretariat will process the
formal BR closure and the ERB will report the closure of the BR in the ERB
meeting report.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01365k000a00-100006-0
rage E-i
Appendix E
PRIORITY SYSTEM
E1.0 PRIORITY SYSTEM
E1.1 Purpose
The purpose of this appendix is to establish a standard priority system
for use in the preparation and processing of all DRs and RFCs for the
operational FBIS systems.
E1.2 Applicability and Scope
The requirements of this appendix apply to the operational FBIS systems
which are the responsibility of the ERBs chartered in Appendix A. Personnel
involved in the preparation and processing of all DRs and RFCs for the
operational FBIS systems will prioritize DRs and RFCs in accordance with this
appendix.
E1.3 Procedures
The ERB requires that priorities be assigned to all DRs and RFCs by the
originator. The assignment of a priority provides the ERB with an indication
of how critically the DRs and RFCs are viewed by the originator. Priorities
will be reviewed by the ERB and evaluated to verify that they are appropriate
to the criticality of the change. If the ERB changes the priority the
originator will be notified.
E1.3.1 Priorities
There are four priority levels in the ERB priority system. RFCs may
be assigned any one of the four priorities. Category I DRs may be assigned
only priorities A, and B. Category II DRs may be assigned only priorities B,
C, and D. The four priorities are described below.
Priority Definition
A All conditions related to an imminent threat to the safety of the
operators/users of the FBIS systems or a situation so severe that
operations cannot continue.
Such conditions are critical and their correction has absolute
priority. All other activities of the system support organization
will be curtailed if they interfere. System maintenance resources
will be applied in the most expeditious manner.
B All conditions related to maintaining the existing FBIS systems
capabilities and correcting performance deficiencies which impact
the quality and quantity of the FBIS product and its timely
production and delivery.
Such conditions are urgent and will be corrected as soon as
practical, consistent with the urgency of the situation.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
. _
Declassified in Part- Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Page E-2
E1.3.1 Priorities (cont'd)
Priority Definition
C All conditions related to operational efficiency and improvements.
The resolution of such conditions is routine and will be
accomplished in a timely fashion.
Those activities related to documentation updates, and other changes
which have no direct impact on operations.
Such activities are routine and will be accomplished on a not to
interfere basis with other activities.
All DRs and RFCs must be assigned a priority. No set of definitions
covers all situations, and the definitions above should be considered as
explanatory and not exclusive. Conditions not covered by the definitions, will
be assigned a priority by the ERB Chairman. Only the ERB Chairman may assign
Priority A to conditions not covered by the definition above.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-0135-5booao6-166006-0
rage te-1
Appendix F
BUILD REQUEST PROCESSING
F1.0 BUILD REQUEST (BR) PROCESSING
F1.1 Purpose
Standardized Build Request procedures have been created to enable each
ERB to provide efficient and timely technical assistance and support to the
FBIS systems. These procedures will provide a standardized means of
documenting and installing approved changes and corrections to the FBIS
systems.
F1.2 Applicability and Scope
The requirements of this appendix apply to the operational FBIS systems
'which are the responsibility of the ERBs chartered in Appendix A. Personnel
involved in the preparation and processing of BRs for the operational FBIS
systems are required to follow the procedures in this appendix.
FI.3 Procedures
FI.3.1 Build Request Submissions
The ERB requires that the results of all approved DRs or RFCs to the
FBIS systems software, database, hardware, facility, procedures or
documentation baselines must be documented on a Build Request. BRs will be
submitted to the ERB for each resolved DR or RFC prior to implementation. A BR
may contain the documentation of more than one resolved DR or RFC. The ERB
will review BRs, verify priorities and completeness, and authorize
implementation of the results of all approved DRs or RFCs to the FBIS systems.
F1.3.2 Build Request Format
Each originator is responsible for preparing the BR using the form
shown in Figure F1.3.2-1. This form should be filled out completely and
accurately. BRs which do not contain sufficient information will not be
approved by the ERB.
F1.3.2.1 Build Request Number
All BRs will be assigned a BR Number by the ERB Secretariat. This
number will uniquely identify the BR for reference in correspondence and the BR
database. The BR Number will be specified as follows:
VV-BR-X-YYY-ZZ
where VV is the FBIS Segment digraph, X is the ERB or CCB designator, YYY is a
three digit sequential number for each FBIS Segment, and ZZ is the two digit
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
DeclassffiediWrtral:Z;dCopyApprovedforieie;ST2b.le/(580:CIA-RDP91-0135-5bookaii66006-0
rage if-z
F1.3.2.1 Build Request Number (cont'd)
year number. Examples of these identifiers are detailed below:
VV = FBIS Segment Digraph
CO AFS Communications Segment
HU AFS Headquarters Unclassified Segment
HC AFS Headquarters Classified Segment
FC AFS Facilities
FS AFS Field Segment
X = FBIS Board Designator
ERB
FBIS CCB
YYY = Sequential Number
A rising sequential number for the FBIS Segment affected by the BR,
ranging from 001 to 999. This number is reset at the beginning of a new
calendar year.
ZZ = Year Number
The calendar year during which the BR is initiated.
Examples: CO-BR-E-002-87 Second BR for the Commo Segment submitted to the
ERB during 1987.
HU-BR-E-033-87 33rd BR for the Headquarters Unclassified Segment
submitted to the ERB during 1987.
F1.3.2.2 Build Request Priority
Each BR will be assigned a priority. The BR priority will be the
same as the highest priority of any resolved DR or RFC which is documented by
the BR.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
UnT nnn 011A en n
et nrt rn, a t. s ? te
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07 : CIA-RDP91-0135.5R000300100006-0
rage r-.5
F1.3.2.3 Build Request Instructions
The BR will be completed using the instructions below, which are
keyed to Figure F1.3.2-1.
a. A short descriptive title of the BR.
b. BR Number (ERB Secretariat use only).
c. Contract Number of affected contract, in any.
d. Date Logged (ERB Secretariat use only).
e. Priority of the BR.
f. Originator's name and phone number.
g. Indicate the type of change.
h. System/Subsystem affected by implementation of the BR.
i. Component affected by implementation of the BR.
j.
System impact created by implementation of the BR.
k. Documents which would be affected by implementation of the BR.
1. Description of the changes included in the BR.
m. Installation procedures.
n. Verification procedures.
o. Results of Verification procedures.
p. Acceptance signature of system operator/administrator.
q. Backout procedures.
r. ERB Chairman Approval signature and date.
s. Engineering Review Board Comments (ERB Secretariat use only).
LDeclassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
-Fart reiSaaniiti.i .
Sanitized Copy Approved for Release -CIA-RDP91-01365k000800
Declassified in 100006-0
rage i'-4
FBIS
Build Request
Title: a
BR No.: b Contract No.: c
Date Logged: d Priority: e
Originator: f Telephone Number: f
Type Change: g Software Hardware Facility Procedure Documentation
System/Subsystem Affected: h
Component Affected: i
System Impact: j
Affected Documents: k
Title: Number:
Description of Change: 1
(Include DRs/RFCs resolved)
Installation Procedures: in
Verification Procedures: n
Result: o Acceptance: p
Backout Procedures: q
ERB Chairman Approval: r Date: r
Board Comments: s
Figure F1.3.2-1
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
ADVDAMTAMAT nu mitt/ I vs---1- man
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0
nage r-*-1
F1.3.3 Build Request Processing
BRs will be submitted to the ERB Secretariat, where they will be
reviewed for completeness, assigned a BR Number, and entered into the BR
database. The ERB Secretariat will make any pre-ERB meeting distribution
required and add the BR to the ERB agenda. The ERB Secretariat will track the
status of BRs and provide periodic and ad hoc reports as required.
The ERB will review each new BR, verify the priority, and assess the
implementation impact on the FBIS systems. If the BR is complete, accurate and
ready for implementation, the ERB will approve the BR and authorize
implementation of the BR. The ERB will assign an implementation date for the
BR based upon the priority of the BR and the system impact entailed in the
implementation of the BR. If the BR is not considered to be ready for
implementation, the ERB will document the required changes to the BR. The ERB
will defer approval of the BR.
F1.3.4 Build Request Closure
The completion of BR implementation will result in ERB closure of
the BR. The formal,closure of a BR by the ERB will include a listing of the
approved DRs or RFCs resolved by the implementation of the BR. Formal closure
of the BR will constitute formal closure of these DRs or RFCs. The ERB
Secretariat will process the formal BR closure and the ERB will report the
closure of the BR in the ERB meeting report.
Declassified in Part - Sanitized Copy Approved for Release 2013/08/07: CIA-RDP91-01355R000300100006-0