Group: program design
Group: program proving
Group: requirement specification
Topic: constructing proof and program together
Topic: design documentation
Topic: incremental development
Topic: incremental testing
Topic: personal software process (PSP)
Topic: programming without errors
Topic: quality assurance
Topic: requirement specification by diagrams
Topic: requirement specification by function
Topic: software change management
Topic: software management
Topic: software review
Topic: team programming
Topic: statistical testing based on a usage profile
| |
Subtopic: stastical quality control, formal specification, no unit debugging
Quote: Cleanroom develops software incrementally with statistical quality control; if too many errors then improve process [»millHD9_1987]
| Quote: Cleanroom is for highly reliable software via formal specification and design non-execution program development, and statistical testing
| Quote: Cleanroom development with statistical quality control, mathematical verification, no unit debugging, incremental development, change control
| Quote: Cleanroom engineering uses teams for specification, development, and certification [»cobbRH11_1990]
| Subtopic: error free code
Quote: in Cleanroom, the team's goal was error-free code for an increment; occurred many times; high satisfaction and motivation [»lingRC10_1988]
| Quote: Cleanroom focus on error prevention by formal design methods and mathematics-based verification; halves error rate [»millHD9_1987]
| Quote: under Cleanroom, high quality code rapidly becomes error free; expect defect free within a day or two of first execution [»lingRC10_1988]
| Subtopic: top down design with box structures
Quote: a program function transforms input state to output state; a clear box includes its intended function and the intended functions of its refinements [»lingRC5_1993]
| Topic: requirement specification by diagrams
| Quote: Cleanroom uses box structures for specification; before design starts, everyone must agree that the specification is correct [»lingRC10_1988]
| Quote: box structures avoid the ambiguities and omissions for natural language specifications; detects gaps and misunderstandings early [»lingRC5_1993]
| Quote: Cleanroom's development team designs each increment top-down with usage hierarchy, black-box, state-box, and clear-box [»cobbRH11_1990]
| Quote: both data (state-boxes) and process (clear-boxes) views are needed for designing software; related by box structures [»cobbRH11_1990]
| Quote: Cleanroom's black-box view defines system responses in terms of stimuli histories; implementation-independent [»cobbRH11_1990]
| Quote: Cleanroom's development team implements clear boxes by stepwise refinement and verifies each function
| Quote: Cleanroom designs are constructed by decomposing a specified function into control structures and subspecifications; never bottom-up [»lingRC10_1988]
| Quote: Cleanroom's clear-box view defines system responses in terms of lower level black boxes, data abstractions for states, and current stimuli; process-driven [»cobbRH11_1990]
| Quote: Cleanroom's state-box view defines system responses in terms of state data and the current stimuli; data-driven, captures stimuli history [»cobbRH11_1990]
| Quote: a Cleanroom objective was simplifying designs; sometimes achieved a five-fold reduction in size [»lingRC10_1988]
| Subtopic: coding follows design exactly, automated
Quote: coding a Cleanroom design must follow the design exactly
| Quote: Cleanroom designs are mapped statement-to-statement into PL/1; automated [»lingRC10_1988]
| Subtopic: large scale proofs
Quote: using Cleanroom techniques, can construct proof arguments for very large software systems
| Quote: confirm that a program implements an intended function by correctness conditions for sequence, alternation, and iteration [»lingRC5_1993]
| Subtopic: testing in a controlled environment
Quote: programmers in the Coding War Games complained about the total separation of coding and testing; but a third delivered zero-defect products [»demaT5_1989]
| Quote: Cleanroom rejects testing's fundamental purpose: to find bugs [»beizB3_1997]
| Quote: Cleanroom development separates testing from software development; random test cases; should be more reliable [»parnDL6_1990]
| Quote: Cleanroom places programs under engineering change control before first execution; for reliable statistics [»lingRC10_1988]
| Quote: testing is facilitated in a controlled environment which is separate from the development environment [»mcgoMJ7_1983]
| Quote: in Cleanroom, the primary function of testing is to certify code, not debug it; reject if 7-8 errors/KLOC [»lingRC10_1988]
| Quote: errors in Cleanroom projects tend to be simple mistakes found by statistical testing, not deep design or interface errors [»lingRC5_1993]
| Subtopic: good results
Quote: a Cleanroom project developed 107 KLOCs in 3 increments; 50 people, 2.6 errors/KLOC and 486 LOC/developer/month [»lingRC5_1993]
| Quote: successful use of Cleanroom methods for NORAD tracking system; incremental development, team walkthroughs, state-based, almost all defects discovered before compilation [»tackBD5_1999]
| Quote: Cleanroom teams met requirements better and passed more test cases; all intermediate deliveries were on schedule [»selbRW9_1987]
| Quote: COBOL/SF used a Cleanroom software team of 8 people plus 3 summer students; first software development project for all but two people [»lingRC10_1988]
| Quote: COBOL/SF development by Cleanroom methods meet all schedules and budgets; all committed functions were delivered [»lingRC10_1988]
| Quote: developed COBOL/SF (for structuring programs) with Cleanroom techniques; 80K lines; field test found 10 simple errors [»lingRC10_1988]
| Quote: in Cleanroom, used intensive team reviews to verify two formal grammars of 1500 productions each; no grammar errors found in field testing [»lingRC10_1988]
| Quote: Cleanroom projects achieve 3.3 errors/KLOC in testing after correctness verification [»lingRC5_1993]
|
Related Topics
Group: program design (13 topics, 454 quotes)
Group: program proving (10 topics, 311 quotes)
Group: requirement specification (11 topics, 307 quotes)
Topic: constructing proof and program together (22 items)
Topic: design documentation (43 items)
Topic: incremental development (74 items)
Topic: incremental testing (26 items)
Topic: personal software process (PSP) (2 items)
Topic: programming without errors (28 items)
Topic: quality assurance (22 items)
Topic: requirement specification by diagrams (27 items)
Topic: requirement specification by function (20 items)
Topic: software change management (48 items)
Topic: software management (28 items)
Topic: software review (80 items)
Topic: team programming (7 items)
Topic: statistical testing based on a usage profile (27 items)
|