systems engineering 1version 1.0 – october 18, 2005 systems architecting an introduction

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

Upload: paige-mcconnell

Post on 27-Mar-2015

216 views

Category:

Documents


1 download

TRANSCRIPT

Systems Engineering

1Version 1.0 – October 18, 2005

Systems ArchitectingAn introduction

Systems Engineering

2Version 1.0 – October 18, 2005

Agenda

• Evolution of Systems

• Relating Systems Engineering & Architectures

• Representing an Architecture

• Using Architectures

• Summary

Systems Engineering

3Version 1.0 – October 18, 2005

Evolution of Systems

Systems Engineering

4Version 1.0 – October 18, 2005

Evolution of Systems

Systems Engineering

5Version 1.0 – October 18, 2005

Evolution of Systems

Systems Engineering

6Version 1.0 – October 18, 2005

Evolution of Systems

Systems are becoming increasingly large and complexSystems are becoming increasingly large and complex

Systems Engineering

7Version 1.0 – October 18, 2005

No Easy Answer

Modern Systems:– Ill-Structured– Involve New & Untested

Ideas– Complex

Systems Engineering

8Version 1.0 – October 18, 2005

Overcoming these Problems

How will we:– Manage uncertainty– Manage complexity– Manage technological

change

Maybe he doesn’t want to be in charge of the next customer review

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

Systems Engineering

10Version 1.0 – October 18, 2005

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…

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.

Systems Engineering

12Version 1.0 – October 18, 2005

ProcessOutputs• “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 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

System Analysis• Modeling & Simulation• Trade Studies• Effectiveness Analysis

System Management• Risk Management• Data Management• Configuration Management• Progress Measurement

IMP/IMS & TPMs Technical Reviews

ProcessInputs• 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

Requirements Loop

Design Loop

Verification Loop

Iteration Loop(Derived Requirements for the Next Level of Decomposition)

Goal/MissionAnalysis/Validation

FunctionalArchitecture

Analysis

PhysicalArchitecture Analysis

Architecting in the Systems Engineering Process

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

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

Systems Engineering

15Version 1.0 – October 18, 2005

Describing the Architecture

Physical Descriptions

Behavioral Descriptions

Operational Expectations

Many perspectives: physical, functional, operational, technical…

Systems Engineering

16Version 1.0 – October 18, 2005

Physical View to an Architecture

Front Elevation View

Plan View

Perspective View

Building CodesTechnical Standards View

Front Elevation View

Plan View

Perspective View

Building CodesTechnical Standards View

Systems Engineering

17Version 1.0 – October 18, 2005

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

Provide Access & Mobility

Provide Space

Provide Living Space

Provide Vehicle Storage

Provide Storage

Provide Object Storage

Provide Food & Drink

Provide Nurishment

Provide Waste Disposal

Provide Physical Security

Provide Protection

Provide Physical Protection

Provide Sleeping

Provide Personal Cleaning

Provide Seating

Provide Comfort

Provide Climate

Provide Video Entertainment

Provide Audio Entertainment

Provide Computing Entertainment

Provide Telephony

Provide Human Habitat

Provide Communications & Entertainment

Systems Engineering

18Version 1.0 – October 18, 2005

Mission plan completed in planning system, encrypted, and ready for transfer

Display menu for selecting method of transfer of mission plan to Air Vehicle

Radio mission plan to Air Vehicle

Transfer mission plan to data transfer cartridge

Choose appropriate mission plan transfer method

Carry data transfer cartridge to Air Vehicle

Put data transfer cartridge in Air Vehicle

Air Vehicle powered up, checked out and ready for mission plan

Radio receive mission plan

Receive data transfer cartridge

Request decryption key

Display confirmation of mission plan & pilot acceptance

Air Vehicle ready for taxi and operational use

See Mission Plan & Pilot Authentication Use Case

: PSS Air Vehicle : PSS Pilot : Planning System

Piloted Strike System & SoS Aggregations with System of System Classes in green

Air Operations Commander Mission Area Commander

Operation Commander

Combat Air Operations Group

11 0..n0..n

Operation Group

11

1..n1..n

Mission Commander

Small Diameter BombPSS Air Vehicle JDAM

Flight Package

1..n1..n

11

PSS Pilot

Piloted Strike System

0..n0..n11 0..n0..n

1..n1..n

11

Perform Final Pre-Flight Tests

Taxi Solo to Point

Enter Solo Flight Holding Pattern

Take Off Solo Air Vehicle

Enter Solo Landing Approach

Taxi Solo to Taxi Hold-Point

Taxi Solo to Take Off Hold-Point

<<extend>>

<<extend>>PSS Pilot

Air Traffic Controller

Land/ Taxi Solo Air Vehicle

<<include>>

<<include>>

Operation CommanderReceive Solo Mission Start

Clearance

Taxi/ Take Off Solo Air Vehicle

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

: PSS Pilot : PSS Air Vehicle

: Airborne Tanker

: Refueling Specialist

Initiate Fuel Flow Through Fuel Boom

Display Fuel Level,Report Fuel Level

Visually Monitor Tanking Operation,Monitor Fuel Level

5: Radio Relay Fueling Anomaly Report(Verbal Anomaly Report : Data)

4: Report Fueling Anomaly Status(Anomaly Scene : View, Anomaly Fuel Level

Data : Data)

1: Flow Fuel to Air Vehicle(Initiate Fuel Flow :

Command)

3: Monitor Fueling Situation Display(Fuel Level : Data,

Fueling Operation Scene : View)

6: Audio Message Fueling Anomaly Report(Verbal Anomaly Report : Data) 7: Monitor for Fueling

Anomaly Reports(Verbal Anomaly Report : Data)

Display Fueling Progress,Display Interlock Locked Status

Seq's 3, 7, and 8 are concurrent2: Update Fueling Progress

Display(Fuel Level : Data)

8: Automatically Monitor for Fuel Level and Emergencies( )

Class DiagramsUse Case Diagrams

Activity & State DiagramsSequence Diagrams

Product Diagrams of the Systems Architecture

Systems Engineering

19Version 1.0 – October 18, 2005

DoDAF – DoD Architecture FrameworkCustomer Defined Views of the Model

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)

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)

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)

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

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.

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

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 PracticesStevens Institute of Technology, March 15, 2004

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

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

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

Systems Engineering

30Version 1.0 – October 18, 2005

Risks of Not Architecting

• Late Identification of Problems

• Lack of Unified Design

• Issues of Complexity Management

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

Systems Engineering

32Version 1.0 – October 18, 2005

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

Systems Engineering

33Version 1.0 – October 18, 2005

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)

Systems Engineering

35Version 1.0 – October 18, 2005

Recommended Use of DoDAF Products

Systems Engineering

36Version 1.0 – October 18, 2005

DoDAF View Extraction

Systems Engineering

37Version 1.0 – October 18, 2005

Evolving Architectures: Impact of Spiral Development

Continuous User Assessment & Collaboration; Sustainment & CONOPSContinuous User Assessment & Collaboration; Sustainment & CONOPS RefinementRefinement

CollaborativeSpirals

OCA = Ops Capability Assessment Spiral Definition / Requirements

System Technology Demo

Fieldable Prototype DemoOCA

Integrated Acquisition

Team•• UsersUsers•• AcquirersAcquirers•• TestersTesters•• ResearchersResearchers•• LogisticiansLogisticians

OCA

Production

Spiral 2

Spiral 3OCA

OCASpiral 1 Development

FY02 FY03 FY04 FY05 FY06 FY07 FY08 FY09 FY10 FY11 FY12

TraditionalFY13

Development

Production

FY01FY99-00Concept Demo

Continuous User Assessment & Collaboration; Sustainment & CONOPSContinuous User Assessment & Collaboration; Sustainment & CONOPS RefinementRefinement

CollaborativeSpirals

OCA = Ops Capability Assessment Spiral Definition / Requirements

System Technology Demo

Fieldable Prototype DemoOCA

Integrated Acquisition

Team•• UsersUsers•• AcquirersAcquirers•• TestersTesters•• ResearchersResearchers•• LogisticiansLogisticians

OCA

Production

Spiral 2

Spiral 3OCA

OCASpiral 1 Development

FY02 FY03 FY04 FY05 FY06 FY07 FY08 FY09 FY10 FY11 FY12

TraditionalFY13

Development

Production

FY01FY99-00Concept Demo

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