1 / 38

Systems Architecting

Systems Architecting. An introduction. Agenda. Evolution of Systems Relating Systems Engineering & Architectures Representing an Architecture Using Architectures Summary. Evolution of Systems. Evolution of Systems. Evolution of Systems. Evolution of Systems.

shannonbarney
Download Presentation

Systems Architecting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Systems Architecting An introduction

  2. Agenda • Evolution of Systems • Relating Systems Engineering & Architectures • Representing an Architecture • Using Architectures • Summary

  3. Evolution of Systems

  4. Evolution of Systems

  5. Evolution of Systems

  6. Evolution of Systems Systems are becoming increasingly large and complex

  7. No Easy Answer Modern Systems: • Ill-Structured • Involve New & Untested Ideas • Complex

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

  9. 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 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…

  11. 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. Architecting in the Systems Engineering Process • System Analysis • Modeling & Simulation • Trade Studies • Effectiveness Analysis • 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 • System • Management • Risk Management • Data Management • Configuration Management • Progress Measurement • IMP/IMS & TPMs • Technical Reviews 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 Physical Architecture Analysis Design Loop Verification Loop • Synthesis • Transform Each Level’s 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 Iteration Loop (Derived Requirements for the Next Level of Decomposition) • Process • Outputs • “Best Value” System Architecture • System Architecture Models and Specifications

  13. 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. 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. Describing the Architecture Physical Descriptions Operational Expectations Behavioral Descriptions Many perspectives: physical, functional, operational, technical…

  16. Physical View to an Architecture

  17. Functional View to an Architecture(Example Based on Unified Modeling Language)

  18. Product Diagrams of the Systems Architecture Use Case Diagrams Class Diagrams Activity & State Diagrams Sequence Diagrams

  19. DoDAF – DoD Architecture FrameworkCustomer Defined Views of the Model

  20. Operational View (OV)What needs to be done & Who does it High Level Operational Concept Graphic (OV-1) Operational Exchange Matrix (OV-3) Operational Node Connectivity Diagram (OV-2) Organizational Relationships Chart (OV-4)

  21. 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)

  22. 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. 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 – 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

  24. DoDAF Summary DoDAF isa way of describing a system. DoDAF representsa number of different views of the architecture. DoDAF isa required output to our customers. DoDAF is NOTa methodology or process. DoDAF is NOTa UML based set of views.

  25. 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. 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. 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. 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. The Risks of Architecting • Early Identification of Problems • Perception of Program Delay • Inconsistent Application of Methodologies • Limited Numbers of Skilled Creators/ Reviewers

  30. Risks of Not Architecting • Late Identification of Problems • Lack of Unified Design • Issues of Complexity Management

  31. 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. Summary • Increasingly complex systemsdrive 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

  33. References • Boeing Systems Architecture Development Guidebook • “The Art of Systems Architecting”, Eberhardt Rechtin, Mark W. Maier • DoD Architecture Framework (DoDAF)

  34. Recommended Use of DoDAF Products

  35. DoDAF View Extraction

  36. Evolving Architectures: Impact of Spiral Development

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

More Related