REG NASA-LLIS-1501-2003 Lessons Learned - Orbital Space Plane - Stay true to the process!.pdf

《REG NASA-LLIS-1501-2003 Lessons Learned - Orbital Space Plane - Stay true to the process!.pdf》由会员分享，可在线阅读，更多相关《REG NASA-LLIS-1501-2003 Lessons Learned - Orbital Space Plane - Stay true to the process!.pdf（4页珍藏版）》请在麦多课文档分享上搜索。

1、Lessons Learned Entry: 1501Lesson Info:a71 Lesson Number: 1501a71 Lesson Date: 2003-07-01a71 Submitting Organization: MSFCa71 Submitted by: Lisa CarrSubject: Orbital Space Plane - Stay true to the process! Abstract: The Orbital Space Plane (OSP) problems were the result of (1) a lack of a discipline

2、d, well communicated, Level 1 requirements development process, (2) open or architecture-free Level 2 requirements, and (3) contractor-developed Level 3 requirements (system specification) Rigorous, well communicated, requirements development processes and rationale is paramount to stakeholders, tec

3、hnical experts and contractors interpretation of the requirements and promotes personal “buy-in”. Description of Driving Event: (1) a lack of a disciplined, well communicated, Level 1 requirements development process, (2) open or architecture-free Level 2 requirements, and (3) contractor-developed L

4、evel 3 requirements (system specification)Lesson(s) Learned: Three major contributors to the dilemma within OSP were (1) a lack of a disciplined, well communicated, Level 1 requirements development process, (2) open or architecture-free Level 2 requirements, and (3) contractor-developed Level 3 requ

5、irements (system specification). Rigorous requirements development processes consistent with accepted system engineering practices are critical to establishing a good requirements foundation. The Requirements Development Team (RDT) attempted to insert rigor during the Level 2 requirements developmen

6、t in a short time and with a laser-like focus. But for team members not in the lasers light, the RDT was a blackout.Additionally: a. Communication of Requirements. A requirements philosophy paper was written to help Provided by IHSNot for ResaleNo reproduction or networking permitted without license

7、 from IHS-,-,-communicate the message. Where it failed was in limited distribution and the lack of diligence to get this message to the personnel involved after the process had started. The use of a small, co-located requirements development team (RDT) also tended to isolate people at different cent

8、ers as well as the contractors from the discussion behind the requirements. This led to confusion in interpretation of the requirements by the contractors and by the Project Managers who were trying to help the contractors with the interpretation.b. OCD in Parallel. Since the Operations Concept Docu

9、ment (OCD) was developed in parallel with the system requirements the two teams tended to focus on different areas of operation. In some instances the desires of the OCD and the requirements of the SRD were in conflict.c. Multiple Level 2 Documents. Requirements controlled at the program level were

10、contained in a number of documents; the Systems Requirements Document (SRD), the ISS/OSP Interface Requirements Document (IRD), and the Human Rating Plan (HRP). Additional verification requirements were found in the System Verification Plan. Also, some program level requirements were derived from th

11、e OCD scenarios and the ELV Interface Design Document (IDD). The locating of Level II requirements in multiple documents did not provide a comprehensive set of Level II system requirements nor provide for consistency of Level III requirements.d. Too much Trade Space. The notion that “saying less giv

12、es the contractor more freedom” isnt entirely true. Having not worked in this environment with NASA previously, the contractors struggled to produce the requirements at Level 3. In all cases the Contractors were looking for much more guidance so they would not go down a path that would lead them to

13、losing out on the Full Scale Development.e. Minimum Standards. A minimum set of standards should have been developed to grade the contractors by and to give them a “watermark” to go by in the development of level 3 requirements.f. Validation Issues. Validation of the system-level requirements for OS

14、P required the use of the contractors architecture to show that the requirements can, in fact, be met. Having multiple contractors with different architectures made this a daunting task and, due to limited personnel and time, near impossible. The validation of OSP Level 2 requirements was not adequa

15、tely resolved.g. Requirements Philosophy. A requirements philosophy paper was written to help communicate the message.h. Level 1 Requirements. The process by which the Level 1 Requirements were developed was not clear to the program implementers. Rationale was not provided for the requirements and t

16、he resultant set of requirements was never formally transferred to OSP nor placed under configuration control. It was also indicated that pushback was not allowed. This caused major problems when early government-led trades revealed that the requirements might not be entirely feasible. The ambiguity

17、 of the requirements led OSP to create a Level 1 requirements interpretation document and place it Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-under configuration management. However, the OSP requirements development team was not able to communic

18、ate directly with the Level 1 requirements developers in order to establish agreement on Level 1 requirements interpretation. Level 2 Requirements Development of the Level 2 requirements did not follow established systems engineering guidelines for allocation, inclusion of performance and functional

19、 requirements, validation, and feasibility assessments.i. Synchronize Development. Requirement development, analyses, and system design activities were not synchronized. Functional decomposition was not complete before system design started and before Level 3 requirements were base-lined. Also, in t

20、he environment of acceleration a Requirements Development Team (RDT), consisting of decision makers from the OSP, Expendable Launch Vehicles (ELV) and International Space Station (ISS) Programs and Headquarters, was formed.j. Feasibility Assessment. The process for demonstrating requirements feasibi

21、lity was unclear.Recommendation(s): Rigorous, well communicated, requirements development processes and rationale is paramount to stakeholders, technical experts and contractors interpretation of the requirements and promotes personal “buy-in”. Programs should establish and maintain regular consiste

22、nt forums to inform all who choose to attend with a summary of the management focus and decisions. Utilize these forums as an opportunity for team members to question management decisions/approaches.A definite hierarchy should be established on the documentation to clear up confusion on which requir

23、ements take precedence in the event of unforeseen conflicts. Set minimum program standards. For multiple contractors, each NASA assessment team should be trained to understand the requirements before validating them based on the individual contractors designs. A more efficient process for executing

24、to the requirements could be established by involving implementers and stakeholders in the development process to assist in validation and configuration control and eliminate the need for an interpretation document. Guidance and training for requirements generation should be provided to requirements

25、 development groups. The greater the schedule pressure, the more important it is to establish, follow, and enforce a Systems Engineering Management Plan. Programs should define a rigorous process for technical feasibility (in the SEMP) and especially feasibility of Human Spaceflight on existing ELVs

26、. Evidence of Recurrence Control Effectiveness: N/ADocuments Related to Lesson: N/AProvided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-Mission Directorate(s): a71 Exploration Systemsa71 Space Operationsa71 Aeronautics ResearchAdditional Key Phrase(s): a7

27、1 Administration/Organizationa71 Policy & Planninga71 Program and Project ManagementAdditional Info: Approval Info: a71 Approval Date: 2005-04-01a71 Approval Name: Lisa Carra71 Approval Organization: MSFCa71 Approval Phone Number: 256-544-2544Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-