(Moonconf 2016) Fetching Moths from the Works: Correctness Methods in Software
-
Upload
brian-troutwine -
Category
Software
-
view
466 -
download
0
Transcript of (Moonconf 2016) Fetching Moths from the Works: Correctness Methods in Software
FETCHING MOTHS FROM THE WORKSCORRECTNESS METHODS IN SOFTWARE
- or -
An Investigation into the Nature of Software with
a Particular Concern toward its Effective
Construction
- or -
Why do Computers Fail and What can be Done About It?
Why do Computers Stop and What Can be Done About It?
Jim Gray - 1986
@bltroutwine Moonconf, 2016
“The resulting systems have hardware MTBF
measured in decades or centuries. ”
@bltroutwine Moonconf, 2016
“Unfortunately, it says nothing about tolerating
the major sources of failure. . .”
@bltroutwine Moonconf, 2016
“Software”
@bltroutwine Moonconf, 2016
design failures, open doors --
@bltroutwine Moonconf, 2016
The Case of the Three Engineers vs. BART
Gordon Friedlander - 1974
@bltroutwine Moonconf, 2016
agile iteration takes to the sky --
@bltroutwine Moonconf, 2016
SIGSOFT Vol. 6 No. 2: Frontmatter
*gSoft Editor - 1981
@bltroutwine Moonconf, 2016
a bug affects the staging prototype --
@bltroutwine Moonconf, 2016
The BUG Heard 'Round the World Discussion of The Software Problem Which Delayed the First Shuttle Orbital Flight
John Garman - 1981
@bltroutwine Moonconf, 2016
“Maintaining software systems in the field, absorbing large changes or additions in the middle of development
cycles. . . @bltroutwine Moonconf, 2016
. . . reconfiguring software systems to ‘fit’ never-quite-identical vehicles or missions are our real problems today.”
@bltroutwine Moonconf, 2016
That was the late 1970s, have we made
progress?
@bltroutwine Moonconf, 2016
Yes!
@bltroutwine Moonconf, 2016
Sorta!
@bltroutwine Moonconf, 2016
‘Correct’ is not a state, it’s a goal.
@bltroutwine Moonconf, 2016
What’s needed is an understanding of how we fail to achieve it.
@bltroutwine Moonconf, 2016
Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems
Robin R. Lutz - 1993@bltroutwine Moonconf, 2016
“Few internal faults were uncovered
during integration and system testing.”
@bltroutwine Moonconf, 2016
“Functional faults are the most common kind
of software error.”
@bltroutwine Moonconf, 2016
What kind of software faults are there?
@bltroutwine Moonconf, 2016
Program Faults • Internal mistakes • Interface violations • Functional violations
@bltroutwine Moonconf, 2016
Program Faults • Internal • Interface • FunctionalBugs
@bltroutwine Moonconf, 2016
Human Error • Intra-team comms. • Extra-team comms. • Misunderstanding spec. • Mishandling spec.
@bltroutwine Moonconf, 2016
Human Error • Intra-team comms. • Extra-team comms. • Misunderstanding spec. • Mishandling spec.
Comm. Problems
@bltroutwine Moonconf, 2016
Process Error • Inadequate testing • Inadequate specs. • Unknown requirements • Incorrect requirements
@bltroutwine Moonconf, 2016
Process Error • Inadequate testing • Inadequate specs. • Unknown requirements • Incorrect requirements
Org. Goofs
@bltroutwine Moonconf, 2016
‘Correct’ breaks down into two sub-goals.
@bltroutwine Moonconf, 2016
- Validation -
@bltroutwine Moonconf, 2016
- Verification -
@bltroutwine Moonconf, 2016
What steps can we take today?
@bltroutwine Moonconf, 2016
Step 0.
@bltroutwine Moonconf, 2016
Convince your organization to
invest.
@bltroutwine Moonconf, 2016
Eliminating Embedded Software Defects Prior to Integration Test
Ted Bennett, Paul Wennberg - 2005
@bltroutwine Moonconf, 2016
“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
Step 1.
@bltroutwine Moonconf, 2016
Aim to make systems both safe
and reliable.
@bltroutwine Moonconf, 2016
Engineering a Safer World Systems Thinking Applied to Safety
Nancy Leveson - 2011
@bltroutwine Moonconf, 2016
Step 2.
@bltroutwine Moonconf, 2016
Be clear on what your system must and mustn’t do.
@bltroutwine Moonconf, 2016
The Role of Software in Spacecraft Accidents
Nancy Leveson - 2004
@bltroutwine Moonconf, 2016
“. . .software specifications often describe nominal behavior well but are very incomplete with respect to required software behavior under off-nominal
conditions . . .@bltroutwine Moonconf, 2016
“Most safety-related requirements. . .are best described using. . .design
constraints.”@bltroutwine Moonconf, 2016
Step 3.
@bltroutwine Moonconf, 2016
"We don't want nobody that nobody
sent."
@bltroutwine Moonconf, 2016
The Role of Software in Spacecraft Accidents
Nancy Leveson - 2004
@bltroutwine Moonconf, 2016
“It is widely believed that because software has executed safely in other applications, it will be safe
in the new one. . .
@bltroutwine Moonconf, 2016
(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
Step 4.
@bltroutwine Moonconf, 2016
Audit and review all code. Aid with automated tests.
@bltroutwine Moonconf, 2016
The OpenBSD Culture
David Gwynne - 2006
@bltroutwine Moonconf, 2016
Going Fast Slowly
Poul-Henning Kamp, 2016
@bltroutwine Moonconf, 2016
How SQLite is Tested
Dwayne Hipp - 2009
@bltroutwine Moonconf, 2016
Step 5.
@bltroutwine Moonconf, 2016
Use randomized testing and track coverage.
@bltroutwine Moonconf, 2016
An Evaluation of Randomized Testing
Joe Duran, *meon Ntafos - 1984
@bltroutwine Moonconf, 2016
“Our experiments have shown that random testing
can discover some relatively subtle errors without a great
deal of effort.”@bltroutwine Moonconf, 2016
QuickCheck A Lightweight Tool for Random Testing of Haskell Programs
Coen Claessen, John Hughes - 2000
@bltroutwine Moonconf, 2016
Step 6.
@bltroutwine Moonconf, 2016
Be willing to change your approach.
@bltroutwine Moonconf, 2016
An Experimental Evaluation of the Assumption of Independence in Multiversion Programming
Nancy Leveson, John Knight - 1986@bltroutwine Moonconf, 2016
Step 7.
@bltroutwine Moonconf, 2016
Use tools amenable to formal methods.
@bltroutwine Moonconf, 2016
Rigorous Software Development An Introduction to Program Verification
Jose Almedia et al., 2011
@bltroutwine Moonconf, 2016
Building High Integrity Applications with SPARK
John McCormick, Peter Chapin - 2015
@bltroutwine Moonconf, 2016
Step 9.
@bltroutwine Moonconf, 2016
Use formal methods.
@bltroutwine Moonconf, 2016
Formal Specification and Documentation with Z A Case Study Approach
Jonathan Bowen, 2003
@bltroutwine Moonconf, 2016
Moving Fast with Software Verification
Cristiano Calcagno et al., 2015
@bltroutwine Moonconf, 2016
Step 9.
@bltroutwine Moonconf, 2016
Build simple.
@bltroutwine Moonconf, 2016
Out of the Tar Pit
Ben Moseley, Peter Marks - 2006
@bltroutwine Moonconf, 2016
Normal Accidents Living with High-Risk Technologies
Charles Perrow - 1986
@bltroutwine Moonconf, 2016
Step 10.
@bltroutwine Moonconf, 2016
Build for failure.
@bltroutwine Moonconf, 2016
Crash-Only Software
George Candea, Armando Fox - 2003
@bltroutwine Moonconf, 2016
Making Reliable Distributed Systems in the Presence of Software Errors
Joe Armstrong - 2003
@bltroutwine Moonconf, 2016
“We assume that such programs do contain errors, and investigate methods for
building reliable systems despite such errors.”
@bltroutwine Moonconf, 2016
What must we invent?
@bltroutwine Moonconf, 2016
Formal specification tools a project
manager can love.
@bltroutwine Moonconf, 2016
Effective system modeling tools.
@bltroutwine Moonconf, 2016
Methods for the effective analysis of running systems.
@bltroutwine Moonconf, 2016
A techno-political culture of excellence.
@bltroutwine Moonconf, 2016
What can we study?
@bltroutwine Moonconf, 2016
Lots!
@bltroutwine Moonconf, 2016
The End!