REG NASA-LLIS-1715-2005 Lessons Learned - The Pitfalls of Engineering-by-Presentation (2005).pdf

《REG NASA-LLIS-1715-2005 Lessons Learned - The Pitfalls of Engineering-by-Presentation (2005).pdf》由会员分享，可在线阅读，更多相关《REG NASA-LLIS-1715-2005 Lessons Learned - The Pitfalls of Engineering-by-Presentation (2005).pdf（4页珍藏版）》请在麦多课文档分享上搜索。

1、Lessons Learned Entry: 1715Lesson Info:a71 Lesson Number: 1715a71 Lesson Date: 2005-12-15a71 Submitting Organization: JPLa71 Submitted by: David Oberhettingera71 POC Name: Sammy Kayali / Jay Schmuecker / Howard Eisena71 POC Email: Sammy.A.Kayalijpl.nasa.gova71 POC Phone: 818-354-6830Subject: The Pit

2、falls of “Engineering-by-Presentation“ (2005) Abstract: Formal documentation of requirements, resolutions, and decisions was once a standard NASA practice. However, the increased use of informal documentation such as viewgraphs and e-mail may be inhibiting the ability of NASA projects to reference t

3、he basis for technical decisions and to validate or verify engineering designs. Produce a record of technical decisions and supporting information within technical reports and memos as a standard practice across the institution, with a defined process for review, approval, and records management.Des

4、cription of Driving Event: Independently reviewing their own performance in system development (Reference (1), the Mars Reconnaissance Orbiter (MRO) project identified a need to improve the engineering decision trail that documented the basis and justification for design changes and other engineerin

5、g decisions. MRO technical meetings or engineering change boards sometimes made flight system design decisions based on studies described in viewgraphs, but the basis for each decision was not always documented for future reference. Although meeting minutes, waivers, or engineering change request (E

6、CR) forms would capture “Was/Now“ information, they would not necessarily record the detailed technical rationale for each change, or the alternatives that were considered. It was not an established practice to either update the presentation slides to capture this history, or to document it in an en

7、gineering form, technical report, or memorandum. As a consequence, the MRO flight project technical staff found themselves repeatedly revisiting the Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-same technical issues: “Now, why did we decide at the

8、 last meeting to set fault protection to ON for launch?“ Later in development, or during the spaceflight phase of a mission, poor recordkeeping may make it difficult to evaluate the system impacts of proposed design or operations changes. Future projects that wish to use inherited hardware or softwa

9、re are forced to perform reverse engineering to fully understand the evolution of the design. Approximately 80 percent of the results of engineering decision making at JPL, as archived in flight project libraries, are captured in viewgraph format (Reference (2). The Prometheus project was also aware

10、 of this process flaw, and project management viewed inadequate engineering documentation as a widespread NASA practice that affects projects ability to substantiate and verify designs (Reference (3). In response, Prometheus instituted a requirement for project personnel to document all technical de

11、cisions in an official memo or report. This was done to assure that decisions and supporting justifications were documented, made available to project personnel and stakeholders, and used for future activities. More recently, the NASA Office of the Chief Engineer issued a memo (Reference (4) reporti

12、ng that NASA advisory boards had “noted the increased use of presentation software and/or e-mail as a substitute for technical reports and other formal documentation.“ It concluded that “this trend must be arrested and the practice stopped.“ References: (1) MRO Lessons Learned Review Session oral pr

13、esentation to Howard Eisen, September 14, 2005. (2) “Methods of Capturing Engineering Decision-Making Audit,“ JPL Office of the Management System, March 3, 2005, p. 1. (3) S. Kayali, Prometheus Project Lessons Learned, Section 2.3.1, September 30, 2005, p. 5. (4) G. Robinson, NASA Office of the Chie

14、f Engineer, Memo No. 6208 (“Documentation“), September 16, 2005. (5) J. Beckman & M. Landano, “Technical Documentation and Retention,“ JPL IOM No. 3000-jcb-032406-0830, April 18, 2006. Lesson(s) Learned: Formal documentation of requirements, resolutions, and decisions - including maintaining records

15、 of the basis and justification for each engineering decision - was once a standard NASA practice. The increased use of informal records such as presentation slides and e-mail may be inhibiting the ability of NASA programs and projects to reference technical decisions and to validate or verify engin

16、eering designs.Recommendation(s): Produce a record of technical decisions, and of other engineering products and data designated as important by line and project management, as a standard practice across the institution. Implement a defined process for review, approval, and management of these recor

17、ds. Utilize presentations only as Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-supporting material.Evidence of Recurrence Control Effectiveness: JPL opened Preventive Action Notice (PAN) No. 1442 on 2/13/06 to initiate and document appropriate Lab

18、oratory-wide action on the above recommendations.Documents Related to Lesson: “Flight Project Practices, Rev. 5,“ JPL DocID 58032, February 27, 2003, Paragraph 5.10 (Information, Data Management, and Archiving)Mission Directorate(s): a71 Space Operationsa71 Sciencea71 Exploration Systemsa71 Aeronaut

19、ics ResearchAdditional Key Phrase(s): a71 Program Management.a71 Program Management.Configuration and data managementa71 Missions and Systems Requirements Definition.a71 Missions and Systems Requirements Definition.Configuration control and data managementa71 Engineering Design (Phase C/D).a71 Engin

20、eering Design (Phase C/D).Spacecraft and Spacecraft Instrumentsa71 Safety and Mission Assurance.a71 Safety and Mission Assurance.Review systems and boardsa71 Additional Categories.a71 Additional Categories.Configuration Managementa71 Additional Categories.Flight Equipmenta71 Additional Categories.Ha

21、rdwarea71 Additional Categories.Payloadsa71 Additional Categories.SpacecraftAdditional Info: a71 Project: Mars Reconnaissance Orbiter, Prometheusa71 Year of Occurrence: 2005Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Approval Info: a71 Approval Date: 2006-06-30a71 Approval Name: tmasona71 Approval Organization: HQProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-