File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/metho/96/x96-1045_metho.xml
Size: 16,773 bytes
Last Modified: 2025-10-06 14:14:26
<?xml version="1.0" standalone="yes"?> <Paper uid="X96-1045"> <Title>Reason for Proposed Change Requestor Requestor</Title> <Section position="3" start_page="350" end_page="351" type="metho"> <SectionTitle> TIPSTER II: </SectionTitle> <Paragraph position="0"/> </Section> <Section position="4" start_page="351" end_page="359" type="metho"> <SectionTitle> 3.0 ORGANIZATION </SectionTitle> <Paragraph position="0"> The structure, roles and responsibilities of the Configuration Management organization are defined in the paragraphs below.</Paragraph> <Section position="1" start_page="351" end_page="353" type="sub_section"> <SectionTitle> 3.1 Organizational Structure </SectionTitle> <Paragraph position="0"> The TIPSTER II SE/CM project employs a Configuration Management organization to establish CM procedures, oversee the application of these procedures by all team members and provide all necessary reports and support for the CM function. The overall TIPSTER Text Phase II program organization, depicted in Figure 3-1, identifies the relationship of the SE/CM support function with other TIPSTER components. This complex structure consists of the multi-agency Executive Committee and Architecture Committee, architecture contractors, demonstration and prototype development contractors, COTRs and the SE/CM contractor. Figure 3-2 illustrates the functional structure of the CM organization.</Paragraph> </Section> <Section position="2" start_page="353" end_page="355" type="sub_section"> <SectionTitle> 3.2 Roles and Responsibilities </SectionTitle> <Paragraph position="0"> The following paragraphs describe the roles and responsibilities of each project element involved in the CM function. Figure 3-3 illustrates the organizational structure of the SE/CM organization.</Paragraph> <Paragraph position="1"> The Program Manager (PM) assists the Chair of the Architecture Committee in meeting the objectives of the TIPSTER Architecture and Demonstration programs, with respect to requirements definition, coordination of disparate contractors and approaches, and supervision of the configuration management and verification/validation efforts. Compliance with the guidelines and procedures specified in this plan is the primary responsibility of the program manager along with the CM Manager (CMM). The PM is responsible for approving the tailoring of CM policies, practices, and procedures to ensure that adequate methods are implemented for identification and control of the TIPSTER Architecture.</Paragraph> <Paragraph position="2"> The Program Manager ensures that: * Adequate CM resources, including CM tools, are made available.</Paragraph> <Paragraph position="3"> * CM plans and procedures are approved by the Architecture Committee Chair.</Paragraph> <Paragraph position="4"> * Documented and approved CM practices and procedures are followed by all team members. * CM personnel are trained in the objectives, procedures, and methods for performing their assigned CM activities.</Paragraph> <Paragraph position="5"> * CM requirements, processes, and practices are conveyed to all TIPSTER team members for compliance.</Paragraph> <Paragraph position="6"> The CM Manager (CMM) will report to the TIPSTER SE/CM Program Manager. The CMM is responsible for (a) implementing a CM system which is tailored for the unique features of the TIPSTER Text Phase II Program and (b) developing CM procedures to assure control of documentation. To support the preparation of configuration status reports, the CMM maintains a database containing the change status of all Architecture elements and changes. To assure the integrity of all items placed within CM control, the CMM establishes and maintains both electronic and hard copy libraries with access limited to CM personnel. The CMM acts as the point of contact for receiving and processing information from external organizations. Incoming and outgoing shipments of CM controlled items will be handled by the CMM. The CMM is also responsible for performing and supporting both formal and informal audits conducted at appropriate milestones during the Architecture life cycle.</Paragraph> <Paragraph position="7"> The CMM is a regular participant in all ERB and CCB meetings. The role of the CMM is to schedule these meetings, provide an agenda, record and disseminate minutes, and track action items.</Paragraph> <Paragraph position="8"> The CMM, in performing the foregoing responsibilities, will have the independence and authority to coordinate and communicate CM functions with management and technical personnel involved in the Architecture effort. All management and technical personnel are required to be familiar with and comply with the provisions of this CM plan, as well as being responsible for certain configuration activities in support of CM functions. The following Table 3-1, CM Responsibilities and Relationships, is a matrix of the major CM functions and responsibilities of various management and technical personnel.</Paragraph> <Paragraph position="9"> A software architecture engineer will assist the Architecture Committee Chair by performing certain CM tasks. These tasks consist of reviewing/analyzing problem reports and change requests, and preparing recommendations to effect proposed changes or preparing a statement why the proposed change should not be made to the Architecture. 3.2.4 Verification and Validation Testing Engineer The Verification and Validation (V&V) Testing Engineer will develop and implement tests to determine if modules in TIPSTER Applications are consistent with the Architecture Design Document by ensuring that they conform to the specifics in the Architecture Design Document.</Paragraph> <Paragraph position="10"> Additionally, if necessary, the V&V Test Engineer will determine that shared components and modules interface as required, both in isolation and in combination with the other components and modules. Specifically, the interfaces must be as described in the TIPSTER Interface Control Document. Internal component processing capabilities do not come under the scope of V& V Testing. (See V&V Test Plan). The V&V Testing Engineer controls formal CSCI test procedure development prior to those components being placed under formal CM control, reports problems identified during formal CSCI testing to CM, and actively participates in ERB and CCB meetings.</Paragraph> </Section> <Section position="3" start_page="355" end_page="359" type="sub_section"> <SectionTitle> 3.2.5 Configuration Control Board (CCB) </SectionTitle> <Paragraph position="0"> The CCB is the Government review and action board comprised of key personnel from the Architecture Committee, SE/CM, and the appropriate contractors. The CCB provides a central point of coordination of changes to the baseline Architecture. The CCB is the focal point and the source of direction for implementation of Class I changes to the TIPSTER II Architecture.</Paragraph> <Paragraph position="1"> The CCB reviews each Class I change and makes a decision as to the disposition with the options of (a) approve the change, (b) disapprove the change, or (c) defer the proposed change. Each board member is allowed to state his/her official position on the proposed change. However, the CCB is a non-voting board. Thus, the CCB Chairman shall render the final decision as to the course of action to the taken. The CCB's decision is recorded as a Change Directive.</Paragraph> <Paragraph position="2"> The CCB's major responsibilities are: Other key personnel will be assigned to the CCB as the Chair may deem necessary to resolve particular issues. The CCB Chair will conduct the meeting and render the final decision to the course of action to be taken. The above members form the core of the CCB. If a member is unable to attend a meeting, he/she must designate a representative to attend in his/her place. The representative must have full authority to act on behalf of the missing member. Additional individuals are invited to participate, as appropriate, when their technical expertise is required. The ERB is an internal TIPSTER II Architecture review and action panel comprised of personnel from all project groups. Membership of the ERB is: The objectives of the ERB are disposition of problems, classification of proposed changes, and disposition of Class II changes. Upon receipt and disposition of a problem, the ERB will analyze it for type of problem, priority, and verification of the proposed solution. When the problem is fixed, the ERB will determine the implementation schedule of the fix into the affected baselines. Upon review of a change request, the ERB first determines the classification as either a Class I or Class II type of change. For Class I changes, the ERB assigns preparation of a Request For Change (RFC) to the responsible groups for submittal to the CCB for their review and disposition. Class II changes are within the scope of authority of the ERB for disposition. The ERB reviews each Class II change and then takes appropriate action for its disposition. Each panel member is allowed to state his/her position on the change. However, the ERB is a non-voting board. Thus, the ERB chairman shall render final decision as to the course of action to be taken. ERB decisions are recorded on Change Directives, a copy of which is sent to the CCB for information only.</Paragraph> <Paragraph position="3"> The TIPSTER Phase II evaluation working group (EWG) is tasked with designing, implementing, and coordinating evaluations intended to demonstrate the effectiveness of TIPSTER architectural approaches; thus, the EWG will be a user of the results of the CM process by using the appropriate Architectural version in their evaluations. The membership of the EWG is composed of the following core personnel:</Paragraph> </Section> </Section> <Section position="5" start_page="359" end_page="362" type="metho"> <SectionTitle> 4.0 CONFIGURATION MANAGEMENT ACTIVITIES </SectionTitle> <Paragraph position="0"/> <Section position="1" start_page="359" end_page="359" type="sub_section"> <SectionTitle> 4.1 TIPSTER CM Approach </SectionTitle> <Paragraph position="0"> The CM organization is responsible for identifying the specific items that define the Architecture and will be configuration controlled, as well as when and how they are to be controlled. CM conducts audits of the Architecture baseline to ensure conformance with the TIPSTER concept and to verify that the configuration management library system is functioning adequately.</Paragraph> </Section> <Section position="2" start_page="359" end_page="359" type="sub_section"> <SectionTitle> 4.2 Configuration Management Responsibilities </SectionTitle> <Paragraph position="0"> TIPSTER's CM responsibilities comprise baseline management, interface control, and the CM aspects of quality control in each of the following six areas which operate throughout the Architecture's life cycle: In the area of item and baseline identification and management, configuration management is responsible for baseline traceability and integrity by retention of all versions and releases of Architecture elements. As stated in Section 1, once an element is part of the baseline, it is placed under change control. In this area, configuration management has many responsibilities. These include administrative handling of all changes, from initial receipt and logging of Change Requests through issuance of Change Directives indicating final disposition. Configuration management prepares, publishes, and incorporates the change pages in the defining documentation. Configuration management personnel also act as the recording secretary for the two project change review organizations: the Engineering Review Board (ERB) and the Configuration Control Board (CCB).</Paragraph> <Paragraph position="1"> Configuration management has this status accounting responsibility where in monthly status reports for changes, problems, and action items are reported.</Paragraph> <Paragraph position="2"> Architecture files contain all written materials and documentation on the TIPSTER II Architecture. This critical area is the responsibility of configuration management.</Paragraph> <Paragraph position="3"> Finally, configuration management is responsible for formal delivery of all TIPSTER II Architecture defining documents to the Government.</Paragraph> </Section> <Section position="3" start_page="359" end_page="361" type="sub_section"> <SectionTitle> 4.3 Configuration Management Phasing and Milestones </SectionTitle> <Paragraph position="0"> The CM activities described in this CM Plan are initiated and completed in accordance with the Program Master Schedule. Table 4-1 is a list of major events/milestones and specifies the CM activities conducted and the planned dates for initiation and completion of each event/milestone.</Paragraph> </Section> <Section position="4" start_page="361" end_page="361" type="sub_section"> <SectionTitle> 4.4 Architecture Request For Change Process 4.4.1 The Goal </SectionTitle> <Paragraph position="0"> The SE/CM has five major goals with respect to the RFC process for the TIPSTER Architecture.</Paragraph> <Paragraph position="1"> follows: Submissions of RFCs can come from any source. developers, the CAWG, or the SE/CM.</Paragraph> </Section> <Section position="5" start_page="361" end_page="362" type="sub_section"> <SectionTitle> 4.4.2.1 Application Developer Submission </SectionTitle> <Paragraph position="0"> Submissions from applications developers will be They are as Provide for consistency in the development of the Architecture. Allow for changes, proposed on the basis of different versions of the Architecture, to be combined into a single change.</Paragraph> <Paragraph position="1"> Provide for consideration of changes proposed by any interested party. Encourage changes to the Architecture from anyone who has done an implementation. Provide for independent submission and review of proposed changes. It is expected that submissions will be made by application reviewed by the SE/CM and approved/disapproved by the Architecture Committee. As reviewer, the SE/CM will recommend minor modifications to the RFC to maintain a level of consistency in names and methods. If major modifications are necessary, the SE/CM may submit an entirely new RFC. The Architecture Committee will then have both RFCs to approve/disapprove. The CAWG will be able to evaluate the proposed changes and make suggestions to the SE/CM or the Architecture Committee. Any comments/recommendations by the CAWG will be an addendum to the formal RFC. As a minimum, the CAWG will receive the RFC when it is formally submitted to the SE/CM. Under normal circumstances, however, the SE/CM will be aware that changes are likely to be forthcoming from an application under development. In such cases, the SE/CM will keep the CAWG informed of the issue under discussion. In this way, the CAWG may be able to provide timely input to the application developer as to previously debated issues or 'known' work-arounds for the difficulty encountered.</Paragraph> </Section> </Section> <Section position="6" start_page="362" end_page="362" type="metho"> <SectionTitle> 4.4.2.2 CAWG Submission </SectionTitle> <Paragraph position="0"> Submissions from the CAWG will be reviewed by the SE/CM and approved/disapproved by the Architecture Committee. As reviewer, the SE/CM may recommend minor modifications to the RFC to maintain a level of consistency in names and methods.</Paragraph> </Section> <Section position="7" start_page="362" end_page="363" type="metho"> <SectionTitle> 4.4.2.3 SE/CM Submission </SectionTitle> <Paragraph position="0"> On rare occasions, submissions may come from the SE/CM and will be reviewed by the CAWG or other person(s) as designated by the Architecture Committee and approved/disapproved by the Architecture Committee. The reviewer may recommend minor modifications to the RFC to maintain a level of consistency in names and methods.</Paragraph> <Paragraph position="1"> If the reviewer is not the CAWG, the SE/CM will keep the CAWG informed of the issue under discussion. In this way, the CAWG will be able to provide comments and recommendations to the Architecture Committee.</Paragraph> <Paragraph position="2"> The RFCs will be available on the internet on the TIPSTER web page</Paragraph> </Section> <Section position="8" start_page="363" end_page="367" type="metho"> <SectionTitle> 5.0 GLOSSARY AND LIST OF ABBREVIATIONS </SectionTitle> <Paragraph position="0"> The terms and abbreviations listed below are used within this CM Plan. Their meanings are provided for the reader's convenience.</Paragraph> </Section> class="xml-element"></Paper>