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

[email protected]

©

Pro

f. D

r. A

mir

Tom

er

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

mailto:[email protected]

Kinneret College on the Sea of Galilee

©

Pro

f. D

r. A

mir

Tom

er


Kinneret College –Lake View from inside the Library

©

Pro

f. D

r. A

mir

Tom

er


OTH-Regensburg & HS-KemptenPartnership with Kinneret College

©

Pro

f. D

r. A

mir

Tom

er


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


The Current Situation

©

Pro

f. D

r. A

mir

Tom

er


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

http://blissfulwriter.hubpages.com/hub/Software-Code-in-Your-Car

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


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


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


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

Software as the Nervous Subsystem of a System

©

Pro

f. D

r. A

mir

Tom

er


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

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


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


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


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


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


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


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


Behaviour Singularity Yields to High Vulnerability

©

Pro

f. D

r. A

mir

Tom

er


http://www.eetimes.com

http://www.pedalboxusa.com

Is thethrottle-control softwarea true implementation of the

throttle response function?

http://www.eetimes.com/

http://www.pedalboxusa.com/

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


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



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


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


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


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


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


http://www.medicaldevice-network.com

http://www.medicaldevice-network.com/

BYOD: Airplane Entertainment

©

Pro

f. D

r. A

mir

Tom

er


http://www.futuretravelexperience.com

http://www.futuretravelexperience.com/

BYOD: Military Applications

©

Pro

f. D

r. A

mir

Tom

er


http://gizmodo.com

http://gizmodo.com/

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


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


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

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

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

A Common Perspective on the Life-Cycle Model

©

Pro

f. D

r. A

mir

Tom

er


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: Software Engineering for Systems Engineers

INCOSE International Symposium 2012

©

Pro

f. D

r. A

mir

Tom

er


Swise arc2015

Documents

Transcript of Swise arc2015