===========================================================================

Introduction

Brief discussion of logistics.
See website for most logistical details,
so that we can spend class time on more interesting topics.

Students say who they are and what they hope/expect from the class.
Most common answers:
 * learn what quality is
 * learn how to achieve better quality, fewer bugs in their own code

===========================================================================

Why quality?

Motivation: bad problems

$312 billion per year global cost of software bugs (2013)
$300 billion dealing with the Y2K problem
$440 million loss by Knight Capital Group Inc. in 30 minutes in August 2012
$650 million loss by NASA Mars missions in 1999; unit conversion bug
$500 million Ariane 5 maiden flight in 1996; 64 bit to 16 bit conversion bug

Software bugs can cost lives
1997: 225 deaths: jet crash caused by radar software
1991: 28 deaths: Patriot missile guidance system
2003: 11 deaths: blackout
1985-2000: >8 deaths: radiation therapy
2011: Software is the cause for 25% of all medical device recalls

===========================================================================

What is quality?

Software quality:  "the program does what it is supposed to do"
 (our expectations match the behavior of the software)
Break this down into:
 * what is the program supposed to do?
 * does the program do that?

External vs. internal quality
 * external quality: visible to users of the software
    * correctness
    * robustness/stability
    * not our focus:
       * usability
       * user delight
    * scalability
    * fault-tolerance
 * internal quality: visible to implementers/programmers of the software
    * readability/understandability
    * extensibility
    * modifiability/maintainability
    * debuggability
    * reusability
We will focus somewhat more on external quality.

Digression about internal quality:
What percentage of effort should be spent on each of these?
 * initial development
 * maintenance
The real breakdown is about 10%-90%.
Maintenance includes:
 * bug fixing
 * refactoring
 * optimization
 * specification/requirements changes
    * new features
    * regulations
    * port to new environment (OS, framework, programming language)
These are not predictable.  To try to accommodate all these in the original
design would be a bad use of resources, and the project would fail.
We don't care about internal quality for its own sake, but because it will
make the 90% of the development life cycle that is devoted to maintenance
cheaper and easier.  But accept that you cannot predict all possible changes
and requests.

Back to external quality:

What it is supposed to do:
 * requirements
    * validation vs. verification
       * this class will focus on verification
 * specification

Does it do it?  Two ways to tell: dynamic analysis and static analysis

===========================================================================

Approaches to achieve quality

Dynamic analysis: runs the program
 * examples:
    * testing
    * log analysis
    * profiling
    * debugging
 * Testing:
    * precise
    * no guarantee for future executions
 * Testing produces an answer of either
    * "incorrect", or
    * "I don't know
   [exception: exhaustive testing]

Static analysis: does not run the program, but reasons about what the
program would do if it were run
 * examples:
    * compiler
    * type systems
    * linters
    * dataflow analysis, abstract interpretation, symbolic execution
       * all synonyms for the purpose of this class.
    * code reading
       * Introspect; watch what you do and be inspired to improve or automate it
    * model checking (has a bit of a feel of dynamic analysis too)
  * Can be sound:  gives a proof or guarantee
    * imprecise -- uses abstractions
 * Static analysis produces an answer of either
    * "correct", or
    * "I don't know"
   [exception: sometimes also "incorrect", but "I don't know" is always possible]

It is theoretically impossible to have a precise, complete analysis that
terminates.  The Halting Problem prevents this.

Key idea of static analysis:
Abstraction, or throwing away information.

===========================================================================

Example problems:

Dynamic analysis
 * Testing:
    * generation
    * prioritization
    * test quality: coverage, mutation
 * Debugging:
    * fault localization
    * bug-fixing

===========================================================================

We might have time to show some example static analysies.

===========================================================================