Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "Systems Engineering 1Version 1.0 – October 18, 2005 Systems Architecting An introduction."— Presentation transcript:

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

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

3 Systems Engineering 3Version 1.0 – October 18, 2005 Evolution of Systems

4 Systems Engineering 4Version 1.0 – October 18, 2005 Evolution of Systems

5 Systems Engineering 5Version 1.0 – October 18, 2005 Evolution of Systems

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

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

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

9 Systems Engineering 9Version 1.0 – October 18, 2005 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

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

11 Systems Engineering 11Version 1.0 – October 18, 2005 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.

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

13 Systems Engineering 13Version 1.0 – October 18, 2005 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

14 Systems Engineering 14Version 1.0 – October 18, 2005 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

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

16 Systems Engineering 16Version 1.0 – October 18, 2005 Physical View to an Architecture

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

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

19 Systems Engineering 19Version 1.0 – October 18, 2005 DoDAF – DoD Architecture Framework Customer Defined Views of the Model

20 Systems Engineering 20Version 1.0 – October 18, 2005 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)

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

22 Systems Engineering 22Version 1.0 – October 18, 2005 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)

23 Systems Engineering 23Version 1.0 – October 18, 2005 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 – 6a Operational Rules OV – 6b Operational State Transition OV – 6c 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 – 10a System Rules Model SV – 10b System State Transition Description SV – 11 Physical Data Model TV – 1 Technical Architecture Profile TV – 2 Standards Technology Forecast 25 Views Integrated Together

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

25 Systems Engineering 25Version 1.0 – October 18, 2005 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

26 Systems Engineering 26Version 1.0 – October 18, 2005 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

27 Systems Engineering 27Version 1.0 – October 18, 2005 Architecture Used In … Analysis of Alternatives (AoA) 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

28 Systems Engineering 28Version 1.0 – October 18, 2005 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

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

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

31 Systems Engineering 31Version 1.0 – October 18, 2005 Example Architecture Issues Audi 2006 A8, A8 L, and A8 L W12 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.

32 Systems Engineering 32Version 1.0 – October 18, 2005 Summary Increasingly complex systems drive a need for better, clearer design descriptions Architectures convey the system designers 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

33 Systems Engineering 33Version 1.0 – October 18, 2005

34 Systems Engineering 34Version 1.0 – October 18, 2005 References Boeing Systems Architecture Development Guidebook The Art of Systems Architecting, Eberhardt Rechtin, Mark W. Maier DoD Architecture Framework (DoDAF)

35 Systems Engineering 35Version 1.0 – October 18, 2005 Recommended Use of DoDAF Products

36 Systems Engineering 36Version 1.0 – October 18, 2005 DoDAF View Extraction

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

38 Systems Engineering 38Version 1.0 – October 18, 2005 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

Download ppt "Systems Engineering 1Version 1.0 – October 18, 2005 Systems Architecting An introduction."

Similar presentations

Ads by Google