Map
Index
Random
Help
Topics
th

Topic: sensitivity of software to change

topics > computer science > Group: systems



Group:
software maintenance

Topic:
abstraction
Topic:
change
Topic:
defensive programming
Topic:
design for change
Topic:
discrete vs. continuous
Topic:
error safe systems
Topic:
handling complexity
Topic:
hardware vs. software
Topic:
interface between program modules
Topic:
separate a module's interface specification from its implementation
Topic:
software change management
Topic:
testing by program mutation
Topic:
what is a computer

Subtopic: software difficult to change up

Quote: 2nd-5th graders felt it was too difficult to make changes to their KIDSIM science models
Quote: a library of subroutines may be difficult to change [»utleAM6_1949]
Quote: use the same order code for new machines since the library of subroutines may be as valuable as the machine itself

Subtopic: connections between modules up

Quote: measure system complexity by the percentage of modules impacted by a change in one module [»belaLA_1979]
Quote: analyze connections between modules to predicate the total number of changes required to change a set of modules [»haneFM_1972, OK]
Quote: connections between modules are their assumptions about each other; generally more than calling sequences [»parnDL8_1971]
QuoteRef: chanRN_1974 ;;10 Measure structure by the assumptions each portion makes on the data objects environment, algorithms

Subtopic: dependencies up

Quote: with MicroTool, difficult to modify a name's definition since its references may become inconsistent; produces an error [»elshJL1_1991]

Subtopic: increasing complexity up

Quote: law of increasing complexity of an evolving program due to deteriorating structure; must be actively corrected [»lehmMM9_1980]
Quote: the un-structuredness of a system (its entropy) increases with time unless work to reduce it [»belaLA3_1976]
Quote: software complexity grows unless the software is restructured, either periodically or continuously [»belaLA_1979]
Quote: without attention, the structure of an evolving program deteriorates and its complexity increases [»lehmMM3_1981]
Quote: each release of OS_360 had the same amount of modification but effected more modules; last releases effected most modules [»belaLA10_1980]
Quote: modularity decays; in 1989, the change history clearly separated two clusters of modules; by 1996, these clusters had broken down [»eickSG1_2001]

Subtopic: old software up

Quote: old changes are difficult to reverse; early decisions should be least likely to change, based on universal truths [»parnDL8_1971]

Subtopic: need to rewrite system up

Quote: plan to throw one away: because of continuous change, it is eventually cheaper to recreate a system [»brooFP_1975]
Quote: a system that is used undergoes continuing change; eventually better to freeze and recreate it [»belaLA3_1976]
Quote: despite lots of time spending tidying things, things get in a muddle by themselves [»bateG_1972]
QuoteRef: brooFP_1975 ;;123 Pascal: "Things are always at their best in the beginning" or CS
Quote: change or keep a program until it is cheaper to rewrite it
Quote: a program that reflects some other reality must change continuously or become less useful; eventually need to rewrite [»lehmMM3_1981]

Subtopic: problem of traceability up

Quote: machine code programming allows any change; errors may be hard to trace, especially with index registers [»hoarCA_1974]
Quote: problem of traceability--how does change in one software artifact (requirement, design, code) affect other artifacts [»clarS11_1999]

Subtopic: change causes bugs 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: while not serious, the number of files touched by a change is a symptom of error-proneness [»eickSG1_2001]

Subtopic: bugs causing bugs up

Quote: 40% of changes to fix errors introduced more errors [»puruR6_2005]
Quote: software repair should be assigned to those with maximum system overview and insight [»belaLA_1979]
Quote: in most cases, the cause of a software product failure was introduced while fixing another failure [»cobbRH11_1990]
Quote: unit verification by debugging may cause design faults when the fixed modules are combined [»cobbRH11_1990]

Subtopic: sensitivity to change up

Quote: software is not soft; to change a system's behavior requires major reprogramming [»fishG7_1987]
Quote: in a digital device, changing a single bit can have drastic consequences; a radical novelty of computers [»dijkEW12_1989]
Quote: a randomly altered program rarely serves a useful function; unsuited to evolution [»conrM5_1985]
Quote: unlike physical systems, software is not continuous; small changes can cause large failures; small requirement changes can cause large design changes [»wegnP_1979a]
Quote: a trivial, minute change can wreak havoc in a massive system; like the time traveler who damages a butterfly [»demiRA5_1979]
Quote: apparently innocuous changes to a program can have surprising and disastrous effects [»jackMA_1975]
Quote: constructing stable software is like constructing a skyscraper that depends on every detail fitting exactly [»fairRE_1985]
Quote: the idea of tolerances does not apply to software; the building blocks are absolute [»dijkEW_1982]

Subtopic: continuous vs. discrete up

Quote: analog systems can be reliable because they are continuous; small input changes cause small output changes [»parnDL12_1985]
Quote: in physics, action has local effects (e.g., inverse square law); in computation, a tiny program can clear all of memory [»hillWD_1985]

Subtopic: independent parts up

Quote: variables, arrays, files splits a machine into disjoint areas; updating one does not effect the others [»hoarCA_1974]

Subtopic: maintaining good structure despite change up

Quote: a system must maintain its good structure despite an unending sequence of changes [»belaLA_1979]
Quote: after each pseudocode refinement, measure its complexity to evaluate the programming process; called the Partial_Metrics_system [»reynRG11_1987]
Quote: systems built under Mesa will usually remain reliability after changes to interfaces [»laueHC_1979]

Subtopic: fixing software OK up

Quote: did not find error corrections to software causing new errors; could be result of experience or of monitoring development [»weisDM2_1985]


Related Topics up

Group: software maintenance   (14 topics, 368 quotes)

Topic: abstraction (62 items)
Topic: change (28 items)
Topic: defensive programming (22 items)
Topic: design for change (76 items)
Topic: discrete vs. continuous (47 items)
Topic: error safe systems (76 items)
Topic: handling complexity (60 items)
Topic: hardware vs. software (15 items)
Topic: interface between program modules (55 items)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: software change management (48 items)
Topic: testing by program mutation (18 items)
Topic: what is a computer
(62 items)


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