Software Engineering Lecture 22: Dependable Systems II - Validation and Verification, Slides of Software Engineering

Download Software Engineering Lecture 22: Dependable Systems II - Validation and Verification and more Slides Software Engineering in PDF only on Docsity!

CS 501: Software Engineering

Fall 2000

Lecture 22

Dependable Systems II Validation and Verification

docsity.com

Administration

Final Presentation

• Completed code, demonstration of operational system
• Program documentation
• User documentation

Client should be present at final presentation

docsity.com

Defensive Programming Examples

• Use boolean variable not integer
• Test i <= n not i = = n
• Assertion checking
• Build debugging code into program with a switch to display values at interfaces
• Error checking codes in data, e.g., checksum or hash

docsity.com

Terminology

Fault avoidance

Build systems with the objective of creating fault- free systems

Fault tolerance

Build systems that continue to operate when faults occur

Fault detection (testing and validation)

Detect faults before the system is put into operation.

docsity.com

Fault Tolerance

Backward Recovery:

• Record system state at specific events (checkpoints). After failure, recreate state at last checkpoint.
• Combine checkpoints with system log that allows transactions from last checkpoint to be repeated automatically.

docsity.com

Fault Tolerance

General Approach:

• Failure detection
• Damage assessment
• Fault recovery
• Fault repair

N-version programming -- Execute independent implementation in parallel, compare results, accept the most probable.

docsity.com

Cleanroom Software Development

Software development process that aims to develop zero-defect software.

• Formal specification
• Incremental development with customer input
• Constrained programming options
• Static verification
• Statistical testing

It is always better to prevent defects than to remove them later.

Example: The four color problem.

docsity.com

Static and Dynamic Verification

Static verification: Techniques of verification that do not include execution of the software.

• May be manual or use computer tools.

Dynamic verification

• Testing the software with trial data.
• Debugging to remove errors.

docsity.com

Static Verification: Program Inspections

Program reviews whose objective is to detect faults

• Code may be read or reviewed line by line.
• 150 to 250 lines of code in 2 hour meeting.
• Use checklist of common errors.
• Requires team commitment, e.g., trained leaders So effective that it can replace unit testing

docsity.com

Inspection Checklist: Common Errors

Data faults: Initialization, constants, array bounds, character strings

Control faults: Conditions, loop termination, compound statements, case statements

Input/output faults: All inputs used; all outputs assigned a value

Interface faults: Parameter numbers, types, and order; structures and shared memory

Storage management faults: Modification of links, allocation and de- allocation of memory

Exceptions: Possible errors, error handlers docsity.com

Static Analysis Tools (continued)

• Cross-reference table: Shows every use of a variable, procedure, object, etc.
• Information flow analysis: Identifies input variables on which an output depends.
• Path analysis: Identifies all possible paths through the program.

docsity.com

Test Design

Testing can never prove that a system is correct. It can only show that (a) a system is correct in a special case, or (b) that it has a fault.

• The objective of testing is to find faults.
• Testing is never comprehensive.
• Testing is expensive.

docsity.com

Acceptance Testing

Alpha Testing: Clients operate the system in a realistic but non-production environment

Beta Testing: Clients operate the system in a carefully monitored production environment

Parallel Testing: Clients operate new system alongside old production system with same data and compare results

docsity.com

The Testing Process

System and Acceptance Testing is a major part of a software project

• It requires time on the schedule
• It may require substantial investment in datasets, equipment, and test software.
• Good testing requires good people!
• Management and client reports are important parts of testing.

What is the definition of "done"? docsity.com