Software Change

1
Software Change

• Strategies
• Software maintenanceCode changes, but
  fundamental structure constant
• Architectural transformationSignificant changes
  to system architecture
• Software re-engineeringModifications so system
  is easier to understand, maintain (not motivated
  by need to add specific functionality)

2
Lehmans Laws

• Change is inevitable
• As systems change, complexity increase
  structure degrades
• In large systems, evolution controlled not by
  management decisions, but by organizational
  factors.
• Evolution is fairly constant, generally unrelated
  to changes in resources
• Rate at which new functionality can be introduced
  limited
• Lehman Belady (1985)

3
Forms of Software Maintenance

1. Repairing software faults
2. Adaptation to new environment
3. Addition/modification of functionality

4
Forms of Software Maintenance

• Repairing software faults (17)
• Adaptation to new environment (18)
• Addition/modification of functionality (65)
• Leintz Swanson (1980)
• also Nosek Palvia (1990)
• Lesson Plan ahead!

5
Spiral Maintenance Model
6
Costs of Software Maintenance

• Higher costs due to
• Team (in)stability
• Contractual failings
• Staff skills
• maintenance is less sexy
• System structure degradation

7
Reaction instead of proaction

• Emergency bug fixes age system unnecessarily fast
• Fixing the fault (at any cost) is highest
  priority
• Cleaning the mess up afterwards ends up as (too)
  low priority

8
Architectural EvolutionCentralized ? Distributed
systems

• Example migration from a (1980s-style)
  centralized to a (modern) distributed system
• Pressures
• Hardware costs mainframes
• User interface expectationsText forms vs. GUIs,
  mice, etc.
• Remote/distributed accessMultiple company sites,
  Internet

9
Architectural EvolutionCentralized ? Distributed
systems

• Keep old system, but wrap new (distributed)
  components around it
• Legacy system stays on legacy environment
• Offloads work, increases traffic support
• Can distribute data processing, UI processing
• see 27.3 for elaboration

10
Legacy Systems

• Old, existing systems that are well-established
  components of business
• Tricky to replace, because
• lack of complete specification
• intertwined with business process
• may include embedded business rules
• replacement software risky

11
Legacy SystemsAssessment

• Options
• Discard
• Continue to maintain
• Transform (improve maintainability)
• Replace

12
Legacy SystemsAssessment

• Assessments
• Low quality, low business valueCandidate for
  discarding
• Low quality, high business valueExpensive to
  maintain transform or replace
• High quality, low business valueNot worth
  attention maintain or discard
• High quality, high business valueIdeal continue
  regular maintenance