SEN4013 LECTURE NOTES, Lecture notes of Software Engineering

Download SEN4013 LECTURE NOTES and more Lecture notes Software Engineering in PDF only on Docsity!

SEN

Software Verification and

Validation

Lecture 4 Test and Analysis Activities within a Software Process

Learning objectives

• (^) Understand the role of quality in the

development process

• (^) Build an overall picture of the quality

process

• (^) Identify the main characteristics of a

quality process

• (^) visibility
• (^) anticipation of activities
• (^) feedback

4

The Quality Process

• (^) Quality process: set of

activities and responsibilities

• (^) focused primarily on ensuring adequate dependability
• (^) concerned with project schedule or with product usability
• (^) The quality process provides

a framework for

• (^) selecting and arranging activities
• (^) considering interactions and trade-offs with other important

Interactions and tradeoffs

• (^) Example: high dependability vs. time to market
• (^) Mass market products:
  • (^) better to achieve a reasonably high degree of dependability on a tight schedule than to achieve ultra-high dependability on a much longer schedule
• (^) Critical medical devices:
  • (^) better to achieve ultra-high dependability on a much longer schedule than a reasonably high degree of dependability on a tight schedule

Reasons for Carrying Quality Activities at the Earliest Opportunity

• (^) Quality assurance or quality

improvement

• (^) Activities whose primary goal is to prevent or detect faults.
• (^) Architectural design of a software system has an enormous impact on the test and analysis approaches
• (^) Precise, relatively formal architectural models
  • (^) Form the basis for static analysis

Reasons for Carrying Quality Activities at the Earliest Opportunity

• (^) It would be foolish to put off quality

activities until late in a project.

• (^) Early test planning during requirements

engineering typically clarifies and

improves requirements specifications.

• (^) Developing a test plan during

architectural design may suggest

structures and interfaces that facilitate

testing earlier in development.

• (^) Also makes key interfaces simpler and more precisely defined.

Planning and Monitoring

• (^) The quality process
  • (^) Balances several activities across the whole development process
  • (^) Selects and arranges them to be as cost- effective as possible
  • (^) Improves early visibility
• (^) Quality goals can be achieved only

through careful planning

• (^) Planning is integral to the quality process

Process Visibility

• (^) A process is visible to the extent that one can answer the question - (^) How does our progress compare to our plan? - (^) Example: Are we on schedule? How far ahead or behind?
• (^) The quality process has not achieved adequate visibility if one cannot gain strong confidence in the quality of the software system before it reaches final testing - (^) quality activities are usually placed as early as possible - (^) design test cases at the earliest opportunity (not “just in time”) - (^) uses analysis techniques on software artifacts produced before actual code. - (^) motivates the use of “proxy” measures - (^) Ex: we may count faults discovered in design inspections as an early indicator of potential quality problems

A&T Plan

• (^) A comprehensive description of the quality process that includes: - (^) objectives and scope of A&T activities - (^) documents and other items that must be available - (^) items to be tested - (^) features to be tested and not to be tested - (^) analysis and test activities - (^) staff involved in A&T - (^) constraints - (^) pass and fail criteria - (^) schedule - (^) deliverables - (^) hardware and software requirements - (^) risks and contingencies

Quality Goals

• Process qualities (visibility, ....)

• Product qualities

Dependability Qualities

• (^) Correctness:
  • (^) A program is correct if it is consistent with its specification - (^) seldom practical for non-trivial systems
• (^) Reliability:
  • (^) Likelihood of correct function for some “unit” of behavior - (^) statistical approximation to correctness (100% reliable = correct) - (^) relative to a specification and usage profile - (^) availability: failure duration - (^) mean time between failures

Dependability Qualities

• (^) Safety:
  • (^) Preventing hazards
• (^) Robustness:
  • (^) Acceptable (degraded) behavior under extreme conditions
  • (^) Software that gracefully degrades or fails softly outside of its normal operating parameters is robust.

Relation among

Dependability Qualities

Analysis

• (^) analysis includes
  • (^) manual inspection techniques
  • (^) automated analyses
• (^) can be applied at any development stage
• (^) particularly well suited at the early

stages of specifications and design