 CS 5380 Software Engineering Chapter 9 Software Evolution

Cost  Author: 80-90% of cost of organizational software is evolution Chapter 7 - Design and Implementation2

Software Lifetime  Large – military, government, infrastructure  years  Air traffic control  SCADA – pipeline, process control  GIS  Why?  Product  years  What happens after this?  Embedded  Life of the physical product (5-10)  Printer, Car, Insulin Pump Chapter 7 - Design and Implementation3

(Software Lifetime)  Enterprise solutions (Custom)  years  Y2K Chapter 7 - Design and Implementation4

Why Is Software Modified?  Defect fixes  Changing Environment  Hardware  Operating Systems  External interfaces  Software Product - New Versions  New Features  Competitive Pressures  New Market  Sell upgrades  Dedicated Application  Changing business model  Changing environment Chapter 7 - Design and Implementation5

Types of Change  Evolution – ongoing feature change  Repetitive cycles of requirements, design, development, test, delivery  Very common with products  Maintenance – more related to bug fixing, environment change  Sommerville: consequence of no transition from development to subsequent phases Chapter 7 - Design and Implementation6

Cycle  Change requests  Evaluation, prioritization, release plan  Implementation  Release Chapter 7 - Design and Implementation7

Starting Point  Evolution team same as original development team  Can proceed directly to evolution process  Evolution team not involved in original development team  Understand architecture, design, from docs if plan-based development  Understand architecture, design from code, users if not documented Chapter 7 - Design and Implementation8

Starting point challenges  Evolution team is separate, but development team was agile.  Documentation, understanding  Evolution team is agile, but development team was plan based.  Structure for refactoring, regression testing may be weak/missing Chapter 7 - Design and Implementation9

Product Challenges  Downsizing of ongoing development team  Need to retain core knowledge  Temptation may be to remove highest paid people with the most experience  Company takeover  Continuation of development team is important Chapter 7 - Design and Implementation10

Custom Software  Original Development  Contract with finite duration  Challenges  Original developers not available  Documentation not available  Based on old technology (hardware, languages, databases, GUIs)  Result  Modifications made by those who don’t know  Application  Architecture  Technologies  Potential of introduced bugs Chapter 7 - Design and Implementation11

Program Evolution Dynamics  Study of system change  Lehman and others  Lehman’s laws  Apply to large, organizational systems Chapter 7 - Design and Implementation12

Lehman’s Laws Chapter 7 - Design and Implementation13 LawDescription Continuing changeA program that is used in a real-world environment must necessarily change, or else 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. Organizational 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) Chapter 7 - Design and Implementation14 LawDescription Conservation of familiarityOver the lifetime of a system, the incremental change in each release is approximately constant. Continuing growthThe functionality offered by systems has to continually increase to maintain user satisfaction. Declining qualityThe quality of systems will decline unless they are modified to reflect changes in their operational environment. Feedback systemEvolution processes incorporate multiagent, multiloop feedback systems and you have to treat them as feedback systems to achieve significant product improvement.

Software Maintenance  3 types:  Fault repair  Environmental adaption  Functionality addition Chapter 7 - Design and Implementation15

Features Added Later, by Second Team  Author:  Team stability (knowledge)  Poor development practice (if contracted out)  Staff skills (old technologies, languages)  Program age and structure Chapter 7 - Design and Implementation16

Software Reengineering  Why  Reduce risk/cost  Rearchitect for future  Figure 9.11 in text  Steps (some combination used)  Source code translation  Reverse engineer  Program structure improvement  Program modularization  Data reengineering Chapter 7 - Design and Implementation17

Refactoring  Fowler – code smell  Duplicate code (standardize)  Long methods (break apart)  Switch statements (duplication)  Data clumping (encapsulate in objects)  “Speculative” generality (eventually not needed) Chapter 7 - Design and Implementation18

Legacy Systems  Options  Scrap the system (if not contributing)  Leave in place  Reengineer system  Replace with new system Chapter 7 - Design and Implementation19

Examples  Desktop Applications  Microsoft Word  Autodesk  Visio  Web Applications  Google Docs  Facebook  Large System, Custom  Air traffic Control System  Custom Medical Records System Chapter 7 - Design and Implementation20