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