<?xml version="1.0" standalone="yes"?>
<Paper uid="X96-1038">
  <Title>Final Operating Capability Review ERBProcess TIPSTER Program Can Support the Integration of New Technology and Algorithms</Title>
  <Section position="1" start_page="0" end_page="0" type="metho">
    <SectionTitle>
OVERVIEW AND ACCOMPLISHMENTS
THE SE/CM PERSPECTIVE
TIPSTER SE/CM
TIPSTER @TIPS TER. o r g
THE SE/CM PROCESS
</SectionTitle>
    <Paragraph position="0"> The SE/CM process, which is part of the overall TIPSTER program, includes the following responsibilities:</Paragraph>
  </Section>
  <Section position="2" start_page="0" end_page="0" type="metho">
    <SectionTitle>
* Track Application Conformance with
</SectionTitle>
    <Paragraph position="0"> the Architecture and the lessons learned are fed back into the Architecture for the purpose of refining those details which have been determined and specifying those interfaces which remain under specified. These changes are being managed by a</Paragraph>
  </Section>
  <Section position="3" start_page="0" end_page="212" type="metho">
    <SectionTitle>
CONFORMANCE TO THE
ARCHITECTURE
</SectionTitle>
    <Paragraph position="0"> The TIPSTER Architecture has been completed to the extent that the basic ~nctionality of components has been determined. Many interfaces, however, have not yet been defined to the level of detail which will be needed for the Government to meet its goals of software reuse and modular upgrading; i.e., they are under specified. The Architecture has been constructed with a high level of abstraction and flexibility. With these characteristics, applications can comply with the Architecture with relative ease, but the interface elements do not have enough constraints to be precisely defined in an Interface Control Document. As an example, specific annotation types have not yet been defined, specified and made available as a TIPSTER standard. In another example, the attributes for a document may be anything the developer chooses with no constraints on definition or scope.</Paragraph>
    <Paragraph position="1"> In TIPSTER Phase II, the Architecture is being tested by use in a number of applications Under these circumstances, conformance to the TIPSTER Architecture cannot be rigidly def'med. For the current Architecture, conformance is def'med as follows: Designs of applications or products are submitted to a TIPSTER Engineering Review Board (ERB). The ERB produces a TIPSTER</Paragraph>
    <Section position="1" start_page="0" end_page="212" type="sub_section">
      <SectionTitle>
Architecture Conformance Assessment Document
</SectionTitle>
      <Paragraph position="0"> (TACAD) detailing the ways in which the design complies with the Architecture and those where it does not. Regarding those places within the design which do not comply, the ERB issues a recommendation, that the Architecture be changed, that the design be changed, or that the exception be allowed. This recommendation is reviewed by the TIPSTER Configuration Control Board. All designs are kept on record, both in Design-to and As-built form, with the TIPSTER SE/CM.</Paragraph>
      <Paragraph position="1"> This process will result in an enrichment of the Architecture with the experience gained ffi'om specific implementations as well as the beginnings of a library of information about what TIPSTER compliant components exist throughout the Government community.</Paragraph>
      <Paragraph position="2"> Figure 1 shows the basic ERB process with two principal gates that a project must pass through. The ERB review just before the Preliminary Design Review is the first ERB to initially examine TIPSTER conformance. The level of conformance is documented in the TACAD. The final ERB occurs after the completion of the project implementation.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>