Reliability 1
(and a little Privacy)

CS 5150
•
Milestone 3 this week
•
Presentation
•
Report
•
Teammate feedback
2

CS 5150
3

CS 5150
•
If you remember nothing else about privacy from 5150:
•
Store as little data about people as you can
•
Consult a lawyer before launching a publiclyaccessible service that retains personal information
4

CS 5150
•
Computers challenge assumptions about the division between public and private
•
Targeted advertising
•
Government records
•
Cameras and microphones in public places
•
RFID everywhere
•
Network monitoring
5

Dependable and Reliable Systems:
The Royal Majesty
CS 5150
•
From the report of the National Transportation Safety
Board:
•
"On June 10, 1995, the Panamanian passenger ship
Royal Majesty grounded on Rose and Crown Shoal about 10 miles east of Nantucket Island,
Massachusetts, and about 17 miles from where the watch officers thought the vessel was. The vessel, with 1,509 persons on board, was en route from St.
George’s, Bermuda, to Boston, Massachusetts."
•
"The Raytheon GPS unit installed on the Royal
Majesty had been designed as a standalone navigation device in the mid- to late1980s, ...The
Royal Majesty’s GPS was configured by Majesty
Cruise Line to automatically default to the Dead
Reckoning mode when satellite data were not available."
6

CS 5150
•
The ship was steered by an autopilot that relied on position information from the Global Positioning
System (GPS).
•
If the GPS could not obtain a position from satellites, it provided an estimated position based on Dead
Reckoning (distance and direction traveled from a known point).
•
The GPS failed one hour after leaving Bermuda.
•
The crew failed to see the warning message on the display (or to check the instruments).
•
34 hours and 600 miles later, the Dead Reckoning error was 17 miles.
7

•
All the software worked as specified (no bugs), but ...
•
Since the GPS software had been specified, the requirements had changed (stand alone system now part of integrated system).
•
The manufacturers of the autopilot and GPS adopted different design philosophies about the communication of mode changes.
•
The autopilot was not programmed to recognize valid/invalid status bits in message from the GPS (NMEA
0183).
•
The warnings provided by the user interface were not sufficiently conspicuous to alert the crew.
CS 5150
•
The officers had not been properly trained on this equipment.
8

CS 5150
•
The reliability of software is related to how frequently it does what it is supposed to do
•
The robustness of software is related to how badly things go wrong when it fails to do exactly what it is supposed to do
9

CS 5150
•
Organization culture that expects quality
•
Software design and implementation that hides complexity
(e.g., structured design, object-oriented programming)
•
Precise, unambiguous specification
•
Software tools that restrict or detect errors (e.g., strongly typed languages, source control systems, debuggers)
•
Programming style that emphasizes simplicity, readability, and avoidance of dangerous constructs
•
Continuous validation (e.g., reviews, unit testing)
•
Systematic testing (test plan, test cases, etc.)
•
Change management (regression testing)
10

CS 5150
•
Acceptance of the group's style of work (e.g., meetings, preparation, support for juniors)
•
Visibility – tell people your problems
•
Issue tracking
•
Completion of a task before moving to the next
(e.g., documentation, comments in code)
11

CS 5150
•
Standard terminology (requirements, specification, design, etc.)
•
Software standards (coding standards, naming conventions, etc.)
•
Regular builds of complete system
•
Internal and external documentation
•
Reporting procedures
12

CS 5150
•
Pay even more attention to the early parts of the design process
•
“Measure twice, cut once”
•
Programmers tend to prefer to get something working, then refine/reimplement
•
Investing in early design tends to lead to an acceptable product sooner
13

CS 5150
•
Source code management and version control
•
Tracking of change requests and bug reports
•
Procedures for changing requirements specifications, designs and other documentation
•
Regression testing
•
Release control
14

CS 5150
•
Informally speaking
•
Probability of a software system failing in real-world use
•
Perceived reliability
•
User behavior
•
Sets of inputs
•
Pain of failure
15

CS 5150
•
For online systems
•
Mean time between failures
•
Availability (up time)
•
Mean time to repair
•
Market measures
•
Complaints
•
Customer retention
16