Map
Index
Random
Help
Group
th

Group: software maintenance

topics > computer science > Group: programming



Topic:
bug tracking system
Topic:
change notification
Topic:
configuration management
Topic:
merging changes
Topic:
reverse engineering of software
Topic:
revision delta
Topic:
software change management
Topic:
software maintenance and testing of distributed systems
Topic:
software maintenance by patching
Topic:
system builds
Topic:
system integration
Topic:
user maintenance
Topic:
version control
Topic:
version identification
Group:
debugging
Group:
software engineering
Group:
testing
Group:
type checking

Topic:
archives
Topic:
design for change
Topic:
defensive programming
Topic:
error safe systems
Topic:
incremental development
Topic:
information retrieval by cross reference
Topic:
management of large software projects
Topic:
managing a Thesa database
Topic:
open systems
Topic:
programmer productivity
Topic:
programming environment
Topic:
public domain software
Topic:
quality assurance
Topic:
sensitivity of software to change
Topic:
software lifecycle
Topic:
software metrics
Topic:
software management
Topic:
software review
Topic:
team programming
Topic:
test scripts
Topic:
testing testing
Topic:
understanding systems

Summary

Over half of software costs goes into enhancement and system maintenance, yet most of programming methodology is aimed at program development. The best programmers won't touch maintenance because it requires understanding old programs and satisfying unhappy users. There are many user demands but most modifications will cause new user problems. Testing modified software is particularly difficult, if not impossible. In maintenance, there is little room for creative effort, and during maintenance, the system's representation degrades until the system has to be scrapped and a replacement built.

Alternatives are easily modified descriptions, automatic testing aids, and user maintenance with simple inter-user communication. (cbb 5/80)

Subtopic: maintenance is necessary up

Quote: don't live with broken windows; fix bad decisions and poor code; isolate if not enough time [»huntA_2000]
Quote: software requires a lot of maintenance because it is difficult to develop systems which are correct and capable [»millHD_1979]
Quote: despite lots of time spending tidying things, things get in a muddle by themselves [»bateG_1972]
Quote: human errors are intrinsic to being human [»parnDL2_1986]
Quote: err and err and err again, but less and less and less [»knutDE7_1989]
Quote: most software engineering research concerns new system development instead of software maintenance [»klinR2_1979]
Quote: despite the importance of software maintenance, it has second shortest chapter; even less than software cost estimation [»fairRE_1985, OK]

Subtopic: testing is necessary up

Quote: more resources should be spent on testing a system than on constructing the initial implementation [»stroB_1991]
Quote: software maintenance tools must account for the long tails of many usage statistics; these are critical cases that need support the most [»perrDE4_1998]

Subtopic: inspections up

Quote: inspections make code easier to understand and change; 60% of issues concerned maintainability; e.g., coding standards, comments, portability, documentation [»siyH12_2001]

Subtopic: maintenance errors up

Quote: the most expensive errors are maintenance errors; the top 3 due to changing one digit [»weinGM8_1983]
Quote: small changes have high error rates, because they are not taken seriously [»weinGM8_1983]
Quote: a maintenance programmer is more like a brain surgeon than a janitor [»weinGM8_1983]

Subtopic: software complexity up

Quote: a function interface should lead to correct code; avoid multiple returns, error values, and multipurpose functions; allow strong argument validation [»maguS_1993]
Quote: Y2K happened because data processing implemented existing practices w/o date abstractions [»huntA_2000]
Quote: 20% of maintenance cost due to procedure size; optimal size was 44 executable statements [»bankRD11_1993]
Quote: 12% of maintenance cost due to long goto statements to other COBOL paragraphs [»bankRD11_1993]

Subtopic: maintenance as evolution up

Quote: change is the primary agent of faults; large, recent changes are the most likely to fail; frequency of change is a better predictor of faults than size of module or number of developers [»eickSG1_2001]
Quote: adaptive changes add new functionality or supported environments, corrective changes fix faults, perfective changes and reengineering improves software maintenance [»eickSG4_2002]
Quote: software maintenance is really evolution since it is changing a system's attributes and characteristics [»lehmMM11_1982]
Quote: modularity decays; in 1989, the change history clearly separated two clusters of modules; by 1996, these clusters had broken down [»eickSG1_2001]
QuoteRef: brooFP_1975 ;;123 Pascal: "Things are always at their best in the beginning" or CS

Subtopic: types of maintenance up

Quote: software maintenance consists of enhancements (60%), adaptations (20%), and corrections (20%) [»fairRE_1985]

Subtopic: maintenance steps up

Quote: software maintenance consists of understanding the existing software, modifying it, and revalidating it [»boehBW12_1976]
Quote: the main activity of programming is the integration, modification, and explanation of existing programs [»winoT7_1979]

Subtopic: understanding software up

Quote: DRY--don't repeat yourself; every piece of knowledge must have a single representation in a system; knowledge changes too fast to keep multiple copies consistent [»huntA_2000]
Quote: since a successful program will be read more often than written, review and maintenance are at least as important as design [»parnDL12_1994]
Quote: software maintenance requires good documentation [»roycWW8_1970]
Quote: maintenance programmers either systematically learn how a program behaves or learn the system as-needed; the former does better [»littDC12_1987]
Quote: systematic maintenance programmers perform, by hand, extensive symbolic execution of the data flow paths between subroutines

Subtopic: error diagnonsis up

Quote: with a large user base, most field software failures are rediscoveries of previously reported problems [»leeI6_1996]
Quote: a rediscovery of a previously reported problem wastes service resources
Quote: diagnosed 80% of previously discovered software failures with procedure call traces and other code-oriented symptoms [»leeI6_1996]
Quote: enhanced the diagnosis of previously discovered software failures with predefined error values for certain data items

Subtopic: refactoring up

Quote: refactoring takes time and may require throwing out perfectly good code; used for new requirements under extreme programming [»berrDM10_2002]
Quote: transform source code into XML for re-engineering and migration; represents all or part of the abstract syntax tree for multiple languages; expands text six-fold [»mcarG10_2002]
Quote: refactoring is redesign of existing code; fix now instead of later; started with Smalltalk [»huntA_2000]
Quote: a refactoring browser can split up long routines, rename methods and variables, move code with drag and drop; e.g., Brant [»huntA_2000]
Quote: used points-to analysis for type consistency; given a type change, determine all other objects whose type needs to change [»heinN6_2001]

Subtopic: version control up

Quote: every successful major piece of software will be worked on by a succession of programmers and designers, ported to new platforms, adapted to new uses, and reorganized. Must plan for multiple versions [»stroB_1991]
Quote: a typical release of the 5ESS switch is 0.5M lines of new and changed code on a base of 5M lines [»portAA6_1997]
Quote: studied maintenance of a real-time switching system; >10 million noncommented lines of C, new functions every 15 months, 3,000 software and 500 hardware developers [»perrDE7_1994]
Quote: a new feature of a real-time switching system varied from a few lines of noncommented code to 50,000 lines of noncommented code with many complex, specially designed hardware circuits
Quote: in 1989, less than 2% of changes touched multiple files; by 1996, over 5% touched multiple files [»eickSG1_2001]
Note: nothing should happen at an upgrade; everything should work as before despite many changes [»cbb_1990, OK]

Subtopic: maintenance expense up

Quote: maintenance and enhancement takes 40-75% of total software effort [»lienBP6_1978, OK]
Quote: it takes about three times more development resources to modify code than to create new code [»boydRE3_1984]
Quote: system testing, enhancement and adaptation takes three-fourths of total life-cycle effort [»fairRE_1985]
QuoteRef: klinR2_1979 ;;36 "The problem is that most programming work entails maintaining already existing (sometimes archaic) software systems.
Quote: once the Unix network was in use, system maintainers were easily persuaded to keep it running and improve throughput [»nowiDA8_1978]
Quote: DSEE manages over a million lines of code successfully [»leblDB5_1984]
Quote: customer-reported software errors require an average of 4.5 person-days to repair [»russGW1_1991]
Quote: by 1988, Bell-Northern Research had written 15 million lines of code for telecommunication products [»russGW1_1991]

Subtopic: reducing maintenance costs up

Quote: do not hesitate to throw out clumsy software and rebuild it [»mcilMD7_1978]
Quote: 80% of software maintenance on 2% of system; so rewrite that 2%; large reduction in overall maintenance effort [»pariG_1980]
Quote: contract requirement: 90% of bebugged errors fixed in half an hour or less [»pariG_1980]

Subtopic: maintenance problems up

Quote: main obstacle to changing Multics was updating system documentation [»corbFJ_1979]
Quote: with the software life cycle, changes occur reluctantly and in large packets [»mccrDD4_1982]
Quote: in large systems under maintenance, percentage of coding errors to design errors increased; averaged 40:60 for code:design [»boehBW12_1976, OK]
Quote: software repair should be assigned to those with maximum system overview and insight [»belaLA_1979]
Quote: law of conservation of familiarity: the size of each release of an evolving program will be statistically invariant
[»lehmMM9_1980]

Group: software maintenance up

Topic: bug tracking system (34 items)
Topic: change notification (19 items)
Topic: configuration management (25 items)
Topic: merging changes (7 items)
Topic: reverse engineering of software (6 items)
Topic: revision delta (18 items)
Topic: software change management (48 items)
Topic: software maintenance and testing of distributed systems (16 items)
Topic: software maintenance by patching (27 items)
Topic: system builds (43 items)
Topic: system integration (5 items)
Topic: user maintenance (13 items)
Topic: version control (34 items)
Topic: version identification
(12 items)

Related Topics up

Group: debugging   (10 topics, 333 quotes)
Group: software engineering   (18 topics, 470 quotes)
Group: testing   (18 topics, 557 quotes)
Group: type checking   (12 topics, 392 quotes)

Topic: archives (19 items)
Topic: design for change (76 items)
Topic: defensive programming (22 items)
Topic: error safe systems (76 items)
Topic: incremental development (74 items)
Topic: information retrieval by cross reference (7 items)
Topic: management of large software projects (63 items)
Topic: managing a Thesa database (34 items)
Topic: open systems (33 items)
Topic: programmer productivity (57 items)
Topic: programming environment (46 items)
Topic: public domain software (9 items)
Topic: quality assurance (22 items)
Topic: sensitivity of software to change (44 items)
Topic: software lifecycle (13 items)
Topic: software metrics (32 items)
Topic: software management (28 items)
Topic: software review (80 items)
Topic: team programming (7 items)
Topic: test scripts (13 items)
Topic: testing testing (13 items)
Topic: understanding systems
(48 items)


Updated barberCB 1/06
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.