56 ;;Quote: ten commandments for successful projects using formal methods

56 ;;Quote: use a small vocabulary for formal methods; easier to understand though longer, more abstract, little implementation bias; e.g., Hoare's CSP

57 ;;Quote: do not use formalized methods everywhere; formal methods used for only 10% of CICS

57+;;Quote: formal methods are inappropriate for user interface design

57 ;;Quote: formal specifications are concise, explicit, unambiguous, abstract, and lead to an implementation; generally beneficial

57+;;Quote: full formal development with machine-checked proofs is too expensive except for failure-critical applications

58 ;;Quote: estimate costs when using formal methods; high-integrity systems are intrinsically expensive

59 ;;Quote: need a formal methods guru when using formal methods in a project

59 ;;Quote: use a formal methods team with a traditional design team; catches specification errors early

59 ;;Quote: produce an informal specification in parallel with a formal project description; helps clarify the formal text

60 ;;Quote: formal methods do not guarantee correctness; they achieve higher system integrity when applied appropriately

60 ;;Quote: avoid dogmatism when using formal methods; modify specifications as needed; be skeptical about proofs

60 ;;Quote: testing remains important with formal methods; bugs will be found in the requirements and their refinement

61 ;;Quote: formal methods should improve reuse; they clearly state requirements with high component integrity without implementation bias

61 ;;Quote: reuse is difficult because of superstructure to support composition; large units have largest benefit but too specialized; library design is time-consuming; uneven quality control