Professional Documents
Culture Documents
Lecture 19
Reliability 1
Traditional Measures
• Mean time between failures
• Availability (up time)
• Mean time to repair
Market Measures
• Complaints
• Customer retention
User Perception is Influenced by
• Distribution of failures
Hypothetical example: Cars are less safe than airplanes in
accidents per hour, but safer in accidents per mile.
9 CS 501 Spring 2005
Reliability Metrics for Distributed Systems
Up time
99% 100%
Feasibility study
Requirements
System design
Program design
Coding
Changes Testing
Acceptance
Operation & maintenance
17 CS 501 Spring 2005
Key Factors for Reliable Software
Assumption:
Good processes lead to good software
The importance of routine:
Standard terminology (requirements,
specification, design, etc.)
Software standards (naming conventions, etc.)
Internal and external documentation
Reporting procedures
Change management:
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
Objectives:
• To review progress against plan (formal or informal).
• To adjust plan (schedule, team assignments,
functionality, etc.).
Impact on quality:
Good quality systems usually result from plans that are
demanding but realistic.
Good people like to be stretched and to work hard, but
must not be pressed beyond their capabilities.
Benefits:
• Extra eyes spot mistakes, suggest improvements
• Colleagues share expertise; helps with training
• An occasion to tidy loose ends
• Incompatibilities between components can be identified
• Helps scheduling and management control
Fundamental requirements:
• Senior team members must show leadership
• Good reviews require good preparation
• Everybody must be helpful, not threatening
26 CS 501 Spring 2005
Review Team (Full Version)
Moderator
Scribe
Developer -- the design team
Interested parties -- people who created the system design
and/or requirements specification, and the programmers who
will implement the system
Outside experts -- knowledgeable people who have are not
working on this project
Client -- only if the client has a strong technical representative
Preparation
The developer provides colleagues with documentation
(e.g., specification or design), or code listing
Participants study the documentation in advance
Meeting
The developer leads the reviewers through the
documentation, describing what each section does and
encouraging questions
Must allow plenty of time and be prepared to continue on
another day.
29 CS 501 Spring 2005
Static and Dynamic Verification
Validation &
verification
Requirements
specification Design Program
REVIEWS