1. 1 Colorado Space Grant Consortium Gateway To Space ASEN / ASTR 2500 Class #14 Gateway To Space ASEN / ASTR 2500 Class #14

2. 2 Announcements:

3. 3 - 20 th year report to NASA is DONE! - Thanks for your patience… - If you want a copy

4. 4 Proposals: - I have completed my very thorough review of your proposals - Comments given back at the end of class. - It is only the end of the world if you don’t do anything

5. 5 Proposals: - Process used…

6. 6 Proposals:

7. 7 Design Document: - Design Document template has been posted on the website - DD Rev B must include items from Rev A - DD Rev A is not due Thursday - DD Rev B is due 10/14/08 along with your CDR Slides

8. 8 CDR: - Conflicts with review time if at… 1. 6:00 – 8:00 PM 2. 5:00 – 7:00 PM - Template is on-line - All presentations are due at 4:00 PM via email or in person if larger than 15 MB - Order announced Thursday.

9. 9 Today… - Sign-in sheet with attached letter…please sign both - Password problem, should be fixed by Thursday - Meeting with Kyle tonight at 5:30 PM - If you are doing a sky brightness mission, plan on attending or sending a rep from your team with questions. - Some hardware is here, see me after class.

10. 10 Questions?

11. 11 Today… We have our first guest lecturer of the semester. Topic is System Engineering Let’s welcome… Julia Chu from Lockheed Martin

12. 12 Introduction to Systems Engineering Julia Chu October 7, 2008 Some material developed by P. Robitaille and INCOSE

13. 13 How Would You Define SE?

14. 14 Systems Engineering… Is a systematic, interdisciplinary approach that transforms customer needs into a total system solution Is a systematic, interdisciplinary approach that transforms customer needs into a total system solution Is led by systems engineers Is led by systems engineers -But all functions play a role; Integrated via clear roles & responsibilities Must be rigorously applied across programMust be rigorously applied across program Is the technical "glue" which makes separate design disciplines and subsystems function together to provide an integrated system which performs a specific job. Is the technical "glue" which makes separate design disciplines and subsystems function together to provide an integrated system which performs a specific job. Systems Engineering is a PROCESS - Not an organization

15. 15 The Systems Viewpoint The Design Engineer has the specialist's viewpoint. Views the system from the inside. The Design Engineer has the specialist's viewpoint. Views the system from the inside. - Concerned with other system elements only as they affect their own design task; but not necessarily how theirs may affect others The Systems Engineer has the systems viewpoint. Views the system from the outside. The Systems Engineer has the systems viewpoint. Views the system from the outside. - Concerned with the effect of all system elements as they affect overall system design / performance / cost / schedule

16. 16 Systems Engineering must focus on the entire problem: optimize the whole, not the parts! Why Systems Engineering?

17. 17 Systems Engineering Objectives Systematic elimination of less desirable concepts and early selection of a single preferred system approach. Systematic elimination of less desirable concepts and early selection of a single preferred system approach. Early identification and resolution of critical problem areas. Early identification and resolution of critical problem areas. Focusing of technical expertise to match program needs. Focusing of technical expertise to match program needs. Maintaining compatibility among separate but interrelated technical activities. Maintaining compatibility among separate but interrelated technical activities. Maintaining technical oversight and configuration control throughout concept definition, design, implementation, and support phases. Maintaining technical oversight and configuration control throughout concept definition, design, implementation, and support phases. Key objective: achieve a balanced, affordable design that meets stakeholder needs

18. 18 Integrated Product Teams (IPTs) Integrated Product Teams (IPTs) Systems Engineering Integration Team (SEIT) Program Business Support IPT The SEIT Provides SE Guidance & Support to other IPTs which apply SE Process to their activities. The SEIT Provides SE Guidance & Support to other IPTs which apply SE Process to their activities. Customer Product 2 IPT Product 1 IPT Product 3 IPT Product N IPT Customer Customer Customer CustomerCustomer Program Management Integrated Product Team (IPT)

19. 19 Systems Engineering Tasks No temporal flow is intended for performing these tasks

20. 20 Requirement Decomposition and Definition Integration and Verification HW Drawings, Design Docs Procurement Specifications Make-Buy decisions SW SDDs, UML, etc Inspections bench test Inspect, unit test, integrate units into CSCs (CSC I&T) System Specs Requirement/Integration/Verification Roadmap Systematic Build-Up of Orion Capabilities “design to” Element Specs Subsystem Specs Component, CSCI Specs “design to” CSCI, Comp. T&V Plans, Procedures, Reports Verify to requirements in Section 4 of Component, CSCI Specs Verify to requirements in Section 4 of Subsystem Specs Verify to requirements in Section 4 of Module Specs Assemble & integrate component Integrate CSCs into CSCI Perform informal integration activities (tests, demos) System T&V Plans, Procedures, Reports Element T&V Plans, Procedures, Reports Subsystem T&V Plans, Procedures, Reports Perform I&T & T&V according to plan Perform formal verification & qualification activities according to test procedures Prepare reports documenting all formal verification activities Integration

21. 21 Develop/Acquire Item 2.3.6-T1-DesEng-1.0-P Design System 2.3.4-T1-SysEng-1.0-P Bi-directional RequirementsTraceability Flow [System to Item Overview] Traceability Flow Task 3.5Establish and maintain bi-directional traceability between system requirements and their allocated element… System Requirements/Design Element Requirements/Design Item Requirements/Design Task 2.5Establish and maintain bi-directional traceability between item requirements and the higher level element requirements. Computer Models Part lists/Specs Schematics Drawings Task 2.3Establish and maintain… bi-directional traceability between the allotted element requirements, the detailed derived requirements and the work products… Develop/Acquire Element 2.3.5-T1-DesEng-1.0-P Analyze System Requirements 2.3.3-T1-SysEng-1.0-P Task 4 Step 4.2 …Document…traceability to mission requirements. System requirements are flowed down to lower level requirements…. Item Requirement Database 2.3.6-T1-DesEng-1.0-P W1 Sect 4The Item reqmt Database shall include …Traceability from a reqmt to its source reqmt… …Traceability from a reqmt to its derived reqmt… Requirements/Architecture Flowdown

22. 22 Bi-directional Requirements Traceability Flow [Verification Activity] Traceability Flow System Product/Verification Element Product/Verification Item Product/Verification Computer Models Part lists/Specs Schematics Drawings Verify system 2.3.8-T1-SysEng-1.0-P Task 1.1.7 Document Verification Requirements Traceability Task 1.4.1 The SVP (Sys Verif Plan) shall contain or reference as a minimum: A verification matrix that provides the map from system requirements( specs and interface docs) to the verification program activities. The SVP shall identify component configurations that shall be subject to each verification activities. Task 1.7 …The requirements shall show the bi-directional traceability between the system requirements and their associated verification…ensuring that every product requirement is assigned at least one verification activity. Verification Roll-up Task 1: Perform Verification Planning Task 2.2 The procedures shall contain, as a minimum, the elements defined below: Identification of the item and specific requirement being verified Traceability to the requirement identifier, including references to governing plans Task 2: Prepare for Verification Activities Task 3.1.1 Qualification tests, design analyses, demonstrations and inspections shall be conducted to…have resulted in a product that conforms to specification requirements. Task 3: Executing Verification

23. 23 SE throughout Product Life Cycle Program Life-Cycle Phases SE Effort SE begins with program or proposal, whichever comes first, and continues throughout a program’s life cycle Production & Deployment Pre-Concept Concept Exploration & Definition Engineering & Manufacturing Development Disposal Operation & Support Demonstration & Validation DoD 5000.2 Pre 2002 15 to 20 Percent of total engineering effort on complex development programs Concept & Technology Development System Development & Demonstration Production & Deployment Operations & Support DoD 5000.2 2002-2003 System Development & Demonstration Concept Refine- ment Production & Deployment Operations & Support DoD 5000.2 2003 Technology Development

24. 24 Requirements Tasks Ensure clear, consistent requirements Ensure clear, consistent requirements Decompose requirements from highest to lowest level Decompose requirements from highest to lowest level - complete - unambiguous - verifiable Understand constraints Understand constraints - cost - schedule - technical capability

25. 25 Ensure that engineers understand problem to be solved Provide contractual basis for verification and acceptance If requirements are wrong, so is everything else -architecture, design, tests Poor Requirements yield Wrong Products! Why are Requirements Important?

26. 26 As Contracts Specified It Why are Requirements important? As Engineering Designed ItAs Materiel Ordered It As Manufacturing Assembled It As Test Verified It What the Customer Wanted Clearly communicating requirements is essential

27. 27 One Requirements Repository/Tool for ALL Data and Disciplines Requirements and Design Stakeholder Needs & Mission Requirements Operational Concepts System Requirements System Architectural Design Element Requirements Element Design Repeat to lowest item level Items Q: Where do requirements end and design begin? Proposed Changes A: There is no dividing line. Design work at one level generates requirements for the next lower level.

28. 28 Why is it Important to Manage Requirements? To ensure that there is a stable, consistent requirements baseline To ensure that there is a stable, consistent requirements baseline To avoid requirements growth To avoid requirements growth - “Better is the enemy of good” - Voltaire To ensure everyone is working to the same set of requirements To ensure everyone is working to the same set of requirements To get appropriate cost impact assessments for proposed changes from all stakeholders To get appropriate cost impact assessments for proposed changes from all stakeholders

29. 29 Integration Tasks Optimize system design Optimize system design - the best solution for a subsystem may not be the best system solution Ensure elements, subsystems, components will all work together Ensure elements, subsystems, components will all work together - validate requirements - identify and resolve technical inconsistencies - identify and resolve interface issues Manage program risk Manage program risk Manage program plans Manage program plans

30. 30 Why is Integration Important? Plans allow the program to execute successfully Plans allow the program to execute successfully - plan the technical effort, delineate roles & responsibilities - define tasks and schedules to accomplish the work - allow for changes along the way Identify problems early enough to mitigate them at low cost Identify problems early enough to mitigate them at low cost - What is risk? “A potential event that would be detrimental to the program as related to system performance, cost, or schedule”

31. 31 Impact of SE on Program Cost Defense Systems Management College - 9/1993 Cumulative Percentage Life Cycle Cost 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% ConceptPhase DesignPhase Develop-ment Prod/TestPhase OperationsThroughDisposal 8% 15% 20% 100% Committed Costs 70% 85% 95% 3-6X 20-100X 500-1000X Time Full Program Expenditures 50% Cost to Extract Defects Typically, by the time system level design is complete, around 85% of the costs have been committed and the cost to extract defects goes up exponentially

32. 32 Verification Tasks Ensure that the design meets the requirements Ensure that the design meets the requirements - done at every level (component to system) Start with planning Start with planning - how should each requirement be verified? - test, analysis, inspection, demonstration? - how much is enough? - what is cost-effective? Ensure verifications are complete Ensure verifications are complete - inspection of test conditions and results, analysis reports, etc.

33. 33 Why is Verification Important? To ensure the system as built will work as planned before it becomes operational To ensure the system as built will work as planned before it becomes operational Customers and designers love test Customers and designers love test - some test is always needed – the key is to choose wisely - test is often the most expensive verification method - cases that are difficult to test may be better to verify by analysis Choosing the “wrong” verification methods may result in a failure Choosing the “wrong” verification methods may result in a failure - INTELSAT

34. 34 Characteristics of SEs -Ability to focus on complex problems - Ability to balance risk and opportunity - Ability to facilitate problem solving (involving various domain experts) - Good interpersonal communications skills (to elicit requirements, etc.) - Excellent logic capability and disciplined work habits - Decision making capability (process data and come to conclusion in a timely manner) - Ability to work in teams across functional boundaries - Process awareness and applicability A Systems Engineer needs to be disciplined, balance risk and opportunity, and work across functional boundaries

35. 35 In summary, Systems Engineering: In summary, Systems Engineering: - Focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceed with design. - Provides early IV&V to reduce cost, schedule, and risk - Integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. - Provides confidence that a design will operate successfully. - Considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.