systems engineering competencies and approaches

Report
ESoS
Managing the systems lifecycle: systems
engineering competencies and
approaches
Professor Michael Henshaw
Loughborough University, UK
1
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Content
 Competency in Systems Engineering
 System lifecycles
 Standards
 ISO15288 the systems engineering lifecycle
standard
2
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Systems Thinking for Energy
Negative
Behavioural
Change
Bio Fuels for
cars
CO2
Increase Bio
Fuel Production
Example from Geoff
Robinson, of Atkins,
Keynote at ieee SoSE
2010
Food shortages
Processing
De forestation
Systems Thinking:
Understand complex problems
Explore wider set of options
3
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
INCOSE Competency Framework
Systems Thinking
Systems concepts
Super system capability issues
Enterprise and technology environment
Holistic Lifecycle View
Determine and manage stakeholder
requirements
Systems design
Architectural design
Concept generation
Design for...
Functional analysis
Interface management
Maintain design integrity
Modelling and simulation
Select preferred solution
System robustness
Systems integration and verification
Validation
Transition to operation
Systems Engineering Management
Concurrent engineering
Enterprise integration
Integration of specialisms
Lifecycle process definition
Planning, monitoring and controlling
4
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Typical stages of lifecycle management
Initiation
Planning &
Design
Execution
Monitoring &
Control
Closing
5
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Holistic lifecycle view






Whole life costs
Maintaining performance, safety, security, etc.
Retaining knowledge of the system
Upgrades
Risks over time
Disposal
Image: Hunt Emerson
6
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
A System
 Definition of a system
 A system is a construct or collection of different
elements that together produce results not
obtainable by the elements alone.
 The elements, or parts, can include people,
hardware, software, facilities, policies, and
documents; that is, all things required to produce
systems-level results. ......... (Rechtin, 2000).
INCOSE definition (first part)
Image: AP
7
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Systems Engineering and the Systems Life Cycle Standard
Required by
1. Systems Eng.
and systems
thinking
1. Standards
Mindset and
approach
for
2. System Life
cycles
Defines
3. System of
interest
Constrains
Applies
std.
5. Tailoring
Requires
Is an
appropriate
4. ISO15288
-scope
-structure
-use
illustrates
7. Limitations
8
Enables
mgt of
 Loughborough University, 2012
6. Case studies
MEGS III Lecture: Henshaw
ESoS
Standards - why they are important
The need for standards and Systems Engineering
9
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Standards: Benefits and Applicability
 Benefits




10
Safety
Interoperability
Quality
Upgradeability
 Loughborough University, 2012
 Applicability






Business
Trade
Technical
Engineering
Finance
Etc.
MEGS III Lecture: Henshaw
ESoS
Application to project phases
SAE
DIN
BSI
Manufacture
ASME
IEC
ASTM
Design
Operation
ISO
API – Application Programming Interface
ASME - American Society of Mechanical Engineers
ASTM – American Society for the Testing of Materials
BSI - British Standards Institution
DIN - Deutsches Institut für Normung eV
IEC - International Electrotechnical Commission
ISO - International Standards Organization
ITU – International Telecommunications Union
SAE - Society of Automotive Engineers
11
 Loughborough University, 2012
ISO
ITU
Construction
API
ASME
From ‘Why Standards are Important’, IHS
Whitepaper, www.ihs.com
MEGS III Lecture: Henshaw
ESoS
Compliance
 Regulation
 A regulation is a legal requirement and compliance is,
therefore, compulsory. A regulation is usually developed by
Government and specifies what must be done, but without
specifying how it must be done.
 Code
 A code is a standard (developed by an appropriate body) and
adopted by a Government entity. Compliance is compulsory.
 Standard
 A specification of best practice developed by experts and
based on consensus. It is recognised by an appropriate
standards development organisation. Compliance is
voluntary.
Based on ‘Why Standards are Important’,
IHS Whitepaper, www.ihs.com
12
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Part 4 – ISO 15288
 Origin of ISO 15288
 Application and characteristics of the standard
 Basic content of the standard
13
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Origin of ISO 15288
Emerging Standards
Systems context
1960
1970
Space
systems
Increasing
complexity
Complex
manufacture
1980
Software
Military
and civilian
std. in US
Std. In EU
Software
std.
1990
2000
ISO 15288 (2002)
2010
ISO 15288 (2008)
14
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Characteristics of 15288 (1)
 Product/service
 Although described as applicable to service
systems, the language and approach is strongly
product based
 Description
 Standard is a comprehensive list of processes for
life cycle management, but none is specified in
detail
 Cannot be used without tailoring
 High-tech. Organisations recognise the standard,
but don’t usually seek rigid compliance
15
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Characteristics of 15288 (2)
 Uses
 As an outline framework from which organisation
engineering and project management processes
may be derived
 As a checking procedure for extant processes
 Level of compliance can indicate areas for process
improvement
 Compliance is seen as meritorious, but not essential
16
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Significant INCOSE Publications based on 15288
 INCOSE Handbook
 INCOSE 2010 systems engineering handbook,
version 3.2. San Diego, CA, USA: International
Council on Systems Engineering (INCOSE),
INCOSE-TP-2003-002-03.2
 INCOSE UK Systems Engineering Competency
Framework
 INCOSE UK 2010
17
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Application
Enterprise
Enduring
Organisation
Long term
General
across all
projects
Single project
Project
Enterprise
Tailoring
Short term
Procedures : Processes
General/high level – slowly changing
Consistency
Processes
18
 Loughborough University, 2012
Specific/detailed – as & when required
MEGS III Lecture: Henshaw
ESoS
Generic Lifecycle
Concept
stage
Development
stage
Production
stage
Utilisation stage
Support stage
Retirement
stage
 A system progresses through specific stages
during its life
 In reality stages overlap
 Enabling systems are required at each stage
 All stages should be considered at design time
and lifecycle features incorporated
19
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
ISO 15288 Content
Agreement Processes
Acquisition
Supply
Technical Processes
Project Planning
Stakeholder Req.
Definition
Project Assessment &
Control
Req. Analysis
Decision Mgt
Organizational ProjectEnabling Processes
Architecture Design
Implementation
Risk Mgt
Integration
Life Cycle Model Mgt
Configuration Mgt
Verification
Infrastructure Mgt
Information Mgt
Transition
Project Portfolio Mgt
Measurement
Human Resource Mgt
Quality Mgt
20
Project Processes
System Life Cycle
Processes
on ISO/IEC,University,
2008 figure 4
Based
Loughborough
2012
Validation
Operation
Maintenance
Disposal
MEGS III Lecture: Henshaw
ESoS
Agreement Processes
 Provides symmetric processes for supplier and
customer
 Supply process
 Acquisition process
 Largely concerned with commercial matters
 Not necessarily executed by engineers
 Covers selection of or as supplier, acceptance
criteria of product/service, financial arrangements
21
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Organizational Project-Enabling Processes
 Processes put underlying plan and resources in place
 Selection/creation of appropriate life cycle model provides
underlying assumption for whole project
 E.g. CADMID underpins all UK defence acquisitions
 Creation and maintenance of appropriate infrastructure for
project
 Note that different organizations have different definitions of
infrastructure (buildings, communication channels, computer
networks, ...)
 Business decisions about portfolio of projects (sub-projects)
 Skills and human resources planned
 Quality procedures for project
 Note that these will often be defined at the organization level,
rather than at the individual project level
22
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Project Processes
 Mostly concerned with project management
 Considerable overlap between systems
engineering and project management
 Need to be consistent with standard project managment
processes of the organization
 Standard distinguishes between Project
management and project support
 Management: planning and assessment/control
 Support: decision, risk, information, measurement, and
configuration control
23
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Technical Processes
 Focused on classic Systems Engineering aspects
 Vee-model
 Stakeholder analysis and Requirements
 Design (architecture)
 Implementation and Integration
 Verification, Transition, and Validation
 Operation, Maintenance
 Disposal
24
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
(Typical) Vee-Model
Concept of Operation
Requirements
Operation & maintenance
Verification
and
Validation
Validation
Architecture
Systems Verification
Project test
& integration
Project
Definition
Detailed Design
Test, and verification
Integration
Implementation
Time
25
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
(Typical) Vee-Model + 15288 Technical Processes
Disposal
Concept of Operation
Stakeholder Req. Definition
Requirements
Requirements
analysis
Maintenance
Operation
& maintenance
Operation
Verification
and
Validation
Validation
Validation
Transition
Systems Verification
Architecture
Design
Architecture
Project
Definition
Verification
Detailed Design
Project test
& integration
Test, and verification
Integration
Implementation
Implementation
Time
26
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Use
 To some extent, ISO 15288 represents the
collation of good practice
 Organisations that develop complex systems may
have procedures and processes that follow 15288
implicitly
 Compliance may be advised but rarely (never?)
compulsory
27
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Limitations: SoS Properties - Emergence
Emergence is a phenomenon ascribable to the whole system and not to any of its
individual parts.
Some maintain it is only applied to something that has not been predicted, others that
it may be either planned or unexpected
Desirable/
predicted
Desirable/
unpredicted
Undesirable/
unpredicted
Desirable properties are
designed to emerge
Systems
Subsystems
Components
Traditional systems engineering;
well understood subsystems etc.;
V&V
28
 Loughborough University, 2012
Systems of systems engineering; incomplete knowledge of
interactions, complexity, strong emergence
MEGS III Lecture: Henshaw
ESoS
Managing and Engineering
 Members of the SoS owners’ club have partial knowledge and
influence
 Need to engineer for compliance (interoperability)
 Standards
 Manage own system (part) through control
 Manage other parts of SoS through influence, protective
measures, collaboration, … (not at all)
 If systems thinking tells us that we should make our
systems behave in certain ways to maximise benefit, why
don’t we do it?
 From the single-system community’s perspective, its part of
the SoS capability represents additional obligations,
constraints and complexities. Rarely is participation in an
(sic) SoS seen as a net gain from the viewpoint of singlesystem stakeholders.
 George Rebovich, Jr., 2009
29
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Traditional SE versus SoSE
SoS
Table 1. SE versus SoSE
30
 Loughborough University, 2012
From Neaga Henshaw and Yue, 2009
MEGS III Lecture: Henshaw
ESoS
Limitations of the Standard
What worked in the
past will not always
work in the future.
31
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Systems Engineering
 New publication available:
 Guide to the Systems Engineering Body of
Knowledge (SEBoK) at http://www.sebokwiki.org
32
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Back-up slides
33
 Loughborough University, 2012
MEGS III Lecture: Henshaw
ESoS
Example of use
 Large defence related organisation has recently
carried out a skills audit using the INCOSE
Competency Framework
 This provides health check for systems
engineering skills and marketing information for
use with clients
34
 Loughborough University
ISO 15288 Lectures: Henshaw

similar documents