CS 501: Software Engineering Reliability I CS 501 Spring 2002 Lecture 21

advertisement
CS 501: Software Engineering
Lecture 21
Reliability I
1
CS 501 Spring 2002
Administration
2
CS 501 Spring 2002
Principles for Dependable Systems
The human mind can encompass only limited complexity:
=> Comprehensibility
=> Simplicity
=> Partitioning of complexity
3
CS 501 Spring 2002
Principles for Dependable Systems
High-quality has to be built-in:
=> Each stage of development must be done well
=> Testing and correction does not lead to quality
=> Changes should be incorporated into the structure
4
CS 501 Spring 2002
Quality Management Processes
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
5
CS 501 Spring 2002
Factors for Reliable Software
• Precise, unambiguous specification
•
Organization culture that expects quality
• Approach to software design and implementation that hides
complexity (e.g., structured design, object-oriented
programming)
•
Use of 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
•
6
Incremental validation
CS 501 Spring 2002
Quality Management Processes
Change management:
Source code management and version control
Tracking of change requests and bug reports
Procedures for changing requirements
specifications, designs and other documentation
Release control
7
CS 501 Spring 2002
Process (Plan) Reviews
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.
8
CS 501 Spring 2002
Design and Code Reviews
DESIGN AND CODE REVIEWS ARE A FUNDAMENTAL
PART OF GOOD SOFTWARE DEVELOPMENT
Concept
Colleagues review each other's work:
can be applied to any stage of software development
can be formal or informal
Most effective when everybody prepares well.
9
CS 501 Spring 2002
Benefits of Design and Code Reviews
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
• Must be helpful, not threatening
10
CS 501 Spring 2002
Review Team
Moderator -- ensures that the meeting moves ahead steadily
Scribe -- records discussion in a constructive manner
Developer -- person(s) whose work is being reviewed
Interested parties -- people above and below in the software
process
Outside experts -- knowledgeable people who have are not
working on this project
Client -- representatives of the client who are knowledgeable
about this part of the process
11
CS 501 Spring 2002
Example: Program Design
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
12
CS 501 Spring 2002
Process
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.
13
CS 501 Spring 2002
Validation and Verification
Validation: Are we building the right product?
Verification: Are we building the product right?
In practice, it is sometimes difficult to distinguish between
the two.
That's not a bug. That's a feature!
14
CS 501 Spring 2002
Discussion of Pfleeger, Chapter 8
Format:
State a question.
Ask a member of the class to answer.
(Sorry if I pronounce your name wrongly.)
Provide opportunity for others to comment.
When answering:
Stand up.
Give your name or NetID. Make sure the TA hears it.
Speak clearly so that all the class can hear.
15
CS 501 Spring 2002
Q1: Failures and Faults
(a) Define the term failure.
(b) Define the term fault.
(c) What is the usual term for fault?
16
CS 501 Spring 2002
Q2. Types of Fault
What types of fault cause the following failures:
(a) A mathematical function loops for ever from rounding error.
(b) A distributed system hangs because of a concurrency problem.
(c) After a network is hit by lightning, it crashes on restart.
(d) A program dies because the programmer typed: x = 1 instead
of x == 1.
(e) The President is paid $5 a month instead of $10,005 because
the maximum salary allowed by the program is $10,000.
17
(f) An operating system fails because of a page-boundary error in
the firmware.
CS 501 Spring 2002
Q3. Testing
Define the following. Who carries out each
type of test?
(a) unit test
(b) integration test
(c) function test
(d) performance test
(e) acceptance test
(f) installation test
18
CS 501 Spring 2002
Q4. Inspection
(a) Define code inspection.
(b) How does a code inspection differ from a code review.
(c) The book makes some strong claims about the effectiveness
of code inspection. Do you believe the claims?
(d) A code inspection is a great deal of work. When is it
worthwhile?
19
CS 501 Spring 2002
Q5. Methods of Testing
(a) Define the terms:
closed box testing
open box testing
(b) What is the advantage of each approach?
(c) In each case, how do you set about selecting test cases?
20
CS 501 Spring 2002
Q6. Test Strategies
Define
(a) statement analysis.
(b) branch testing
If every statement and every branch is tested is the
program correct?
21
CS 501 Spring 2002
Q7. Static and dynamic analysis
(a) Define static analysis.
(b) Give examples of tools that can be used for static
analysis.
(c) A static tool like lint identifies some errors, but mainly
gives warnings. What is the use of the warnings.
(d) Define dynamic analysis.
(e) Give examples of tools that can be used for dynamic
analysis.
22
CS 501 Spring 2002
Download