Transcript Software Engineering versus Systems Engineering

Software Engineering
versus
Systems Engineering
John A McDermid, FREng
Professor of Software Engineering
University of York
1
What is a System?
• According to the OED a system is
– An organised or connected group of objects
– A set or assemblage of things connected,
associated or interdependent so as to form a
complex unity
• System is a very general term
– A system might be a flock of geese, an
aircraft, or a set of computers ...
2
A Technical System
• This system (Typhoon) is a combination of
– Hardware, software, people, procedures …
• Hardware is electro-mechanical, hydro-mechanical
structural, etc.
3
A Software-Intensive System
• This system (CAATS) is a combination of
– Hardware - mainly computing
– Software, people, procedures, data …
4
Systems and Software
• IT projects are undertaken to deliver some
kind of business or process change
RAEng and BCS The Challenges of
Complex IT Projects (& many others)
• Hence, to be successful, software projects
must address
– Hardware, people, processes …
– Very similar scope to systems engineering
5
Systems vs Software
• INCOSE
Process
Summary
• Scope of
software
engineering?
– Software
technology
only
Enterprise
Processes
Project Processes
Enterprise
Environment
Management
Investment
Management
System
Lifecycle
Process
Management
Assessment
Planning
Decision
Making
Risk
Management
Process
Guidelines
Requirements
Analysis
Implementation
Quality
Management
Verification
Agreement
Processes
Acquisition
Operation
Supply
Configuration
Management
Architectural
Design
Integration
Transition
Validation
Maintenance
Disposal
6
Information
Management
Technical Processes
Stakeholder
Requirements
Definition
Resource
Management
Control
Some Questions (1)
• Do systems & software require different
modelling languages?
– E.g. SysML or MoDAF vs UML or AADL
• Do technical systems & software intensive
systems require different architectures?
– SOA appropriate for SIS, embedded in an
organisation
– Event driven for technical systems
7
Some Questions (2)
• What is the most effective relationship
between systems & software engineering?
– Systems led, for technical systems
– Software led, for software intensive systems
• Systems engineering can be viewed as
“the art of the trade-off”
– How can we ensure system trade-offs reflect
software properties and process risks?
8
Some Questions (3)
• What can systems engineering learn from
software engineering?
– e.g. disciplined approach to cost estimation
• What can software engineering learn from
systems engineering?
– e.g. consideration of trade-offs and use of
“framework methods” such as QFD
9
Some Questions (4)
• How can systems & software engineering
be taught to communicate the realities of
complex systems development?
– Educating academics
– Educating students
• For complex systems are systems and
software engineering really distinct?
– Will they converge or diverge?
10
Software Engineering
in harmony with
Systems Engineering
11
2. Behaviour
1. Structure
act PreventLockup [Swimlane Diagram]
ibd [block] Anti-LockController
[Internal Block Diagram]
satisfies
«requirement»
Anti-Lock
Performance
ibd [block] Anti-LockController
[Internal Block Diagram]
d1:TractionDetector
«allocate»
[Activity Diagram]
act PreventLockup
:TractionDetector
«allocate»
:BrakeModulator
allocatedFrom
«activity»DetectLos
d1:Traction
Of
Traction
OfTraction
Detector
c1:modulator
c1:modulator
Interface
Interface
c1:modulator
interface
DetectLossOf
Traction
m1:BrakeModulator
m1:Brake
Modulator
allocatedFrom
«activity»Modulate
BrakingForce
allocatedFrom
«ObjectNode»
TractionLoss:
TractionLoss:
allocatedTo
«connector»c1:modulatorInterface
values
DutyCycle: Percentage
satisfy
Modulate
BrakingForce
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
req [package] VehicleSpecifications
[Requirements Diagram - Braking Requirements]
v.chassis.tire.
Friction:
v.brake.abs.m1.
DutyCycle:
v.brake.rotor.
BrakingForce:
v.Weight:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
Vehicle System
Specification
Braking Subsystem
Specification
«requirement»
StoppingDistance
«requirement»
Anti-LockPerformance
id=“102”
text=”The vehicle shall stop
from 60 mph within 150 ft
on a clean dry surface.”
id=”337"
text=”Braking subsystem
shall prevent wheel lockup
under all braking conditions.”
tf:
tl:
bf:
:BrakingForce
Equation
[f = (tf*bf)*(1-tl)]
c
m:
f:
F:
:Accelleration
Equation
[F = ma]
a:
a:
:DistanceEquation
[v = dx/dt]
VerifiedBy
SatisfiedBy
«interaction»MinimumStopp
«block»Anti-LockController
«deriveReqt»
ingDistance
v:
v:
:VelocityEquation
[a = dv/dt]
x:
«deriveReqt»
«deriveReqt»
v.Position:
3. Requirements
4. Parametrics
12
View
Category
All Views
Strategic
Operational
Systems
Technical
Acquisition
View
No.
AV-1
View Name
View Description
Overview and Summary Information
Scope, purpose, intended users, environment depicted, analytical findings
AV-2
Integrated Dictionary
Architecture data repository with definitions of all terms used in all views
StV-1
Capability Vision
Outlines the vision for a Capability area over a particular time frame
StV-2
Capability Functions
Provides a structured list of Capability functions for a specific Capability area during a certain epoch
StV-3
Capability Phasing
Captures the planned availability of Capability at different points in time, i.e. different epochs
StV-4
System-of-Systems Clusters
Provides a means of analysing the main dependencies between Capability
StV-5
Capability to Systems Deployment Mapping
Shows the planned Capability deployment and interconnection by organisation / epoch
StV-6
Capability Function to Operational Mapping
Describes the mapping between capability elements and operational activities that can be performed using them and thereby
provides a link between capability analysis and activity analysis
OV-1a
High-Level Operational Concept Graphic
High – level graphical / textual description of operational concept
OV-1b
Concept of Operations
Provides a supplementary description of the High Level Operational Concept Graphic
OV-1c
Operational Performance Attributes
Provides detail of the operational performance attributes associated with the scenario / use case represented in the High Level
Operational Concept Graphic
OV-2
Operational Node Connectivity Description
Operational nodes, connectivity, and information exchange needlines between nodes
OV3
Operational Information Exchange Matrix
Information exchanged between nodes and the relevant attributes of that exchange
OV-4
Organizational Relationships Chart
Organizational, role, or other relationships among organizations
OV-5
Operational Activity Model
Capabilities, operational activities, relationships among activities, inputs, and outputs; overlays can show cost, performing nodes
or other pertinent information
OV-6a
Operational Rules Model
Identifies business rules that constrain operation
OV-6b
Operational State Transition Description
Identifies business process responses to events
OV-6c
Operational Event-Trace Description
Traces actions in a scenario or sequence of events
OV-7
Logical Data Model
Documentation of the system data requirements and structural business process rules of the Operational Viewpoint
SV-1
SV-2a
Systems Interface Description
System Port Specification
Identification of systems and system components and their interconnections, within and between nodes
System ports and protocols used by those ports when communicating with other systems
SV-2b
System To System Port Connectivity
Protocol stack used by a connection between two ports. The ports may be on different systems
SV-2c
System Connectivity Clusters
Individual connections between system ports, and grouping into logical connections between nodes
SV-3
Systems-Systems Matrix
Relationships among systems in a given architecture; can be designed to show relationships of interest, e.g., system type
interfaces, planned vs. existing interfaces, etc
SV-4
Systems Functionality Description
Functions performed by systems and the system data flows among system functions
SV-5
Operational Activity to Systems Functionality
Traceability Matrix
Mapping of systems back to capabilities or of system functions back to operational activities
SV-6
Systems Data Exchange Matrix
Provides details of system data elements being exchanged between systems and the attributes of that exchange
SV-7
Systems Performance Parameters Matrix
Performance characteristics of Systems Viewpoint elements for the appropriate time frame(s)
SV-8
Systems Evolution Description
Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a
future implementation
SV-9
Systems Technology Forecast
Emerging technologies and software/hardware products that are expected to be available in a given set of time frames and that
will affect future development of the architecture
SV-10a
Systems Rules Model
Identifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation
SV-10b
Systems State Transition Description
Identifies responses of a system to events
SV-10c
Systems Event-Trace Description
Identifies system-specific refinements of critical sequences of events described in the Operational Viewpoint
SV-11
Physical Schema
Physical implementation of the Logical Data Model entities, e.g. , message formats, file structures, physical schema
TV-1
Technical Standards Profile
Listing of standards that apply to Systems View point elements in a given architecture
TV-2
Technical Standards Forecast
Description of emerging standards and potential impact on current Systems Viewpoint elements, within a set of time frames
AcV-1
System-of-Systems Acquisition Clusters
Provides detail of how Acquisition tasks are grouped to improve management of interoperability and programmatic dependencies
AcV-2
System-of-Systems Acquisition
Provides an overview of either the complete acquisition Programme or a subset of projects
13
AADL Fragment
14
DEFINE REQUIREMENTS
FMEA
Generate
acceptance
criteria
“Customer”
Requirement
CONCEPT DESIGN
Acceptance
Test Spec
Structured Textual Analysis
Project:
Reliability Model
Fault Tree Analysis
Manage
Requirements
DOORS
Determine failure modes & mechanisms
and predict overall system reliability
Textual Analysis
sense
lawn state
cut grass
collect
grass
cuttings
drive and
manoeuvre
self
monitor
learning
Multi-language
3
Display
Coin handling
Optional Lan
Number entry
Durable
5
Reliable
4
Cleans easily
2
Maintainable
5
x
Function
x
Hands free Mic
S. steel casing
LCD Display
Card reader
Abc 16 Key pad
Containment
Voice
Switch
Sun-shine
& date
Remote
control
Buried cable
Bar coded
beacons
Ultrasonic
beacons
Radio
beacons
Learning
Neural Net
Lawn map
Database
Blackboard
System
AI
System
Self Monitor
Internal
sensors
& Memory
BITE
Cutting
Obstacle
detection
Solar
Petrol
Electric Motor
Drum
All wheels
CCD
ICE
Metal Blade
Battery
Microwave
Raised Edge
Clockwork
Gas
Steam
Clockwork
Plastic Blade
Laser Blade
Cord
Rear wheel
Ind. Brakes
IR
Ultrasonic
Touch probes
Expert
system
Neural Net
Deterministic
Front wheel
Learnt
Memory
Condition
monitoring
Navigate
Fuzzy logic
Inform user
Voice
LCD display
Plasma
display
CRT
Injection
Moulded
Weight On
switch
Glass Fibre
Carbon Fibre
Pressed Metal
Cutting
exposure
Light beam
navigate
Mercury
switch
Homing
beacon
Gyro
Return to base
Learnt
Memory
Casing
Indicator
lights
Cost < £28
Sensitivity -10dB
95% validation
All standard
500k inserts
70x50 mm
Check Requirements-Concept solution
compliance and determine sub system targets
Clockwork
dial
Identify means of
achieving functionality
WEATHER
IM operations
Target values
Fab. Metal
Function Means
Analysis
39 82 58 139 126 50 18
1kN shock
3 min
min ingress
Wipe Clean
Means
Activate
Mower
Determine
Position
Manoeuvre
Technical competitive
assessment
SEEDS
Card Reader
QFD 2
Motivator
Importance Weighting
luminosity
95%
validation
All standard
500k inserts
Coin Handling
Determine and model system
physical architecture
Provide Power
Target values
Display
32k Ram 120Mhz
x
5
Coin/card/credit
Architecture Modelling
x
95%
validation
All standard
500k inserts
sense
obstacles
4
16 max
1M ops
determine
position
cutting
Easy to use
European
Arabic
supply
power
navigation
Features
internal
management
Requirements
maintenance
luminosity
cutting
process
user
interaction
po
Design
rta
nc Requirements
e to
Cu
sto
Customer
me
r
Operation
supply
machine
Determine system
functionality (Y = f)
and structure
Im
x
Number Entry
Correlate and cross check
requirements for completeness
and consistency
Intelligent
Lawn mower
European
Arabic
16 max
1M ops
Optional Lang
x
Viewpoint Analysis
XYZ Coin Mech
QFD 1
x
Non Functional
Implementation
Requirement
x
Non Functional
Performance
Requirement
Element
Ty Requirements
pe
of
Ta
rge
t
Design
Requirements
Wipe clean
Functional
Requirement
Capture stated customer
requirements and
determine Operational,
Functional and NonFunctional Requirements
Containment
Non functional System Requirements:
1kN shock
Operational Requirement:
3 min
min ingress
Context:
Card reader
Requirements
Microprocessor
Author:
Decision Matrix
Criteria
Weighting
Reliab’ty
0.25
Obstacle
Avoid/safe
.1
COMPOST
PICK
VEGETABLE
VEGETABLES
3
HOME_GROWN_SEED
EXTRACT
SEED
4
Functional Modelling
Develop a functional model of
the system Y= f(x) to identify
logical interfaces and
Functional dependencies
Assess the functional sensitivity
and potential functional failure
modes to identify potential
emergent functionality and risk
F 6
3 E 1
1 K
3 3
2 2
90%
50%
70%
30%
90%
22.5
15
7
9
9
80%
100%
70%
70%
50%
20
25
7
21
5
70%
100%
80%
70%
40%
17.5
25
8
21
4
Design A
Function
M
8
1 4
9 8
4
C 8 9 8
2
G
9 8
D
Output
Viewpoint: Function
Input
Receiving
Function
ABC
X
DEF
X
IJK
S
LMN
Severity of Occurrence
O
Probability of Occurrence
PQR
D
Probability of Detection
System: Washing Machine
Criticality Index
Date...............................
.
No: ....
Author: ..........................
Issue
Checked: .......................
...........
CI = SOD
Subsystem: ......................................
6
2 6
Self Monitor
Provide Power
Motivator
A 6
2 J
MODE
IJK
Y
DETERMINE LOAD MAKE
UP
EFFECTS
CAUSE
INDEX
O
S
D
CI
OVERLOAD
POOR WASH
USER ERROR
6
6
3
108
UNDERLOAD
POOR WASH
USER ERROR
4
4
3
48
EXTREME MIX OF
LOAD
POSSIBLE COLOUR
RUN
EXTREMES NOT
IDENTIFIED
8
8
3
96
FABRIC SHRINK
EXTREMES NOT
IDENTIFIED
4
8
3
96
POOR WASH
ITEM OF CLOTHING
NOT INDENTIFIED
4
8
3
96
INCORRECT LOAD
MAKE UP
INDENTIFIED
COMMENTS
POSSIBLE COLOUR
RUN
FABRIC SHRINK
© Burge Hughes Walsh 2005
N2 Analysis
Assess degree of natural
functional dependencies
15identify architecture
to
and system redundancy
AI
System
BITE
Solar
Battery
Metal Blade
All wheels
Obstacle
detection
Navigate
Remote
control
Electric Motor
Front wheel
IR
Fuzzy logic
Inform user
Plastic Blade
Rear wheel
Ind. Brakes
Ultrasonic
Touch probes
Expert
system
Deterministic
Indicator
lights
LCD display
Cutting
exposure
Injection
Moulded
Weight On
switch
Return to base
navigate
Casing
CHARACTERISTICS OF FAILURE
FUNCTION
LOAD DIRTY CLOTHES
Internal
sensors
& Memory
Cutting
Manoeuvre
Sun-shine
& date
Blackboard
System
Ultrasonic
beacons
Learning
3 7
1 N 8
7
4 5 4 1 9 O 7 9 2 9
9 H 9
Switch
Lawn map
Database
Buried cable
78.0%
Design C
Means
Activate
Mower
Determine
Position
62.5%
Design B
3 3 7
6 6 7
B 3 9
6 L 9
I
Overall
Satisfaction
Concepts
Evaluate whole concepts
against key requirements
for further down-selection
2
DIAGRAM 0
Risk
0.3
Sensitivity Analysis
PLANTS
CULTIVATE
Ease of
use
0.1
PURCHASE
1
cut
perform’
0.25
Carbon Fibre
Mercury
switch
Whole System
Solution Identification
Determination of whole
Concept system solutions
75.5%