S

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 30-40 years Air traffic control SCADA – pipeline, process control GIS Why?

Product 10-20 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) 20-30 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

Law Description

Continuing change A 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

Law Description

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 decline unless they are modified to reflect changes in their operational environment.

Feedback system Evolution 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