swise arc2015

Software-Intensive-Systems EngineeringHow Software Affects System Development

Prof. Dr. Amir Tomer, CSEPHead, Dept. of Software and Information Systems Engineering

Achi Racov Engineering SchoolsKinneret Academic College on the Sea of Galilee, Jordan Valley, Israel

amir@amirtomer.com

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 1

Kinneret College on the Sea of Galilee

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 2

Kinneret College on the Sea of Galilee

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 3

Kinneret College –Lake View from inside the Library

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 4

OTH-Regensburg & HS-KemptenPartnership with Kinneret College

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 5

Kinneret Visit - December 2014

Systems Engineering

• Systems Engineering is an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 6

The Current Situation

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 7

Text source :http://blissfulwriter.hubpages.com/hub/Software-Code-in-Your-CarPicture source :http://www.ramanmedianetwork.com/ibm-software-drives-chevrolet-volt/

Most Systems Today are Software-Intensive-Systems

• A software-intensive system is any system where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole

[IEEE-Std-1471]

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 8

http://images.cryhavok.org/

Where is the Software?

• Components– Operation

• System– Integration / Communication

– Operating System

• System-of-Systems– Interoperability

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 9

http://www.autosec.org/pubs/cars-usenixsec2011.pdf

Component-specific Software

• Embedded Software– Firmware: Burnt within the components

• Drivers– External C&C over components

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 10

http://sudcamp.hubpages.com/hub/Sensors-in-smartphone

Software as the Nervous Subsystem of a System

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 11

The only interactive subsystem in the human body

C4I = Command, Control, Computing, Communication and Intelligence

The body’s Operating System

http://philschatz.com/anatomy-book

Software as the Enabler of Interoperability for SoS

• System-of-Systems (SoS)– A SoS is an integration of a finite number of constituent systems which are

independent and operable, and which are networked together for a period of time to achieve a certain higher goal

[prof. Mo Jamshidi, 2005]

• Interoperability– A property of a product or system, whose interfaces are completely understood,

to work with other products or systems, present or future, without any restricted access or implementation

[http://interoperability-definition.info]

• Common interoperability standards / conventions– Bluetooth

– TCP/IP

– XML

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 12

Halt!

Jawohl!

Essential Influences of Software on Systems Engineering: Examples

• Impacts on System Operation– Different mathematics

– High vulnerability

– Different concept of reliability

• Impacts on System Design– Development Life Cycle

– BYOD (Bring Your Own Device)

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 13

https://www.thedropon.com/drop/funny

Digital Math vs. Physical Math

• Question

• Answer

1. Infinity (scientist)

2. ERROR (engineer)

3. OVERFLOW/EXCEPTION (software engineer)

• Digital math cannot model asymptotic behaviour

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 14

lim𝒙→𝟎 (𝟏𝒙 )=?

Limited Precision

• Physical functions which are expressed digitally can never represent the real functions– Limited Precision

1/3 is always greater than 0.3333333333333333333333333333…3

May not be significant in a single calculation, but may cause a significant “drift” in iterative calculation

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 15

Discontinuity/Singularity

• Every digital function is a “step function”– Each point is a point of discontinuity/Singularity!

– A derived phenomenon: Random singular behaviour

See following examples

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 16

Random Singular Behaviour – Excel 2007

• The unsigned binary representation of 65535 in 16-bit is

1111111111111111

• Which is also the 2’s-complement binary representation of (-1)!

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 17

Should be65535

http://www.lomont.org/Math/Papers/2007/Excel2007/Excel2007Bug.pdf

Random Singular Behaviour – Crash by Text String

• A text message that crashed iOS

• The text string that crashed SKYPE

http://:

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 18

Behaviour Singularity Yields to High Vulnerability

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 19

http://www.eetimes.com

http://www.pedalboxusa.com

Is thethrottle-control softwarea true implementation of the

throttle response function?

Reliability: Software vs. Hardware Failures

• A typical hardware failure curve (“the bathtub curve”)

• Ideal software failure curve

Time

FailureRate

Early life

Wear out

Time

FailureRate Fixed rate until retirement

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 20

The Impact of Software Changes on the Failure Curve

Time

FailureRate

The ideal curve

Introduced changes

New features + regression failures = increased failure rate

The actual curve

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 21

ARC 2015 Conference, Nürnberg, Germany, July 2015 22

Software Reliability

• Software does not break…

rather it was always broken!

• Software reliability– The confidence that a certain bug was detected and removed

– Software reliability is directly related to software test coverage

©

Pro

f. D

r. A

mir

Tom

er

http://web.cecs.pdx.edu/~hamlet/testutorial.html

ConfidenceC

Failure probability f

1

1

00

C = 1 – (1 – f)N

More tests N

Less tests N

The “Heisenbug” Phenomenon

• The Observer Effect (a derivative of Heisenberg’s Uncertainty Principle):– The act of observation may make changes to the observed phenomenon

• The Observer Effect in Software Engineering (3 versions)

1. The potential impact of the act of observing a process output while the process is running

2. Observing the performance of a CPU by running both the observed and observing programs on the same CPU

3. Observing a running program by modifying its source code (such as adding extra output or generating log files)

• Heisenbug

– A software bug that seems to disappearor alter its behavior when one attemptsto study it

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 23

What is “Good (Reliable) Software”?

• Defect Density =

The number of software defects (“bugs”) per 10,000 lines of code

• Delivered (Escaped/Fielded/Residual) Defects– Software defects which persist in the product after delivery to the customer

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 24

Source: A.M. Neufelder, Current Defect Density Statistics(2007), © SoftRel LLC

Development Life Cycle

• Typical product development life cycle (Systems Engineering)

• Typical software development lifecycle (Software Engineering)

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 25

Specifi-cation

Design Simu-lation

Prototype manu-

facturing

Produc-tion

Requirements Product

Specifi-cation

Design Simu-lation

Prototype manu-

facturing

Produc-tion

Programming = [code-compile-run-oops…]n

Agile Software Development

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 26

http://agafonovslava.com

Manifesto Source: http://agilemanifesto.orgPicture Source: http://agilesista.com

The SCRUM Methodologyfor Software Development

BYOD: Medical Systems

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 27

http://www.medicaldevice-network.com

BYOD: Car Diagnosis System

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 28

http://gadizmo.com

BYOD: Airplane Entertainment

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 29

http://www.futuretravelexperience.com

BYOD: Military Applications

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 30

http://gizmodo.com

Systems Engineering and Software Engineering United

• Mutual Standards

• Modeling

• Common Life-cycle Model

• Education

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 31

Systems and Software Engineering Common Standards

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 32

Modeling Languages

• Unified Modeling Language (UML) TM

– A “toolbox” of models

– Originally targeted Object Oriented SW design

– May be effectively used for SWIS modeling• See http://

www.slideshare.net/DrAmirTomer/just-enough-system-modeling

• System Modeling Language (SysML) TM

– An extension / mutation of UML

– Lacks software-specific expressiveness

– Not always integrates well with UML

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 33

TM UML and SysML are Trademarks by the Object Management Group (OMG)®: www.omg.org

A Common Perspective on the Life-Cycle Model

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 34

Stakeholder Requirements

SystemRequirements

SystemArchitecture

ComponentRequirements

ComponentDesign

ComponentConstruction

InternalVersionsAgile

SW Dev.

ReleasedVersions

Iterative/Incremental

Development

Product Upgrading Product

Generations

Product Lines New

Products

Market/Client Developers Market/Client

Definition, specification and design Implementation, integration and testing

Education: Systems Engineering for SW Engineers

EDUCON 2012 / TDSE Session

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 35

Education: Software Engineering for Systems Engineers

INCOSE International Symposium 2012

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 36

Thank you for listening!

Any questions?

©

Pro

f. D

r. A

mir

Tom

er

ARC 2015 Conference, Nürnberg, Germany, July 2015 37