Software Maintenance

Software maintenance is most costly phase. 80% of the budget is on maintenance with more than 3/4th engineers involved in maintenance activities.

Maintenance is inevitable for almost any kind of product but software maintenance is not same as hardware maintenance. It is so because software does not deteriorates over time.

Software maintenance is doing anything to software after delivery, typically, after acceptance testing.

Why maintenance cost is high?

  • future maintenance is not kept in mind while developing
  • systems to be maintained are unstructured
  • sometimes, complete development cycle to be executed for the change
    Solution: Follow non-linear life cycle like incremental development as enhancement done in increments is more manageable.

Maintenance Management
  • development consideration: maintenance should be forethought throughout development, IPR, development and maintenance contract. Fixed price vs cost plus contract. Software engineering being new field, this has weakness
  • anticipated life cycles
  • scope of maintenance
  • initial product status
Types of Maintenance
  1. Preventive: during life cycle, extra effort to make it easier to maintain
  2. Corrective: rectify bugs while system is in use
  3. Adaptive: adapting to new platforms, OS, software and hardware interfaces
  4. Perfective: support new features, different functionality demanded by user, performance enhancement
Why maintenance is required?
  • Rate of hardware obsolescence
  • demand of user community to support
    • new platforms
    • new environments
    • enhanced features
  • If software does some low level functions then it must also change with hardware change
  • If support environment changes then software must change for newer itself
  • Software may require change with change of OS
Maintenance Cost Factor = Technical Costs + Non-Technical Costs

Technical Costs = Quality of original product i.e. quality of development (Req Specs, Design, Code, Testing, Documentation

Non-Technical Costs = Applications, changes operating systems, hardware stability, system lifespan

Belady-Lehman Model of Maintenance Effort

M = P + K pow (c-d) where
 P = productive maintenance comprising analysis, coding, design, testing
 c = system complexity (fixes new errors introduced - 1 error for every 6 changes, structure is compromised
 d = familiarity of the staff with the system (new staff, low maintenance profile, specialisation)

  • Maintenance effort M is directly related to amount of maintenance carried out
  • But, exponentially related to system complexity and staff familiarity
Staffing for Software Maintenance Phase
Wrong: No creativity involved so place new staff or lame ducks is wrong and will lead to high maintenance costs
Right: Better have higher rated software engineers who has better understanding of SDLC and will not increase system complexity

Scrap the System?
  • maintenance cost too high
  • product no longer competitive
  • hardware cost is high
  • application environment is disappearing
  • technical viability - compromise performance, compromise reliability
   IBM considers a 12% change to an existing system as cut-off point in deciding to start a fresh

Software Maintenance Phase
  • understand the software
    • If documentation is good then follow Top-Down approach: evaluate design, plan approach, modify design, re-code
    • if no proper documentation then follow Bottom-Up approach: evaluate code, re code
      • if no proper documentation then cost is 4 times higher
  • generate maintenance proposals
  • predict consequences
  • modify code
  • cope with any ripple effect
  • regression test
  • distribute new versions
Retesting the Modified Code
  • Test
    • required change
    • for side effects
    • for degradation in quality
  • Perform Regression Testing
  • Update Regression test suite
   undocumented systems take longer time to change + No test data stored for them implies regression testing is impossible as ripple effect cannot be checked

Maintenance Tools
  • Tools that give information about the code e.g. cross references, flow analysers (data+control)
  • Tools that restructure the badly written unstructured code
  • Reverse Engineering tools that generates design model from code
  • Development tools that are required for new requirements and design needs to be modeled, new code produced and testing e.g. auto code generators
  • Automated Regression Testing tools
Belady and Lehman 3 Laws of Characteristics of Software Evolution
  1.  A software product must change continually or become progressively less useful
  2. The structure tends to degrade as more and more maintenance is carried out
  3. Over a program's lifetime, its rate of development is constant
       Elaboration of Laws:
         1. This is irrespective of how well the system was designed. Remember good products are 
         maintained and bad products are thrown away
         2. Addition to an existing system that is not intended to support it. If system is not re-designed 
         then it will become too complex. Quick fix solutions will only degrade program structure, 
         documentation becomes inconsistent and less helpful
         3. i.e. the rate at which code is written or modified is approximately same during development    
           and maintenance