Ac2017 8. metrics forprivacysafety-notes

Thomas Fehlmann, Eberhard KranichEuro Project Office, Zürich & Duisburg

NESMA Autumn Meeting, Soestduinen, 7th November 2017

17:25 – 17:50 Metrics for Privacy & Safety in Software Contracts, Thomas Fehlmann (Euro Project Office)

A software contract must include measurable and resilient clauses about how well the new software shall be hardened against attacks. This presentation outlines how to define such attributes and how to count them in a model, be it the COSMIC data movement map – suitable for communication among things – or an IFPUG-‐like transaction map, ideal for web portals.

Page 1

Thursday, 9 November 2917

© Euro Project Office AG, 2017

Dr. Thomas Fehlmann

Speaker & Authors

Thomas Fehlmann, Zurich, Vice-president ISBSG, Member of swissICT, NESMA, UKSMA, GUFPI-ISMA, DASMA

Eberhard Kranich, Duisburg, Member of swissICT, NESMA, DASMA

Dr. Thomas Fehlmann Thursday, 9 November 2917

© Euro Project Office AG, 2017 Page 2

Agenda

Test Metrics

Privacy Metrics

Safety Metrics

Metrics in Contracts

| METRICS FOR PRIVACY & SAFETY IN CONTRACTS

• The Vision

• Testing the IoT

• Truck Platooning

• Real-Time Testing



Agenda

Test Metrics

Privacy Metrics

Safety Metrics


Test Metrics


• The Vision

• Testing the IoT





Bad Mathematics in Software Testing

▪ What is the Size of Software?

▪ Lines of (undocumented?) Code?

▪ What is a Software Defect?

▪ An entry in a bug tracking system??

▪ What is a Defect Density?

▪ Number of bug entries per line of code in a bug tracking repository????

What Defect Density has this

Google Car’s Software?

Compared toNissan’s Software?


Today’s practice in software and system testing is simply a mess. People count entries in bug inventories and mistake this for the number of defects. Even worse, they look at lines of code and define one defect if they have to fix this line – notwithstanding that code can contain many more defects than just one per line, and functionality often can be implemented by hundreds of lines of code, containing dozens of defects, or simply by one concise statement providing the same functionality –without defects or bugs.



Testing refers to Functionality not Code

▪ Code is not the object of testing of software or systems

▪ Test metrics refer to functionality

▪ Test metrics cannot refer to code

▪ Most code is open source

▪ Well code-tested by Daily Builds & JUnit’s Green Bar


123456789101112131415161718

#include "mbed.h"

DigitalIn button1( SW2 ); // Right Button on ARM BoardDigitalOut led( LED1 );

int main(){led = 1; // red (RGB LED use inverse logic

// 1 = OFF, 0 = ON)

while ( true ) {if ( button1 == 0 ) // Button pressedled = 0;elseled = 1;}}

Common testing techniques still refer to code – however, code is most often not available if we test our software, and definitely not for systems.

Functionality is there and can be assessed and modelled. Code is subject to the programming language, programming environment, and sometimes not even open.

Scala today is the language of choice for functional programming; Java, C++ or C# tend to be verbose, even when used within a object-oriented programming paradigm. Lines of codes are not comparable, not even within one programming language. Maybe, it’s useful as a personal measure.

An automatic count from a functional programming language is easy for the COSMIC model; the IFPUG model is considerably harder to build. The effort is comparable to building a compiler.



Software Models

▪ Modeling Software by

▪ ISO/IEC 20926 IFPUG

▪ ISO/IEC 19761 COSMIC

▪ Others….

▪ Sizing Software according

▪ Functionality & Test Intensity

▪ Non-functional Characteristics

▪ Privacy

▪ Safety

▪ Other constraints


Sizing software takes two distinct steps:

• Creating a model for the software, based on elementary functional components (IFPUG) or movements of data groups (COSMIC). This step is called Mapping.

• Counting the number of model elements identified according counting rules.

Best-known counting rules are those assigning Function Points according IFPUG, depending on complexity criteria such as Data Elements Types, Record Element Types and File Type Referenced. Simplest ones are those of COSMIC – one data movement is one Function Point. Newly added are the rules of the Software Non-functional Assessment Process (SNAP). More sizing assessment counting rules for these models create metrics for software privacy or software safety. All you need is agree on a set of unambiguous and repeatable counting rules that are validated in practice.

This workshop introduces the audience to this new view on software metrics. It evolved during the IWSM 2015 conference in Kraków, driven by attempts to automate functional sizing. The Visual Excel tool has been enhanced to model according IFPUG and COSMIC, adding SNAP and future assessment models. For instance, you can take your COSMIC count and SNAP it. Or model software according IFPUG and size its security vulnerability.

The Excel model is public domain under a GNU license and runs under Office 2010 or newer.



The IFPUG Model of Software (ISO/IEC 20926)

▪ Transactions

▪ EI: Elementary Input

▪ EO: Elementary Output

▪ EQ: Elementary Query

▪ Data Elements

▪ ILF: Internal Logical Files

▪ EIF: External Logic Files

Software Boundary

ILF

User

(Person or application)

EIF

EI EO EQ


The IFP count needs two distinct steps:

• Count the data function types: ILF, which are logical data groups maintained within the application boundary, and EIF, used for reference by the application;

• Count the transactional function types El, which are data entry processes and controlled inputs; EO, (e.g., reports with calculations) and EQ, (e.g., retrieval of stored data by inquiries from one or more ILF/EIF).

ISO/IEC 20926 provides several simple matrices to determine whether a function is Low, Average or High, based on Data Element Types, (DET; user recognizable, non–repeated data fields), Record Element Types (RET; subsets of user recognizable data), and File Types Referenced, (FTR; number of logical data groupings, (i.e., ILF and EIF), required to complete a process).



The IFPUG Model of the Employee Database

▪ Transaction Map

▪ 4 EI, 1 EO, 1 EQ

▪ 2, 12 and 13 DET

▪ 9 FTR

▪ 1 ILF, 1 EIF

▪ 3 and 12 DET

▪ For Test Size, we need sizing parts

▪ IFPUG Counting Rules are not compliant to the VIM and the GUM


T001 T003 T005 T006

T002

T004

D002 D001

BoundaryIFP=33

ILF

12 / 1

Employee Data

EIF

3 / 1

Active Directory

EI

13 / 1

Add Employee

EQ

12 / 2

View Employees

EI

13 / 1

Merge Employees

EO

12 / 2

Weekly Report

EI

13 / 1

Update Employee

EI

2 / 2

Terminate Employee

• The VIM: ISO/IEC Guide 99:2007, 2007. International Vocabulary of Metrology – Basic and general concepts and associated terms (VIM).

• The GUM: ISO/IEC CD Guide 98-3, 2015. Evaluation of measurement data - Part 3: Guide to Uncertainty in Measurement (GUM)

Page 9



Dr. Thomas Fehlmann

The COSMIC Model of Software (ISO/IEC 19761)

▪ Functional Processes

▪ Devices & Applications

▪ Entry and eXit

▪ Persistent Data

▪ Read and Write

▪ Data Movement

▪ Moves Data Groups

▪ Trigger triggers a functional process

Software Boundary

Functional

Process

Persistent Data

TriggerEntry

Entry

eXit

eXit

Write Read

Device User Application User


ISO/IEC 19761 COSMIC describes a significantly more complicated model.

The principles behind COSMIC are:

• The Functional User Requirements (FUR) generate Functional Processes. A functional process is “an elementary component of a set of FUR comprising a unique cohesive and independently executable set of data movements. It is triggered by one or more triggering events… it is complete when it has executed all that is required to be done in response to the triggering event” (COSMIC Measurement Practices Committee, 2014). Triggering events occur outside the software boundary.

• Software manipulates pieces of information, designated as data groups, which consist of data attributes. Figure 6-6 depicts the data group flow.

• Functional processes involve sub-processes, concerned with movement – Entries (E), eXits (X), Reads (R), and Writes (W) – and transformations of data groups.

• The functional size of a functional process is directly proportional to its number of data movements.

• The functional size of an application is the sum of the sizes of its functional processes.



The COSMIC Model – Data Movement Map▪ Data Movement Map

▪ One object per functional process

▪ It has six Functional Processes ▪ Add Employee▪ Update Employee▪ Merge Employees▪ View Employee▪ Weekly Report▪ Terminate Employee

▪ 31 Data Movements yields 29 CFP

▪ Some data movements move identical data groups


9 Entry (E) + 11 eXit (X) + 5 Read (R) + 4 Write (W) = 29 CFP

HR User Add New Employee Update Employee Merge Employees View Employee Weekly Report Terminate Employee Employee Database Active Directory

1.// Add Employee

Add

2.// Get Employee ID

3.// Write Employee Data

4.// Show Employee ID

5.// Confirm Transaction

6.// Update Employee

Update

7.// Read Employee Data

8.// Write Employee Data

9.// Confirm Update

10.// Select Employee 1

Merge

11.// Read Data for Employee 1

12.// Select Employee 2

13.// Read Data for Employee 2

14.// Show Data for Merge

15.// Select Data to Merge

16.// Consolidate Merge

17.// Confirm Merge

18.// Request Employee Data

View

19.// Get Employee Data

20.// Read Access Rights

21.// Show Employee Data

22.// Confirm Data Retrieval

23.// End of Week

End of Week

24.// Get Data for Weekly Report

25.// Read Access Rights

26.// Weekly Report

27.// Confirm Report

28.// Terminate Employee

Terminate

29.// Block IT Access

30.// Terminate Employment

31.// Confirm Termination

A Data Movement Map resembles an UML Sequence Diagram – and almost is one. Missing are

• Option combination fragments (combined fragments in UML 2.0)

• Optional return messages (if data is moved, they aren’t optional in COSMIC)

• Sending messages to itself – used in UML sequence diagrams to draw attention to the fact that the object’s life line is a functional process indeed.

In fact, an UML sequence diagram isn’t quite a COSMIC count in itself –functional processes need being identified among the UML objects, and persistent stores and devices as well. However, data movement maps are sufficiently close for allowing a rapid COSMIC count even without all the details needed for validating the count.

A data movement map depicts the objects and classes involved in the UML scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario.



Visualizing Software Testing

▪ Tester sees selected sequences in the Data Movement Map

▪ Tester can “walk” the data movements when planning or executing tests

▪ Makes functionality visible to the development team

▪ Localizes defects that impact functionality

▪ Supports communication between testers, users, and developers

Functional

Process

Other

Application

Some

Device

8.// Move some data

9.// Move some data

10.// Move some data


Other

Device


The basic interface is the Data Movement Map.

Although Data Movement Maps can become large, you should use a tool that allows focusing on a selection of data movements only. Here only four objects of interest are displayed and only four out of 23 data movements.

The tester should be able to step through an App by halting execution when “visiting” an object of interest, e.g., before executing a functional process. This can be achieved by test stubs inserted in the code and connected to the sequence diagram shown on the SharePoint site.



Functionality, Defect Size, and Defect Density

▪ What happens if data movements don’t work as expected, have defects instead?

▪ Testers mark and count data movements where defects have been detected

▪ One Size Metric:

▪ ISO/IEC 19761 COSMIC

Functional

Process

Other

Application

Some

Device

8.// Move some data

Move some data



Other

Device

Test Size = 4

Defect Count = 1


Functional Size Number of Data Movements needed to implement required functionality

Test Story Collection of Test Cases aiming at certain functionality

Test Size Number of Data Movements executed in Tests

Defect Count Number of Data Movements affected by some defect detected in a Test Story

When a defect has been identified, the respective data movement can be visually marked, e.g., by being blocked by a bug.

However, such a defect might exist only under defined test data conditions. If test management confirms the existence of such a defect, it is possible to block that data movement for this particular test data or environment.

Now we can define Test Size and Defect Density based on the ISO/IEC 19761 COSMIC international standard, now available in version 4.0.2



Agenda

Test Metrics

Privacy Metrics

Safety Metrics



• The Vision

• Testing the IoT





Agenda

Test Metrics

Privacy Metrics

Safety Metrics


Privacy Metrics


• The Vision

• Testing the IoT





Current Approach in Assessing Security

▪ The Center for Internet Security (CIS) presents the CIS Controls for Effective Cyber Defense Version 6.0, a recommended set of actions that provide specific and actionable ways to stop today's most pervasive and dangerous cyber attacks

▪ The CIS Security Benchmarks program provides well-defined, un-biased and consensus-based industry best practices to help organizations assess and improve their security

▪ https://www.cisecurity.org


For security, today’s most popular approaches still protect the system as a whole – trying to block access to the system rather than protecting its components.



Critique at Current Approaches to Security

▪ This is not software security but system security

▪ Assessment concerns a system as a whole

▪ Cyber defense must start at the component level

▪ Where is the system as a whole in the Web of Things?

▪ The Web of Things changes equally fast as requirements in agile software development

TheTraditionalApproach


Security today must look at components and data movements – for instance, to recognize patterns in data access.



How to Measure Privacy for Software?

▪ Privacy Value▪ Value = 0: No privacy. It’s public.

▪ Value = 1: Disclosure is inconvenient

▪ Value = 2: Disclosure can be harmful

▪ Value = 3: Disclosure costs money

▪ Value = 4: Disclosure makes guilty

▪ Value = 5: Disclosure threatens lives

▪ Public Exposure▪ Value = 0: No encryption. It’s public.

▪ Value = 1: Weak encryption

▪ Value = 2: Strong encryption

▪ Value = 3: Two-way encryption

▪ Value = 4: Data never leaves system

▪ Value = 5: Computer-internal data

▪ The principle for Each Model Element is

Privacy Protection = Privacy Value * Public Exposure


Measuring Privacy is basically the product of privacy value for the user times the degree of public exposure.



𝑃𝑟𝑖𝑣𝑎𝑐𝑦 𝐼𝑛𝑑𝑒𝑥 =

𝑃𝑟𝑖𝑣𝑎𝑐𝑦 ∗ 𝐸𝑥𝑝𝑜𝑠𝑢𝑟𝑒 + 1 − 1

26 − 1∗ 5

The Privacy Index

▪ The product

Privacy Value * Public Exposure

is in the range 0 to 25

▪ Privacy Index is range 0⋯5▪ Five 5 is the index for

maximum privacy

▪ Zero 0 privacy means public data

▪ The Privacy Index range is on a polynomial scale between zero and five

Zero = No Privacy

All is open

Five = Full

Privacy Protection

0....5


Full privacy means that the system does not communicate with the exterior. Zero privacy is fully open. Ranges above a privacy index of 1 typically deal with confidential data.

Puuh! A complicated formula, not very useful in contracts… go next slide, fast!



The Privacy Index

▪ For contract purposes, use a graphical representation


4

3

2

1

0

5

Privacy Protection

Impa

ct o

n P

rivac

y

Data Movement

Low Privacy Index

Medium Privacy Index

High Privacy Index

Major Privacy Index

No Privacy Needed

1235 4 0

0.9

Index 0.9: W004 Terminate EmploymentIndex 1.2: X009 Confirm ReportIndex 1.5: R001 Get Employee ID, +8

Index 1.8: X011 Confirm Termination, +1Index 2.0: X007 Confirm Data Retrieval

1.5

1.21.5

4.4

2.0

Index 2.4: E001 Add Employee , +11Index 3.2: X005 Confirm MergeIndex 4.4: R002 Read Employee Data, +12.43.2

Use a graphical notation to explain the privacy index to managers. Low privacy indices, in red, are positioned in the upper right (where the high risks are in FMEA), then the data movements move down the scale yellow –blue – green.

You can use this privacy index representation to get agreement on privacy level with your customer, and use it in the contract.

The overall software has a “High Privacy Index” of 2.4. This is mean of all privacy indices for data movements. Major privacy would possibly be reserved for financial privacy protection. Here, termination of an employee is something that cannot kept totally private, as not only family members, but also tax authorities and probably banks must know.

If both impact on privacy and privacy protection are zero, then there is no privacy needed and thus no graphical representation.



Agenda

Test Metrics

Privacy Metrics

Safety Metrics



• The Vision

• Testing the IoT





Agenda

Test Metrics

Privacy Metrics

Safety Metrics


Safety Metrics


• The Vision

• Testing the IoT





Safety for Software

▪ Software impacts physical world

▪ Level 1: Low – break

▪ Level 3: Medium

▪ Level 5: High – crash

▪ Probability Levels

▪ Less likely on motorways

▪ Highly probably in villages and urban areas


Safety is another upcoming concern for software measurement. As more and more things communicate and act together, safety hazards no longer depend from hardware failure.

Software failure is already more important.



Measure Safety Risk

▪ Impact through actuators

▪ Steering Wheel in Autonomous Cars

▪ Closed Door at Smart Homes

▪ Indicated by an index 1⋯5

▪ Other classical software risks remain:

▪ Causing losses for business

The principle for Each Model Element is

Safety = Probability * Impact

0....5


Zero = All Safe!

Highly unlikely

Five = Danger!

Safe Our Souls!

The principles for measuring safety is known from risk management –although impact is no longer financial impact only. It still is, but other kind of impact might also play a role.



What means Safety for Software?

▪ Impact Levels

▪ Level 1: Low

▪ Level 3: Medium

▪ Level 5: High

▪ Probability Levels

▪ By percentages1

2

3

4

5

Probability

Impa

ct o

n S

afet

y

Data Movement

Major Safety Risk

High Safety Risk

Medium Safety Risk

Low Safety Risk

Risk Incurred/ Feature

100%80%60%20% 40%0%

3.2

Index 3.2: E010 Terminate Employee

2.0

Index.2.0: X010 Block IT Access

Index 1.2: W004 Terminate Employment

0.6

Index 0.8: X011 Confirm Termination

Index 0.6: X008 Weekly Report, +24


0.8

1.2

Representing Privacy Impacts looks similar to classical risk assessment and mitigation methods, but addresses now different things and – most important – it is not constrained to a closed software system.

You can also blow up bubbles if two or more data movements produce identical safety risks.

Total safety index for this employee database is again the mean risk exposure of 0.2; maximum risk is 3.2, in case an employee reacts upon termination with panic.

The risk representation is taken from classical risk management, for instance used in automotive when assessing an FMEA.

If probability is 100%, the risk incurred is no longer a risk but a feature.



Agenda

Test Metrics

Privacy Metrics

Safety Metrics



• The Vision

• Testing the IoT





Agenda

Test Metrics

Privacy Metrics

Safety Metrics




• The Vision

• Testing the IoT





Privacy of Data Movements

▪ How private is a Data Movement?

▪ Can it be intercepted?

▪ Not really if machine-internal

▪ Quite easy if HTTPS

▪ Less easy with two-way authentication

▪ Most difficult with private key encryption

▪ ISO/IEC 19761 COSMIC provides a model for measuring privacy that is well suited for distributed systems such as an IoT Concert, Embedded Systems, or Mobile Apps

Software Boundary

Functional

Process

Persistent Data

TriggerEntry

Entry

eXit

eXit

Write Read

Device User Application User


It makes sense and is relatively easy to measure security components-wise in a software model. Both models are utterly useful but measure different aspects of safety and privacy.



Name Label Data Movement Sub-Process Description

1) E001 Add Employee Enter new employee data

2) R001 Get Employee ID Unique ID for employee identification

3) W001 Write Employee Data Store in database

4) X001 Show Employee ID Confirm new employee added

5) X002 Confirm Transaction Confirmation or error message

Data Movements

23) E008 End of Week Timing Signal

24) R006 Get Data for Weekly Report Select employee data that changed during past week

25) E009 Read Access Rights Get external IT access rights

26) X008 Weekly Report All data including termination records

27) X009 Confirm Report Weekly report done

28) E010 Terminate Employee Enter termination control flag

29) X010 Block IT Access Block access to IT

30) W004 Terminate Employment Update an employee record

31) X011 Confirm Termination Confirmation or error message

Add Row Ins Row Del Row Validate Extract SNAP

1.22

Effe

ct w

hen

Priv

ate

Dat

a is

Dis

clos

ed

Priv

acy

Pro

tect

ion

Leve

l

Pri

vacy

Pro

babi

lity

Impa

ct o

n

Saf

ety

Saf

ety

4: Makes guilty 2: Strong 2.4 10% 2: Little 0.2

4: Makes guilty 1: Weak 1.5 5% 2: Little 0.1






4: Makes guilty 1: Weak 1.5 5% 4: Quite 0.2

2: Harmful 3: Two-way 2.0 20% 3: Medium 0.6

1: Inconvenient 3: Two-way 1.2 10% 3: Medium 0.3

1: Inconvenient 4: Enclosed 1.5 80% 4: Quite 3.2

1: Inconvenient 5: Internal 1.8 50% 4: Quite 2.0

1: Inconvenient 2: Strong 0.9 30% 4: Quite 1.2

1: Inconvenient 5: Internal 1.8 40% 2: Little 0.8

2.4 0.2

0.9 3.2

Safety Index:

Minimum Privacy: Maximum Risk:

Privacy Index:

Assessing Privacy & Safety


AssessingImplementation

Assessingthe Model

This is the detail view on a COSMIC model, showing the degree of privacy protection for each data movement.

Note that the left side of the privacy and of the security assessment refer to the model; the right side refers to implementation.

Page 29



Dr. Thomas Fehlmann

Privacy of Data Functions & Transactions

▪ How private is Data / are Transactions?

▪ Can it be accessed?

▪ Not really if machine-internal

▪ Quite easy with password

▪ Less easy with two-way authentication

▪ Most difficult with private key encryption

▪ ISO/IEC 20926 IFPUG provides a model for measuring privacy that is well suited for web pages and transactional systems


Software Boundary

ILF

User

EIF

EI EO EQ

It makes sense and is relatively easy to measure security components-wise in a software model. Both models are utterly useful but measure different aspects of safety and privacy.



Assessing Privacy & Safety


Name Label Description of Elementary Data Function ILF EIF Type

1) D001 Employee Data A persistent logical entity maintained by the application 1) ILF

2) D002 Active Directory The active directory provides the unique username and the account list where he or she has access 1) EIF

1

EIF: 1

Elementary Data Functions

ILF:Add Row Ins Row Del Row Validate Extract SNAP

1.22

Effe

ct w

hen

Priv

ate

Dat

a is

Dis

clos

ed

Exp

osur

e to

Priv

acy

Vio

latio

n

Pri

vacy

Pro

babi

lity

Impa

ct o

n

Saf

ety

Saf

ety

4: Makes guilty 2: Strong 2.4

3: Costs money 3: Two-way 2.6 5% 1: Low 0.1

SNAP 2.4 0.2

0.9 3.2

Privacy Index: Safety Index:

Minimum Privacy: Maximum Risk:

Name Label Description of Elementary Transaction Type1) T001 Add Employee Primary intent is to maintain data in the ILF EI

2) T002 View Employees Primary intent is to present data to the user, data is retrieved both from an ILF and an EIF, and there are none of the following involved: calculations, derived data, ILF update or alteration of system behavior EQ

3) T003 Merge Employees Primary intent is to maintain data in the ILF EI

4) T004 Weekly Report Show total employment status with liabilities by the salaries EO

5) T005 Update Employee Primary intent is to maintain data in the ILF EI

6) T006 Terminate Employee Stops access to the IT and terminates employment EI

EI: 4

EO: 1

EQ: 1

Elementary Transactions

Add Row Ins Row Del Row More FTR Validate Extract SNAP

1.22

Effe

ct w

hen

Priv

ate

Dat

a is

Dis

clos

ed

Exp

osur

e to

Priv

acy

Vio

latio

n

Pri

vacy

Pro

babi

lity

Impa

ct o

n

Saf

ety

Saf

ety


4: Makes guilty 4: Enclosed 3.8 10% 3: Medium 0.3

4: Makes guilty 2: Strong 2.4 20% 1: Low 0.2

4: Makes guilty 3: Two-way 3.2 10% 4: Quite 0.4


1: Inconvenient 2: Strong 0.9 80% 4: Quite 3.2

2.4 0.2

0.9 3.2

21

Maximum Risk:

Privacy Index:

Minimum Privacy:

Safety Index:

This is the detail view on an IFPUG model, showing the degree of privacy protection for each data function, and each transaction identified in the model.

Note again that the left side of the privacy and of the security assessment refer to the model; the right side refers to implementation.

Page 31



Dr. Thomas Fehlmann

Metrics for Software Contracts

▪ Functional Size

▪ COSMIC

▪ IFPUG, NESMA

▪ …

▪ Test Size

▪ Test Intensity

▪ Acceptable Defect Density

▪ Privacy Index & Minimum Privacy

▪ For Data Movements

▪ For Data Functions & Transactions

▪ Security Index & Maximum Risk




The recommended way is always to agree on both data movement protection and elementary data functions and transaction protection. However, you can select what is more relevant.

Since the COSMIC model is easy to build automatically from code, test size should also be specified and thresholds agreed.

Older software contracts might not belong to the 21st century.

Page 32



Dr. Thomas Fehlmann

Metrics for System Contracts

▪ Hardware Vulnerability

▪ Software might destroy itself when Hardware is compromised

▪ Functional Size

▪ COSMIC

▪ IFPUG, NESMA

▪ Test Size

▪ Test Intensity

▪ Acceptable Defect Density

▪ Privacy Index & Minimum Privacy



▪ Security Index & Maximum Risk




System contracts must specify additionally how to protect physically parts of the system, especially those containing or presenting confidential data.

Page 33



Dr. Thomas Fehlmann

Conclusions

▪ Contracts for safety-critical software must specify how well we protect privacy and how safe the software behaves

▪ Based on a functional size model

▪ Contracts without specifying test metrics are dangerous and bound to later arbitration

▪ Currently, test metrics work with ISO/IEC 19761 COSMIC only

▪ Make ISO/IEC 20926 & 24570 compliant with the VIM and the GUM

▪ Consumers need such test metrics, privacy and safety metrics when purchasing software or autonomous systems


Software Metrics for Privacy and Safety are the future of Software Metrics organizations – it’s high time to agree on an international standard and promote it through consumer protection channels.

IFPUG and NESMA must make their counting rules compliant to the VIM and the GUM.



Logos Press

Berlin 2016

Questions?


The speaker has published quite a bit on the subject together with Eberhard Kranich in Duisburg – e.g., in QFD symposia, at SW metrics conferences like IWSM / Mensura; also at Lean Six Sigma Conference in Glasgow, Strathclyde and Zurich.

Managing Complexity appeared 2016 in Logos Press, Berlin: http://www.logos-Verlag.de/cgi-bin/buch?isbn=4406




New Book on Six Sigma Transfer Functions

The rise of Information and Communication Technology (ICT) in the second half of the 20th century became the dominant force in economics. Its rise accelerates in the first 15 years of this century at an astonishing speed. The world of ICT right now is in the process of cosmic inflation.

In the early universe, quantum fluctuations in a microscopic inflationary agile region became the seed for growing structures in the universe of galactic nebula, galaxies and stars, making the universe transparent. This phenomenon, familiar to physicist and cosmologists, happens right now to ICT. The current observation is that “things” of the physical world become intelligent, receive IP addresses and connect to the Internet. The possibilities to create new ICT-based products seem unlimited; however, sponsors must fuel the inflation.

Complexity was already an issue when developing software in the early days of ICT. Software development is often done in projects that turn out to be exploratory in the sense that they aim at translating human voices, uttering requirements, into a machine-readable language. Requirements for the software to be build are usually not known at the beginning; the project must uncover them. Developing software without knowing the outcome in advance is a complex undertaking. Predicting the outcome of software projects by proven methods of civil engineering did not work out well.

Now, new levels of complexity arise with ICT. Agile approaches are appropriate for software development; however, predicting the outcome of projects still is difficult. New techniques must manage the growing levels of complexity within ICT. Fortunately, mathematics has provided these new techniques. They rely on transfer functions and Eigenwert theory. Its usefulness already has been proven in major search engines of this century. However, this is not the end of the story.

This book makes the mathematics of Lean Six Sigma transfer functions available to ICT practitioners. It provides the basic theory, explained with many examples, and even more suggestions, how Six Sigma Transfer Functions help with complex problems.

