PART1-WS13-14 V10 20130819 - TU Dresdenst.inf.tu-dresden.de/.../ws13/fps13/PART1-WS13-14_V1… ·...

Future-Proof Software-Systems(Zukunftsfähige Software-Systeme)

Frank J. FurrerFrank J. FurrerDr. sc. techn. ETH-Zürich

TU Dresden WS 2013/2014

Part 1Part 1

I prefer dialog - rather than monolog: Please feel free toask questions at any time

Future-Proof Software-Systems: Preferred Interaction Style

My Preferred Interaction Style

Copyright Frank J. Furrer 2013 2

ask questions at any time

I am available for additional questions or discussionsafter each lecture

Lecture Summary

Content:

1. What future-proof software-systems are

2. Why future-proof software-systems are key successfactors for today‘s and tomorrow‘s products and

services

Future-Proof Software-Systems: Lecture Summary


services

3. Which body of knowledge exists for future-proofsoftware-systems

4. How the context for future-proof software-systemsdevelopment should look

Lecture Summary

Future-Proof Software-Systems: Lecture Objectives

Objectives:

1. Understand „future-proof software systems“, theirstructure, properties and their quality attributes

2. Learn the principles, concepts and methods to design,


2. Learn the principles, concepts and methods to design,implement and evolve future-proof software systems

3. Know the skills which are needed by a „future-proofsoftware-systems engineer“

4. Accept the (economical, ecological, societal) businesscase for future-proof software systems

Future-Proof Software-Systems:


Motivation

Future-Proof Software-Systems: Motivation

Software powers most of our products and services weuse everyday.

Mobile phones, personal computers, traffic control,energy distribution, production lines, medical

equipment, aeroplanes, trains (and many, many more)have most of their functionality implemented in software.


have most of their functionality implemented in software.

Our society has become completely dependent onsoftware!

– therefore we need future-proof software-systems


htt

p:/

/web

.kyo

to-i

net

.or.

jp/p

eop

le/s

-oga

/old

com

/in

de

x.h

tml UNIVAC 120 (1953)

Decimal storage: 120 digits„Program“: Wired Panel

CRAY Titan (2013)

http

://ww

w.ew

eek.com

/servers/slidesh

ow

s

Data storage: 710 Terabytes RAM30 Petabytes Disk+ 60 years


htt

p:/

/web

.kyo

toh

ttp

://w

ww

.mo

torb

ase.

com

/pic

ture

/by-

id/4

37

94

16

11

Land Rover 1953: SLOCs = 0(SLOC = Source Lines of Code)

Computing Power: 17,59 Petaflops

Mercedes S-Class 2013: SLOCs 100 Million

http

://myau

to2

4.b

logsp

ot.ch

/20

13

/


Example: VW Phaeton(Automotive Software)

Electrical/Electronic Architecture

http://www.cars2review.com/2013-volkswagen-pheaton/

http://delphi.com/manufacturers/auto/ee/


http://delphi.com/manufacturers/auto/ee/

A modern luxury car contains 70 … 100electronic control units (= ECU‘s) in theform of networked microprocessors

The modern luxury car is controlled byapprox. 100 Million source lines of code(SLOC‘s)

2014: 90% of the innovationin cars is due to software


Software is one of the most important key success factorsfor today‘s and tomorrow‘s products and services

Software determines (to a large extent):

Functionality

http

://ww

w.ch

ange-m

anagem

ent.co

m


Functionality

Quality Properties, such as safety, security,availability, integrity, performance etc.

Competitiveness

Revenue generation

Innovation capacity

Intellectual Property Rights ( IPR protection)


“It is not the strongest of the species that survives,nor the most intelligent that survives.It is the one that is the most adaptable to change.”

Charles Darwin: The Origin of Species (1859)

Which software do we need and how do we produce it?


What must we do to make our software-systems „most adaptable to change“ andthus future-proof ?

Future-Proof Software-Systems: Lessons learned for FPSS

Lessons learned for future-proof software-systems:

„Good“ software is the key success factor for many productsand services

We – as software engineers – have a high responsibility toproduce „good“ software


Software production has mutated from an art to an industrialactivity

Today we have the knowledge, the concepts, the methods andthe tools to produce „good“ software

This „Future-Proof Software-Systems (FPSS)“ lecture willprovide you with the knowledge, the concepts and the methods

Future-Proof Software-Systems: References

References:

ReferencesBrynjolfsson11 Erik Brynjolfsson, Andrew McAfee:

Race Against the Machine – How the Digital Revolution is Accelarting Innovation, Driving Productivity, andIrreversibly Transforming Employment and the Economy

Digital Frontier Press, Lexington, MA, USA, 2011. ISBN 978-0-9844725-11-3

Kurzweil99 Ray Kurzweil:

The Age of Spiritual Machines – When Computers Exceed Human Intelligence

Penguin Group Publishing, N.Y., USA, 1999. ISBN 978-0-14-028202-3

vanSanten10 Rutger van Santen, Djan Khoe, Bram Vermeer:

2030 – Technology that will Change the World

Oxford University Press, N.Y. USA, 2010. ISBN 978-0-19-537717-0


Harris11 Robert Harris:

The Fear Index

Hutchinson Publishing, UK, 2011. ISBN 978-0-09-193697-6

Suarez09 Daniel Suarez:

Daemon

Penguin Books (Signet), London, UK, 2009. ISBN 978-0-451-22873-4

Levy06 David Levy:

Robots Unlimited – Life in a Virtual Age

A.K. Peters, Ltd., Wellesley MA, USA, 2006. ISBN 978-1-56881-239-6

Ribbens12 William B. Ribbens:

Understanding Automotive Electronics – An Engineering Perspective

Butterworth & Heinemann Publishers (Elsevier), Waltham MA, USA, 7th printing 2012. ISBN 978-0-0809-7097-4Collinson11 R.P.G. Collinson:

Introduction to Avionics Systems

Springer Science+Business, Dordrecht, NL, 3rd edition 2012. ISBN 978-94-007-0707-8



Contents

Future-Proof Software-Systems: Contents

Contents

Part 1:Introduction & Motivation

Context & Definitions System Properties & Quality Standards The WAY to Future-Proof Software-Systems Industrial Architecture Architecture Metrics


Part 2:Architecture Principles

Part 3:The Role, Personality and Context of the „Future-Proof Software-System Architect“



Context & Definitions

Future-Proof Software-Systems: Context & Definitions

What is a future-proof software-system?

„The three devils of systems engineering are:

Complexity,

Change,

Uncertainty”Anonymous


Definition:

A future-proof software-system is a structure

that enables the management

of complexity, change and uncertainty

with the least effort, with acceptable risk and with specified quality properties


Definition:





Parts of the systemand their relationsships

Activity: Steering thedevelopment & evolution



Providing the best valuefor the resources ‘money‘

and ‘time-to-market‘

Having an adequate probability forundesired effects and consequences

Assuring the desired properties(„Fit for Purpose“)


Thus:

Definition:






1. We need principles, concepts, methods and metricsto design, implement and evolve future-proofsoftware-systems

2. We need „future-proof software-systems engineers“who have the necessary skills to architect, design,engineer, build, maintain and evolve such systems


Programs Functionality

Historical Context:

1960

1950

Object Technology Systems Partitioning, Encapsulation

Re-Use


2010

2000

1990 Component Systems Re-Use

Service-Oriented Systems Sustainability

Systems-of-Systems Interoperability


Technical Context:

ApplicationSoftware

ApplicationSoftware


1960

TechnicalInfrastructure

ApplicationSoftware

1980


ApplicationSoftware

InfrastructureServices

2000



CommoditiesSourcing

2020



CommoditiesSourcing


very high

Size/Complexity

Criticalityvery strong

Range Context:


low

weak

Rate of Change

slow

very fast


very high

Size/Complexity


Example:Mobile Phone Software


low

weak

Rate of Change

slow

very fast


very high

Size/Complexity


Example:Aeroplane ControlSoftware


low

weak

Rate of Change

slow

very fast


very high

Size/Complexity


Example:Global BankingSoftware


low

weak

Rate of Change

slow

very fast

Replacement& Extension


Environment Context:

Greenfield

Specs

Extension& Integration

Specs


Specs

• Clean architecture

• New technology

Specs

• Improved architecture

• New technology• Coherence

• Integration• Extension• Refactoring


BusinessCase

justifies

Future-ProofSoftware-System

QualityProperties

definedby

Structure

enables

Architectureforms

guide

control

DevelopmentProcess

builds

ArchitecturePrinciples

enforce


Future-ProofSoftware-Systems

Engineer

leads

appliesMetrics

quantify

uses

Conceptual Context:(Lecture Map)

WorkingEnvironment

is embedded in


Summary:

The 3 devils of systems engineering are: (a) complexity, (b)change, and (c) uncertainty

A future-proof software-system is a structure thatenables the management of complexity, change anduncertainty with the least effort, with acceptable risk andwith specified quality properties


with specified quality properties

We need principles, concepts, methods and metrics todesign, implement and evolve future-proof software-systems

We need „future-proof software-systems engineers“ whohave the necessary skills to engineer, build, maintain andevolve such systems

Future-Proof Software-Systems: Research Topics

Research Questions Master Thesis Level:• Research and describe how future-proof software-systems have emerged from1960 to today – Which were the drivers, consequences and successes?

• Apply the definition of a future-proof software system, including the necessarymetrics to a few typical application domains (such as automotive or telcom)

• Research the impact of complexity, change and uncertainty, including suitablemetrics to a few typical application domains (such as aerospace or railway)

Research Questions Ph.D. Thesis Level:


• Develop a methodology to formulate business cases for future-proof software-systems, especially demonstrating the business value of agility and other qualityproperties

• Assess the impact (qualitative and quantitative) of architecture principles on thestructure of the future-proof software-system

Research Questions (Full Research Projects):• How many and which architecture principles are needed (complete set) to fullydefine and enforce the architecture of a future-proof software-system? Are theprinciples different for different application domains?


References:

ReferencesMurer11 Stephan Murer, Bruno Bonati, Frank J. Furrer:

Managed Evolution – A Strategy for Very Large Information Systems

Springer-Verlag, Berlin Heidelberg, 2011, ISBN 978-3-642-01632-5Greefhorst11 David Greefhorst, Erik Proper:

Architecture Principles – The Cornerstones of Enterprise Architecture

Springer Verlag, Heidelberg, Berlin, 2011. ISBN 978-3-642-20278-0

DeWeck11 Olivier L. de Weck, Daniel Roos, Christopher L. Magee:

Engineering Systems – Meeting Human Needs in a Complex Technological World

MIT Press, Cambridge, USA, 2011. ISBN 978-0-262-01670-4



deNeufville11 Richard de Neufville, Stefan Scholtes:

Flexibility in Engineering Design


ISTAG12 ISTAG – Information Society Technologies Advisory Group (Working Group on Software Technologies), July 2012:

Software Technologies – The missing Key Enabling Technology (Toward a Strategic Agenda for SoftwareTechnologies in Europe)

Downloadable from: http://cordis.europa.eu/fp7/ict/docs/istag-soft-tech-wgreport2012.pdf [last accessed:14.3.2013]

Monson09 Richard Monson-Haefel (Editor):

97 Things Every Software Architect Should Know – Collective Wisdom from the Experts

O’Reilly Media, Sebastopol CA, USA, 2009. ISBN978-0-596-52269-8

Denning97 Peter J. Denning, Robert M. Metcalfe (Editors):

Beyond Calculation – The Next Fifty Years of Computing

Springer Verlag, Nex York, USA, 1997. ISBN 978-0-387-94932-1



System Properties & QualityStandards

Future-Proof Software-Systems: Properties & Quality Standards

Parts of the System

Dependencies in the System


System: A collection ofparts organized toaccomplish a specificfunction or set of functions[IEEE Std 610.12-1990]

System Boundary(System Scope)


System: A collection ofparts organized toaccomplish a specificfunction or set of functions[IEEE Std 610.12-1990]

Functionality:• Reason for the system• Business value in products or processes

… however: Functionality alone is not enough!


System quality properties required

Quality properties qualify a system for a certain use

Quality properties must carefully be defined for each specific system

Quality properties must consequently be enforced

Quality properties must be measurable


System Quality Property

Business Value

Agility

Availability

Security

Safety

Performance

Usability

Robustness

Definition:

Statement of the exact meaning in thecontext of the application domain

Metric:

Definition of measurable attributes, of ameasurement process, and a quantified

value for the attribute(s)


Operating Cost

Production Cost

Compliance to laws and regulations

Compliance to industry-standards

Memory Size

Power consumption

Testability

etc.Target Values:

Desired value or range for theattribute(s)


Example: Availability(System Quality Property)

Definition:

Availability = The degree to which a system or component is operational andaccessible when required for use [IEEE Std 610.12-1990]

Simply put, availability is the proportion of time a system is in a functioning condition

S


Metric:E[Uptime]

Availability A =E[Uptime]+E[Downtime]

Example:

Uptime = 23.8 hrs/day

Downtime = 0.2 hrs/day

A = 0.9917


Quality Properties Tradeoffs: Financial On-Line Transaction System

Usability

very user-friendly

Quality Properties Tradeoff


Securityhigh

annoying

low


# System Quality Property Weight

(0 … 10)

Metric ValueYear1

ValueYear2

ValueYear3

…

1 Business Value 10 NPV VY1 VY2 VY3

2 Agility 10 1/ V V V

Quality Properties Scorecard:Base for Architectural Tradeoffs

Example: Automotive Domain


2 Agility 10 1/ VY1 VY2 VY3

3 Safety 9

4 Compliance to laws &regulations

9

5 Compliance to industry-standards

8

6 Resources (Memory, CPU,…)

8

7 Security 7

8

9

etc.

time

System at time tn

tn

System at time tn+y

tn+y

Systemdevelopment cycle


Incremental System Development Cycle


Properties at tn

• Functionality• Agility• Safety

• Security• Resource utilization

• etc.

System propertiestransformations

(following requirements)

Properties at tn+y

• Functionality• Agility• Safety

• Security• Resource utilization

etc.

ChangeRequirements

QualityStandards


Quality Standards:

a) Process-Standards: „how“b) Product-Standards: „what“

Internal Company Standards:

• Company-internal regulations and procedures• Company-specific architecture principles

Company-specific procedures and review processes


• Company-specific procedures and review processes

Industry Standards:

• Standards by international standards organizations, such as ISO• Standards by industry-associations, such as AUTOSAR



Any system development cycle transforms the properties ofthe system at time tn into a new system with required propertiesat time tn+y: The development process must measurably improvethe system quality properties

Both the systems and the development cycle are continuously


impacted by effects of complexity, by unexpected change, andplagued by uncertainty: We must professionally cope with thissituation

We must have an accepted quality properties scorecard forany system we build or extend (used for architecture trade-offs)

Functionality and architecture are (nearly) orthogonal: Do notlet functionality force architectural decisions


Research Questions Master Thesis Level:• Elaborate a general list of system quality properties. Investigate which qualityproperties are important for different applications domains (automotive, medical,etc.). Justify the choices with the use of adequate metrics

• Define a method and a process for resolving quality properties conflicts, i.e. formaking justified and comprehensive architecture tradeoff decisions

• Take an industrial example and demonstrate, how the architecture of the systemis impacted by a specific quality attribute (e.g. security in a banking system, safetyin an automotive system, or reliability in a space system)


Research Questions Ph.D. Thesis Level:• Today‘s design and development processes are functionality-centered. Qualityattributes are in many cases an afterthought. Identify and assess the existingdesign and development processes and propose a new one which focusses in equalparts on functionality and on quality properties. Cover the full process-chain, i.e.from requirements management to modeling, design, development, testing andmaintenance


References:

ReferencesClements02 Paul Clements, Rick Kazman, Mark Klein:

Evaluating Software Architectures – Methods and Case Studies

Addison-Wesley, Boston, USA, 2002. ISBN 978-0-201-70482-XFairbanks10 George Fairbanks:

Just Enough Software Architecture – A Risk-Driven Approach

Marshall & Brainerd, Boulder CO, USA, 2010. ISBN 978-0-9846181-0-1

Bass13 Len Bass, Paul Clements, Rick Kazman:

Software Architecture in Practice

SEI-Series (Pearson Education), Addison-Wesley, N.J., USA, 3rd edition, 2013. ISBN 978-0-321-81573-6



Barbacci95 Mario Barbacci, Mark H. Klein, Thomas A. Longstaff, Charles B. Weinstock:

Quality Attributes

Software Engineering Institute (SEI), Carnegie Mellon University, Technical Report CMU/SEI-95-TR-021,December 1995. Downloadable from: http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm (lastaccessed 24.6.2013)

Rozanski12 Nick Rozanski, Eoin Woods:

Software Systems Architecture

(Pearson Education), Addison-Wesley, N.J., USA, 2nd edition, 2012. ISBN 978-0-321-71833-4

deNeufville11 Richard de Neufville, Stefan Scholtes:

Flexibility in Engineering Design


Kossiakoff11 Alexander Kossiakoff, William N. Sweet, Samuel J. Seymour, Steven M. Biemer:

Systems Engineering – Principles and Practice

John Wiley & Sons, Inc., Hoboken, N.J., USA, 2nd edition 2001. ISBN 978-0-470-40548-2



The Way to Future-ProofSoftware-Systems

Future-Proof Software-Systems: The Way

“It is not the strongest of the species that survives,nor the most intelligent that survives.It is the one that is the most adaptable to change.”


Charles Darwin: The Origin of Species (1859)

How can we produce and evolve adaptable– and thus future-proof – software-systems ?


A future-proof software-system is a structure that enables themanagement of complexity, change and uncertainty

with the least effort, with acceptable risk and with specified qualityproperties


http://www.0lll.com/architecture-exhibitions/?gal=24 http://www.asisbiz.com/index.html

Which structure is easier to expand and evolve?Which structure has the better properties, e.g. quality of life?

Which structure is future-proof?


Why is structure important? What determines structure?

htt

p:/

/ww

w.n

ews.

wis

c.ed

u/n

ewsp

ho

tos/

iro

nV

I.h

tml Th

eto

wer

of

bab

elby

Pieter


htt

p:/

/ww

w.n

ews.

wis

c.ed

u/n

ewsp

ho

tos/

iro

nV

I.h

tml

Structure is the basis forordered, managed evolution

Pieter

Bru

egelthe

Elder

(15

63

)

Architecture! Architecture! Architecture!


Example: Access Control(Applications Security)

Impact of a change: 5’000 privacy-critical banking applications

DigitalCertificate

DigitalCertificate

UID,PW

Structure 1: Distributed Access Control Structure 2: Central Access Control


Access Control

Application

Access Control

Application

Access Control

Application

Access Control

Application

Access Control

Application

Access Control

Application

UID,PW

Application

Application

ApplicationApplication


UID,PW

Access Control

Future-Proof Software-Systems: Architecture

System Boundary• Governance

• Legal• Technical

• etc. ( SoS)

Existing

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy) Change

Change


(Legacy)ApplicationExisting

(Legacy)Application

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy)

Application

Existing(Legacy)

Application

(Legacy)Application

Change

ChangeIn most cases thechanges to thesystem areincremental[ size, rate of change]

time

System at time tn

tn

Functional

System at time tn+y

tn+y

System developmentcycle


BusinessRequirements

Functional systemproperties Functional


FunctionalProperties at tn

StructuralProperties at tn

ArchitectureRequirements

propertiestransformations(following business

requirements)

FunctionalProperties at tn+y

StructuralProperties at tn+y

Structural systemproperties

transformations(following architectural

requirements)


The eternal dilemma of (industrial) software-development:

Business requirements Architectural requirements

Business wants:• (Very) short time to market

• Low cost

• Only essential functionality

• Newest technology

Architecture wants:• Good fit into the existing system

• Refactoring to improvearchitectural quality

• Limit growth in complexity

• Use proven technologies


htt

p:/

/wo

hle

ran

zeig

er.c

h/s

eilz

ieh

en/i

nd

ex.h

tml

• Use proven technologies


Agility

Future-Proof Software-Systems Coordinates:

“… It is the one that is themost adaptable to change”


Business Value

Business Functionality


Why is agility so important?

Business Value

Agility

Time to market

Reqs

Time to market

Time to market

we

Competitor A

Competitor B


time

Time to market Competitor B

time

Development Cost

Reqs

Development Cost

Development Cost

we

Competitor A

Competitor B



(0 … 10)

Metric ValueYear1

ValueYear2

ValueYear3

…



Reminder: Quality Properties Scorecard

Business Value

Agility

FPSS


1/ Y1 Y2 Y3

3 Safety 9


9


8


8

7 Security 7

8

9

etc.


Agility

Future-Proof Software-Systems Coordinates: Project Impact

System Stateat time tn+T


Business Value

System Stateat time tn


Agility

System Stateat time tn+T

Future-Proof Software-Systems Coordinates: Project Impact


Business Value

System Stateat time tn+kT


http

://articles.econ

om

ictimes.in

diatim

es.com

/20

13

-02

-06

/new

s/36

94

96

15

_1_b

oein

g

Example: Boeing 787(787 Dreamliner Grounding)

On January 17, the fleet of 50 dreamliner787 aircraft was grounded due toproblems with its lithium-ion batteries


06

/new

s/36

94

96

15

_1_b

oein

g-s-dream

liner-fligh

ts-nip

po

n-airw

ays

Reason: The pressure to meet tight deadlines

http://www.nbcnews.com/id/50584174

Highly dangerous:

Business requirementsmassively overruledengineering requirements

Agility


The project funding battle:

Business requirements Architectural requirements


Business Value


Case 1: Opportunistic ApproachAgility

Loss ofAgility


BusinessValue

Gain of BusinessValue


Case 2: Managed Evolution

Agility

htt

p:/

/lu

nat

un

es.d

evia

nta

rt.c

om

/art


BusinessValue

Gain ofAgility


Case 2: Managed Evolution

AgilityManagedEvolutionChannel


BusinessValue

Manifesto of Future-Proof Software-Systems:

1. „Fit-for-Future“ of an IT-systemdepends on ist structure and isdetermined by ist architecture

2. The agility must continuously beimproved

3. Future-proof software-systems needstrong architects and an farsighted

management

Agility


The project funding battle:

Gain of


Business Value

• Business Requirements• Development Budget

• Time-to-market• Resource constraints

• Architecture Requirements• Structure• Properties

• Consistency

Gain ofAgility


Deutsch: Kontostand am 31.12.2012Französisch: Solde bancaire le 31.12.2013Italienisch: Saldo il 31.12.2013Englisch: Balance at 31.12.2013

Example: 5th Language Until 1995 Swiss banking IT-systems used 4 languages:

Spanisch: Saldo el 31.12.2013Due to globalization, in Y2000 a newlanguage (Spanish) had to be offered

to the customers

PROGRAMM N…(1;12;Kontostand am x.y.z)(2;12;Solde bancaire le x.y.z)(3;12;Saldo il x.y.z)(4;12;Balance at x.y.z)

Traditionally, thetexts were part ofthe individualprograms („text-string“),identified by

Create a centrallanguage file andexport it to allprograms

Solution 2:

(1;12;Kontostand am x.y.z)(2;12;Solde bancaire le x.y.z)(3;12;Saldo il x.y.z)(4;12;Balance at x.y.z)


(4;12;Balance at x.y.z)……

identified bylanguage codeand text code

PROGRAMM N…(1;12;Kontostand am x.y.z)(2;12;Solde bancaire le x.y.z)(3;12;Saldo il x.y.z)(4;12;Balance at x.y.z)(5;12;Saldo x.y.z)……

Individuallymodify all theprograms whichneed Spanishoutput (ca. 5‘000applications)

Solution 1:

PROGRAMM N……

programs(4;12;Balance at x.y.z)(5;12;Saldo x.y.z)

PROGRAMM N+1…… PROGRAMM N+2

…… PROGRAMM N+3

……


Agility

Future-Proof Software-Systems Coordinates: Metrics

Metric Idea:

„How much effort do you need to produce a certain amount offunctionality“

Amount of functionality: Use Case Points or Function PointsEffort: Development Cost and Development Time

Method: Agility = Functionality/(DevC*DevT)

Metric Idea:


BusinessValue

Metric Idea:

„How much monetary return do you get if you invest a certainamount of money“

Investment: €Return: €

Method: Business Value = NPV (Net Present Value)



Business Value = Net Present Value (NPV)

Earnings: Year1 Year2 Year3 Year5 Year6

htt

p:/

/w

ww

.eco-w

ay.c

h/?p=10846

Investment:

- 860‘000.- €

NPV = +165‘000 €


Earnings: Year1 Year2 Year3 Year5 Year6240‘000 € 270‘000 € 230‘000 € 280‘000 € 300‘000 €

(1+0.8)-1

1.08(1+0.8)-2

1.17(1+0.8)-3

1.26(1+0.8)-4

1.36(1+0.8)-5

1.478 %/year:

+ 222‘000 €+ 230‘000 €+ 182‘000 €+ 205‘000 €+ 186‘000 €+ 1‘025‘000 €



Agility

Measurement of Time-to-Marketfor all relevant projects

1Project Start Project End

TtM (Time-to-Market)

Measurement of Implementation-cost for all relevant projects

2Project Start Project End

DevC (Development Cost)

WarrantyPeriod


Determination of functional project-size (Use Case Points or Function Points)

3Amount of functionality:Functional Size(#UCP or #FP )

Size

Project Start Project End

i = 1 … n / Sample Sets:All projects in a time interval

All projects with certain characteristics

Subset of projects with defined characteristics

Agility =TtMi DevCi

(Sizei)2


The Value of Agility:

High agility favours all projects:

Every project is done with reasonable cost and adequate time-to-market

Low agility punishes all projects:

Every project suffers excessive cost and delayed time-to-market


myth

olo

gy


TtM (Time-to-Market)

Gain in TtM


Gain in DevC

htt

p:/

/m

ark

sre

cru

itm

en

tblo

g.w

ord

pre

ss.c

om

/ta

g/gre

ek-m

yth

olo

gy

low agility


Agility

Future-Proof Software-Systems Coordinates: Metrics

Agility

t


BusinessValue

BusinessValue

t


Agility Agile Development

Agility = Important property of a future-proof software-system

Agile Development = Software development process to increase productivity

Agility and Agile Development are not the same !


Manifesto for Agile Software Development:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan


The Importance of Architecture

Future-ProofSoftware System

(FPSS))Structure Architecture

An adequate, continuously improving system architectureis the key to a future-proof software-system


is the key to a future-proof software-system

Architecture


QualityStandards


Agility

The Importance of Architecture


QualityStandards


Business Value


Architecture Erosion and Technical Debt Accumulation

Agility

ArchitectureErosion


BusinessValue

TechnicalDebt


Safety

Security

Agility

Availability

etc.

Functionality and architecture are (nearly) orthogonal

syste

mor

an

exte

nsio

n Fm


Safety

Security

Agility

Availability

etc.

Fu

ncti

on

ality

of

asyste

m

F1

F2

F5F4F3

A1

System & software architecture

AnA4 A5A3A2 A9



Copyright Frank J. Furrer 2013 72http://famouswonders.com/matterhorn-in-between-switzerland-and-italy

• Business Requirements• Functional Reqs• Non-functional Reqs• Resource constraints


(0 … 10)

Metric ValueYear1

ValueYear2

ValueYear3

…



3 Safety 9


9


8


8

7 Security 7

8

9

etc.

ArchitectureFu

ncti

on

ality

Usability

Security



(0 … 10)

Metric ValueYear1

ValueYear2

ValueYear3

…




Business Value

Agility

FPSS


1/ Y1 Y2 Y3

3 Safety 9


9


8


8

7 Security 7

8

9

etc.



The structure of a future-proof software-system is determined by thequality of its architecture

Good architecture = „fit-for-future“ ( agile, cost-efficient, adequatequality properties)

Bad architecture = „stuck in the past“ ( rigid, resistant-to-change,


Bad architecture = „stuck in the past“ ( rigid, resistant-to-change,hard to understand systems with possibly unpredictable behaviour)

Functionality and architecture are (nearly) orthogonal

Each project which modifies the system must create business valueand improve the system architecture at the same time

Developing and maintaining the architecture of a system is acontinuous, incremental process – which needs strong architecturalgovernance, sufficient funding and a farsighted management


Research Questions Master Thesis Level:• Much work has been reported on architectural quality (especially on softwarequality). However, this work remains fragmented. There is no complete, consistentand quantifiable definition of the architectural quality of a system. Such adefinition – and the associated metric – would have to include all knownarchitecture principles – and possibly discovering new ones

Research Questions Ph.D. Thesis Level:


• Future-proof software-systems require continuous, incremental investment bothinto creating business value and into improving system architecture (during eachproject modifying the system). Which is the required, adequate, justifiable ratio ofinvestment into architecture improvement in relation to business value creation?

• Future-proof software-systems require continuous, incremental investment bothinto creating business value and into improving system architecture, especiallyagility (during each project modifying the system). Which is the required,adequate, justifiable ratio of investment into architecture improvement in relationto business value creation?


References:ReferencesMurer11 Stephan Murer, Bruno Bonati, Frank J. Furrer:


Springer-Verlag, Berlin Heidelberg, 2011, ISBN 978-3-642-01632-5Gutbrod12 Roger Gutbrod, Christian Wiele:

The Software Dilemma – Balancing Creativity and Control on the Path to Sustainable SoftwareSpringer-Verlag, Heidelberg, 2012. ISBN 978-3-642-27235-6

DeMarco97 Tom DeMarco:

The Deadline – A Novel About Project Management

Dorset House Publishing, N.Y., USA, 1997. ISBN 978-0-932633-39-2

Fowler09 Martin Fowler:

Technical Debt

February 2009, downloadable from: http://martinfowler.com/bliki/TechnicalDebt.html (last accessed 24.6.2013)


February 2009, downloadable from: http://martinfowler.com/bliki/TechnicalDebt.html (last accessed 24.6.2013)

Duvall07 Paul Duvall, Steve Matyas, Andrew Glover:

Continuous Integration - Improving Software Quality and Reducing Risk

(Pearson Education) Addison-Wesley, N.J., USA, 2007. ISBN 978-0-321-33638-5

Feathers07 Michael Feathers:

Working Effectively with Legacy Code

Prentice Hall International, USA, 2007. ISBN 978-0-13-117705-5

Barbacci95 Mario Barbacci, Mark H. Klein, Thomas A. Longstaff, Charles B. Weinstock:

Quality Attributes

Software Engineering Institute (SEI), Carnegie Mellon University, Technical Report CMU/SEI-95-TR-021,December 1995. Downloadable from: http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm (lastaccessed 24.6.2013)

Fairbanks10 George Fairbanks:


Marshall & Brainerd, Boulder CO, USA, 2010. ISBN 978-0-9846181-0-1



Industrial Architecture


Future-ProofSoftware System

(FPSS))Structure Architecture

An adequate, continuously improved system architectureis the key to a future-proof software-system


(FPSS))

?Industrial IT Architecture


EngineeringDiscipline

ArchitectureProcess

GovernanceInstrument

Structure

IT Architecture Definition:

“The fundamental organization of a system embodied in its elements, their relationships toeach other and to the environment, and the principles guiding its design and evolution”

[adapted from IEEE00]

Industrial Architecture … but industrial IT architecture is more:


Discipline Process Instrument


ArchitectureGuidelines &Best Practices

ArchitectureMetrics

ArchitectureStandards

BusinessArchitecture

ApplicationsArchitecture

Safety & SecurityArchitecture

IntegrationArchitecture

TechnicalArchitecture

IT StandardsEnforcement

TechnologyPortfolio

Management

ApplicationsPortfolio

Management

ServicePortfolio

Management

IT StandardsDevelopment

ComplexityManagement

Architect‘sTraining

Business – ITAlignment

ArchitectureCommunication



ArchitectureProcess


Structure



Architecture



Integration


TechnologyPortfolio

Management

Service


Complexity




ArchitectureMetrics






Management

ServicePortfolio

Management




Architecture Development

Architecture Enforcement

Result: Structure („Architecture“)


Arc

hite

ctu

reD

evelo

pm

en

t

Existingsystem

architecture

Requirements• functional

• non-functional

RequirementsEngineering

stakeholderscompleteness,consistency


Architecture options

Arc

hite

ctu

reE

valu

atio

n

Target architecture

weightingtrade-offs Architecture

Top-LevelProcess


Example: Sanction Filter(Financial embargo enforcement)

SIC XYZSWIFT SWIFT SWIFT SWIFT SWIFT SWIFT SIC XYZ

hundreds of clearing hubs worldwide

world

wid

e

New legal requirement:„Strictly enforce embargo lists

worldwide“

filt

er


Application


Application



Application


Application




Application

Application

several 1‘000 applicationsin >40 countries

world

wid

econ

nectiv

ity

several 1‘000connections toclearing hubs

San

cti

on

filt

er





filt

er

Architecture option 1:Fully decentralized installation


Application


Application



Application


Application




Application

Application


several 1‘000connections toclearing hubs

San

cti

on

filt

er





Architecture option 2:Fully centralized installation


Application


Application



Application


Application




Application

Application


centralized, high-performancesanction filter





Architecture option 3:Sub-clustering


Application


Application



Application


Application




Application

Application


Sanctionlist

centrallymaintained



Arc

hite

ctu

reE

valu

atio

n

Target architecture

weightingtrade-offs

Criteria Option 1: fullydecentralized

Option 2: fullycentralized

Option 3: Sub-clustering

Performance 3 1 2


Security 1 3 2

Maintainability 1 3 3

Dependability 3 1 2

Implementation cost 1 2 3

Operational cost 1 3 2

Match withorganizationalstructure

1 1 3

Governance 1 1 3

Legal & complianceconformance

2 3 3

Archiving 1 3 2

Assessment 15 21 25

1 = low2 = average3 = good

Information (Data)


ApplicationsArchitecture(Functionality)

BusinessArchitecture(Business Processes)

Arc

hit

ectu

reLayers

Arc

hit

ectu

res

SecurityArchitecture

(Defense)

SafetyArchitecture

(Accidents)

PerformanceArchitecture

(Real-Time)

SystemManagementArchitecture

(Control)

… etc.X-Architectures

Vertical Architectures

Information (Data)Architecture(Information & Data)


TechnicalArchitecture(TechnicalInfrastructure)

IntegrationArchitecture(CooperationMechanisms)

Str

uctu

ralA

rch

itectu

reH

ori

zon

talA

rch

itectu

res


Example: Automotive Controlh

ttp

://w

ww

.ve

hic

le-l

ab.n

et

Business Architecture:• Definition of Functionality & Interactions


Information (Data) Architecture:• Specification of information used (car & environment) and data structures

Technical Architecture:• Number and location of the ECU‘s, cabling structure• System software (RTOS)

Integration Architecture:• Design of bus-structure(s) and interaction mechanisms & middleware

Applications Architecture:• Assignment of functionality to tasks, definition of interfaces, redundancy


Why is architecture layering important ?

InformationArchitecture

Integration



Security Safety Perfor-mance

SystemManage-

ment

www.123rf.com




Future-ProofSoftware-SystemEngineer



ArchitectureProcess


Structure


ArchitectureGuidelines &

Best Practices

Architecture



Integration


TechnologyPortfolio

Management

Service


Complexity




ArchitectureMetrics






Management

ServicePortfolio

Management




Architecture Development

Architecture Enforcement

Result: Structure („Architecture“)



Architecture

Architecture Developmenthttp://www.telco2.net/blog/2007/04/telco_20_event_digital_worker.html

Fundamental insights– formulated as rules –how a good IT-systemshould be built

http://www.wyattresources.com/guardrail.htm

Implementation advice


ArchitectureGuidelines &

Best Practices


Implementation advice– seen as „guardrails“ –to guide the architect

Binding, enforcableregulation for buildingan IT-system


BusinessCase

justifies


QualityProperties

definedby

Structure

enables

Architectureforms

guide

control

DevelopmentProcess

builds


enforce



Engineer

leads

appliesMetrics

quantify

uses

Conceptual Context:(Lecture Map)

WorkingEnvironment

is embedded in


… the birth of architecture principles (1972):

htt

p:/

/dat

apea

k.n

et/c

om

pu

ters

cien

tist

s.h

tm


htt

p:/

/dat

apea

k.n

et/c

om

pu

ters

cien

tist

s.h

tm

David L. Parnas* February 10, 1941 in Pittsburgh, USA

Communications of the ACM, Volume 15, Number 12, December 1972Available at: http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf


Example: Managed Data Redundancy(Applications Architecture & Information Architecture)

Problem: Different applications work with inconsistent data

Information(Content)

InformationSource

InformationSource

Multiple, uncoordinatedacquisition of the sameinformation


DataSource

DataSource

Snap-shot

ApplicationUserApplication

UserApplicationUser


User

ApplicationUser

Redundant, ofteninconsistent data

Applications or userswork with different,inconsistent data


Example: Managed Data Redundancy(Applications Architecture & Information Architecture)

Architecture Principle:For each information (content) one andonly one master source is defined. All

managed data redundancy derives solelyfrom this master source

Information(Content)

InformationSource

InformationSource

Master Data

Synchronization/Consistency


The data is generatedand propagated in aconsistent way

Applications or userswork with consistent data

Master DataSource

Snap-shot

DataSource

DataSource


UserApplicationUser


User

ApplicationUser


Example: Access Control(Security Architecture)

UserNameIDCredentials

Protection Object

NameIDConfidentiality LevelConstraints

Role

Role NameID

1…*1…*

MemberOf

1…*1…*

isAuthorizedfor

RightAccessTypeCredentials


InformationArchitecture





Security Safety Perfor-mance

SystemManage-

ment

Credentials

checkRights

http://www.techwench.com

Rights DB

Access Control

APPLICATION

Rights



Structure

enables

Architectureforms


enforce

ArchitecturePrincipleArchitecture

PrincipleArchitecturePrincipleArchitecture

ArchitectureFuture-Proof


PrinciplesPrinciplePrincipleArchitecture

Principle

http://berxblog.blogspot.ch


Engineer


Architecture Erosion:

Any IT-architecture is continuously degeneratingdue to many factors:

• technological change

• progress in software-engineering

• new laws & regulations

• accumulation of mistakes + shortcuts

• sloppy system extensions

… and some more

Architecture Erosionhttp://thoreau.colonial.net/Students/EricksonHoyt/erosion


… and some more

Quality Properties:• Business Value

•Agility• Security

• Availability• etc.

Time



ArchitectureProcess


Structure



Architecture



Integration


TechnologyPortfolio

Management

Service


Complexity




ArchitectureMetrics






Management

ServicePortfolio

Management




http://berxblog.blogspot.ch

goodarchitecture


Architecture Views

Parts of the System

Internal Dependencies(Relationships)

External Dependencies(Relationships)

Properties

Behaviour

Properties

Behaviour


System Boundary

(Relationships)

Properties

Behaviour


Architecture View: Security – a selective view

Security Properties:• Protocol: Secure ESB

• Encryption: RSA-1024• Encryption: Link

• Authentication: none

Security Properties:• Authentication: # Certificates

• Authorization: Role-Based• Audit Trail: Real-Time

• Monitoring: continuous• Databases: encrypted


System Boundary

• Authentication: none

Security Properties:• Protocol: SSL

• # Cert: 2‘048 Bit• Encryption: End-to-End

• Authentication: PKI


Use and Importance of Architecture Views www.123rf.com

Sys Mgmt

Security

Safety

etc.


Stakeholders

Architecture documentation:

Documentation Framework

Views:

Overarching documentation


How much Architecture is enough?

Architecture = Front-end effort (beforethe productive work starts)

Cost, delay, constraintsProject effort (€)

100 %

??


G. Fairbanks / ISBN 978-0-9846181-0-1

Architecture work

10 %

Answer:

• System creation/extensions with highrisk need much architecture work

• System creation/extensions with lowrisk need little architecture work(George Fairbanks - ISBN 978-0-9846181-0-1, 2010)


How much Architecture is enough?h

ttp:/

/w

ww

.skyscra

pern

ew

s.o

rgh

ttp:/

/w

ww

.dim

en

sio

nsin

fo.c

om

/dim

en

sio

ns-o

f-a-d

og-h

ou

se


Architecture work

Project effort (€)

10 %

100 %

htt

p:/

/w

ww

.dim

en

sio

nsin

fo.c

om

/dim

en

sio

ns


Where do Architecture Principles come from? Which are the good ones?

IT ArchitecturePrincipleIT Architecture

PrincipleIT ArchitecturePrincipleIT Architecture

Principle



Legacy Softwareh

ttp:/

/w

ww

.nzz.c

h/aktu

ell/

sta

rtseite

/h

inte

rtuerc

hen

htt

p:/

/w

ww

.123rf

.com

/ph

oto

_4985178_o

ld-r

usti

ng-s

cra

pped-c

ars

-in

-a-j

un

k-y

ard

.htm

l


http

://w

ww

.nzz.c

h/aktu

ell/

sta

rtseite

/h

inte

rtuerc

hen

-der-b

an

ken

-bei-d

en

-gold

-etf-1

.5956390

htt

p:/

/w

ww

.123rf

.com

/ph

oto

_4985178_o

ld

Liability Asset

good:

• invaluable implicit knowledge of thedomain and the business processes

• stable operation (mature)

• good solutions/algorithms

• often: suprisingly good code

bad:• eroded architecture• badly or not documented• obsolete technology (HW & SW)• lost knowledge (people left)• difficult integration context



Good architecture (structure) is the result of the consequent andcontinuous application of architecture principles

A number of architecture principles have proven their great valueover time and in many successful systems


The architecture principles form the toolbox of the future-proofsoftware-systems engineer: He is responsible for consistently applyingthe principles during system development

Architecture is always under risk of deteriorating: From architectureerosion, from business pressure, from implementations short-cuts etc.

Architecture thus needs constant care and attention


Research Questions Master Thesis Level:• Choose one architecture principle from this lecture. Investigate, formalize andquantify the impact of the architecture principle on the specific quality propertiesof a system

• Investigate the reasons for IT architecture erosion. Describe their impact on thearchitecture. Research methods to combat architecture erosion (such asrefactoring, reengineering or rebuild)

• Research existing IT architecture standards (such as ISO, IEEE, OMG, Autosar,IMA, etc.) and describe their positive impacts on their respective applicationsdomains


domains

• Investigate the available architecture description languages (such as UML,SysML, XML, domain-specific languages etc.). Compare their relative strengthsand weaknesses and assess their usefulness for embedded software development

Research Questions Ph.D. Thesis Level:• Research the literature and assemble all known architecture principles. Organizeand structure them. Assess their value in the form of impact on quality properties.Distill a necessary and sufficient set of architecture principles for a number ofspecific application domains, such as automotive, aerospace and medicalequipment. Provide a taxonomy which is useful for the working future-proofsoftware-systems engineer in his daily work


Research Questions Ph.D. Thesis Level:• George Fairbanks (ISBN 978-0-9846181-0-1, 2010) introduces the interestingand fruitful link between the risk of a system creation/extension and the amountof front-end architecture work required to mitigate the risk. However, he gives onlylittle causal evidence and metrics, and no practical methodology to make practicaluse of this valuable idea. Develop the link between risk and architecture, proposea methodology for use in the future-proof systems-software engineers‘ daily workand introduce some useful metrics



References:ReferencesMurer11 Stephan Murer, Bruno Bonati, Frank J. Furrer:


Springer-Verlag, Berlin Heidelberg, 2011, ISBN 978-3-642-01632-5Fairbanks10 George Fairbanks:


Marshall & Brainerd, Boulder CO, USA, 2010. ISBN 978-0-9846181-0-1DeWeck11 Olivier L. de Weck, Daniel Roos, Christopher L. Magee:

Engineering Systems – Meeting Human Needs in a Complex Technological World

MIT Press, Cambridge, USA, 2011. ISBN 978-0-262-01670-4Bass13 Len Bass, Paul Clements, Rick Kazman:

Software Architecture in Practice



SEI-Series (Pearson Education), Addison-Wesley, N.J., USA, 3 edition, 2013. ISBN 978-0-321-81573-6Beijer10 Peter Beijer, Theo de Klerk:

IT Architecture – Essential Practice for IT Business Solutions

Lulu Enterprises Inc., USA, 2010 (www.lulu.com). ISBN 978-1-4457-0603-0Clements10 Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord:

Documenting Software Architectures: Views and Beyond

SEI Series in Software Engineering. Addison Wesley, MA, USA, 2nd revised edition, 2010. ISBN 978-0-321-55268-6

Gorton06 Ian Gorton

Essential Software Architecture

Springer-Verlag, Berlin Heidelberg, 2006. ISBN 978-3-540-28713-1Greefhorst11 David Greefhorst, Erik Proper:

Architecture Principles – The Cornerstones of Enterprise Architecture

Springer Verlag, Heidelberg, Berlin, 2011. ISBN 978-3-642-20278-0Lattanze09 Anthony J. Lattanze:

Architecting Software Intensive Systems – A Practicioner’s Guide

Auerbach Publications, Taylor & Francis Group, LLC, 2009. ISBN 978-1-4200-4569-7


Architecture Metrics




ArchitectureProcess


Structure



ArchitectureMetrics




Safety &Security

Architecture



StandardsEnforcement

TechnologyPortfolio

Management


Management

ServicePortfolio

Management




Business-to-ITAlignment


Future-Proof Software-Systems: Architecture Metrics

Metric: Quantitative measurement of a product or a process attribute

Metric Definition


defined

1) Metrics are indispensable for the

management of future-proof software-

systems („you cannot control what you


QualityProperties

definedby

Metrics

quantify

systems („you cannot control what you

cannot measure“)

2) Metrics are expensive. You need a very

clear purpose and great staying power


Which metrics are necessary?

BusinessValue

Agility

a) FPSS key metrics:


TtM (Time-to-Market)Unit: days (d)

Amount of functionality:Functional Size

Size Unit: #UCP or #FP




WarrantyPeriod

Unit: k€

Agility =TtMi DevCi

(Sizei)2

Unit: #UCP/(days*k€)

CREDIT SUISSE values:

~ 4.2 k€/UCP

~ 0.8 days/UCP



Project Size(#UCP)

TtMi(days)

DevCi(k€)

End Date

P1 1’200 900 5’600 Jan 2012

P2 650 645 2’566 Jan 2012

P3 4’400 5’280 27’270 March 2012

availability data


P4 980 620 5’400 April 2012

P5 11’250 6’600 75’600 April 2012

P6 2’300 1’900 13’900 June 2012

P7 800 390 6’200 August 2012

P8 1’850 1’250 13’200 August 2012

etc. … … … …

Agility =TtMi DevCi

(Sizei)2

Unit: #UCP/(days*k€)

measurementperiod



BusinessValue

Agility

a) FPSS key metrics:

NPV = Net Present Value(€)I = Investment(€)i = Interest rate (%)

(1 + i)n

Benefityear-nNPV = - I

n


i = Interest rate (%)n = year (n=0: Project start)

Types of benefits:

• Earnings (new business)

• Cost avoidance (Rationalization, automation)

• Safety & security enhancements (NPV = indirect, enabling)

• Legal & compliance conformance (NPV = indirect, enabling)



Business Value = Net Present Value (NPV)

Earnings: Year1 Year2 Year3 Year5 Year6

htt

p:/

/w

ww

.eco-w

ay.c

h/?p=10846

Investment:

- 860‘000.- €

NPV = +165‘000 €


Earnings: Year1 Year2 Year3 Year5 Year6240‘000 € 270‘000 € 230‘000 € 280‘000 € 300‘000 €

(1+0.8)-1

1.08(1+0.8)-2

1.17(1+0.8)-3

1.26(1+0.8)-4

1.36(1+0.8)-5

1.478 %/year:

+ 222‘000 €+ 230‘000 €+ 182‘000 €+ 205‘000 €+ 186‘000 €+ 1‘025‘000 €


Domain-specific metrics:

Domain-specific

definedby


Future-Proof Software-Systems:agility & business value

Financial Information Systems:integrity, security, availability, legal&compliance conformance,usability, user response time, SoS-interoperability, …

Automotive domain:safety, reuse, modularity, resource-consumption,


specificQuality

Properties

Metrics

quantify

safety, reuse, modularity, resource-consumption,maintainability, availability, usability, cost, certifiability, …

Medical domain:safety, usability, performance, certifiability, maintainability,operating cost, …

Mobile robots:safety, SoS-interoperability, performance, certifiability,dependability, versatility, …


Example:ServiceReuse

(CREDITSUISSECorbaServicesReuse2005-2009)

408

317315

343

308

283

258

354

252

287

411

350

376

% reused CORBA services

100Number of CORBA services


2005-2009)

06/05

113

03/0909/0703/0703/05

92

03/0806/0712/0609/06 12/0706/0603/0612/05

226

09/05

107

12/0806/08 09/08

50



(0 … 10)

Metric ValueYear1

ValueYear2

ValueYear3

Tendency




Domain-Specific Quality Properties:

3 Safety 9

Domain-Specific Quality Properties Scorecard:



9


8

6 Resources (Memory, CPU, …) 8

7 Security 7

8

9

etc.



(0 … 10)

Metric ValueYear1

ValueYear2

ValueYear3

…




Business Value

Agility

FPSS


1/ Y1 Y2 Y3

3 Safety 9


9


8


8

7 Security 7

8

9

etc.



The key metrics proposed in this lecture for future-proof softwaresystems are „Agility“ and „Business Value“. Due to the background of thelecturer, these metrics are very well suited to very large informationsystems in the financial industry (Are they also as powerful in otherapplications domains, such as automotive, aerospace etc.?)


Reliable metrics are indispensable for the successful management offuture-proof software-systems (in fact: for any technical system)

Metric programs are (very) expensive. The purpose and benefit of ametric must therefore be very clear before starting a measurementprogram. Measurement programs must be strongly supported bymanagement

The scorecard is a valuable tool to visualize the progress of metrics


Research Questions Master Thesis Level:• Define and justify an optimal set of metrics for a (small) number of differentapplications domains (financial systems, automotive applications, medicalapplications, …). Is there a common set of cross-domain metrics (apart from theFPSS metrics)?

• Software quality is a wide research field and many metrics exist to expressparticular aspects of software quality. Software quality is a cross-property concernwhich impacts many of the quality properties of a system. Demonstrate the impactof a number of software quality metrics on the system quality properties in aspecific applications domain


Research Questions Ph.D. Thesis Level:• Quality properties – quantitatively expressed by their metrics – are impacted by anumber of factors, such as architecture, people skills, quality of requirements,maturity of development processes, etc. Detect the causal relationship betweenthe factors and the quality properties (possibly using statistical factor analysis)

• Strong empirical evidence shows that the structure/architecture of a system hasthe strongest influence on its agility. This can be easily demonstrated for thenegative effects of architecture. It is more difficult – but would be of high value tothe field – to show quantitatively the impact of good architecture, specifically achoosen architecture principle on the agility of a system


References:

ReferencesKan95 Stephen H. Kan:

Metrics and Models in Software Quality Engineering

Addison Wesley Longman Inc., Reading, USA,1995. ISBN 978-0-201-63339-6Garmus01 David Garmus, David Herron:

Function Point Analysis – Measurement Practices for Successful Software Projects

Addison-Wesely, Boston, USA, 2001. ISBN 978-0-201-69944-3Ebert07 Christof Ebert, Reiner Dunke:

Software Measurement: Establish - Extract - Evaluate – Execute

Springer Verlag, Berlin, 2007. ISBN 978-3-540-71648-8Fenton97 Norman E. Fenton, Shari Lawrence Pfleeger:

Software Metrics – A Rigorous & Practical Approach


PWS Publishing company, Boston, MA, USA, 2nd edition, revised printing, 1997. ISBN 798-0-534-95425-1McGary02 John McGary, David Card, Cheryl Jones, Beth Layman, Elizabeth Clark, Joseph Dean, Fred Hall:

Practical Software Measurement – Objective Information for decision makers

Addison-Wesley, Boston, USA, 2002. ISBN 978-0-201-71516-3Remenyi00 Dan Remenyi, Arthur Money, Michael Sherwood-Smith:

The effective measurement and management of IT costs and benefits

Butterworth-Heinemann, Oxford UK, 2nd edition, 2000. ISBN 0-7506-4420-6Renkema00 Theo J.W. Renkema :

The IT Value Quest – How to Capture the Business Value of IT-Based Infrastructure

John Wiley & Sons, Inc., Chichester, UK, 2000. ISBN 978-0-471-98817-0Remenyi00 Dan Remenyi, Arthur Money, Michael Sherwood-Smith:

The effective measurement and management of IT costs and benefits

Butterworth-Heinemann, Oxford UK, 2nd edition, 2000. ISBN 0-7506-4420-6Murer11 Stephan Murer, Bruno Bonati, Frank J. Furrer:


Springer-Verlag, Berlin Heidelberg, 2011, ISBN 978-3-642-01632-5


BusinessCase

justifies


QualityProperties

definedby

Structure

enables

Architectureforms

guide

control

DevelopmentProcess

builds


enforce



Engineer

leads

appliesMetrics

quantify

uses

WorkingEnvironment

is embedded in

Part 2

Part 3

Future-Proof Software-Systems


This is the end of Part 1:

you know now the foundations of future-proof software-systems

Part 2:

explains the important architecture principles

Part 3:

describes the „future-proof software-systems engineer“ and his working context

Date post:	18-Mar-2018
Category:	Documents
Upload:	phamnhi
View:	213 times
Download:	1 times

PART1-WS13-14 V10 20130819 - TU Dresdenst.inf.tu-dresden.de/.../ws13/fps13/PART1-WS13-14_V1… ·...

Documents