Software Engineering & Architecture

Transcription

1 Software Engineering & Architecture 10. SOFTWARE EVOLUTION Martin Kropp University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems

2 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 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,

3 Learning Targets You 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 3

4 Content Software Evolution Evolutionary Processes Legacy Systems Program Comprehension Program Transformation Other Trends in Software Evolution 4

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

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

7 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 Why and how does Software get old? And How can we keep software fit? 7

8 Task 1 Software Aging DOS: MS Office: Dec VMS: 8

9 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 David L. Parnas in Software Aging [Parnas 1994] 9

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

11 Ignorant Surgery The changes of the software itself Changes break original design Software gets bigger and slower Software get more complex Software is more expensive to change New bugs are injected Documentation becomes outdated 11

12 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 Poor design decreases performance Decreasing reliability As the software is maintained, errors are introduced 12

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

14 Maintenance vs. Evolution Software maintenance = the activities of changing the system after it has been delivered Software evolution = the process of continuous software change from the very beginning Evolution Maintenance 14

15 Goal of Software Evolution Traditional Software Development Software Evolution Software Degradation Quality Alive Software Dead Software Time 15

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

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

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

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

20 Task 2. Lehman s Laws 20

21 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 evolution. Change identification and evolution continue throughout the system lifetime. 21

22 Change Identification and Evolution Change identification process New system Change proposal Software evolution process Taken from Sommerville 8ed 22

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

24 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! Need for a more objective approach for identifying evolution-prone parts of a software system e.g. software metrics (see next week) 24

25 The System Evolution Process Change request Impact analysis Release planning Change implementation System release Fault repair Platform adaption System enhancement Taken from Sommerville 8ed 25

26 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 going to be (cf. effort estimation) and whether it is to be undertaken at all. 26

27 Change Implementation Proposed changes Requirements analysis Requirements updating Software development Taken from Sommerville 8ed 27

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

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

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

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

32 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 hoc updating over the years Data used by the system is difficult to understand and manipulate; it can also be obsolete and/or redundant 32

33 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 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] 33

34 Program Comprehension Understanding an existing program in order to change it. Necessary to be able to do changes to a program Typical Methods Source code analysis Metrics Visualization tools Runtime analysis Performance analysis Design and architecture analysis Tools Sotograph Metric Checkstyle CodeCrawler 34

35 Program Comprehension New approaches Analyse the evolution of the software Mining source code repositories, including bug databases, documentation, etc. 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 35

36 Program Comprehension A hot topic in evolution research Tom Mens, University of Mons-Hainut Empirical studies of software evolution Mining software repositories Semantic change analysis H. Gall, University of Zurich Mining software repositories Release history analysis The Evolizer tool 36

37 Task 3. Program Comprehension 37

38 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 program transformation. 38

39 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, 39

40 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 Evolution of software artifacts 40

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

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

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

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

45 Other evolution issues Data evolution Migrating to a new database schema. Verifying that the information in the existing databases are preserved. 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. 45

46 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 system stakeholders Evolution addresses development, maintenance and retirements and it is a cool topic 46

47 Some Further Resources The Software Evolution wiki site The ERCIM Software evolution home page Lehman s FEAST project Program transformation wiki site 47

48 Retrospective Give your feedback Goto to n10retrospective 48