Group:
program proving
Group:
security
Topic:
automated tests of specifications and designs
Topic:
Cleanroom software development
Topic:
constructing proof and program together
Topic:
error safe systems
Topic:
hard real time systems
Topic:
programming as mathematics
Topic:
safe use of pointers
Topic:
safety critical systems
Topic:
software review
| |
Summary
Some researchers believe we should write programs that don't need testing; others believe that this is an unrealistic goal.
The compromise used in Thesa is to hopefully reduce the possible causes of errors to design errors, and to create systems which tolerate errors. (cbb 12/89)
Subtopic: no errors 
| Quote: programs should be bug free from the start [»dijkEW10_1972, OK]
| | Quote: debugging tools can not take the place of good programming; programs should be correct to begin with [»millHD_1979]
| | Quote: if a large program is to be correct then the probability that a module is correct must be indistinguishable from 1 [»dijkEW_1976a]
| | Quote: can not find logic errors by testing because they depend on combinations of circumstances; should make testing unnecessary [»jackMA_1975]
| | Quote: faith in a program depends on the original thought processes; any error undermines this faith [»millHD6_1975]
| | Quote: professional programmers can consistently write error-free programs; errors will be rare [»millHD6_1975]
| | Quote: for reliable software need to write programs so that obscure bugs don't happen [»cbb_1980, OK]
|
Subtopic: errors as testing failed
| Quote: testing should provide evidence of correctness; errors indicate a failure that may require restarting the testing process [»hennMA3_1984]
|
Subtopic: reliable library
| Quote: library subroutines are know to be correct; reduces errors from the fallible human element [»wheeDJ6_1949]
|
Subtopic: examples
| Quote: real-time program of 27 KLOCs with two customer-reported failures in first full year of continuous operation [»postRM5_1987, OK]
| | Quote: a book on how to write good, understandable programs that are correct the first time [»ledgHF_1975]
| | Quote: near zero software failures by testable requirements, testable software, designing tests before coding, design and code reviews [»postRM5_1987]
| | Quote: 1509 pages of program design for 700 pages of test plans, 25k of FORTRAN and assembly code, 25k of comments [»postRM5_1987]
| | Quote: independent testing found a bug only after severely straining the system [»postRM5_1987]
| | Quote: after continuous operation of software at nine additional sites, 11 failures were reported [»postRM5_1987]
|
Subtopic: Cleanroom development
| Quote: Cleanroom focus on error prevention by formal design methods and mathematics-based verification; halves error rate [»millHD9_1987]
| | Quote: Cleanroom is for highly reliable software via formal specification and design non-execution program development, and statistical testing
| | Quote: Cleanroom teams met requirements better and passed more test cases; all intermediate deliveries were on schedule [»selbRW9_1987]
| | Quote: in Cleanroom, the primary function of testing is to certify code, not debug it; reject if 7-8 errors/KLOC [»lingRC10_1988]
| | Quote: in Cleanroom, the team's goal was error-free code for an increment; occurred many times; high satisfaction and motivation [»lingRC10_1988]
| | Quote: under Cleanroom, high quality code rapidly becomes error free; expect defect free within a day or two of first execution [»lingRC10_1988]
|
Subtopic: failure is necessary
| Quote: no matter what is done, small mistakes with large consequences will still occur; prolonged field testing is necessary for a payment system [»andeRJ5_1996]
| | Quote: an untested program does not work [»stroB_1991]
| | Quote: make programs as fast as possible with acceptable correctness; or as correct as possible with acceptable speed [»stoyJE3_1972]
| | Quote: in practice, can not design and verify a program to work the first time
| | Quote: 10% of test cases for boundary and limits, 15% for errors, and 15% for different platforms and performance [»yamaT11_1998]
| | Quote: only through failure can engineers advance the state of the art; success alone gives insufficient information [»abraP12_1986]
| Quote: nothing can prove the absence of bugs; verification can not prevent failures from unforeseen causes
[»abraP12_1986]
|
Related Topics
Group: program proving (10 topics, 311 quotes)
Group: security (23 topics, 874 quotes)
Topic: automated tests of specifications and designs (12 items)
Topic: Cleanroom software development (38 items)
Topic: constructing proof and program together (22 items)
Topic: error safe systems (76 items)
Topic: hard real time systems (64 items)
Topic: programming as mathematics (27 items)
Topic: safe use of pointers (102 items)
Topic: safety critical systems (32 items)
Topic: software review
(80 items)
|
