PROD VALU Value-Driven Software Maintenancest.inf.tu-dresden.de/files/teaching/ws12/ring/02... ·...

29
V alue-Driven Software Maintenance PROD VALU Life Cycle of a Software Product? Calculating Benefits of SW-Maintenance 1 14 2 Hindu Version of Software Life Cycle Phases of a Software Life Cycle 3 15 Calculating Costs of SW-Maintenance Calculating the Return on Investment 16 Maintenance Activities Maintaining the Value of Capital Goods 4 5 Software Cost/Benefit Analysis Legacy Software Problem (Java) 17 18 Maintaining the Value of Software Products Mutual Dependency of Capital Goods 7 6 Legacy Software problem (DotNet) Allternate Solutions to the Legacy Problem 20 19 Software as packaged Knowledge Software Maintenance Tasks 8 9 Is Outsourcing a viable long range Solution The ALU-II Project 21 22 Benefits of Maintenance Tasks Costs of Maintenance Tasks 10 Evolution of the ALU-II Project The GEOS Project 23 11 24 Value Driven Software Development Value Driven Software Maintenance Evolution of the GEOS Project Summary 12 25 13 26

Transcript of PROD VALU Value-Driven Software Maintenancest.inf.tu-dresden.de/files/teaching/ws12/ring/02... ·...

Value-Driven Software MaintenancePROD VALU

Life Cycle of a Software Product? Calculating Benefits of SW-Maintenance1 14

2 Hindu Version of Software Life Cycle

Phases of a Software Life Cycle3

15 Calculating Costs of SW-Maintenance

Calculating the Return on Investment16

Maintenance Activities

Maintaining the Value of Capital Goods

4

5

Software Cost/Benefit Analysis

Legacy Software Problem (Java)

17

18

Maintaining the Value of Software Products

Mutual Dependency of Capital Goods7

6 Legacy Software problem (DotNet)

Allternate Solutions to the Legacy Problem20

19

Software as packaged Knowledge

Software Maintenance Tasks

8

9

Is Outsourcing a viable long range Solution

The ALU-II Project

21

22

Benefits of Maintenance Tasks

Costs of Maintenance Tasks

10 Evolution of the ALU-II Project

The GEOS Project

23

11 24

Value Driven Software Development

Value Driven Software Maintenance

Evolution of the GEOS Project

Summary

12 25

13 26

Initial 30%

PROD VALU-1

Development 30%

usable?

Maintenanceand 70%

evolution

obsolete?no

Grave

yes

Grave

Live Cycle of a Software Product according to N. Zwegintzow

God of conservationPROD VALU-2

Vishnuthe maintainer

God of creation God of re-useEvolution Conservation

Birth DeathReencarnation =

RecyclingRecyclingDevelopment Redemption

Brahmathe developer

Shivathe reengineerHindu teaching of the Holy Trinity

Hindu Version of Software Life Cycle according to Gerish Parikh

Hindu teaching of the Holy Trinity

Phases of a Software Life Cycle PROD VALU-3

CnceptionPhase

Bi th

Product Management

Corrections,changes,

DevelopmentPhase

Birth changes,Improvements,Enhancements

EvolutionPhase

Corrections,Changes

ConservationPhase Phase out

Displacement

FirstRelease

Redem-ption

Phase

Ti

Burial

Time

Costs

5%

10%

10%

20%

25%

40%

55%

25%

5%

5%10% 20% 40% 25% 5%

according to Bennett and Rajlik

Maintenance ActivitesPROD VALU-4

according to Lientz and Swanson

Functional Evolution

Progression

Enhancement Change

Perfection Stabilization

Technical Refinement

Conservation

Maintaining the Value of Capital Goods PROD VALU-5

• Franz Schmidt , a German economist, came in 1872 to the conclusion that the value of a product on the market can only be ascertained in relation to other similar products. If the need for a product is great and there are no other alternatives, the value is high. If there is no need for it or if there are other similar products the value is low. A product has

l h l t ti l b tt h t it Th t l ionly as much value as potential buyers attach to it. That value is independent of the cost and effort that went into producing it. There is no direct relation between effort and value.F i d i h H k A i i i h 1920‘ i d• Friedrich Hayek, an Austrian economist in the 1920‘s, was interested in the question of what it costs to preserve an existing product relative to the costs of reproducing it or replacing it with another product. H k t “Th ti i h h f th i t f hiHayek wrote “The question is, how much of the gross receipts from his capital income does the entrepreneur have to reinvest in order to ensure a constant flow of income? Either he may reduce his investment to a minimum until the value of his product has been depreciated byto a minimum until the value of his product has been depreciated by change, or he may reinvest amortization quotas of the same on an increasing magnitude as before.” Hayek emphasized the responsibility of a product owner to preserve• Hayek emphasized the responsibility of a product owner to preserve the value of his product by continuously renewing it.

Maintaining the Value of Software ProductsPROD VALU-6

• In respect to software products, Hayek‘s thesis means that a product owner can reduce his maintenance costs to a bare minimum and allow the value of the product to sink relative to the value of the other comparative products, or he can reinvest relative to the costs of the original development in the preservation and evolution of the product, th i it l B f t h i l ti dthus preserving its value. By means of technical renovation and functional enhancement the owner can not only preserve the value of his product but also increase that value. Otherwise the value will sink as the quality decreases and the complexity increasesas the quality decreases and the complexity increases.

• With every correction, change and insertion to the existing code, the complexity increases and the quality decreases. This has been proven b B l d d L h i th i k ft l ti Th bby Belady and Lehman in their work on software evolution. The number of relationships between code blocks goes up as does the size of the individual code blocks. The quality of the code suffers under constant hot fixes and ad hoc patches that destroy the original well thoughthot fixes and ad hoc patches that destroy the original well thought structure and causes the code to become chaotic. The greater the chaos, the more difficult it becomes to restore order and sustain functionality This loss of quality means loss of valuefunctionality. This loss of quality means loss of value.

Mutual Dependency of Capital GoodsPROD VALU-7

• The German economist Lachmann enhanced the teaching of Franz Schmidt with the notion of Complementarity. Goods are complementary when the value of one good is dependent on the value of others. The devaluation of software is explainable in terms of complementary systems, i.e. systems that are dependent on one another. In the IT

ld t d t l t Th d d h th Ifworld most products are complementary. They depend on each other. If the value of one of a network of systems goes down, it pulls the other systems down with it. L h i f ti l t f it l d i t• Lachmann writes „for any particular type of capital good, maintenance is a matter of maintaining its complementarity to the rest of the changing capital structure. Hence, maintenance means not only

ti h th h d t i ti b t t ll h ipreventing any change through deterioration, but actually changing a good directly, in a manner that adapts it to the changing capital structure around it, thereby delaying obsolescence…” If IT t t t it h ti ff t th d d t• If an IT system stagnates, it has a negative effect on the dependent systems. Since IT systems are complementary, all systems in a network of integrated systems must be kept on the same technical and functional level Thus to maintain the value of all systems each systemfunctional level. Thus, to maintain the value of all systems, each system must be evolved at the same pace as the others.

Complementary SystemsPROD VALU-7

As a result of their mutual dependency the devaluation of one system leads to the devaluation of the other systems

System System

one system leads to the devaluation of the other systems

SystemA

SystemB

SystemC

SystemD

A chain is only as strong as the weakest linky g

Software as packaged KnowledgePROD VALU-8

• The value of a software system is directly proportional to the value of those systems upon which it is dependent. Since human users are dependent on the systems they use, they too are affected by the devaluation of any one system. To maintain the value of capital goods in an evolving economy, each good must not only retain ist current

l b t t i i l i d t k i li ith thvalue, but must increase in value in order to keep in line with the systems around it [14].

• According to Hayek capital goods are packaged knowledge. S f d h b d fi d i l d i hi hSoftware products can thus be defined as capital goods, in which human knowledge is packed into code. The knowledge in the code is the result of a learning process which extends over many years. After

f t i l d f i bl t ll t dmany years of trial and error a group of persons is able to collect and stabilize their knowledge in the form of a software product. The long path to a stabile, useful software product is extremely expensive and capital intensive It ties up money and resources that could have beencapital intensive. It ties up money and resources that could have been used for other purposes. Therefore, the preservation of that good should be a major concern of the owner. He needs to invest in order to preserve the value of his capital asset If he does not his investment ispreserve the value of his capital asset. If he does not, his investment is lost.

A Software System is packaged knowledgePROD VALU-8

CodeDocuments

Data

SoftwareSystem

mpl

exity

PackagedKnow-How

System

Com

Know How

Quantity (Size)

Software Maintenance Tasks

VALU- 9PROD

Software Maintenance Tasks

• Corrective Maintenance is triggered by problemCorrective Maintenance is triggered by problem reports and is directed toward error correction (see ITIL Problem Management)

• Adaptive Maintenance is triggered by Change Requests and is aimed at the change and enhancement of existing software components and documents. P f ti M i t i t i d b i t• Perfective Maintenance is triggered by improvement suggestions and leads to the Reengineering or Refactoring of existing components and theirRefactoring of existing components and their documentation.

Benefits of Maintenance Tasks VALU-10PROD

Benefit of corrective Maintenance = Number of working hours lost because of software errors + business opportunities lost due to inaccurate or wrong results.

Benefit of adaptive Maintenance = added value of Software System Added Value = Value of changed System version - Value of previous version.

Benefit of perfective Maintenance = Added ValueAdded Value = (1 - NewSize/OldSize))

+ (OldComplexity - NewComplexity)+ (NewQuality – OldQuality)

In case of a System with 100 000 statements a complexity of 0 70 and aIn case of a System with 100.000 statements, a complexity of 0,70 and aQuality of 0,45 before renovation and with 90.000 statements, a complexity of 0,60 and a Quality of 0,55 after renovation is the added value :

Size: (1 – (90.000 / 100.000)) +Complexity(0,70 – 0,60) + Quality (0,55 – 0,45) = 0,30 = 30% Value increase

Costs of Maintenance TasksVALU-11PROD

Brutto change size = (directly impacted class size * change rate)+ (Σ indirectly impacted class sizes * (change rate/4))

ComplexityAdjustment = measured Complexity / medianComplexity

QualityAdjustment = median Quality / measured QualityQualityAdjustment median Quality / measured Quality

adjusted impact size = raw–size * ( complexity / 0.5) * (0.5 /quality)

Assuming that the direct impact domain of a change contains 800 statements, that the indirectly impacted domain includes 4000 statements and that the rate of change is estimated to be 10%

{impacted Statements / Productivity} * Influence Factors * Overhead Factor

impacted domain includes 4000 statements and that the rate of change is estimated to be 10%.

(800 + (4000/4) * 0.1 = 180 statements.

With a complexity factor of 0.7 und a quality factor of 0.6 the adjusted size of the impact domainIs 209 statements.

180 * [0.7/0.5] * [0.5/0.6] = 209 statements.

Change costs = 209 / 20 = 10,5 PDs * 0,9 * 1,3 = 12,2 PDs

V l D i S ft D l t

VALU-12PROD

Value Driven Software Developmentaccording to Barry Boehm

The essence of value–based software development is that every task produces some result and that this result is judged on the basis of its return on investmentsome result and that this result is judged on the basis of its return on investment which is defined as

ROI = (benefit – cost) / (costs * risk)

Example:

The benefit of a new application is calculated to be € 1 5 MillionThe benefit of a new application is calculated to be € 1.5 Million.

The costs of the development are estimated to be € 1.0 Million

The risk factor of the development is calculated to be 1.2

The ROI = (1.5 – 1) / (1 * 1.2) = (0.5) / 1.2) = 0.4 = € 400.000

Value Driven Software Maintenance

VALU-13PROD

Types of Maintenance Requests

Maintenance tasks are triggered by maintenance requests.There are three types of maintenance requests:• Error reportsp• Change requests• New requirements

Trigger Maint TypeTrigger Maint. Type_______________________________________________________________error report → correctionchange request → adoptiong q p

perfectionnew requirement → enhancement

The two prerequisites to calculating the ROI of a maintenance task are:The two prerequisites to calculating the ROI of a maintenance task are:• to predict the costs of that task• to assess the benefit of that task.

Value Driven Software MaintenanceC l l ti th B fit f M i t R t

VALU-14PROD

Calculating the Benefits of Maintenance Requests

The benefit of an error correction can be defined as the difference between theThe benefit of an error correction can be defined as the difference between the value of the system with the error and the value of the system without the error.

Benefit = Value of Corrected System V l f E S t- Value of Erroneous System

The benefit of an adaptation can be defined as the added value of the system brought about by the change:brought about by the change:

Benefit = Value of Adapted System - Value of Original System

The benefit of an enhancement can be defined as the added value of the system brought about by the enhancement:

Benefit = Value of Enhanced System - Value of Original System

Value Driven Software MaintenanceCalculating the Costs of a Maintenance Task

VALU-15PROD

g

Raw change size = (primary impacted class size * change rate)+ (Σ secondary impacted class sizes * (change rate / 2))+ (Σ tertiary impacted class sizes * (change rate / 4))+ (Σ tertiary impacted class sizes (change rate / 4))

If there are 500 statements in the primary impacted class with a change rate of 20% and 1500 statements in the secondary impacted classes and 3000 statements in the tertiary impacted classes the raw change size will be:

(500 * 0.2) + (1500 * 0.1) + (3000 * 0.05) = 400 Statements

ComplexityAdjustment = Complexity Ratio / Median RatioA complexity ratio of 0.7 gives a complexity adjustment factor of 1.4.

QualityAdjustment = MedianQuality / Quality RatioA quality ratio of 0.6 gives a quality adjustment factor of 0.83.

adjusted size = raw–size * ( complexity factor) * (quality factor)adjusted size = raw–size ( complexity factor) (quality factor)

Adjusted size = 400 * 1.4 * 0.83 = 465

Costs = adjusted size / productivityWith a productivity of 10 statements per day the cost of the change will be 46 person days * € 400 = € 18.400

Value Driven Software Maintenance

VALU-16PROD

a ue e So t a e a te a ceCalculating the Return on Investment

ROI = (benefit – cost) / (costs * risk)

Example:

The benefit of the current system is € 2.500.000.

The benefit of the adapted system is € 2.550.000 = 4% increase

The benefit of the maintenance task is:

2.550.000 – 2.500.000 = 50.000

The risk factor of the maintenance task is calculated to be 1 3The risk factor of the maintenance task is calculated to be 1.3

ROI = (50.000 – 18.500) / (18.500 * 1.3 ) = 2.2

Software Cost/Benefit AnalysisPROD VALU-17

Costs Benefits

[Personnel,Software,Hardware]

[Income,Productivity increase,Cost reduction,Market Share]Market Share]

What is the added value of a Software project?

Das Legacy Software Problem (Java)PROD VALU-18

Ein Java System fuer die Stromabrechnung hat folgende quantitative Eigenschaften:1.977 Source Members270 729 echte Codezeilen ohne Kommentare270.729 echte Codezeilen ohne Kommentare183.474 Anweisungen, davon18.299 if Anweisungen

152 switch Anweisungeng1.591 loop Anweisungen7.071 Ausnahmebehandlungen

31 Komponente1 654 Klassen1.654 Klassen15.384 Methoden788 Schnittstellen47 Datenbanktabellen155 Datenbankzugriffe129 Eingaben420 Ausgaben6 866 Function Points = 27 Anweisungen pro Function Point6.866 Function-Points = 27 Anweisungen pro Function-Point

Wenn dieses System sich nur um 10% jährlich verändert, sind immerhin18.347 Anweisungen, bzw. 686 Function-Points betroffen.

Bei einer Produktivität von 400 Anweisungen, bzw. 14 Function-Points, pro Personenmonat werden 46-48 Personenmonate jährlich benötigt um den Code fortzuschreiben, d.h. es werden mindestens vier Java Fachkräfte gebunden.

Legacy Code bindet knappe Personalkapazität

Das Legacy Software Problem (DotNet)PROD VALU-19

Ein .Net System fuer den Gebühreneinzug hat folgende quantitative Eigenschaften:1.804 Source Members388.576 echte Codezeilen ohne Kommentare388.576 echte Codezeilen ohne Kommentare309.823 Anweisungen, davon

18.608 if Anweisungen474 switch Anweisungen

3 119 l A i3.119 loop Anweisungen5.434 Ausnahmebehandlungen

36 Komponente2.606 Klassen2.606 Klassen16.832 Methoden = Grundbausteine492 Schnittstellen204 Datenbanktabellen716 D t b k iff716 Datenbankzugriffe286 Eingaben530 Ausgaben7.540 Function-Points = 41 Anweisungen pro Function-Point.7.540 Function Points 41 Anweisungen pro Function Point.

Wenn dieses System sich um 10% jährlich ändert, sind 30.982 Anweisungen, bzw. 754 Function-Points, betroffen.

Bei einer Code-Produktivität von 400 Anweisungen pro Personenmonat werden 78 P t jäh li h b öti t di S t L b h lt d hPersonenmonate jährlich benötigt um dieses System am Leben zu erhalten, d.h. es werden sieben .Net Fachkräfte durch das System gebunden.

Legacy Code bindet knappe Personalkapazität

VALU-20PROD

Alternate Solutions to the Legacy System Problem

Maintain the Status Quo

Alternate Solutions to the Legacy System Problem

• Maintain the Status Quo• Replacement by Standard Software (ERP)• Renovation / Reengineering• Redevelopmentede e op e t• Migration to a more modern Environment • Wrapping the old Software in a more modern• Wrapping the old Software in a more modern

EnvironmentO t i th M i t O ti• Outsourcing the Maintenance Operation

• Migration and Wrapping do not solve the Maintenance Problem, they only compound it.

Is Outsourcing a viable long range Solution?

VALU-21PROD

Is Outsourcing a viable long range Solution?

Rights

UserOutsourced

ITSoftware

Maintenance

ServiceLevel

AgreementOperations

Operation

Obligations

The ALU-II Project

VALU-22PROD

j

• Old software was reimplemented (MF-COBOL)• System is platform dependent• System is platform dependent• User Interface code intertwined with application logic• No separate test teamp• No Service Level Agreement• High 2nd level Error Rate (7 per Kilo) • Erroneous transfer of medical insurance payments

(-346 Mio)• Late payment of unemployment compensationLate payment of unemployment compensation• 146 work arounds required• Loss of 2 hours per day per end user• Negative Return on Investment • High maintenance fees due to expensive contract

programmers (65 * € 120 per hour)programmers (65 € 120 per hour)

Evolution of the ALU II ProjectPROD VALU-23

678

0,60,70,8

2345

0,20,30,40,5

012

2002 2005 20080

0,10,

2002 2005 2008

SIZE (MLOCS) COMPLEXITY RATING

789

607080

34567

30405060

0123

2002 2005 20080

1020

2002 2005 2008

ERROR RATE (per KLOC) MAINT. PERSONNEL

00 005 008 2002 2005 2008

The GEOS ProjectVALU-24PROD

• Technical components are separated from application components in the architectureapplication components in the architecture.

• System is platform independent• Objekt orientiert implementiert in C++• Objekt-orientiert implementiert in C++• All Error Reports and Change Requests are

recorded and monitoredrecorded and monitored• Strict Quality Management with well defined

processes for every maintenance typeprocesses for every maintenance type• Separate Test Team

F ll t t d R i t t• Fully automated Regressiontest• Automated Impact Analysis• Metric database is maintained

8 0 005

Reduction of Code Volume by 26%

Reduction of theError rate to 0,0005

VALU-25PROD

5

6

7

8

0,003

0,004

0,005

2

3

4

0,001

0,002

0,003

CodeMenge

0

1

0

MillionLOCs

0 6

0,7

0 6

0,7

OCsQualityIncreased by 21%

Complexityreduced by 14%

0 3

0,4

0,5

0,6

0 3

0,4

0,5

0,6

Qualitäts-grad

0,1

0,2

0,3

0,1

0,2

0,3

0 0

Evolution of the GEOS Product

Industralization of Software MaintenanceVALU-26PROD

• Software Maintenance & Evolution can be i d t i li d b t l hindustrialized, but only when:

• The maintenance conditions are fixed in a service level agreementservice level agreement

• The maintenance work is cost justified• The software architecture is tuned for• The software architecture is tuned for

maintainability• The maintenance processes are preciselyThe maintenance processes are precisely

defined and followed• The maintenance tasks are highly automatedg y• The maintenance personnel are well trained

and disciplined• Agility is forbidden!