Systems Engineering Systems Architecting An introduction Version 1

Systems Engineering Systems Architecting An introduction Version 1. 0 – October 18, 2005 1

Systems Engineering Agenda • Evolution of Systems • Relating Systems Engineering & Architectures • Representing an Architecture • Using Architectures • Summary Version 1. 0 – October 18, 2005 2

Systems Engineering Evolution of Systems Version 1. 0 – October 18, 2005 3

Systems Engineering Evolution of Systems Version 1. 0 – October 18, 2005 4

Systems Engineering Evolution of Systems Version 1. 0 – October 18, 2005 5

Systems Engineering Evolution of Systems are becoming increasingly large and complex Version 1. 0 – October 18, 2005 6

Systems Engineering No Easy Answer Modern Systems: – Ill-Structured – Involve New & Untested Ideas – Complex Version 1. 0 – October 18, 2005 7

Systems Engineering Overcoming these Problems Maybe he doesn’t want to be in charge of the next customer review How will we: – Manage uncertainty – Manage complexity – Manage technological change Version 1. 0 – October 18, 2005 8

Systems Engineering: the Process A process that transforms an operational need or market opportunity into a system description to support detail design. • Requirements Analysis • Functional Analysis • Synthesis • Systems Analysis / Management Version 1. 0 – October 18, 2005 9

Systems Engineering Systems Architecture: a Product The design team’s interpretation / implementation of customer requirements communicated thru: • System Usage Scenarios (i. e. , Use Cases) • Functional Components & Interrelationships • Physical Subsystems & Interfaces • Etc… Version 1. 0 – October 18, 2005 10

Systems Engineering Systems Architecting: a Methodology A Segment of the Systems Engineering Process Which Facilitates the Identification of: • System Elements • Relationships • Design Principles That Collectively Satisfy Customer Requirements and Meet User Needs. Version 1. 0 – October 18, 2005 11

Systems Engineering Architecting in the Systems Engineering Process Inputs • Stakeholder Inputs Ø Operational Requirements Ø MOE’s Ø Environments Ø Constraints Ø Capability-Based Acquisition Ø Quality Attributes Ø Interoperability Ø COTS/GOTS/BOTS Ø Re-Use and Legacy • Technology Base • Prior Phase Results • Applied Standards Goal/Mission Analysis/Validation Requirements Analysis • Analyze Missions and Environments • Identify Functional Requirements • Define/Refine Performance and Design Constraints • Identify Quality Attributes • Validate Requirements Functional Architecture Analysis Requirements Loop Functional Analysis & Allocation • Decompose to Next-Lower Level Functions • Define/Refine Functional Interfaces (Internal/External) • Define/Refine/Integrate Functional Architecture • Allocate Performance & Other Requirements Design Loop Verification Loop System Analysis • Modeling & Simulation • Trade Studies • Effectiveness Analysis System Management • Risk Management • Data Management • Configuration Management • Progress Measurement Ø IMP/IMS & TPMs Ø Technical Reviews Physical Architecture Analysis Synthesis • Transform Each Level’s Architecture from Functional to Physical Iteration Loop (Derived Requirements for the Next Level of Decomposition) • Define Alternative System Concepts & Configuration Items • Define/Refine Physical Interfaces (Internal/External) • Identify Candidate Architecture Styles • Select “Best Value” Design Process Outputs Version 1. 0 – October 18, 2005 • “Best Value” System Architecture • System Architecture Models and Specifications 12

Systems Engineering The Two Primary Methods of Architecting • Structured Analysis and Design Technique (SADT) – Graphical Representation of System Requirements • Boxes and Arrows • Logical Flows • Object-Oriented Analysis (OOA) and the Unified Modeling Language (UML) – Structure Diagrams – Behavior Diagrams – Interaction Diagrams Version 1. 0 – October 18, 2005 13

Systems Engineering Goals of Systems Architecting • Take into account the whole picture – Life cycle phases, boundaries, external elements… – Users, builders, benefactors, supporters, environments – Affordability, safety, availability, survivability, security, etc. • Communicate clearly the components and their inter-relationships from user and engineering perspectives – for customer validation – for use in analysis and design by all engineering disciplines Version 1. 0 – October 18, 2005 14

Systems Engineering Describing the Architecture Physical Descriptions Operational Expectations Behavioral Descriptions Many perspectives: physical, functional, operational, technical… Version 1. 0 – October 18, 2005 15

Systems Engineering Physical View to an Architecture Version 1. 0 – October 18, 2005 16

Systems Engineering Functional View to an Architecture (Example Based on Unified Modeling Language) Version 1. 0 – October 18, 2005 17

Systems Engineering Product Diagrams of the Systems Architecture Use Case Diagrams Class Diagrams Activity & State Diagrams Version 1. 0 – October 18, 2005 Sequence Diagrams 18

Systems Engineering Do. DAF – Do. D Architecture Framework Customer Defined Views of the Model Version 1. 0 – October 18, 2005 19

Systems Engineering Operational View (OV) What needs to be done & Who does it High Level Operational Concept Graphic (OV-1) Operational Node Connectivity Diagram (OV-2) Operational Exchange Matrix (OV-3) Organizational Relationships Chart (OV-4) Version 1. 0 – October 18, 2005 20

Systems Engineering System View (SV) Relates Systems and Characteristics to Operational Needs System Interface Description (SV-1) System – Systems Matrix (SV-3) System Functionality Description (SV-4) UML Version System Functionality Description (SV-4) Version 1. 0 – October 18, 2005 21

Systems Engineering Technical View (TV) Prescribes Standards and Conventions System Products Associated With Standards (TV – 1) Template for Time Records (TV-1) Technical Standards Profile Template (TV-1) Version 1. 0 – October 18, 2005 22

Systems Engineering 25 Views Integrated Together AV – 1 Overview & Summary Information AV – 2 Integrated Dictionary OV – 1 High Level Operational Concept OV – 2 Op. Node Connectivity Description OV – 3 Op. Informational Exchange Matrix OV – 4 Org. Relationships Chart OV – 5 Activity Model OV – 6 a Operational Rules OV – 6 b Operational State Transition OV – 6 c Op. Event Trace Description OV – 7 Logical Data Mode SV – 1 Systems Interface Description SV – 2 Systems Communication Description SV – 3 Systems Matrix SV – 4 System Functionality Description SV – 5 Op. Activity to Systems Function Traceability Matrix SV – 6 System Data Exchange Matrix SV – 7 System Performance Parameters SV – 8 System Evolution Description SV – 9 System Technology Forecast SV – 10 a System Rules Model SV – 10 b System State Transition Description SV – 11 Physical Data Model TV – 1 Technical Architecture Profile TV – 2 Standards Technology Forecast Version 1. 0 – October 18, 2005 23

Systems Engineering Do. DAF Summary Do. DAF is a way of describing a system. Do. DAF represents a number of different views of the architecture. Do. DAF is a required output to our customers. Do. DAF is NOT a methodology or process. Do. DAF is NOT a UML based set of views. Version 1. 0 – October 18, 2005 24

Systems Engineering Benefits of Architecting • • • Identifies All System Elements Earlier vs. Later Matches Function to Requirements Capture & Communicate Key concepts Results in ONE design Manages Increasing Complexity Allows Modular Design Version 1. 0 – October 18, 2005 25

Systems Engineering Users of the Architecture • Systems Architect: Translate Client Needs into Builder Requirements • System Designers: Design Guidance • Program Managers: Program Performance Measurement and Guidance • Customers: Validation of Requirements and Design • Other Stakeholders: Various Views of the System* – Manufacturers - Trainers – Testers - Users – Purchasers - Logistics Personnel – Handlers - Maintainers * Adapted from: Agile Systems Engineering Architecting: Methods, Processes, and Practices Stevens Institute of Technology, March 15, 2004 Version 1. 0 – October 18, 2005 26

Systems Engineering Architecture Used In … • Analysis of Alternatives (Ao. A) • Business and Technical Planning • Communications among Organizations – Internal to Internal – Internal to External • Input to Subsequent System Design and Development • Criteria for Certifying Conformance of Implementations • Development, Maintenance, and Reuse Repositories • Review, analysis, and evaluation of the system across the life cycle • Basis for incremental/spiral development Version 1. 0 – October 18, 2005 27

Systems Engineering Characteristics of a Systems Architect • • • • Analytical Attention to Detail Visionary Generalist Common Sense Know-How Drive Critical Attitude Multi-tasking Teamwork Communicator/Documenter Flexible Process Insight Political Insight/Negotiation Version 1. 0 – October 18, 2005 28

Systems Engineering The Risks of Architecting • Early Identification of Problems • Perception of Program Delay • Inconsistent Application of Methodologies • Limited Numbers of Skilled Creators/ Reviewers Version 1. 0 – October 18, 2005 29

Systems Engineering Risks of Not Architecting • Late Identification of Problems • Lack of Unified Design • Issues of Complexity Management Version 1. 0 – October 18, 2005 30

Systems Engineering Example Architecture Issues Audi 2006 A 8, A 8 L, and A 8 L W 12 Passenger Vehicles On certain passenger vehicles, a wiring harness condition exists that may deactivate the passenger side frontal air bag even under circumstances when it should remain activated. Starbucks Coffee Company Recall of Ceramic Teapots The teapots are labeled safe for microwave use, but the handles can become hot in the microwave oven. This poses a possible burn hazard to consumers. Microsoft Xbox 360 – Class Action Lawsuit There may be a design flaw which causes the console's power supply and CPU to overheat, causing the whole system to seize up. Complaints of similar freezing problems began to surface almost as soon as the Xbox 360 went on sale November 22. Version 1. 0 – October 18, 2005 31

Systems Engineering Summary • Increasingly complex systems drive a need for better, clearer design descriptions • Architectures convey the system designer’s interpretation of the requirements • Architectures may be presented by a variety of views which collectively describe the system • As part of the systems engineering process, systems architecting defines and manages development of a system Version 1. 0 – October 18, 2005 32

Systems Engineering Version 1. 0 – October 18, 2005 33

Systems Engineering References • Boeing Systems Architecture Development Guidebook • “The Art of Systems Architecting”, Eberhardt Rechtin, Mark W. Maier • Do. D Architecture Framework (Do. DAF) Version 1. 0 – October 18, 2005 34

Systems Engineering Recommended Use of Do. DAF Products Version 1. 0 – October 18, 2005 35

Systems Engineering Do. DAF View Extraction Version 1. 0 – October 18, 2005 36

Systems Engineering Evolving Architectures: Impact of Spiral Development Version 1. 0 – October 18, 2005 37

Systems Engineering Model-Based Architecture Why Model-Based Architectures? – Help to Explain How Things Work – Broaden Our Perspective – Provide a Common Conceptual Frame of Reference – Express Rules More Simply – Clarify Relationships, Identify Key Elements, and Consciously Eliminate Confusion Factors From: Forsbert, Kevin; “Visualizing Project Management”, Pg. 14 Version 1. 0 – October 18, 2005 38