190 likes | 440 Views
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
E N D
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 • Annual growth rate should not exceed 25% to be considered maintenance – rule of thumb • Customers should pay for everything except corrective maintenance
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
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
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?
GEOS Functionality Preserved • QUESTION: What does major reorganization have to do with it? Did the company or the code reorganize?
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
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
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
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
GEOS Avoiding Increasing Volatility • Good example of a highly volatile system • Not successful in controlling volatility
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?
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
GEOS Sustaining User Satisfaction • Unknown at this point
GEOS Covering Costs • Operating at a slight loss • but the author has lots of excuses for this
Grades redux • Functionality - unproven • Quality - C • Complexity – C- • Volatility - D • Costs – C+ • Release Deadlines - C • User satisfaction - unproven • Profitability - D
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
Capitalizing Software • New development can be capitalized (under some accounting systems) • Maintenance cannot be capitalized