Software Aging Proc of 1994 ICSE David Parnas

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

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.

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

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

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

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

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

Causes of software aging i. Lack of movement • Failure to modify software to meet its changing needs • Unless updated, software is considered as old and outdated ii. 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

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

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

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

Preventive medicine Ø “ delay the decay” Ø Ways of slowing deterioration: i. Design for success ii. Documentation iii. Second opinions-reviews

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

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

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

Second opinions-reviews i. iii. iv. v. 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

Aging is inevitable …Why? i. iii. iv. 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

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

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

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

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

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

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

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

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

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

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

Discussions. . comments…