Software Evolution 

 September 25, 2013

Maintenance and updating of existing software systems

Software evolution means maintenance plus further development of an existing system. Existing systems contain the accumulated experience of a company and the work of several people over many years.

The book emphasizes the immense value of existing software systems and the need to preserve them. They need to be constantly expanded and regularly renovated. All this requires different techniques and methods than when developing a new system.

In this basic work, the authors cover topics such as maintenance and reprocessing processes, reuse, software analysis methods,
reverse engineering, post-documentation and economic aspects of software system maintenance. Aspects of agile development projects
are also covered. The chapters of the book are structured according to the activities in a software evolution process.

Authors: Harry M. Sneed, Richard Seidl

Publisher: dpunkt.verlag

ISBN: 978-3-86490-041-9

Edition: 1st edition

Table of Contents

1 Introduction to software evolution

1.1 Maintenance and Evolution - a Definition
1.1.1 On the Origin of the Term "Maintenance"
1.1.2 On the Difference between Maintenance and Development
1.1.3 On the Difference between Maintenance and Evolution
1.1.4 On the Difference between Modification and Enhancement
1.1.5 On the Difference between Correction and Remediation
1.2 Iterative and Evolutionary Software Development
1.3 Software Evolution and Agile Software Development
1.4 Maintenance and Evolution in a Service-Oriented IT World
1.5 Structure and Content of the Following Chapters

2 Economics of software evolution

2.1 On the value preservation of software capital goods
2.2 Software as packaged knowledge
2.3 Value-driven software evolution
2.4 Influences on evolution costs
2.4.1 The influence of size on software preservation
2.4.2 The influence of complexity on software preservation
2.4.3 The influence of quality on software preservation
2.5 Estimating evolution costs
2.6 Determining the evolution benefit
2.6.1 The benefit of corrective orders
2.6.2 The benefit of adaptive orders
2.6.3 The benefit of perfective orders
2.6.4 The benefit of enhancive orders
2.7 Example of a cost-benefit calculation
2.7.1 Calculation of the ROI for an operational information system
2.7.2 Calculation of the ROI for a test tool
2.8 Conclusions from the economic analysis

3 The laws of software evolution

3.1 The pioneering work of Lehman and Belady
3.2 Lehman's categorization of software system types
3.2.1 S-Systems
3.2.2 P-Systems
3.2.3 E-Systems
3.3 The five laws of evolution
3.3.1 Law of Continuous Change
3.3.2 Law of Increasing Complexity
3.3.3 Law of Decreasing Quality
3.3.4 Law of Decreasing Productivity
3.3.5 Law of Limited Growth
3.4 On the Validity of the Laws of Evolution
3.5 Consequences of the Laws of Software Evolution
3.5.1 Release sizes must be limited
3.5.2 Documentation must be updated with each release
3.5.3 Code must be sanitized at regular intervals
3.5.4 The quality of the software should be continuously monitored
3.5.5 The evolution of the system must be planned
3.6 Why Software Dies After All
3.6.1 Obsolescence of the Implementation Technology
3.6.2 Inappropriate Technical Solution
3.6.3 Dependence on Key People

4 The evolutionary process

4.1 The Software Evolution Process from a Historical Perspective
4.2 The Release Concept
4.3 System Analysis
4.4 Release Planning
4.5 Updating the System
4.5.1 Correction Tasks
4.5.2 Change Tasks
4.5.3 Further Development Tasks
4.5.4 Integration Tasks
4.5.5 Remediation Tasks
4.5.6 Optimization Tasks
4.6 System Regression Testing
4.6.1 Regression Test Planning
4.6.2 Regression Test Specification
4.6.3 Regression Test Setup
4.6.4 Regression Test Execution
4.6.5 Regression Test Validation
4.6.6 Regression Test Evaluation
4.7 System Documentation
4.8 System Delivery

5 Software system analysis

5.1 Objects of System Analysis
5.2 Methods of System Analysis
5.2.1 Software Rule Testing
5.2.2 Measurement of Software
5.2.3 Post-Documentation of Software
5.2.4 Impact Analysis
5.3 Results of As-Is System Analysis
5.3.1 Test Reports
5.3.2 Metrics Reports
5.3.3 List of Building Blocks to be Changed
5.3.4 Impact Area Size Measures
5.4 Not All System Analysis is the Same

6 Software evolution planning

6.1 The Need for Evolution Statistics
6.1.1 Statistics from Product Analysis
6.1.2 Statistics from Process Analysis
6.2 The Estimation of a New Release
6.2.1 Measuring the Current System Size
6.2.2 Projecting System Maintenance Costs
6.2.3 Estimating Evolution Costs
6.2.4 Calculating the Total Cost of the Next Release
6.3 Identifying and Assigning Evolution Tasks
6.3.1 Evolution Tasks
6.3.2 Assigning Evolution Tasks
6.3.3 Scheduling Evolution Tasks
6.3.4 Management by Contract
6.4 Release Planning Tools

7 Bug fixes

7.1 The Error Message
7.2 The Error Analysis
7.3 Error Cause Research
7.4 Error Correction
7.5 Error Correction Test
7.6 Error Correction Documentation
7.7 Error Statistics

8 Changes

8.1 The Change Process
8.2 The Change Request
8.3 Change Analysis
8.4 Locating the Points to Change
8.4.1 Analysis of Text Documents
8.4.2 Analysis of Design Documents
8.4.3 Analysis of Code
8.4.4 Analysis of Data Structures
8.4.5 Analysis of Test Cases
8.5 Change Sequence
8.6 Change compartmentalization
8.7 Change implementation
8.8 Change validation
8.8.1 Setup of the integration test environment
8.8.2 Generation of the integration test data
8.8.3 Instrumentation of the changed code
8.8.4 Execution of the integration test
8.8.5 Evaluation of the test results
8.9 Change documentation

9 Remediation

9.1 Measurement as a Prerequisite for Remediation
9.2 Remediation Goals
9.3 Remediation Procedures
9.3.1 Freezing Strategy
9.3.2 Opportunity Strategy
9.4 Remediation Procedures
9.4.1 Assembler Languages
9.4.2 Procedural Languages
9.4.2.1 Reformatting the Code
9.4.2.2 Cleaning up the code
9.4.2.3 Renaming non-speaking data names
9.4.2.4 Removing incompatible data types
9.4.2.5 Removing hard-wired data
9.4.2.6 Outsourcing the IO interfaces
9.4.2.7 Restructuring the flow logic
9.4.2.8 Flattening the flow structure
9.4.2.9 Decomposition of the code into smaller building blocks
9.4.3 Object-oriented languages
9.4.3.1 Flattening of the method logic
9.4.3.2 Flattening of the class hierarchy
9.4.3.3 Elimination of redundant methods
9.4.3.4 Replacement of complex selection structures
9.4.3.5 Relocation of common methods and attributes
9.4.3.6 Splitting classes that have grown too large
9.4.3.7 Simplifying interfaces
9.4.3.8 Removing hardwired data
9.4.3.9 Removing dead code
9.4.3.10 Renaming identifiers
9.4.3.11 Adding comments
9.4.3.12 Standardizing code format
9.4.4 Scripting languages
9.5 Remediation Revision

10 Software development

10.1 Commissioning a System Extension
10.1.1 Requirements-Driven Evolution
10.1.2 Model-Driven Evolution
10.1.3 Change-Request-Driven Evolution
10.2 Analysis of an Extension Request
10.2.1 Confirmation of the Stated Benefit
10.2.2 Analysis of the Functional Specification
10.2.3 Impact Analysis of the Requested Extension
10.3 Effort Estimation of an Extension
10.3.1 Effort estimation in requirements-driven evolution
10.3.2 Effort estimation in model-driven evolution
10.3.3 Effort estimation in CR-driven evolution
10.4 Approval of an enhancement
10.5 Establishment of the enhancement project
10.6 Specification of the enhancement
10.7 Implementation of the enhancement
10.8 Testing of the enhancement
10.9 Documentation of the enhancement

11 System regression test

11.1 The Problem of Test Case Selection
11.2 Need for an Independent Test Team
11.3 Regression Testing Tools
11.3.1 Tools for Static Analysis
11.3.1.1 Tools for Testing the Requirements Specification
11.3.1.2 Tools for testing the code and design model
11.3.1.3 Tools for testing documentation
11.3.2 Tools for managing and updating test cases
11.3.3 Tools for test case selection
11.3.4 Tools for test data generation
11.3.5 Tools for Regression Test Execution
11.3.6 Tools for Test Traceability
11.3.7 Tools for Measuring Test Coverage
11.3.8 Tools for Reconciling Test Results
11.3.9 Tools for Error Reporting and Tracking
11.4 Regression Test Procedures
11.4.1 Regression Test Planning
11.4.2 Regression Test Preparation
11.4.3 Regression Test Execution
11.4.4 Regression Test Evaluation
11.5 Regression Test Results

12 Ongoing documentation

12.1 The Justification of System Documentation
12.2 Automated Post-Documentation
12.2.1 Analysis of Requirements Documents
12.2.2 Analysis of Design Model
12.2.3 Analysis of Code
12.2.3.1 Procedural Languages
12.2.3.2 Object-Oriented Languages
12.2.3.3 Structures Common to All Languages
12.3 Multiple Views of a Software System
12.3.1 Static Views of Program Logic
12.3.2 Visualization Techniques
12.3.2.1 Tree Diagrams
12.3.2.2 Network Diagrams
12.3.2.3 Sequence Diagrams
12.3.2.4 Flowcharts
12.3.2.5 Entity/Relationship Diagrams
12.3.3 Limitations of Graphical Representation
12.3.4 Texts vs. Diagrams
12.4 Building and Using a System Repository
12.4.1 Building a Repository
12.4.2 Visiting the repository contents
12.4.3 Querying the repository contents
12.4.4 Generating documents
12.5 Updating the documentation
12.5.1 Coordinated evolution of all software layers
12.5.2 Software = Code + Documentation + Test