proc. of 1994 icse by david parnas software aging proc of 1994 icse – david parnas presented by...
Post on 21-Dec-2015
230 views
TRANSCRIPT
Proc. of 1994 ICSE By David Parnas
Software Aging
Proc of 1994 ICSE – David Parnas
Presented by 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 preventediii. 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 ownersii. Many products are now seen as a
burdensome legacy from the pastiii. 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 memoryii. Files grow and require pruningiii. Swap space decreases and performance
degrades
Analogy: Kidney failure and Dialysis type treatment as solution
Causes of Software aging i. Existing software no longer satisfies the ownerii. Changes made to the software makes it harder
to maintain
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 successii. Documentationiii.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… The barriers of ” design for change”
i. 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. Important aspect of software engineeringii. 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-reviewsi. Often Commercial programs don’t have adequate
reviewii. Many programmers have no professional training,
so they neglect documentation and reviewsiii. Much software is produced as cottage industryiv. Often produced under time pressurev. 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. Changes may violate original assumptions
ii. Documentation will never be perfectiii. There will be Issues that reviewers
overlook iv. 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. Stopping deteriorationii. Retroactive documentationiii. Retroactive incremental modularizationiv. Amputationv. 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. Often documentation is neglected• Either because of haste to correct
problems in software• Or to introduce new features into the
software
ii. 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?• Quick and easy solution doesn’t work out, need
long term solutions
ii. “Our industry is different”• Very little cross communication between
industries• Intellectual isolation is inappropriate and costly
iii. Where are the professionals• The idea that anyone can code is not
professional iv. Talking to ourselves
• 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