Software Engineering & Architecture · Show the shift from the classical software development and...

10. SOFTWARE EVOLUTION

Software Engineering & Architecture

10. SOFTWARE EVOLUTION

Martin Kropp

University of Applied Sciences Northwestern Switzerland

Institute for Mobile and Distributed Systems

References

� Based on the PowerPoint presentation of Chapter 21 of the textbook Ian Sommerville, Software Engineering, 8th Ed., Addison-Wesley, 2006

and

� on the PowerPoint presentation of Chapter 1: History and Challenges of Software Evolution of the textbook Tom Mens, Software Evolution, Springer, 2008

2MSE-SEA - Software Evolution IMVS, M. Kropp

Springer, 2008

Others� [Lindvall&Sandahl 1998] M. Lindvall, K. Sandahl. How Well do Experienced Software

Developers Predict Software Change? J. Systems and Software, 43(1): 19-27, 1998

� [Bohner&Arnold 1996] S.A. Bohner, R.S. Arnold. Software Change Impact Analysis. IEEE Computer Society Press, 1996

Learning Targets

You

� understand and can explain why change is inevitable to keep software

Show the shift from the classical software development and

maintenance view to the more holistic software evolution approach.

Present state and trends in software evolution.


� understand and can explain why change is inevitable to keep software systems useful

� understand how an evolutionary software process supports constant change

� can explain the special requirements of legacy systems

� know methods, tools and practices for an evolutionary software development

� know current trends in software evolution

Content

� Software Evolution

� Evolutionary Processes

� Legacy Systems

� Program Comprehension


� Program Comprehension

� Program Transformation

� Other Trends in Software Evolution

Why Software Changes

� Software change is inevitable� New requirements emerge when the software is used;

� The business environment changes;

� Errors must be repaired;

� New computers and equipment is added to the system;


� The performance or reliability of the system may have to be improved.

� A key problem for organizations is implementing and managing change to their existing software systems.

Types of Changes

� Repair software faults� Changing a system to correct deficiencies in the way meets its requirements.

� Adapt software to a different operating environment� Changing a system so that it operates in a different environment


Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation.

� Add to or modify the system’s functionality� Modifying the system to satisfy new requirements.

� Improve the program structure and system performance� Rewriting all or parts of the system to make it more efficient and maintainable.

… and Software Ages

„Programs, like people, get old“

“Software aging will occur in all successful products“David L. Parnas in „Software Aging“ [Parnas 1994]

But


But

� Why and how does Software get old?

And

� How can we keep software fit?

Task 1 – Software Aging

DOS:

MS Office:


MS Office:

Dec VMS:

Causes of Software Aging

� „Lack of movement“

� The first is caused by the failure of the product‘s owners to modify it to meet changing needs

� „Ignorant surgery“

� The second is the result of the changes that are made


� The second is the result of the changes that are madeDavid L. Parnas in „Software Aging“ [Parnas 1994]

„Lack of Movement“

� The world around changes

� Environment Changes

� New hardware


� New software (e.g. OS)

� Requirements Changes

� New business process

� New functional requirements

� New usability requirements

Ignorant Surgery

� The changes of the software itself

� Changes break original design

� Software gets bigger and slower


� Software gets bigger and slower

� Software get more complex

� Software is more expensive to change

� New bugs are injected

� Documentation becomes outdated

The Cost of Software Aging

� “As software ages, it grows bigger”

� There is more code to change

� It is more difficult to find routines that must be changed

� Reduced performance

More demand on machine resources


� More demand on machine resources

� Poor design decreases performance

� Decreasing reliability

� „As the software is maintained, errors are introduced“

Keep Software Fit

� Establish a graceful evolution of the software� Limit or eliminate the decay

� Limit its side effects

� Include retirement scenario

� Once software gets too old, it has to die – like humans


� Software evolution refers to the study and management of the process of making changes to software over time. � In this definition, software evolution comprises:

� Development activities

� Maintenance activities

� Reengineering activities

Maintenance vs. Evolution

� Software maintenance = the activities of changing the system after it has been delivered

� Software evolution = the process of continuoussoftware change from the very beginning


1.0 1.1 2.01.1.1∗∗∗∗ ��

Evolution

Maintenance

Goal of Software Evolution

Traditional Software

Development

Software Evolution

Software Degradation


Quality

Time

Dead Software

Alive Software

Importance of Evolution

� Organizations have huge investments in their software systems - they are critical business assets.

� To maintain the value of these assets to the business, they must be changed and updated.

� The majority of the software budget in large


� The majority of the software budget in large companies is devoted to evolving existing software rather than developing new software.

� Studies indicate that up to 75% of all software professionals are involved in some form of maintenance/evolution activity

A Short History

� 1960s – 1970s� Inclusion of maintenance in waterfall lifecycle after delivery of the software product.

� Perception that post-delivery activities only consisted of bug fixes and minor adjustments.

� Did not account for the need to add functionality due to new and changed requirements.

� 1970s


� 1970s� Lehman postulated the initial laws of program evolution.� Stressed the need for continuous evolution due to changes in the software’s operational environment.

� Late 1970s – 1980s� Initial process models that handled change requests.

� 1990s� General acceptance of software evolution.� Development of new process models that accounted for evolution activities: evolutionary development, spiral model, agile software development.

Lehman‘s „Laws“ of Evolution (1)

� Continuing change� A program that is used in a real-world environment necessarily must change or become progressively less useful in that environment.

� Increasing complexity� As an evolving program changes, its structure tends to become more complex. Extra resources must be devoted to preserving and simplifying the structure.


simplifying the structure.

� Large program evolution� Program evolution is a self-regulating process. System attributes such as size, time between releases and the number of reported errors is approximately invariant for each system release.

� Organisational stability� Over a program’s lifetime, its rate of development is approximately constant and independent of the resources devoted to system development.

Lehman‘s Laws of Evolution (2)

� Conservation of familiarity� Over the lifetime of a system, the incremental change in each release is approximately constant.

� Continuing growth� The functionality offered by systems has to continually increase to maintain user satisfaction.


maintain user satisfaction.

� Declining quality� The quality of systems will appear to be declining unless they are adapted to changes in their operational environment.

� Feedback system� Evolution processes incorporate multi-agent, multi-loop feedback systems and you have to treat them as feedback systems to achieve significant product improvement.

Task 2. Lehman’s Laws


Software Evolution Processes

� Evolution processes depend on

� The type of software being maintained;

� The development processes used;

� The skills and experience of the people involved.

� Proposals for change are the driver for system


� Proposals for change are the driver for system evolution. Change identification and evolution continue throughout the system lifetime.

Change Identification and Evolution

Change identification process


New system Change proposal

Software evolution process

Taken from Sommerville 8ed

Change Prediction

� Change prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs� Change acceptance depends on the effort required to modify the components affected by the change

� Requires techniques such as


� Requires techniques such as� Impact analysis

� to predict which components will be affected by the change

� Effort estimation

� to predict the effort it will take to modify these components

� depends on the "quality" of these components

� Cost estimation

� to predict the total cost to implement the change

Change Prediction

� Problem: Software engineers are lousy in predicting which classes will change upon evolution

� Empirical study of [Lindvall&Sandahl1998]: only between 30% and 40% of actual changed classes were predicted to be changed!


changed!

� Need for a more objective approach for identifying evolution-prone parts of a software system

� e.g. software metrics (see next week)

The System Evolution Process

Change request Release planningImpact analysisChange

System release


Change request Release planningImpact analysisChange

implementationSystem release

Fault repairPlatform adaption

System enhancement


Change Impact Analysis

� Definition [Bohner&Arnold 1996]

� The activity by which the programmers assess the extent of a change, i.e., the components that will be impacted by the change.

� Change impact analysis indicates how costly the change is


� Change impact analysis indicates how costly the change is going to be (cf. effort estimation) and whether it is to be undertaken at all.

Change Implementation

Proposed changesRequirements Requirements Software


Proposed changesRequirements updating

Requirements analysis

Software development


Legacy Systems

� If we talk about software evolution, we also have to talk about legacy systems

� Legacy systems: old computer-based systems, which are still in use by organizations


are still in use by organizations� Many of them still business critical

� Incorporate many changes made over the years

� Many people have been involved in these changes

� Replacing legacy systems with new systems is risky, yet keeping them means new changes become more and more expensive

And have to be maintained

Legacy Systems

� For many systems, the software evolution process is not as straightforward as described.� Associated models and documentation of the software may be missing or hopelessly outdated.

� The new requirements may not be anticipated by the design of the software, making the resulting changes difficult to implement correctly.

� Legacy systems are old systems that have become significantly


� Legacy systems are old systems that have become significantly difficult to modify.� Accumulation of changes have eroded the modularity of the original design.� The documentation has not been maintained and has become obsolete.� One or more pieces of its underlying technologies have become obsolete.

� Two complementary techniques are employed to support the continued evolution of legacy systems:� Reverse engineering.� Reengineering

Obsolete System Components

� Hardware - may be obsolete mainframe hardware.

� Support software - may rely on support software from suppliers who are no longer in business.

� Application software - may be written in obsolete programming languages.


programming languages.

� Application data - often incomplete and inconsistent.

� Business processes - may be constrained by software structure and functionality.

� Business policies and rules - may be implicit and embedded in the system software

Legacy Systems Risks

� Risks of replacing a legacy system:

� Specification is difficult because existing documentation is typically incomplete

� Changing business processes (now adjusted to the system) may entail high costs


may entail high costs

� Undocumented, yet important business rules may be embedded in the system; a new system may break these rules

� The new system may be delivered late, may cost more than expected, and may not function properly

Legacy System Change Cost

� Factors that make changes to legacy systems expensive:

� In large systems, different parts were implemented by different teams, without consistent programming style

� It is difficult to find personnel who knows the obsolete programming languages used in old systems


� In may cases the only documentation is provided by the source code; even this may be missing

� It is difficult to understand the system given its ad hocupdating over the years

� Data used by the system is difficult to understand and manipulate; it can also be obsolete and/or redundant

Reverse and Re-Engineering

� “Forward Engineering is the traditional process of moving from high-level abstractions and logical, implementation-independent designs to the physical implementation of a system.”

� “Reverse Engineering is the process of analyzing a subject system to identify the system’s components and their interrelationships and create representations of the system in another form or at a higher


create representations of the system in another form or at a higher level of abstraction.”

� “Reengineering ... is the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form.”

Chikofsky and Cross [R.S. Arnold, Software Reengineering, IEEE CS Press, 1993]

Program Comprehension

� Typical Methods� Source code analysis

� Tools

� Sotograph

� Understanding an existing program in order to change it.� Necessary to be able to do changes to a program


� Source code analysis

� Metrics

� Visualization tools

� Runtime analysis

� Performance analysis

� Design and architecture analysis

� …

� Sotograph

� Metric

� Checkstyle

� CodeCrawler

� …


� New approaches� Analyse the evolution of the software

� Mining source code repositories, including bug databases, documentation, etc.

Purpose


� Purpose� Analyse how the software became what it is today

� Detect hidden dependencies

� At which time (weekdays, phases, …) where most errors checked in

�Who checked in most errors

�Which modules where checked in together

� How did decays become


� A hot topic in evolution research

� Tom Mens, University of Mons-Hainut� Empirical studies of software evolution

� Mining software repositories


� Mining software repositories

� Semantic change analysis

� H. Gall, University of Zurich� Mining software repositories

� Release history analysis

� The Evolizer tool

Task 3. Program Comprehension


Program Transformation

� Program transformation is the act of changing one program into another.

� The term program transformation is also used for a formal description of an algorithm that implements


formal description of an algorithm that implements program transformation.

Program Transformation

� Distinguish two main scenarios� ones where the source and target language are different (translations)

� One where the source and target language are the same (rephrasings).


� Translations� Program Migration, Reverse Engineering, ..

� Rephrasings� Reengineering, Refactoring, …

Novel Trends In Software Evolution

� Two aspects of software evolution research

� Reverse engineering and reengineering techniques

� Techniques for dealing with change

� Process and change management


� Process and change management

� Evolution of software artifacts

Two aspects of software evolution

� “What and why”

� Focuses on software evolution as a scientific discipline.

� Studies the nature of the software evolution phenomenon to understand its driving factors.

� Key interests include the formulation and refinement of fundamental theories and laws of software evolution.


theories and laws of software evolution.

� “How”

� Focuses on software evolution as an engineering discipline.

� Studies how to support the daily tasks of the software developer or project manager.

� Key interests include the development and validation of tools and techniques to guide, implement and control software evolution.

Techniques for dealing with change

� Program comprehension� Understanding the existing program in order to change it.

� Change impact analysis� Identification of the parts of the system that will be affected by a proposed change.

� Change propagation� Making sure that all affected parts are changed correctly.


� Making sure that all affected parts are changed correctly.

� Restructuring/Refactoring� Improving the software structure or architecture without changing the behavior.

� Regression testing� Efficiently verifying that the change preserved the behavior of functionalities that should not be impacted.

� Program transformation� One or multiple modifications applied to a program

Management

� Economics of software evolution� Developing economic models to support evolution-related management decisions.

� Comparing the cost of different strategies for changes.

� Assessing the cost-benefits of investing in reengineering.

� Software metrics


� Software metrics� Measuring the quality of a change.

� Measuring the degree of modularity.

� Configuration management� Change management processes.

� Management of multiple versions.

� Merging versions together.

� Release management.

Evolution of software artifacts

� Requirements evolution� Managing requirements changes.

� Architecture evolution� Reengineering the architectures of legacy systems.� Migration to distributed architectures, e.g., service-oriented architectures.Maintenance issues with modern architectures.


� Maintenance issues with modern architectures.

� Design evolution� Evolution of design models.

� Test case evolution� Adding and modifying test cases to verify that the system behavior was changed as intended.

� Traceability management� How to assure the consistency of the different artifacts.

Other evolution issues

� Data evolution� Migrating to a new database schema.

� Verifying that the information in the existing databases are preserved.

� Runtime evolution


Runtime evolution� How to modify a system without stopping it.

� Encompasses runtime reconfiguration, dynamic adaptation, dynamic upgrading.

� Language evolution� Dealing with changes in the programming language definition.

� Especially an issue in multi-language systems.

� Designing languages to make them more robust to evolution.

Summary

� Evolution is the set of activities, both technical and managerial, that ensures that software continues to meet organizational and business objectives in a cost effective way.

� Evolution is driven by requests for changes from


� Evolution is driven by requests for changes from system stakeholders

� Evolution addresses development, maintenance and retirements

� and it is a cool topic ☺

Some Further Resources

� The Software Evolution wiki site

� http://www.planet-evolution.org/

� The ERCIM Software evolution home page

� http://wiki.ercim.org/wg/SoftwareEvolution/index.php/Main_Page

� Lehman’s FEAST project


� Lehman’s FEAST project

� http://www.doc.ic.ac.uk/~mml/feast2/

� Program transformation wiki site

� http://www.program-transformation.org/Transform/WebHome

Retrospective

� Give your feedback

� Goto to http://wiki.hsr.ch/MasterModulSEA/wiki.cgi?Lesson10Retrospective


Date post:	13-Aug-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Software Engineering & Architecture · Show the shift from the classical software development and...

Documents