Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

22
1 Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships Dr. John MacCarthy UMBC CMSC 615 Fall, 2006

description

Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships. Dr. John MacCarthy UMBC CMSC 615 Fall, 2006. Systems Engineering and Biology: The Role of Structure and Function Definitions: System, System of Systems & Family of Systems - PowerPoint PPT Presentation

Transcript of Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

Page 1: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

1

Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

Dr. John MacCarthyUMBC CMSC 615Fall, 2006

Page 2: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

2

Agenda Systems Engineering and Biology: The Role of Structure and Function Definitions:

System, System of Systems & Family of Systems Physical Architecture Hierarchy (Subsystems, Components and

Subcomponent) Configuration Items (CIs) and Computer Software Configuration Items (CSCIs) Goals, Capabilities, Activities, Functions, and Methods Architectures (Informal and Formal) Systems Architecting & System Architects Systems Engineering & Systems Engineers Systems Engineering Process Relationship between Systems Engineering and System Architecting Relationship between Systems Engineers and System Architects Types of Engineering Systems Engineering is qualitatively different from other Engineering Fields Qualities of a Systems Engineer Career Prospects

Page 3: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

3

Systems Engineering and Biology: The Role of Structure and Function

Major SE Objective: Develop structures that

perform required functions Major Systems

Engineering Tasks: Identify needed System

Functions Identify System Components

(Structure) Allocate Functions to

Components Develop Components Verify Components meet

requirements (Test)

Biology (Science) is inverse of SE process

Major Bio Objective: Understand reason for and

evolution of structures Major Bio Research Tasks:

Start with System Identify Structures Test to identify Functions

performed by Structures Test to understand functions

Page 4: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

4

Definitions of a “System” Definitions:

A System is “an integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective.” – DoD SEMG

A System is “an integrated set of elements that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements.” – INCOSE SE Handbook

A System is “a set of components (subsystems, segments) acting together to achieve a set of common objectives via the accomplishment of a set of tasks.” - Buede

A System is “a set of interacting components in which the behavior of each component affects the behavior of the whole set.” - Levis

A System is “an interacting combination of elements viewed in relation to function.” – INCOSE

A System is “any organized assembly of resources and procedures united and regulated by interaction or interdependence to accomplish a set of specific functions.” DoDAF

Characteristics: Generally it performs all functions required to

meet some (generally integrated) set of users’ objectives

Generally there is a System Boundary (& interface(s)) that separates it from the External Systems (and Users) with which it interacts

Generally it is composed of interacting Subsystems/ Components (CIs and/or CSCIs)

Generally it can be HW, SW, HW & SW, facilities, or a combination

Generally it is developed under a single contract Examples:

Aircraft System, Ship System Weapon System, Sensor System, Weapon/Sensor

System, Comm System, BMC2 System, etc. An integrated set of one or more Services

Observations: No universal definition, but much in common Generally one person’s Subsystem is another

person’s System Sometimes, in addition to (HW and/or SW) a

system may include (or consist of) people (and/or organizations) and/or processes (a point of debate)

Exercise: Under what conditions would a Radar be considered System and under what conditions would it be considered a Subsystem/Component?

Page 5: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

5

Definitions of a “System of Systems”and “Family of Systems”

System of Systems: “A set or arrangement of independent systems that are related or connected to provide a given capability. The loss of any part of the system will degraded the performance or capabilities of the whole.” - DAG

Characteristics: Examples:

A Hospital or Clinic An IT Enterprise A Naval Battle Group An Aircraft Carrier Nuclear Waste Disposal SoS

Family of Systems: “A set or arrangement of independent systems that can be arranged or interconnected in various ways to provide a different capabilities. The mix of systems can be tailored to proved desired capabilities, dependent on the situation.” - DAG

Characteristics Examples:

A group of Weapon and Sensor of a systems

A group of Aircraft Legos

Exercise: When does a “System” become a “System of Systems”? Under what conditions would an Aircraft Carrier be considered System of Systems and under what conditions would it be considered a System?

Page 6: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

6

Example of a System of Systems, System, Subsystems, and Components

System of Systems: Battle Group

Aircraft Carrier Aircraft Cruiser Destroyer Etc.

System: Aircraft System Air Frame Propulsion Communications/

Identification Navigation/Guidance Radar Flight Control Central Computer Electronic Warfare Weapon Delivery Equipment Armament

Subsystem: Radar System Receiver Transmitter Antenna Radar Application SW Radar System SW

Component: Radar Application SW Subcomponent (CSCI) 1 Subcomponent (CSCI) 2 Subcomponent (CSCI) 3 …

Page 7: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

7

Configuration Items (CIs) and Computer Software Configuration Items (CSCIs)

Configuration Item (CI): “an aggregation of hardware, firmware, or computer software, or any of their discreet portions, which satisfy an end-user function and is designed for separate configuration management. Any item required for logistic support and designated for separate procurement is generally identified as a CI. Components can be designated as CIs because of crucial interfaces or need to be integrated with operational or other components within or outside of the system.”

Computer Software Configuration Item (CSCI): an aggregation of software, software components and/or classes that is designated as a CI. In UML they are often denoted as “Packages.”Note: CIs are identified and controlled through Configuration

Management.Note: All CIs should be reflected in the WBS as a WBS element.

Page 8: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

8

Formal Physical Architecture Hierarchy(INCOSE SE Handbook)

System: An integrated set of elements, segments and/or subsystems that accomplish a defined objective, such as an air transportation system.

Element or Segment: A major product, service, or facility of the system, e.g., the aircraft element of an air transportation system (commonly used, but subsystems can be used instead of element/segments).

Subsystem: An integrated set of assemblies, components, and parts which performs a cleanly and clearly separated function, involving similar technical skills, or a separate supplier. Examples are an aircraft on-board communications subsystem or an airport control tower as a subsystem of the air transportation system.

Assembly: An integrated set of components and/or subassemblies that comprise a defined part of a subsystem, e.g., the pilot’s radar display console or the fuel injection assembly of the aircraft propulsion subsystem.

Subassembly: An integrated set of components and/or parts that comprise a well-defined portion of an assembly, e.g., a video display with its related integrated circuitry or a pilot’s radio headset.

Component: Comprised of multiple parts; a cleanly identified item, e.g., a cathode ray tube or the ear-piece of the pilot’s radio headset.

Part: The lowest level of separately identifiable items, e.g., a bolt to hold a console in place.Note that for large projects Software

Developers generally decompose SW along similar lines.

Page 9: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

9

Informal Physical/SW Architecture Hierarchy

Software often uses similar notations In OOD/UML Classes are often assigned to (aggregated into)

hierarchies of “Packages” that may be so characterized. For the Purposes of this course, I will use the terms:

“External System” to mean a collection of HW/SW that interfaces with the “System”, is perceived by the “System” as a single unit, and was not developed under the current contract (and possibly by one or more other contractors and/or agencies).

“System” to mean a collection of HW/SW that is being developed under a single contract.

“Subsystem” to mean an aggregate of components that make up a portion of a System

“Component” to mean a CI or CSCI “Subcomponent” to mean one of a collection of different items

that make up a CI or CSCI

Page 10: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

10

Goals, Activities, Functions, and Methods

Definitions: Goals or Objectives are generally

high-level statements identifying what the user wants the system to do (e.g., defend friendly forces from enemy attack)

An Activity (or Task) is generally something that must be performed (by an organization, person, HW/SW System and/or HW or SW Component) to achieve a specific goal (objective) or accomplish a specific higher-level Activity.

A Function is generally understood to be an Activity performed by a HW/SW system, subsystem, element, subelement, component, subcomponent, etc. (as opposed to activities performed by people and/or organizations).

A Method is generally understood to be an Function (allocated to and) performed by a SW Class or Object

Observations: Goals/Objectives may be

decomposed into Activities/ Functions

Activities/Functions may be further decomposed into sub-activities/ sub-functions (functional decomposition)

Within the context of Systems Engineering, the term “Function” has a much broader meaning than in Software Development.

Page 11: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

11

Architectures: Informal [1] Types of Architectures:

Functional Architectures Physical/Component/SW Architectures Data/Data Flow Architectures Allocated (Functions to Components)

Architectures & Architecture Standards: IDEF DoD Architecture Framework (DoDAF)

Operational Views Systems Views Technical Standards View

Zackmann Framework Service Oriented Architectures (SOA) Model-Driven Architectures (MDA) Other

Page 12: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

12

Architectures: Formal [2]

Definitions: Architecture is “the structure – in terms of components, connections,

and constraints – of product, process, or element.” – Rechtin Architecture is “the structure of components, their relationships, and

the principals and guidelines governing their design and evolution over time.” – DoDAF

An Architecture Description is “a representation of a defined domain, as part of a current or future point in time, in terms of its component parts, what those parts do, how the parts relate to each other and the rules and constraints under which the parts function.” “The term architecture will be used as a shorthand reference to architecture.” The Operational View, System View and Technical Standards view together constitute an architecture description.- DoDAF

Architecture View is “ System Architecture is “the arrangement of elements and

subsystems and the allocation of functions to them to meet system requirements.” – DSMC SEF & INCOSE SEF

Page 13: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

13

Functional and Physical Architectures [3]

Functional Architecture: “identifies and structures the allocated

functional and performance requirements” – SEF

a “logical architecture that defines what a system must do, a decomposition of the system’s top-level function” – Buede

a “logical model that captures the transformation of inputs into outputs using control information” - Buede

The hierarchical arrangement of functions, their internal and external (external to the aggregation itself) functional interfaces and external physical interfaces, their respective functional and performance requirements, and the design constraints. – INCOSE SEH

Physical Architecture: “depicts the system product by showing how it is

broken down into subsystems and components.” – SEF

identifies the “resources for every function identified in the functional architecture.” – Buede

“The hierarchical arrangement of product and process solutions, their functional and performance requirements; their internal and external (external to the aggregation itself) functional and physical interfaces and requirements, and the physical constraints that form the basis of design requirements. The physical architecture provides the basis for system/CI baselines as a function of the acquisition phase. It documents one or more physical designs as required to 1) accomplish effectiveness analysis, risk analysis, and technology transition planning; 2) establish the feasibility of physically realizing the functional architecture; 3) identify manufacturing verification, support and training requirements; 4) document the configuration of prototypes and other test articles, and 5) define in increasing detail the solution to identified needs.” – INCOSE SEH

Page 14: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

14

DoD Architecture Framework [4] DoDAF Definitions:

Operational View: “describes the tasks and activities necessary to perform a a mission, the participating nodes, and the associated information exchanges.” “A pure OV is material independent.” - DODAF

System View: “describes the systems of concern and the connections among those systems in the context of the OV.” - DODAF

Technical Standards View: “describes a profile of the minimal set of time-phased standards and rules governing the implementation, arrangement, interaction, and interdependence of systems.” - DODAF

Observations Architecture has many (not

necessarily consistent) meanings A System Architecture

presupposes Functional Architecture Physical Architecture

For Systems Engineers, Software Architecture is considered part of the “Physical” Architecture

Functional Architecture is what the system has to do

Physical Architecture is the components that will do it

As such the complete System Architecture describes not just what the system consists of and how it is connected, but also what the system must do and how it will do it

Page 15: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

15

Systems Architecting and Systems Architects

Systems Architecting: Developing a System Architecture Systems Architect: One who develops System Architectures Types of (System) Architects:

System of Systems Architect: responsible for establishing the architecture for a System of Systems (generally a systems engineer), generally orchestrates the work of System Architects

System Architect: responsible for establishing the architecture for a System (generally a systems engineer), generally orchestrates the work of “Specialty Architects”

Enterprise Architects: responsible for establishing the architecture for an Enterprise (generally an IT or communications systems engineer), generally orchestrates the work of “Specialty Architects”

Domain Architect: responsible for establishing the domain architecture (generally a systems engineer/analyst)

Business/Process Architect: responsible for establishing the architecture for a process (generally a systems analyst)

Software Architect: responsible for establishing the software (logical and component) architecture for a system (generally a software (design) engineer)

Data Architect: responsible for establishing the data architecture for a system (generally a data engineer)

Communications Architect: responsible for establishing the communications (network) architecture for a system (generally a communications (design) engineer)

Hardware/Facility Architect: responsible for establishing the hardware/facility architecture for a system, generally a design engineer (e.g., EE, Mechanical, Nuclear, Civil, etc.)

Transportation Architect: responsible for establishing the transportation architecture for a system, generally a transportation engineer

Note that what is meant by a “System Architect” depends on what one views as the “System.”

Page 16: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

16

Systems Engineering Definitions:

Systems Engineering consists of “the technical knowledge domain and the systems engineering management domain” – DSMC SEF

Systems Engineering is “an interdisciplinary approach and means to enable the realization of successful systems. Systems engineering: a.) encompasses the scientific and engineering efforts related to the development, manufacturing, verification, deployment, operations, support, and disposal of system products and processes; b.) develops needed user training equipments, procedures, and data; c.) establishes and maintains configuration management of the system; d.) develops work breakdown structures and statements of work; and e.) provides information for management decision making.” – INCOSE SE Handbook

Systems Engineering is a “logical sequence of activities and decisions that transforms an operational need into a description of system performance parameters and a preferred system configuration.” - MIL-STD-499A

Systems Engineering is an “interdisciplinary approach that encompasses the entire technical effort, and evolves into and verifies an integrated and life cycle balanced set of system people, products, and process solutions that satisfy customer needs.” - EIA Standard IS-632

Systems Engineering is an “interdisciplinary approach, collaborative approach that derives, evolves, and verifies a life-cycle balanced system solution which satisfies customer expectations and meets public acceptability.” - IEEE P1220

Systems Engineering Process is “a predefined set of activities selectively used to accomplish Systems Engineering tasks.” It is “a comprehensive, iterative problem solving process that is used to: a.) transform validated customer needs and requirements into a life-cycle balanced solution set of system product and process designs, b.) generate information for decision makers, and c.) provide information for the next acquisition phase. The problem and success criteria are defined through requirements analysis, functional analysis/allocation, and systems analysis and control.” – INCOSE SHE

Observations: Systems Engineering is a process for achieving a program’s technical objectives The (Lead/Chief) Systems Engineer is responsible for establishing, monitoring, and guiding (i.e.,

managing) this process

Page 17: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

17

Some Systems Engineering “Standards” DSMC Systems Engineering Fundamentals (SEF) INCOSE Systems Engineering Handbook (SEH) NASA Systems Engineering Handbook IEEE–1220-2005: Standard for Application and

Management of the Systems Engineering Process

EIA/IS-632 ISO/IEC 15288 MIL-STD-499 MIL-HDBK-881 MIL-STD-1521B

Page 18: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

18

Systems Engineers Systems Engineer

A Systems Engineer is “an engineer trained or experienced in the field of Systems Engineering.” –SEF

Types of Systems Engineers Systems Engineering Managers Systems Architects (Domain, HW, SW, Comm, Process, etc.) Systems Engineers (Domain, HW, SW, Comm, Process, etc.) Requirements Engineers Requirements Analysts Systems Analysts Systems Modelers Test Systems Engineers “Specialty” Engineers

Life Cycle Costing Risk Management Configuration Management Reliability, Availability, Maintainability Information Assurance Security Safety Human Factors Integrated Logistic Support …

Page 19: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

19

SE Handbook SE Process

AcquisitionProcess

SupplyProcess

Acquisition& Supply

Technical Evaluation

SystemsAnalysisProcess

SystemVerification

Process

RequirementsValidationProcess

End ProductsValidationProcess

Technical Management

PlanningProcess

AssessmentProcess

ControlProcess

SystemDesign

RequirementsDefinition Process

Solution DefinitionProcess

ProductRealization

ImplementationProcess

Transition to UseProcess

Plans,Directives& Status

Outcomes&

Feedback

Requirements

Designs

Products

AcquisitionRequest

SystemProducts

Page 20: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

20

SEF Systems Engineering Process

Page 21: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

21

Comparing Systems Engineers and Systems Architects

Chief Systems Engineer: Primarily concerned with

ensuring that the Systems Engineering Process is defined and followed

Responsible for ensuring that the product meets customer requirements:

Architecture Requirements Analysis Design Development Test Configuration Management Risk Management …

Chief Systems Architect: Primarily concerned with

developing the Architecture Responsible for ensuring the

Architecture meets customer requirements

The Architecture is implementable

Systems Architecting is a Systems Engineering subspecialty

Page 22: Lecture 1.2: Systems Engineering and Architecting Definitions & Relationships

22

Conclusions on Definitions There is no single “correct” definition

for any of these terms (every reference has its own slightly different definition)

There are common themes to each set of definitions for a given term.

The terms are fuzzy but well-defined