Ac2017 8. metrics forprivacysafety-notes

Thomas Fehlmann, Eberhard Kranich
Euro 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 to
Nissan’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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include "mbed.h"
DigitalIn button1( SW2 ); // Right Button on ARM Board
DigitalOut led( LED1 );
int main()
{
led = 1; // red (RGB LED use inverse logic
// 1 = OFF, 0 = ON)
while ( true )
{
if ( button1 == 0 ) // Button pressed
led = 0;
else
led = 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
Trigger
Entry
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
The
Traditional
Approach
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
ImpactonPrivacy
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: W004Terminate Employment
Index 1.2: X009 Confirm Report
Index 1.5: R001 Get Employee ID, +8
Index 1.8: X011 Confirm Termination, +1
Index 2.0: X007 Confirm Data Retrieval
1.5
1.21.5
4.4
2.0
Index 2.4: E001 Add Employee , +11
Index 3.2: X005 Confirm Merge
Index 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 percentages
1
2
3
4
5
Probability
ImpactonSafety
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: W004Terminate 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

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
Trigger
Entry
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
Effectwhen
PrivateDatais
Disclosed
Privacy
Protection
Level
Privacy
Probability
Impacton
Safety
Safety
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
Assessing
Implementation
Assessing
the 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 access1) EIF
1
EIF: 1
Elementary Data Functions
ILF:Add Row Ins Row Del Row Validate Extract SNAP
1.22
Effectwhen
PrivateDatais
Disclosed
Exposureto
Privacy
Violation
Privacy
Probability
Impacton
Safety
Safety
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 Type
1) 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 systemEQ
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
Effectwhen
PrivateDatais
Disclosed
Exposureto
Privacy
Violation
Privacy
Probability
Impacton
Safety
Safety
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
Transactions
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
Transactions
▪ Security Index & Maximum Risk
Transactions
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.

Ac2017 8. metrics forprivacysafety-notes

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Ac2017 8. metrics forprivacysafety-notes

Similar to Ac2017 8. metrics forprivacysafety-notes (20)

More from Nesma

More from Nesma (20)

Recently uploaded

Recently uploaded (20)

Ac2017 8. metrics forprivacysafety-notes