1 / 18

Critical Success Factors in Software Maintenance

Critical Success Factors in Software Maintenance. Paper by Sneed & Brossler Presented March 17, 2004 By Alice Lewis. What is Software Maintenance?. Adaptive maintenance Functional maintenance Corrective maintenance Perfective maintenance

orea
Download Presentation

Critical Success Factors in Software Maintenance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Critical Success Factors in Software Maintenance Paper by Sneed & Brossler Presented March 17, 2004 By Alice Lewis

  2. What is Software Maintenance? • Adaptive maintenance • Functional maintenance • Corrective maintenance • Perfective maintenance • Annual growth rate should not exceed 25% to be considered maintenance – rule of thumb • Customers should pay for everything except corrective maintenance

  3. Various Types of Systems • e-type – growth rate greater than 10% per annum • s-type – growth rate is less than 10% per annum – equivalent to Rajlich and Bennett’s definition of maintenance • p-type – no maintenance - throwaway

  4. Eight Success Factors Taken from ICSM 1996 • Functionality is preserved • Quality of system is not diminished • Complexity of system relative to size is not increased • Product is not more volatile • Costs per maintenance task is not increased for similar tasks • Release deadlines are kept with no increase in delays • User satisfaction rate should not decrease • Maintenance operation should be profitable or at least break-even

  5. GEOS Functionality Preserved • All functional test cases must pass and results must compare favorably with the last release • How does this prove that functionality is preserved? All it proves is that all test cases still pass – did you really have a test case for each possible combination of each aspect of functionality? • “Thus one can assume that this criteria has been fulfilled” • Static source and test case comparison • How does this prove that functionality is preserved? All it proves is that only code that should have changed actually did change – are you really sure you know what each piece of code does and doesn’t do?

  6. GEOS Functionality Preserved • QUESTION: What does major reorganization have to do with it? Did the company or the code reorganize?

  7. GEOS Preserving Quality • Reliability • defect rates: • Year: #errors: size: density: • 1999 644 92079 .007 • 2000 872 108006 .008 • 2001 612 153830 .004 (2x better!) • 2002 1048 160936 .007

  8. GEOS Preserving Quality, Take 2 • Reliability • defect rates: • Year: #errors: size diff: diff.density: • 1999 644 92079 .007 • 2000 872 15927 .055 • 2001 612 45824 .013 • 2002 1048 7106 .147

  9. GEOS, Preserving Quality • Response time – • Why not compare the response time increase with the increase in hardware response in general to see if response time may actually have decreased? • Construction quality – • unfamiliar with this term – median quality coefficient of a bunch of -abilities

  10. GEOS Controlling Complexity • Micro complexity rate is decreasing • Macro complexity rate is increasing twofold • to be expected? • a matter of concern but typical of a rapidly evolving system • Not clear that this is successful

  11. GEOS Avoiding Increasing Volatility • Good example of a highly volatile system • Not successful in controlling volatility

  12. GEOS Controlling Costs • Same amount of productivity per day • but the claim is that quality has increased in code as well as documentation (when did this happen?) • were there no tools introduced to increase programmer productivity?

  13. GEOS Keeping Regular Releases • Without knowing release process, it’s difficult to judge this one • What does “system has matured” mean? The author still believes that it is highly volatile and is still not the right product • It would be easy to be successful on this one if the release schedule was chosen prudently

  14. GEOS Sustaining User Satisfaction • Unknown at this point

  15. GEOS Covering Costs • Operating at a slight loss • but the author has lots of excuses for this

  16. Grades redux • Functionality - unproven • Quality - C • Complexity – C- • Volatility - D • Costs – C+ • Release Deadlines - C • User satisfaction - unproven • Profitability - D

  17. Case Study Comments • Amazing that this data exists over the entire 5 years • Inspiring that the entire study was put together • Many “results” are squishy and anecdotal – don’t really have numbers to back them up, but only assumptions and comments • More work needs to take place in this area so that results are accepted as industry standards

  18. Capitalizing Software • New development can be capitalized (under some accounting systems) • Maintenance cannot be capitalized

More Related