Colorado Space Grant Consortium

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

2. Announcements:

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

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. Proposals: - Process used…

6. Proposals:

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. 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. 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. Questions?

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

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

13. How Would You Define SE?

14. Systems Engineering is a PROCESS - Not an organization Systems Engineering… • Is a systematic, interdisciplinary approach that transforms customer needs into a total system solution • Is led by systems engineers • But all functions play a role; Integrated via clear roles & responsibilities • Must 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.

15. The Systems Viewpoint • 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. • Concerned with the effect of all system elements as they affect overall system design / performance / cost / schedule

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

17. Systems Engineering Objectives • Systematic elimination of less desirable concepts and early selection of a single preferred system approach. • Early identification and resolution of critical problem areas. • Focusing of technical expertise to match program needs. • Maintaining compatibility among separate but interrelated technical activities. • 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. Integrated Product Teams (IPTs) Program Management Integrated Product Team (IPT) Customer Systems Engineering Integration Team (SEIT) Program Business Support IPT Customer Product N IPT Product 3 IPT Product 1 IPT Product 2 IPT Customer Customer Customer Customer The SEIT Provides SE Guidance & Support to other IPTs which apply SE Process to their activities.

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

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

21. Traceability Flow Bi-directional RequirementsTraceability Flow [System to Item Overview] Analyze System Requirements 2.3.3-T1-SysEng-1.0-P System Requirements/Design Design System 2.3.4-T1-SysEng-1.0-P Element Requirements/Design Develop/Acquire Element 2.3.5-T1-DesEng-1.0-P Requirements/Architecture Item Requirements/Design Flowdown Develop/Acquire Item 2.3.6-T1-DesEng-1.0-P Drawings Schematics Part lists/Specs Computer Models Item Requirement Database 2.3.6-T1-DesEng-1.0-P W1

22. Traceability Flow Bi-directional Requirements Traceability Flow [Verification Activity] Verify system 2.3.8-T1-SysEng-1.0-P System Product/Verification Task 1: Perform Verification Planning Element Product/Verification Verification Roll-up Item Product/Verification Task 2: Prepare for Verification Activities Drawings Schematics Part lists/Specs Task 3: Executing Verification Computer Models

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

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

25. Poor Requirements yield Wrong Products! Why are Requirements Important? • 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

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

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

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

29. Integration Tasks • Optimize system design • the best solution for a subsystem may not be the best system solution • 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 plans

30. Why is Integration Important? • 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 • What is risk? “A potential event that would be detrimental to the program as related to system performance, cost, or schedule”

31. Impact of SE on Program Cost 95% 100% Committed Costs 85% 90% 500-1000X 80% 70% 70% Cost to Extract Defects Operations Through Disposal 20-100X Prod/Test Phase 60% Cumulative Percentage Life Cycle Cost 50% 3-6X 40% 100% Develop- ment 30% Design Phase 50% 20% Concept Phase 20% 10% 15% 8% 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 0% Time Defense Systems Management College - 9/1993 Full Program Expenditures

32. Verification Tasks • Ensure that the design meets the requirements • done at every level (component to system) • 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 • inspection of test conditions and results, analysis reports, etc.

33. Why is Verification Important? • To ensure the system as built will work as planned before it becomes operational • 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 • INTELSAT

34. A Systems Engineer needs to be disciplined, balance risk and opportunity, and work across functional boundaries 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

35. 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.