REG NASA-LLIS-1228--1999 Lessons Learned - Circular document referencing (establishing document relationships).pdf

《REG NASA-LLIS-1228--1999 Lessons Learned - Circular document referencing (establishing document relationships).pdf》由会员分享，可在线阅读，更多相关《REG NASA-LLIS-1228--1999 Lessons Learned - Circular document referencing (establishing document relationships).pdf（3页珍藏版）》请在麦多课文档分享上搜索。

1、Lessons Learned Entry: 1228Lesson Info:a71 Lesson Number: 1228a71 Lesson Date: 1999-03-22a71 Submitting Organization: JSCa71 Submitted by: Dave Collins/ Ronald A. MontagueSubject: Circular document referencing (establishing document relationships) Description of Driving Event: Specifications are wri

2、tten to control the baseline requirements to which the Space Station is designed, constructed, verified, and delivered. A common practice within most specifications is to reference documents (know as applicable documents) with the specification as a source of requirements. Early in the development o

3、f the specifications the undesirable practice of “circular“ referencing of documents infiltrated the specifications within the Space Station Program. Circular references is, in general, a condition by which a specification or document at a low level of the specification (or document) tree hierarchy

4、references a specification of document at a higher level in the specification (or document) tree hierarchy. The following example illustrates the impact of “circular referencing.“Within the Space Station Program the top level specification is the System Specification (SSP 41000). SSP 41000 reference

5、s numerous documents. Among the referenced documents in SSP 41000 are SSP 30558 and SSP 30559. The SSP 30558 and SSP 30559 documents, in turn reference SSP 41000 (completing the “circle“). Other specifications within the Space Station Specification “Tree“ referenced SSP 30558 and SSP 30559. Because

6、41000 is an applicable document in 30558 and 30559, a lower level specification with the spec tree (for example, the United States Lab (USL) Spec) was placed in the posture of inadvertently being subjected to all requirements within the System Specification. There are two undesirable results caused

7、by this practice: 1. Obviously the USL was not intended to fulfill all requirements as defined in the System Specification. The USL, however, under this structuring could have been construed as needing to meet all System Spec Requirements.2. Maintenance of the “applicable document“ section of each i

8、ndividual specification becomes tangled and interwoven to the point that nonapplicable requirements must be verified. For example a modification to SSP 30559 would result in a required document change of every Provided by IHSNot for ResaleNo reproduction or networking permitted without license from

9、IHS-,-,-specification within the Space Station Specification Tree.Root cause: Failure to establish guidelines that define the purpose, use, and relationships of applicable documents. (Center Data Managers note: The confusion over applicable documents arises quite often from an authors perceived need

10、 to justify or establish authority for a document versus identifying documents that, when cited as applicable, will aid in document implementation. The two purposes are quite different but in a poorly defined process both can be considered as meaning “applicable.“) Lesson(s) Learned: Document relati

11、onships in any program must be clearly defined and understood to ensure effective and straightforward implementation of specifications and requirementsRecommendation(s): Provide early definition of both specification tree and document tree hierarchies applicable to the program. (from Center Data Man

12、ager: Consider performing the process for requirement compliance and traceability versus document / specification authority as separate exercises. For example, if a requirement must be traced to a standard, consider using a parallel traceability matrix or a commercial off the shelf requirements trac

13、ing package.) Evidence of Recurrence Control Effectiveness: Action taken at Huntsville: CM This lesson learned does apply to my area of responsibility. This lesson learned is already part of our standard practices for specification development. The spec tree is established early and the parent-child

14、 relationships established. In spec development, the “applicable documents“ section should not reference any document that is a parent to that document on the spec tree. There may be references to parent documents, but they are usually qualified with a statement like - in the case of a discrepancy b

15、etween the (parent document) and (child document), the (parent document) always takes precedence.Action taken at KSC: System and component specifications are not generated nor maintained by the processing team at KSC for flight items. When items of support equipment are designed for use at KSC, Desi

16、gn Certification Reviews are conducted to ensure all the proper specifications have been identified and properly annotated in the equipment spec.Action taken at NASA/JSC: The lesson learned has been reviewed and the following is currently in place to correct this problem: 1. The Program initiated Do

17、cuments 50257 and 50258 (Program and Boeing Controlled Indexes). These two documents would house the inter-relationships between documents and Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-traceability between higher and lower tiered documents. Thi

18、s was instituted on the Program in 1997.2. However, it was determined that these documents could not be responsive to the daily changes on the Program. Therefore, it was agreed that CM would build an interactive database to track these changes and the relationships between documents. This database i

19、s currently in work and is scheduled for implementation late FY99.Documents Related to Lesson: N/AMission Directorate(s): a71 Exploration Systemsa71 Sciencea71 Space Operationsa71 Aeronautics ResearchAdditional Key Phrase(s): a71 Administration/Organizationa71 Configuration Managementa71 Independent

20、 Verification and Validationa71 NASA Standardsa71 Parts Materials & Processesa71 Policy & Planninga71 Procurement Small Business & Industrial Relationsa71 Risk Management/Assessmenta71 Safety & Mission Assurancea71 StandardAdditional Info: Approval Info: a71 Approval Date: 2002-06-27a71 Approval Name: Ronald A. Montaguea71 Approval Organization: JSCa71 Approval Phone Number: 281-483-8576Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-