Table of Contents
Fetching ...

Using Assurance Cases to Guide Verification and Validation of Research Software

W. Spencer Smith, Jingyi Lin

TL;DR

It is illustrated how ACs can guide VnV activities via a case study of software for automatically extracting the 3D segmentation of the aorta from medical images of the chest, and highlights that code is not the only artifact of interest for building confidence.

Abstract

Research software engineers can use Assurance Cases (ACs) to guide Verification and Validation (VnV) efforts. An AC is a structured argument that a property like correctness holds. We illustrate how ACs can guide VnV activities via a case study of software for automatically extracting the 3D segmentation of the aorta from medical images of the chest. The AC argument suggests that the following evidence is required: comparison to a pseudo-oracle; traceability between requirements, design, code and tests; review of all artifacts by a domain expert with proper credentials; documentation of input assumptions; and a warning that only qualified people should use the software. The case study highlights that code is not the only artifact of interest for building confidence and that making an explicit distinction between software and user responsibilities is useful.

Using Assurance Cases to Guide Verification and Validation of Research Software

TL;DR

It is illustrated how ACs can guide VnV activities via a case study of software for automatically extracting the 3D segmentation of the aorta from medical images of the chest, and highlights that code is not the only artifact of interest for building confidence.

Abstract

Research software engineers can use Assurance Cases (ACs) to guide Verification and Validation (VnV) efforts. An AC is a structured argument that a property like correctness holds. We illustrate how ACs can guide VnV activities via a case study of software for automatically extracting the 3D segmentation of the aorta from medical images of the chest. The AC argument suggests that the following evidence is required: comparison to a pseudo-oracle; traceability between requirements, design, code and tests; review of all artifacts by a domain expert with proper credentials; documentation of input assumptions; and a warning that only qualified people should use the software. The case study highlights that code is not the only artifact of interest for building confidence and that making an explicit distinction between software and user responsibilities is useful.

Paper Structure

This paper contains 15 sections, 1 equation, 5 figures, 3 tables.

Figures (5)

  • Figure 1: AortaGeomRecon Screenshot showing 3D aorta segmentation
  • Figure 2: Top Level Goal
  • Figure 3: GI: Implementation Complies with Requirements
  • Figure 4: GA: Input(s) Satisfy Operational Assumptions
  • Figure 5: Warning Message