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..