Verification and Testing of Embedded Systems

Module 2
Software Static Verification Inspection

Prepared By: AMIT Learning

 Outline

• Static Verification; Definition and Scope

• The Inspection Process

• Inspection Roles

• Inspection Prerequisites

• Inspection Procedure

• Inspection Checklists

• Automated Static Analysis

• Effectiveness & Success of Static Analysis

Prepared By: AMIT Learning

 Static Verification

• Software Inspection: process of analyzing the static system representation

against a compiled checklist of common and historical defects

• Static; without execution

• System representation; design documents or prototype

Prepared By: AMIT Learning

 Software Inspections

• These involve people examining the source representation with the aim of
discovering anomalies and defects.

• Inspections do not require execution of a system so maybe used before

implementation.

• They maybe applied to any representation of the system (requirements,

design, configuration data, test data. .etc).

• They have been shown to be an effective technique for discovering program

errors.

Prepared By: AMIT Learning

 Software Inspections

• Formalized approach to document reviews.

• Intended explicitly for defect detection (not correction).

• Defects maybe logical errors, anomalies in the code that might indicate an
erroneous condition (e.g. an un initialized variable) or non-compliance with
standards.

Prepared By: AMIT Learning

 The Inspection Process

Planning

Individual Preparation

Inspection Meeting

Rework

Follow-up

Prepared By: AMIT Learning

 Inspection Roles

• Author or owner: The programmer or designer responsible for producing the program
or document. Responsible for fixing defects discovered during the inspection
process.

• Inspector: Finds errors, omissions and inconsistencies in programs and documents.

May also identify broader issues that are outside the scope of the inspection team.

• Scribe: Records the results of the inspection meeting.

• Chairman: Manages the process and facilitates the inspection. Reports process
results to the Chief moderator.

• Chief moderator: Responsible for inspection process improvements, checklist

updating, standards development etc.

Prepared By: AMIT Learning

 Inspection Prerequisites

• A precise specification must be available.

• Team members must be familiar with the organization standards.

• Syntactically correct code or other system representations must be available.

• An error checklist should be prepared.

• Management must accept that inspection will increase costs early in the
software process.

• Management should not use inspections for staff appraisal ; i.e.: finding out
who makes mistakes.

Prepared By: AMIT Learning

 Inspection Procedure

• System overview presented to inspection team.

• Code and associated documents are distributed to inspection team in

advance.

• Inspection takes place and discovered errors are noted.

• Modifications are made to repair discovered errors.

• Re-inspection may or may not be required.

Prepared By: AMIT Learning

 Stages of Static Analysis

• Control flow analysis: Checks for loops with multiple exit or entry points,
finds unreachable code, etc.

• Data use analysis: Detects un initialized variables, variables written twice

without an intervening assignment, variables which are declared but never
used, etc.

• Interface analysis: Checks the consistency of routine and procedure

declarations and their use.

Prepared By: AMIT Learning

 Stages of Static Analysis

• Information flow analysis: Identifies the dependencies of output variables.

Does not detect anomalies itself but highlights information for code
inspection or review.

• Path analysis: Identifies paths through the program and sets out the
statements executed in that path. Again, potentially useful in the review
process.

• Both these stages generate vast amounts of information.

• They must be used with care.

Prepared By: AMIT Learning

 Inspection Checklists

• Checklist of common errors should be used to drive the inspection.

• Error checklists are programming language dependent and reflect the

characteristic errors that are likely to arise in the language.

• In general, the ‘weaker‘ the type checking, the larger the checklist.

• Examples: Initialization, Constant naming, loop termination, array bounds,

etc.

Prepared By: AMIT Learning

 Inspection Checklists

Data faults
• Are all program variables initialized before their values are used?
• Have all constants been named?
• Should the upper bound of arrays be equal to the size of the array or Size -1?
• If character strings are used, is a delimiter explicitly assigned?
• Is there any possibility of buffer overflow?

Control faults
• For each conditional statement, is the condition correct?
• Is each loop certain to terminate?
• Are compound statements correctly bracketed?
• In case statements, are all possible cases accounted for?
• If a break is required after each case in case statements, has it been included?

Input/output faults
• Are all input variables used?
• Are all output variables assigned a value before they are output?
• Can unexpected inputs cause corruption?

Prepared By: AMIT Learning

 Inspection Checks

Interface faults
• Do all function and method calls have the correct number of parameters?
• Do formal and actual parameter types match?
• Are the parameters in the right order?
• If components access shared memory, do they have the same model of the shared memory
structure?

Storage management faults

• If a linked structure is modified, have all links been correctly reassigned?
• If dynamic storage is used, has space been allocated correctly?
• Is space explicitly de-allocated after it is no longer required?

Exception management faults

• Have all possible error conditions been taken into account?

Prepared By: AMIT Learning

 Common Errors Samples
Data faults Variables used before initialization
Variables declared but never used
Variables assigned twice but never used between assignments
Possible array bound violations
Undeclared variables
Control faults Unreachable code
Unconditional branches into loops
Input/output
Input/output faults Variables output twice with no intervening assignment

Interface faults Parameter type mismatches

Parameter number mismatches
Non-usage of the results of functions
Uncalled functions and procedures
Storage management faults Unassigned pointers
Pointer arithmetic

Prepared By: AMIT Learning

 Inspection Rate

• 500 statements – per-hour during overview.

• 125 source statement – per-hour during individual preparation.

• 90-125 statements - per-hour can be inspected.

• Inspection is therefore an expensive process.

• Inspecting 500 lines costs about 40man – hours effort

Prepared By: AMIT Learning

 Automated Static Analysis

• Static analyzers are software tools for source text processing.

• They parse the program text and try to discover potentially erroneous
conditions and bring these to the attention of the V&V team.

• They are very effective as an aid to inspections.

• They are a supplement to but not a replacement for inspections.

Prepared By: AMIT Learning

 Verification or Validation?

• Walkthroughs
• Code verification
• Document verification

• Inspections
• Code verification
• Document Audits verification

• Program Reviews
• Customer/Standard involved validation
• No customer verification

Prepared By: AMIT Learning

 Use of Static Analysis

• Particularly valuable when a language such as C is used which has weak

typing and hence many errors are un detected by the compiler,

• Less cost-effective for languages like Java that have strong type checking
and can therefore detect many errors during compilation.

• Inspection cost-effect is inversely proportional to the maturity of the

development team.

Prepared By: AMIT Learning

 Inspection Success

• Many different defects maybe discovered in a single inspection.

• In testing, one defect, may mask another so several executions are required.

• The reuse domain and programming knowledge so reviewers are likely to

have seen the types of error that commonly arise.

Prepared By: AMIT Learning

 Effectiveness of Static Verification

• More than 60% of program defects can be detected by program inspections.

• More than 90% of program defects maybe detectable using more rigorous
mathematical program verification.

• The defect detection process is not confused by the existence of previous

defects.

Prepared By: AMIT Learning

 Why Inspection is important?

• Relative cost to fix a defect

• Phase in which found Cost ratio (hours)

• Requirement 1
• Design 3-6
• Coding 10
• Testing 15-70
• Operation 40-1000

Prepared By: AMIT Learning

 Q&A

Prepared By: AMIT Learning

THANK YOU!