The document discusses steps that can be taken to improve software correctness. It begins by outlining 10 steps, such as convincing organizations to invest in correctness, aiming for safe and reliable systems, clearly defining specifications, auditing and reviewing code with automated tests, using randomized testing and tracking coverage, and building systems to fail safely. It then notes that effective formal specification tools, system modeling tools, methods for analyzing running systems, and a culture focused on excellence need to be developed. Various software faults, errors, and accidents are analyzed throughout the document.

1. FETCHING MOTHS
FROM THE WORKS
CORRECTNESS METHODS IN SOFTWARE

2. - or -

3. An Investigation into the
Nature of Software with
a Particular Concern
toward its Effective
Construction

4. - or -

5. Why do Computers
Fail and What can
be Done About It?

6. Why do Computers Stop
and What Can be Done
About It?
Jim Gray - 1986
@bltroutwine Moonconf, 2016

7. “The resulting systems
have hardware MTBF
measured in decades or
centuries. ”
@bltroutwine Moonconf, 2016

8. “Unfortunately, it says
nothing about tolerating
the major sources of
failure. . .”
@bltroutwine Moonconf, 2016

9. “Software”
@bltroutwine Moonconf, 2016

11. design failures,
open doors --
@bltroutwine Moonconf, 2016

13. The Case of the Three
Engineers vs. BART
Gordon Friedlander - 1974
@bltroutwine Moonconf, 2016

14. agile iteration
takes to the sky --
@bltroutwine Moonconf, 2016

16. SIGSOFTVol. 6 No. 2:
Frontmatter
*gSoft Editor - 1981
@bltroutwine Moonconf, 2016

17. a bug affects the
staging prototype --
@bltroutwine Moonconf, 2016

19. The BUG Heard 'Round
the World
Discussion of The Software Problem Which Delayed the
First Shuttle Orbital Flight
John Garman - 1981
@bltroutwine Moonconf, 2016

20. “Maintaining software
systems in the field, absorbing
large changes or additions in
the middle of development
cycles. . .
@bltroutwine Moonconf, 2016

21. . . . reconfiguring software
systems to ‘fit’ never-quite-
identical vehicles or missions
are our real problems today.”
@bltroutwine Moonconf, 2016

22. That was the late
1970s, have we made
progress?
@bltroutwine Moonconf, 2016

23. Yes!
@bltroutwine Moonconf, 2016

25. Sorta!
@bltroutwine Moonconf, 2016

26. ‘Correct’ is not a
state, it’s a goal.
@bltroutwine Moonconf, 2016

27. What’s needed is an
understanding of how
we fail to achieve it.
@bltroutwine Moonconf, 2016

28. Analyzing Software
Requirements Errors in
Safety-Critical, Embedded
Systems
Robin R. Lutz - 1993
@bltroutwine Moonconf, 2016

29. “Few internal faults
were uncovered
during integration and
system testing.”
@bltroutwine Moonconf, 2016

30. “Functional faults are
the most common kind
of software error.”
@bltroutwine Moonconf, 2016

31. What kind of software
faults are there?
@bltroutwine Moonconf, 2016

32. Program Faults
• Internal mistakes
• Interface violations
• Functional violations
@bltroutwine Moonconf, 2016

33. Program Faults
• Internal
• Interface
• Functional
Bugs
@bltroutwine Moonconf, 2016

34. Human Error
• Intra-team comms.
• Extra-team comms.
• Misunderstanding spec.
• Mishandling spec.
@bltroutwine Moonconf, 2016

35. Human Error
• Intra-team comms.
• Extra-team comms.
• Misunderstanding spec.
• Mishandling spec.
Comm.
Problems@bltroutwine Moonconf, 2016

36. Process Error
• Inadequate testing
• Inadequate specs.
• Unknown requirements
• Incorrect requirements
@bltroutwine Moonconf, 2016

37. Process Error
• Inadequate testing
• Inadequate specs.
• Unknown requirements
• Incorrect requirements
Org.
Goofs@bltroutwine Moonconf, 2016

38. ‘Correct’ breaks down
into two sub-goals.
@bltroutwine Moonconf, 2016

39. - Validation -
@bltroutwine Moonconf, 2016

40. - Verification -
@bltroutwine Moonconf, 2016

41. What steps can we
take today?
@bltroutwine Moonconf, 2016

43. Step 0.
@bltroutwine Moonconf, 2016

44. Convince your
organization to
invest.
@bltroutwine Moonconf, 2016

46. Eliminating Embedded
Software Defects Prior to
Integration Test
Ted Bennett, Paul Wennberg - 2005
@bltroutwine Moonconf, 2016

47. “The more faults that pass
undetected into integration test
and beyond, the more the
project will cost and the longer
it will take to complete.”
@bltroutwine Moonconf, 2016

48. Step 1.
@bltroutwine Moonconf, 2016

49. Aim to make
systems both safe
and reliable.
@bltroutwine Moonconf, 2016

51. Engineering a Safer World
Systems Thinking Applied to Safety
Nancy Leveson - 2011
@bltroutwine Moonconf, 2016

52. Step 2.
@bltroutwine Moonconf, 2016

53. Be clear on what
your system must
and mustn’t do.
@bltroutwine Moonconf, 2016

55. The Role of Software in
Spacecraft Accidents
Nancy Leveson - 2004
@bltroutwine Moonconf, 2016

56. “. . .software specifications often
describe nominal behavior well
but are very incomplete with
respect to required software
behavior under off-nominal
conditions . . .
@bltroutwine Moonconf, 2016

57. “Most safety-related
requirements. . .are best
described using. . .design
constraints.”
@bltroutwine Moonconf, 2016

58. Step 3.
@bltroutwine Moonconf, 2016

59. "We don't want
nobody that nobody
sent."
@bltroutwine Moonconf, 2016

61. The Role of Software in
Spacecraft Accidents
Nancy Leveson - 2004
@bltroutwine Moonconf, 2016

62. “It is widely believed that because
software has executed safely in
other applications, it will be safe
in the new one. . .
@bltroutwine Moonconf, 2016

63. (M)ost accidents involve software
that is doing exactly what it was
designed to do (but) it reliably
performs the wrong function.”
@bltroutwine Moonconf, 2016

64. Step 4.
@bltroutwine Moonconf, 2016

65. Audit and review
all code. Aid with
automated tests.
@bltroutwine Moonconf, 2016

67. The OpenBSD Culture
David Gwynne - 2006
@bltroutwine Moonconf, 2016

68. Going Fast Slowly
Poul-Henning Kamp, 2016
@bltroutwine Moonconf, 2016

69. How SQLite is Tested
Dwayne Hipp - 2009
@bltroutwine Moonconf, 2016

70. Step 5.
@bltroutwine Moonconf, 2016

71. Use randomized testing
and track coverage.
@bltroutwine Moonconf, 2016

73. An Evaluation of Randomized
Testing
Joe Duran, *meon Ntafos - 1984
@bltroutwine Moonconf, 2016

74. “Our experiments have
shown that random testing
can discover some relatively
subtle errors without a great
deal of effort.”
@bltroutwine Moonconf, 2016

75. QuickCheck
A Lightweight Tool for Random Testing of Haskell Programs
Coen Claessen, John Hughes - 2000
@bltroutwine Moonconf, 2016

76. Step 6.
@bltroutwine Moonconf, 2016

77. Be willing to
change your
approach.
@bltroutwine Moonconf, 2016

79. An Experimental Evaluation
of the Assumption of
Independence in Multiversion
Programming
Nancy Leveson, John Knight - 1986
@bltroutwine Moonconf, 2016

80. Step 7.
@bltroutwine Moonconf, 2016

81. Use tools amenable to
formal methods.
@bltroutwine Moonconf, 2016

83. Rigorous Software
Development
An Introduction to ProgramVerification
Jose Almedia et al., 2011
@bltroutwine Moonconf, 2016

84. Building High Integrity
Applications with SPARK
John McCormick, Peter Chapin - 2015
@bltroutwine Moonconf, 2016

85. Step 9.
@bltroutwine Moonconf, 2016

86. Use formal methods.
@bltroutwine Moonconf, 2016

88. Formal Specification and
Documentation with Z
A Case Study Approach
Jonathan Bowen, 2003
@bltroutwine Moonconf, 2016

89. Moving Fast with Software
Verification
Cristiano Calcagno et al., 2015
@bltroutwine Moonconf, 2016

90. Step 9.
@bltroutwine Moonconf, 2016

91. Build simple.
@bltroutwine Moonconf, 2016

93. Out of the Tar Pit
Ben Moseley, Peter Marks - 2006
@bltroutwine Moonconf, 2016

94. Normal Accidents
Living with High-Risk Technologies
Charles Perrow - 1986
@bltroutwine Moonconf, 2016

95. Step 10.
@bltroutwine Moonconf, 2016

96. Build for failure.
@bltroutwine Moonconf, 2016

98. Crash-Only Software
George Candea, Armando Fox - 2003
@bltroutwine Moonconf, 2016

99. Making Reliable Distributed
Systems in the Presence of
Software Errors
Joe Armstrong - 2003
@bltroutwine Moonconf, 2016

100. “We assume that such
programs do contain errors,
and investigate methods for
building reliable systems
despite such errors.”
@bltroutwine Moonconf, 2016

101. What must we invent?
@bltroutwine Moonconf, 2016

103. Formal specification
tools a project
manager can love.
@bltroutwine Moonconf, 2016

104. Effective system
modeling tools.
@bltroutwine Moonconf, 2016

105. Methods for the
effective analysis of
running systems.
@bltroutwine Moonconf, 2016

106. A techno-political
culture of excellence.
@bltroutwine Moonconf, 2016

107. What can we study?
@bltroutwine Moonconf, 2016

109. Lots!
@bltroutwine Moonconf, 2016

114. The End!