REG NASA-LLIS-1801--2004 Lessons Learned Human Factors Engineering Acceptance Implementation and Verification as a System.pdf

《REG NASA-LLIS-1801--2004 Lessons Learned Human Factors Engineering Acceptance Implementation and Verification as a System.pdf》由会员分享，可在线阅读，更多相关《REG NASA-LLIS-1801--2004 Lessons Learned Human Factors Engineering Acceptance Implementation and Verification as a System.pdf（4页珍藏版）》请在麦多课文档分享上搜索。

1、Lessons Learned Entry: 1801Lesson Info:a71 Lesson Number: 1801a71 Lesson Date: 2004-3-25a71 Submitting Organization: KSCa71 Submitted by: Damon Stamboliana71 POC Name: Tico Foleya71 POC Email: theodore.t.foleynasa.gova71 POC Phone: 281-483-2996Subject: Human Factors Engineering; Acceptance, Implemen

2、tation, and Verification as a System Abstract: There was a continual struggle for acceptance of Human Engineering, during the evolution of the SLI and OSP programs. The status, visibility, responsibilities, resources, and authority of Human Engineering vacillated. At the end of the OSP cycle, the Hu

3、man Systems Office had achieved a seat at the table. This allowed human factors engineers voices to be heard and resulted in human factors engineering being integrated into other systems of the OSP. Description of Driving Event: There was a continual struggle for acceptance of Human Engineering, dur

4、ing the evolution of the SLI and OSP programs. The status, visibility, responsibilities, resources, and authority of Human Engineering vacillated. At the end of the OSP cycle, the Human Systems Office had achieved a seat at the table. This allowed human factors engineers voices to be heard and resul

5、ted in human factors engineering being integrated into other systems of the OSP. However, many decisions were being made about OSP that initially ignored the human as the primary reason for the mission, and then tried to retrofit the human into the physical and dynamic parameters that remained in th

6、e trade space. Even though the human was emphasized in Level I requirements and in Request for Proposals (RFPs), both NASA and the contractors had to be frequently reminded that the human is an essential driver for requirements and deliverables for human spaceflight. Placing human system requirement

7、s last in priority will result in higher costs for training and Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-operational work-arounds in order to accommodate. We know from ISS crew debriefs that there are interface issues that lead to continual wo

8、rkarounds; interfaces are in conflicting designs. If NASA would do a life cycle cost analysis, then the impacts to training and operations costs would become very apparent. The root causes of Human Factors Engineering requirements being deemed of low priority center around three phenomena: (1) hardw

9、are and software short-term schedules and cost concerns often lead to decisions to ignore Human Factors Engineering requirements with the rationale that the human is malleable and can adjust to the design, (2) some project managers, decision makers, and designers think that because of their human ex

10、periences they are human factors experts, and (3) claims that a human can endure or accomplish almost anything with the proper motivation or rationale. Lesson(s) Learned: Include Human Factors Engineering as an essential system for human spaceflight. Human Factors Engineering impacts all systems hav

11、ing interfaces and interactions with humans, including: hardware, software, flight preparation, mission operations, and maintenance for both ground and flight. How Solved: The Human Engineering Office was established within the Spacecraft Project Office. Human Engineering was included at a visible l

12、evel for RFPs and WBSs. Recommendation(s): 1. Human Factors Engineering requirements that are carried as applicable requirements should not be ignored; rather they should be (a) adequately funded, (b) implemented in the design definition, and (c) properly verified. 2. Human Factors Engineering perso

13、nnel with training, experience, and expertise should be hired and retained at NASA and at the contractors as key personnel. 3. Human Factors Engineering design tools should be funded to enable spacecraft-specific research and design development, providing actual data from trade-off studies. Include

14、1-g full-scale mockups and multi-degrees-of-freedom simulators as well as virtual simulators. 4. Human Factors Engineering awareness training and re-education should be provided to NASA and contractor management, budget controllers, contracting officers, design discipline leads, as well as to legisl

15、ative and executive branch government leaders. 5. Emphasize that Human Factors Engineering is a primary systems discipline necessary for safe and efficient spaceflight. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-6. Human Factors Engineering scop

16、e and language at NASA and among the contractors must be standardized with the overall Human Factors Engineering community. For example, does Human Factors Engineering include everything in NASA-STD-3000 or is it limited to what might be funded for crew systems and cockpit layout? For example, does

17、habitable volume mean the same thing to each NASA and contractor player? 7. Human Factors Engineering should be included in the work breakdown structure (WBS) of the new program, Crew Exploration Vehicle (CEV). Preferably this should be done in the Systems Engineering / Systems Integration section;

18、alternatively a standard Human Factors Engineering statement should be called out in every WBS callout for deliverables having human interfaces. 8. Spaceflight proposals should include a stand-alone section on Human Factors Engineering, with emphasis on scope, personnel, resources, and facilities al

19、l with sufficient funding to accomplish a successful Human Factors Engineering design. In addition, the introduction and executive summary should make it clear that Human Factors Engineering is a primary system. 9. Data from Human Factors Engineering assessments and tests should drive lower level re

20、quirements and resulting design. 10. Human Factors Engineering should be involved and integrated in the daily engineering problem solving and integration process. 11. Human Factors Engineering should have signature authority on all designs and drawings affecting human environments, interfaces, and i

21、nteractions. 12. Human Factors Engineers with training, experience, and expertise should be the ones making decisions on Human Factors Engineering. This should be done with participation, but not domination, by users (crew, ground support personnel, mission controllers) and managers. Evidence of Rec

22、urrence Control Effectiveness: N/ADocuments Related to Lesson: N/AMission Directorate(s): a71 Exploration SystemsAdditional Key Phrase(s): Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-a71 Systems Engineering and Analysis.Additional Info: a71 Project: OSPApproval Info: a71 Approval Date: 2007-08-31a71 Approval Name: ghendersona71 Approval Organization: HQProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-