Presentation is loading. Please wait.

Presentation is loading. Please wait.

Systems Architecting An introduction.

Similar presentations

Presentation on theme: "Systems Architecting An introduction."— 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 Systems are becoming increasingly large and complex
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
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 System Analysis Modeling & Simulation Trade Studies Effectiveness Analysis Requirements Analysis Analyze Missions and Environments Identify Functional Requirements Define/Refine Performance and Design Constraints Identify Quality Attributes Validate Requirements Goal/Mission Analysis/Validation 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 Many perspectives: physical, functional, operational, technical… Behavioral Descriptions

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 Framework Customer 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) The OV is a description of the tasks and activities, operational elements, and information exchanges required to accomplish DoD missions. DoD missions include both war fighting missions and business processes. The OV contains graphical and textual products that comprise an identification of the operational nodes and elements, assigned tasks and activities, and information flows required between nodes. It defines the types of information exchanged, the frequency of exchange, which tasks and activities are supported by the information exchanges, and the nature of information exchanges. An Operational View (OV) describes the tasks and activities, operational elements, and information exchanges required to conduct operations. A pure OV is materiel independent. However, operations and their relationships may be influenced by new technologies such as collaboration technology, where process improvements are in practice before policy can reflect the new procedures. There may be some cases, as well, in which it is necessary to document the way processes are performed given the restrictions of current systems, in order to examine ways in which new systems could facilitate streamlining the processes. In such cases, an OV may have materiel constraints and requirements that must be addressed. For this reason, it may be necessary to include some high- level Systems View (SV) architecture data as overlays or augmenting information onto the OV products. There are seven OV products described in this section: · High-Level Operational Concept Graphic (OV-1) · Operational Node Connectivity Description (OV-2) · Operational Information Exchange Matrix (OV-3) · Organizational Relationships Chart (OV-4) · Operational Activity Model (OV-5) · Operational Activity Sequence and Timing Descriptions (OV-6a, 6b, and 6c) · Logical Data Model (OV-7) 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) The SV is a set of graphical and textual products that describes systems and interconnections providing for, or supporting, DoD functions. DoD functions include both warfighting and business functions. The SV associates system resources to the OV. These system resources support the operational activities and facilitate the exchange of information among operational nodes. The Systems View (SV) is a set of graphical and textual products that describe systems and interconnections providing for, or supporting, DoD functions. SV products focus on specific physical systems with specific physical (geographical) locations. The relationship between architecture data elements across the SV to the Operational View (OV) can be exemplified as systems are procured and fielded to support organizations and their operations. There are eleven SV products: · Systems Interface Description (SV-1) · Systems Communications Description (SV-2) · Systems-Systems Matrix (SV-3) · Systems Functionality Description (SV-4) · Operational Activity to Systems Functionality Traceability Matrix (SV-5) · Systems Data Exchange Matrix (SV-6) · Systems Performance Parameters Matrix (SV-7) · Systems Evolution Description (SV-8) · Systems Technology Forecasts (SV-9) · Systems Functionality and Timing Descriptions (SV-10a, 10b, and 10c) · Physical Schema (SV-11) 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) The TV is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements. Its purpose is to ensure that a system satisfies a specified set of operational requirements. The TV provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed. The TV includes a collection of the technical standards, implementation conventions, standards options, rules, and criteria organized into profile(s) that govern systems and system elements for a given architecture. The Technical Standards View (TV) provides the technical systems-implementation standards upon which engineering specifications are based, common building blocks are established, and product lines are developed. The TV includes two products: · Technical Standards Profile (TV-1) · Technical Standards Forecast (TV-2) 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 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 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 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


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

35 Recommended Use of DoDAF Products
Suggest that the lecturer doesn’t go over the details but just makes the point that there are ways to use the dodaf products in different phases of the architecture process – reuse means we don’t need to do some other diagrams if we can use the ones we created for the customer to help us describe some aspects of our design

36 DoDAF View Extraction

37 Evolving Architectures: Impact of Spiral Development

38 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 Architecting An introduction."

Similar presentations

Ads by Google