Proc. of 1994 ICSE By David Parnas - PowerPoint PPT Presentation

Loading...

PPT – Proc. of 1994 ICSE By David Parnas PowerPoint presentation | free to download - id: 7e793-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Proc. of 1994 ICSE By David Parnas

Description:

Professor Parnas is the author of more than 200 papers ... Software geriatrics. Prevention is better than cure .But.. How to deal with already old software? ... – PowerPoint PPT presentation

Number of Views:33
Avg rating:3.0/5.0
Slides: 30
Provided by: pree152
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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 doesnt make sense
  • Software is a mathematical product and
    mathematics dont 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?
  1. Growing economic importance of software
  2. Software is the major capital of many high tech
    firms
  3. 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
  1. Inability to keep up Lose customers because it
    is difficult to keep up with the market
  2. Reduced performance Software Aging degrades
    performance of the system on the whole
  3. 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 dont 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?
  1. Changes may violate original assumptions
  2. Documentation will never be perfect
  3. There will be Issues that reviewers overlook
  4. 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 doesnt 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
  1. We cannot assume that the old stuff is known and
    didnt work
  2. We cannot assume that the old stuff will work
  3. We cannot ignore the splinter software
    engineering groups
  4. Model products are a must for others to imitate
  5. 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
29
(No Transcript)
About PowerShow.com