Software Product EvolutionPROD EVOL

1 The Waves of Change 14 System Types by Lehman & Belady

Components of an Application Environment

Evolution of Architecture

2

3

Throw-Away Applications

Specified Systems

15

16

Evolution ot Database Technology

Evolution of User Interfaces

6

5

4 Standard Information Technology

Static Application Systems

19

18

17

Evolution of Programming Technology

Evolution of Programming Languages

6

7

8

Flexible Information Technology

Dynamic Application Systems

19

20

21Never ending Maintenance

Environmental Influences on IT Systems

R i J

8

9

The Laws of Software Evolution

Consequences of the Laws

R f S f M li

21

22

10 23Requirements Jam

Evolution as permanent Change

E l ti S ft D l t

Reasons for Software Mortality

Possibilities for Life Elongation

C l i

10 23

11 24

Evolutionary Software Development

Software System Growth over Time

Conclusions12 25

13

EVOL-1

The Waves of Change

PROD

The Waves of Change

Object Technology

Web Technology

CASE/4GLClient / Server

Object Technology

Batch/Online

ThTheIT User

Components of an Application Environment

EVOL-2PROD

User InterfacesUser Interfaces

Architecture

Programming Technology

ProgrammingLanguages

Data Storage

Evolution of System Architecture

EVOL-3PROD

1970 2000

Browser

TP-Monitor Server Server

HierarchicalStandalone

OnlineTransaction Web2

BatchSequential Client / Server

A hi

Server

Architecture Architecture Architectureq

Architecture Architecture

OneStep

OneLayer

Thin Client

SomeLayers

Thin Client

SomeSteps

TwoLayers

Fat Client

Evolution of Database Technology

EVOL-4PROD

1970 20002000

CODASYLIDMS

IMSUDS

VSAMISAM

DB2Oracle

DB2Oracle

NetworkedHierarchicalVSAM Object RelationalRelationalNetworkedDatabases

•Fixed Records•Variable Records•Overlaying Record

HierarchicalDatabases

•Fixed Record Size•Variable Segments•Differing Segment

VSAMFiles

•Fixed physical Records•Variable logical

jDatabases

•Objects•Tabels•Differing Formats

RelationalDatabases

•Tabels of Tuples•Variable Length of LinesOverlaying Record

Structures•Pointer Chaining•Primary und secondary Seatch Items

Differing Segment Structures•Pointer Chaining•Physical and logical AccessesHierarchical

Variable logical Records•Differing Record Formats•Primary and secondary Search

Differing Formats•Indexing and Pointer Chaining•Multiplex Access LogicAdaptablility

Lines•Fixed Number of Attributes•Primary & Foreign KeysComplex AccessItems

•Multiple Access Paths•Navigation through the Database

•Hierarchical Access Logic

secondary Search Items•Nested Access Logic

•Adaptablility•XML Translation

•Complex Access Logik•Independence of the Data from the Program

Evolution of User Interfaces

EVOL-5PROD

1970 2000

TerminalMonitor

Online Systems

GUIFat Client

Client/Server

Web BrowserThin ClientWeb based

Record ReaderBatch Systems

Punched CardsPunched TapesBatch Systems y

TP-MonitorsIMS DCCICSUTM

Systems Systemsy

TIP

Evolution of Programming Techniques

EVOL-6PROD

1970 2000

NormalizedProgramming

Data orientedProgramming

StructuredProgramming

Object orientedProgramming

ComponentProgramming

•File affected •Control Flow •Database affected •Encapsulating of •Encapsulating of•File affected Programming•Input, Processing, Output

•Control Flow affected Programming•Sequence, Choice, Repetition

•Database affected Programming•Create, Update, Retrieve, Delete

•Encapsulating of Data and Functions•Inheritance•Polymorphism•Dynamical Binding

•Encapsulating of Functions•Hiding of States•Interfaces as WrappersDi i i f D t•Division of Data

and Functions

Evolution of Programming Languages

EVOL-7PROD

Evolution of Programming Languages

1970 2000

4GLLanguages

ProceduralLanguagesAssembler Mark-Up

LanguagesOO

LanguagesLanguagesLanguages LanguagesLanguages

IBMS

Fortran ADS-Online C++ HTMLSiemensNixdorf

COBOLPL/IDelta

APSIdeal

Natural

OO-CobolJavaC#

XMLJSPPHP

Principle of Continuous ChangePROD EVOL-8

Functional Change and Enhancement

DP Improvementand Correction

SOFTWARE

Application related Technical related+Application relatedElements

Technical relatedElements

+

HardwareChanges

Basis SoftwareChanges

Software is embedded in an instable world.Software is embedded in an instable world.Thus, it is subject to permanent change.

(according to Les Belady)

Environmental Influences on IT SystemsPROD EVOL-9

1) Technological Changes- centralized Databases,- distributed Processing

4) Social Changes- Attitude to Technology,- Self conception of the employees- distributed Processing,

- Automatisation of Offices,- Micro Processors

- Self conception of the employees,- Authority Structures

5) Organisatorial Changes2) Judicial Changes

- Tax Laws,- social Laws,

5) Organisatorial Changes- Centralisation,- Organisational Structures (central/decentral),,

- Business Laws

3) Economical Changes

( )- Management Style (authoritarian/democratical),- Division of work/Job specification

3) Economical Changes- Growth,- Consolidation / Conserving Actions- Changes of Markets

The Requirements JamPROD EVOL-10

With passing of time more d i t Businessand more requirements

accumulate

BusinessRequirements

Unfulfilled Requirements

ImplementedRequirementsRequirements

Evolution as a Control Feedback LoopPROD EVOL-11

Business BusinesslReality Model

Reality Model

IT-System IT-Concepty p

Evolutionary Software DevelopmentPROD EVOL-12

(according to Tom Gilb, 1985)

Spec., Design,

StabilizationSpec., Entwurf,P T t I t

p , g ,Prog., Test, Int.

Spec., Design,Prog., Test, Int. OptimizationStabilization

Prog., Test, Int.

StabilizationSpec., Design,Prog., Test, Int. RenovationOptimization

Prog., Test, Int.

1 - 2 Years

4 - 8 Years

Größe des Systemsin Function-Points20000

2% 1%

Software System Growth over TimePROD EVOL-13

17500

1615516963

17642 18534 18719

+ 7%

+ 6%+ 5%

+ 4%+ 3% + 2% 1%

The GEOS System

15000

13189

14244

15241

+10%

+9%

+ 8% 7%

10000

12500

11000

12100+ 10%

+10%

7500

10000

5000

2500Jahre nach

0

der ersten Freigabe

1 2 3 4 5 6 7 8 9 10 11 12

Software Evolution by Lehmann und BeladyPROD EVOL-14

Drei IT-Systemtypen nach Belady und Lehman

S i hWegwerf D i hStatischesSystem

WegwerfSystem

DynamischesSystem

S-Systemtyp E-SystemtypP-Systemtypwird spezifiziert,implementiert undweggeworfen

E Systemtypwird konzipiert,und fortdauernd adaptiert

P Systemtypwird spezifiziert,implementiert undfortgeschriebengg adaptiertfortgeschrieben

Academic PressLondon, 1985

Throwaway Application SystemsPROD EVOL-15

SpecificationIdea

Specification

Implementation

System Usageg

SoftwareTrash

Such systems have a limited life time - less than theee years

S-Systems = Temporary SolutionsPROD EVOL-16

Problem

Solution Concept

Programming

Is related to... Defines the Development of...

ProgrammingSpecification

ProblemField

Program

SolutionSpecific for a... Providing a...

The program is customized to a given problem.

Standard Information TechnologyPROD EVOL-17

(Backend Processing)OriginalRequirements

CreationRequests

SystemAnalysis

Functional Concept

ProgramSpecification furtherAnalysis p Specification

P

furtherRequirements

< 10%

ChangeImplementation

ProgramRequirements

ChangeRequests

System Usage

P Systems = Static Application SystemsPROD EVOL-18

Change rate Problem Continuousg< 10% Field

Requirements

ContinuousImprovement

ApplicationModel

VarianceComparison

SolutionSpecificationChange

Deviation

ProgramsResultsInformationInformation

Flexible Information TechnologyPROD EVOL-19

(Frontend Processing)Original

Requirements

furtherRequirements

> 10%ChangesAdditionsRequirement

Document

System Functional C

SystemAnalysis Concept Design

Prototype ProgramDocu.

Implementation UsageSystemation

E-Systems = Dynamic Application SystemsPROD EVOL-20

Problem Field

ContinuousDevelopment

Change Rate> 10%

Disaffection

FutureFutureVisionSystem

VarianceComparison

SolutionSpecification Change Results

Information

Application

Deviation

ppModel

The Laws of Software EvolutionPROD EVOL-21

I. Law of continuous change

Useful software mirrors processes in the real world. If these processes change, also the software has to change in order to be consist with them. Software that does not change or changes slower than the real world gets more and more uselesschange or changes slower than the real world gets more and more useless.

II. Law of increasing complexity

In the beginning, the functionality of a system correlates with its form. Each change or enhancement of the functionality enlarges the gap between form and functionalityenhancement of the functionality enlarges the gap between form and functionality. With increasing functionality and unchanged form the complexity of the system increases. Each evolution step gets more difficult.

III. Law of decreasing qualityg q y

Because each evolution step widens the gap between form and functionality, the quality of the system decreases. More and more conflicts between new and old requirements lead to bad compromises. This in turn leads to system erosion and decreasing qualitydecreasing quality.

IV. Law of diminishing productivity

More and more effort has to be put in the adaptation of the original form. This effort is missing for the evolution of the functionality As a consequence the productivityis missing for the evolution of the functionality. As a consequence the productivity decreases and the costs for evolution rise.

V. Law of restricted growthThe increasing complexity together with the decreasing quality slows down theThe increasing complexity together with the decreasing quality slows down the evolution and stops it at a point in time. The evolution steps become smaller and smaller while the release intervals become larger and larger.

Consequences of the Laws of EvolutionPROD EVOL-22

(according to Belady & Lehmann)

1.) The software manager must know the limits of changeability and extensibility.y

2.) The software manager has to develop a long term plan to guarantee a continuous and controllable enhancement.

3 ) The software specification has to be adapted just like the3.) The software specification has to be adapted just like the programs.

4.) The software documentation may not be disregarded.

5.) The software manager has to maintain a consistent and integrated development environment to ensure the continuity of his work.

6.) The software always has to be constantly checked regarding its ) y y g gquality to avoid erosion.

7.) The management has to take care of keeping the same developing methods during the whole life cycle. One may not change tires g y y gon a running car.

Reasons for Software Mortality

PROD EVOL-23

1) Childhood mortality

Th ft i it d f th b i i- The software is unsuited from the beginning.

2) Unable to adapt

- Hardware changes (software depends on certain hardware)g ( p )- Software changes (software on other software)- Requirement changes (software is design for a certain level)

3) Defectiveness)

- Original errors- Second level errors

4) Inadequacy4) Inadequacy

- The software no longer solves the problem.

5) Obsolete)

- The software does not use the latest technical features.

6) Dependencies on humans

- The software can only be maintained by certain key persons, who threaten to leave the organization.

Possibilities for Life ElongationPROD EVOL-24

1.) More modularization

2.) Better interfaces

3 ) More independent components3.) More independent components

4.) More strict standardization

5.) Limited data access (information hiding)

6.) Division in core and periphery components

7.) Greater use of parameters

) ( )8.) Built-in portability (virtual machines)

9.) Fewer hard-coded data (constants and literals)

10.) More and better documentation10.) More and better documentation

11.) Repeatable test procedures

12.) More independence from personnel

Constant Renovation / Refactoring

Continual Quality Assurance

ConclusionsPROD EVOL-25

A software product runs through five phases:

C ti ( t t d l t)- Conception (prototype development)

- Initial development (1. release)- Evolution (maintenance & evolution)

Conservation (maintenance)- Conservation (maintenance)- Redemption (displacement by another

product)

The software life cycle has to be planed organized and The software life cycle has to be planed, organized and controlled by the product management.

The software product has to be maintained and evolved inconstant intervalsconstant intervals.

The software product has to be fixed between the releases if necessary. (emergency fixes).

The software product must be developed in small and manageable steps (evolutionary development)

Software maintenance & evolution have to take place pwithin a proper organizational infrastructure..