REG NASA-LLIS-0987-2001 Lessons Learned Chandra X-ray Observatory (CXO) Development Program Programmatic Lessons Learned .pdf

《REG NASA-LLIS-0987-2001 Lessons Learned Chandra X-ray Observatory (CXO) Development Program Programmatic Lessons Learned .pdf》由会员分享，可在线阅读，更多相关《REG NASA-LLIS-0987-2001 Lessons Learned Chandra X-ray Observatory (CXO) Development Program Programmatic Lessons Learned .pdf（5页珍藏版）》请在麦多课文档分享上搜索。

1、Lessons Learned Entry: 0987Lesson Info:a71 Lesson Number: 0987a71 Lesson Date: 2001-05-03a71 Submitting Organization: MSFCa71 Submitted by: Jean OlivierSubject: Chandra X-ray Observatory (CXO) Development Program Programmatic “Lessons Learned“ Description of Driving Event: Marshall Space Flight Cent

2、er (MSFC) was responsible for the development of the Chandra X-ray Observatory, successfully launched in July, 1999. Chandra is the third of NASAs “Great Observatories.“ This captures program management lessons learned from Chandras inception through its launch in 1999.Lesson(s) Learned: 1. Stable R

3、equirements are key to program stability. Do not allow requirements to creep. One step in this process is to involve all stakeholders in developing and finalizing requirements. Stakeholders may include potential development and operations contractors, engineering and other organizations and NASA Hea

4、dquarters.2. Plan early in the program for operations considerations, making sure the operations organization is strongly involved in defining requirements and in the early design process to assure systems are user friendly. This is not easy to accomplish for either MSFC or the contractor, particula

5、rly in a schedule and funding constrained development environment where design features to enhance operations may result in features not envisioned by the design organization.3. To the maximum extent possible assure that the operations and verification databases, as well as, command and telemetry pn

6、eumonic are common. Often, to reduce cost, a contractor will propose the use of systems level Electrical Ground Support Equipment (EGSE) that was previously used on another program. This can make portability between operations and verification difficult, since Ground Support Equipment (GSE) Interfac

7、e Control Document (ICD) is often obsolete by the time the program is ready for systems testing. Use of existing GSE may require both hardware and software upgrades.4. The operations organization should realize from the beginning that the development program Provided by IHSNot for ResaleNo reproduct

8、ion or networking permitted without license from IHS-,-,-may suffer schedule erosion, and should therefore develop contingency planning for operations procedure development in an environment where the operations database is not yet finalized. Spending effort complaining about the development program

9、 being late is not productive.5. Spend the necessary resources to provide for a strong systems engineering organization throughout the program. Assign managers for all interface control documents and layout a schedule for their development through baselining. Make sure the systems engineering manage

10、r has direct control of all manpower for systems analyses such as thermal, structural dynamics, error budgets, loads, mass properties, electrical power demand, orbital mechanics, etc. Do not overlook the need for strong systems engineering involvement in requirements and verification traceability.6.

11、 Make sure that one organization is responsible for end-to-end systems engineering for the entire payload including the payload ground operations system. Engineering of the entire system includes penetrating the total system design on both sides of an ICD rather than working just your side of it. Wh

12、en responsible for building a total systems analytical model (thermal, structural, dynamic, electrical, etc.) by assembling a number of analytical inputs from other organizations, systematically check the accuracy of these inputs before using them and perform sanity tests on the total model with sim

13、ple yet carefully chosen boundary conditions to make sure it is correct.7. When verifying performance of optical elements or systems always cross check the results using another completely different test method. When required to use gravity off-loaders in the test of optical systems, it is essential

14、 that they be rigorously tested and correlated with analytical models under both nominal and off nominal conditions.8. Maintain a strong engineering involvement with the contractor from the beginning of the program, not just when you get into trouble. Encourage a sense of “ownership“ and continuity

15、of responsibility for all individuals involved in the program. In the case of engineering this can be helped greatly by insuring that the same individual remains responsible for a given technical discipline throughout the program.9. Assure that adequate funding and schedule reserve is budgeted at th

16、e beginning of the program, no less than 25% and possibly more depending on assessed technical risk.10. Before launch of any remotely operated satellite or other equipment, perform end-to-end tests of the flight system with the ground control system using the final flight and ground versions of hard

17、ware, software, database and procedures. The flight operations team should perform these tests. To the extent possible, each command type should be sent and verified. Commands that by their nature cannot be tested in this manner should be tested in a high fidelity simulator with the ground system an

18、d all hardware commands to the flight system should be verified using the ground system for functionality.11. Any mission critical verification that requires verification, in whole or in part, by analysis should be double checked or preferably analyzed in parallel by an independent party. This same

19、principle should also apply to any operational commands that are generated based on analytical input.12. To the extent that resources permit, design the system with reserve capability, including failure tolerance, beyond that stated in the requirements.Provided by IHSNot for ResaleNo reproduction or

20、 networking permitted without license from IHS-,-,-13. Never stop looking for undetected failure modes or potential risks throughout the entire program development and operational phases.14. Hold regular status meetings by telecon with the entire program team so that all parties remain knowledgeable

21、 of program status and issues.15. NASA managements main goal should be to provide help and guidance to their contractors. Monitoring progress is only a by-product of this effort, not its primary objective.16. Taking shortcuts in box-level testing is a gamble with poor odds. Spend the time to thoroug

22、hly verify the flight worthiness of hardware and software at the lowest level. Finding box-level problems during systems-level testing is much more costly and disruptive in the long run.17. If independent review teams are to be used, get them involved at Preliminary Design Review (PDR) and keep them

23、 involved in all major reviews, as well as in the resolution of critical issues as they arise throughout the program.18. Critically evaluate any hardware or software that a contractor wants to use from another program or verify by similarity. Independently assess its specifications and how it was us

24、ed in former programs, as compared with your requirements. Be particularly wary if the previous program was classified and details are not available. Insist that the contractor provide all specifications to support your evaluation.19. Be especially cautious when dealing with highly complex scientifi

25、c hardware where the developer is “the only one that understands how it works.“ This system should not be exempt from review by as knowledgeable a team of experts as you can assemble, even if they have to be brought in from another NASA center or independent organizations. For instance, the Advanced

26、 Charge-Coupled Device (CCD) Imaging Spectrometer (ACIS) CCD radiation test shortcomings may have been caught by such a team, if one had been assembled one early in the program.Recommendation(s): Reiterating major lessons learned:1. Do not allow requirements to creep.2. Include operations in require

27、ments definition and early design.3. Wherever possible, maintain common pneumonics for all components and sub-systems.4. Develop operational contingency plans to accommodate possible schedule delays.5. Provide strong systems engineering throughout the program life cycle.6. Organize to ensure proper

28、analysis of critical interfaces.7. When verifying performance of optical elements or systems, always cross check the results using another completely different test method.8. Maintain a strong engineering involvement with the contractor from the beginning of the program, not just when you get into t

29、rouble.9. Assure that adequate funding and schedule reserve is budgeted at the beginning of the program.10. Before launch of any remotely operated satellite or other equipment, perform end-to-end tests Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-

30、of the flight system with the ground control system using the final flight and ground versions of hardware, software, database and procedures.11. Provide cross-checks for any mission critical verifications based, in any part, on analysis.12. To the extent that resources permit, make program decision

31、s that provide the system with reserve capabilities that exceed the requirements.13. Never stop looking for undetected failure modes or potential risks.14. Hold regular status meetings with the entire program team so that all parties remain knowledgeable of program status and issues.15. NASA managem

32、ents main goal should be to provide help and guidance to their contractors.16. Spend the time to thoroughly verify the flight worthiness of hardware and software at the lowest level.17. If independent review teams are to be used, get them involved at Preliminary Design Review (PDR) and keep them inv

33、olved.18. Critically evaluate any hardware or software that a contractor wants to use from another program or verify by similarity.19. No system should be exempt from review by technical experts as you can assemble, even if they have to be brought in from outside.Evidence of Recurrence Control Effec

34、tiveness: N/ADocuments Related to Lesson: N/AMission Directorate(s): a71 Space Operationsa71 Sciencea71 Exploration SystemsAdditional Key Phrase(s): a71 Administration/Organizationa71 Flight Operationsa71 Ground Operationsa71 Logisticsa71 Policy & Planninga71 Research & Developmenta71 Risk Managemen

35、t/AssessmentProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Additional Info: Approval Info: a71 Approval Date: 2001-08-20a71 Approval Name: isa Hedigera71 Approval Organization: MSFCa71 Approval Phone Number: 256-544-2544Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-