Software Maintenance and Program Evolution

Software Maintenance

• Software change is unavoidable due to emerging new requirements, changing business environments, error correction, new equipment, and performance/reliability improvements
• A key issue for organizations is managing change to legacy systems
• Software maintenance strategies include:
  • Software Maintenance: Changes are made in response to changing requirements, but the fundamental software structure remains stable. Maintenance does not typically involve major architectural changes.
  • Software Re-engineering: The software is restructured and reorganized without adding new functionality, facilitating future changes.
  • Architectural Transformation: The system's architecture is modified, often from a centralized to a distributed architecture.
  • These strategies can be applied separately or together

Program Evolution Dynamics

• Program evolution dynamics is the empirical study of the process of system changes
• Lehman and Belady's research proposed "laws" applicable to all evolving systems, which show sensible observations rather than strict laws
• The observed laws are mostly applicable to large systems developed by large organizations. Observed laws might have lesser applicability in other cases

Lehman's System Types

• S-system: Formally defined, derivable from a specification (e.g., matrix manipulation)
• P-system: Requirements based on approximate solutions to problems, remaining stable in the real world (e.g., chess)
• E-system: Embedded in the real world, and changes as the world does (e.g., software to predict economic functions)

Changes During System Life Cycle

• S-system: Unchanged
• P-system: Incremental change (approximate solution, change with identified discrepancies or omissions)
• E-system: Constant change

Examples of Change During Software Development

• The text lists various development activities (e.g., requirement analysis, system design, program implementation) and the associated artifacts that need changes as a result

Lehman's Laws

• Continuing change: Programs used in real-world environments often need changes to remain useful
• Increasing complexity: Program structure tends to become more complex as the program evolves
• Large program evolution: System attributes (size, release time) are approximately constant across releases
• Organizational stability: The rate of program development is relatively constant over its lifetime
• Conservation of familiarity: Incremental change in each release is approximately constant throughout the program's life
• Continuing growth: System functionality needs to continually increase to maintain user satisfaction
• Declining quality: System quality appears to decline without adaptation to operational changes
• Feedback system: Evolution incorporates multi-agent, multi-loop feedback systems to improve the program

System Maintenance vs. Decline

• Issues that indicate a system needs maintenance or is declining:
  • Cost of maintenance is too high
  • System reliability is unacceptable
  • System cannot adapt to changes in a reasonable time frame
  • System performance is beyond acceptable constraints
  • System functions have limited usefulness
  • Other systems can perform the same job better, faster, or cheaper
  • Hardware replacement costs exceed the system maintenance cost

Nature of Maintenance Types

• Corrective: Maintains control over day-to-day tasks
• Adaptive: Maintains control over system modifications
• Perfective: Improves existing functions
• Preventive: Prevents system performance from degrading to unacceptable levels

Who Performs Maintenance

• Separate maintenance team: More objective, better at distinguishing intended functionality from actual functionality
• Development team part: Will build the system in a way that makes maintenance easier (but, sometimes ignore documentation)

Skills of the Maintainer

• Novice: Basic language expertise and program understanding
• Expert: Has language expertise, domain expertise, comprehension strategies, and specific program expertise

Information Needs

• Domain expert's view: Concepts of the domain, relations, scope, and boundaries, and program goals
• User's view: Constraints, size, timing, operations, installation
• Programmer's view: Dependencies, program parts, algorithms, representations, resource allocation

Information Sources

• Programmer's knowledge
• Code
• Documentation
• Colleagues on the project

Maintenance Team Responsibilities

• Program Comprehension: Understand the system
• Traceability: Locate information in system documentation
• Performing required changes: Extending existing functions, adding new functions, locating failures/problems, correcting faults, restructuring/rewriting design/code, deleting components
• Keeping system documentation up-to-date
• Answering questions about the way the modified system works

Maintenance Problems

• Staff problems: Limited understanding, management priorities, morale issues related to maintenance teams
• Technical problems: System/code structure and paradigms (e.g., legacy code, non-object-oriented code), testing challenges

Causes of Maintenance Problems

• Unstructured code
• Insufficient knowledge about the system and its domain
• Insufficient documentation
• A bad image of the maintenance department

Maintenance Costs

• Usually greater than development costs
• Affected by both technical and non-technical factors
• Increases as software is maintained (software structure decays due to modifications making further maintenance more difficult)
  • Ageing software has high support costs (e.g., old languages, compilers)

Development/Maintenance Costs

• Development costs tend to be lower but increase over time than maintenance costs
• Maintenance costs are typically higher than development costs

Development/Maintenance Costs (Specific Research)

• Parikh and Zvegintzov study noted development times of two years and maintenance time of 5-6 years
• Fjedstad and Hamlen's study found development effort to be at 39% and maintenance effort at 61%
• 80/20 rule: ~80% of effort in maintenance and ~20% in development

Maintenance Cost Factors

• Team stability: Involves the same staff contributing to avoid higher maintenance costs
• Contractual responsibility: Developers might lack responsibility, leading to poor design for future changes
• Staff skills: Often, maintenance staff are inexperienced and lack domain knowledge
• Program age and structure: Older programs often have degraded structures, making them harder to understand and modify

Factors Affecting Maintenance Effort

• Application type
• System novelty
• Turnover and maintenance staff ability
• System life span
• Dependence on a changing environment
• Hardware characteristics
• Design quality
• Code quality
• Documentation quality
• Testing quality