Proc. of 1994 ICSE By David Parnas

1. Proc. of 1994 ICSE By David Parnas Software Aging Proc of 1994 ICSE – David Parnas Presented by Preethi Mahadev Date 03/07/2003

2. Who is Parnas? • David Lorge Parnas received his B.S., M.S. and Ph.D. in Electrical Engineering - Systems and Communications Sciences from Carnegie Mellon University. • Professor Parnas is the author of more than 200 papers and reports. • He won an ACM "Best Paper" Award in 1979, and two "Most Influential Paper" awards from the International Conference on Software Engineering. • He was the 1998 winner of ACM SIGSOFT's "Outstanding Research Award.“ • He received honorary doctorates from the ETH in Zurich and the Catholic University of Louvain in Belgium.

3. What is software aging? • Closely resembles the phenomenon of human aging • Performance of the software system degrades with time • Software Aging cannot be prevented • Software Aging can be slowed down

4. Purpose of this paper • To explain how an abstract mathematical product like software aging can age • To review approaches to deal with it • Treating aged software • Slowing down the deterioration

5. Reaction of some computer scientists • Software aging doesn’t make sense • “Software is a mathematical product and mathematics don’t decay with time.”

6. Parnas argues “True but not relevant” Why? • Old software has begun to cripple its once proud owners • Many products are now seen as a burdensome legacy from the past • Old softwares have become essential cogs in the machinery of our society

7. Why is Software aging significant? • Growing economic importance of software • Software is the major “capital” of many high tech firms • Software aging is an impediment for further development of the systems

8. Causes of software aging • Lack of movement • Failure to modify software to meet its changing needs • Unless updated, software is considered as old and outdated • Ignorant surgery • Changes made to the current system is harder to maintain • Nobody understands the modified products leads to rapid decline in value of the software

9. Software aging Vs System slow down • Causes of System slow down • Failure to release allocated memory • Files grow and require pruning • Swap space decreases and performance degrades • Analogy: Kidney failure and Dialysis type treatment as solution • Causes of Software aging • Existing software no longer satisfies the owner • Changes made to the software makes it harder to maintain • System degrading in performance can be easily cured than aging

10. The costs of software aging • Inability to keep up: Lose customers because it is difficult to keep up with the market • Reduced performance: Software Aging degrades performance of the system on the whole • Decrease in reliability: Too many errors due to inconsistent changes made

11. Reducing the costs of Software aging • Inexperienced programmers have short term goals • We should look far beyond the first release to the time when the product is old

12. Preventive medicine • “ delay the decay” • Ways of slowing deterioration: • Design for success • Documentation • Second opinions-reviews

13. Design for success is Design for change • Principle to be applied: Object Orientation • We cannot predict actual changes, predictions will be about classes of changes • Confine the probable section of code • Estimate the probability of types of changes

14. Design for success ..contd… • The barriers of ” design for change” • Impatient programmers and managers are more worried about meeting deadlines and starting a new one • Programmers tend to confuse design principles with languages • Code is rarely designed to be easily changed

15. Documentation • Important aspect of software engineering • Inconsistent or inadequate documentation are developed in most cases • Programmers and managers are driven by imminent deadlines • For some, documentation is not interesting  If not documented, we save a little and pay much more in future

16. Second opinions-reviews • Often Commercial programs don’t have adequate review • Many programmers have no professional training, so they neglect documentation and reviews • Much software is produced as cottage industry • Often produced under time pressure • Programmers resent the idea of being reviewed  Every design must be approved by someone whose responsibilities are for long term future of the product

17. Aging is inevitable …Why? • Changes may violate original assumptions • Documentation will never be perfect • There will be Issues that reviewers overlook • The idea of eliminating software aging is not practical

18. Software geriatrics • Prevention is better than cure .But.. • How to deal with already old software? • Stopping deterioration • Retroactive documentation • Retroactive incremental modularization • Amputation • Major surgery-restructuring

19. Stopping deterioration • Reviews must insure consistent changes • New documents must be created and reviewed • Nipping the growth in the bud is by far preferable than retrenchment

20. Retroactive documentation • Often documentation is neglected • Either because of haste to correct problems in software • Or to introduce new features into the software • Side effect of documentation is improvement of software because it reveals bugs, redundancy etc.

21. Retroactive incremental modularization • Each module must comprise of all the programs that are based on a particular design decision • Confining knowledge of a design decision that is likely to change to one module

22. Amputation • Code that is modified so often needs to be cut off from the main code • It can then be replaced by artificial stumps • Amputation is controversial

23. Major surgery -restructuring • Restructure , analyze and get rid of redundant components • Separate versions can be combined by using switches which reduces maintenance costs

24. Planning ahead • A new life style • Imposing standards • Planning for change • Analyze the future changes • Designate a distinct department • No document ? nothing done • Documentation done after shipping the product is usually inaccurat • Retirement savings plan • Make sure that funds and people are available at the right time

25. Barriers to progress The assumptions and attitudes • A 25 year crisis? • Quick and easy solution doesn’t work out, need long term solutions • “Our industry is different” • Very little cross communication between industries • Intellectual isolation is inappropriate and costly • Where are the professionals • The idea that anyone can code is not professional • Talking to ourselves • Researchers should broaden the audience beyond their colleagues

26. Conclusions for our profession • We cannot assume that the old stuff is known and didn’t work • We cannot assume that the old stuff will work • We cannot ignore the splinter software engineering groups • Model products are a must for others to imitate • We need professional standards and identity

27. Patriot missile failure • Failed to intercept an incoming Iraqi scud missile • An inaccurate calculation of the time since boot due to computer arithmetic errors • Calculation was performed using 24 bit fixed point register • Bad time calculation had been improved only in some parts of the code • Software rejuvenation method: Switch the system on and off every 8 hours to regain clean internal states

28. Discussions..comments…