NEWS AT SEI
This library item is related to the following area(s) of work:Software Assurance
This article was originally published in News at SEI on: July 1, 2006
Suppose that your team is developing a state-of-the-art, software-intensive system expected to contribute mightily to your organization and its mission. You know that your team will have to gain confidence that the system will meet expectations and perform as expected.
Unfortunately, you cannot test everything.
Your system might really be a system of systems. Once deployed, it would rely on interoperation among its member systems and on the emergent behavior (i.e., behavior that is not resident in any individual system) that interoperation produces. Testing every detail about those systems and their interactions, if even possible, would take too long and cost too much. How can you keep testing costs under control without releasing unacceptable systems?
Or, your system could be a high-assurance system, which demonstrates a condition that occurs rarely, for example. “Because a condition is rare, perhaps showing up only once in a million transactions, it might not be tested for before the system is deployed,” explains Charles Weinstock, senior member of the technical staff at the Software Engineering Institute (SEI). “If in operation, however, the system’s workload increases to the level of a million transactions per day, this ‘rare’ failure will occur daily, on average.”1
So, if testing isn’t enough, what else can you do to support claims about your system’s dependability such as:
The SEI is investigating analysis-based assurance, an approach that shows promise for helping to gain confidence in claims about the quality of systems of systems and high-assurance systems.
“Analysis-based assurance is a set of techniques that improves confidence that a system or component of a system will perform as expected,” Weinstock explains. “It can replace testing where testing at all would be impossible and augment it where thorough testing would be infeasible or too costly. Or analysis-based assurance can reduce the number of tests that would need to be designed to assure the desired performance.”
An organization can use analysis-based assurance methods to leverage scarce assurance resources and produce a reviewable artifact that provides assurance of mission-critical properties and go/no-go criteria at different stages of development.
This technology can aid organizations in other ways, such as
Central to analysis-based assurance is the assurance-case method. An assurance case is a structured set of arguments and a body of evidence showing that a system satisfies specific claims with respect to a given quality attribute.2 Because it involves a rigorous reasoning process, the assurance-case method can be widely applied—used to satisfy, for instance, claims you need to justify regarding your system’s performance, interoperability, safety, and security.
For example, you may need to prove a claim stated as “My system is dependable” for your system. “We would seek to know more about which dependability properties are important in this particular system,” says John Goodenough, SEI fellow and leader of the SEI investigation of analysis-based assurance. “A more appropriate claim would be, ‘The system meets its dependability requirements as detailed in document XXX.’”
Using the assurance-case method, you can then devise a way to show convincingly that the claim is true. “In this example, a strategy might be ‘Show that each of the dependability requirements is met individually. Then show that they are met collectively,’” says Goodenough.
“This leads to sub-claims, at least one for each of the dependability requirements, with a strategy and sub-sub-claims for each. Eventually the argument gets down to ground truth3—which might be a formal proof, a law of physics, or perhaps even an exhaustive enumeration of possibilities. Once every sub-claim is successfully driven down to its solution, we have an argument that the original claim has been satisfied.
Importantly, this argument can be referred to whenever a question about the claim is raised. In particular, it can be used to identify potential problems when a change in the system is contemplated,” Goodenough notes.
In Dependability Cases, Weinstock, Goodenough, and John Hudak (also a senior member of the SEI technical staff) provide an example of the approach in use through the building of a dependability case for the problem of synchronizing the clocks of a low-orbiting satellite and its ground-control station. In the example, they discuss and illustrate the claim, context, and assumptions about the problem; a strategy to “prove” the claim; sub-claims for the sources of the problem; and sub-dependability cases.
It is common for assurance-case arguments with the same structure to appear in many different contexts. Essentially, the recurring arguments are assurance-case patterns of reasoning that encapsulate what evidence needs to be collected and what pitfalls are likely to occur in applying a particular type of argument. They also capture the expertise of people in an organization who know how to attain assurance.
Assurance-case patterns provide a body of best practices in the form of ready-to-instantiate arguments where only the specific details need to be incorporated, reducing the effort needed to develop an assurance case. As a result, the use of these patterns could help an organization leverage scarce assurance resources.
A model for an assurance-case pattern drawn from the safety-critical milieu is the “as low as reasonably practicable” (ALARP) principle that argues in this way: when a particular hazard cannot be eliminated or reduced to a negligible level, an argument needs to be developed showing that the risk has been reduced to a tolerable level, and any further reduction is impractical.
After initial work establishing assurance cases as part of software development practice, the SEI is seeking organizational partners to develop case studies and a catalog of assurance-case patterns. The SEI can help partner organizations to improve how they establish and sustain a sense of assurance by reviewing the “as-is” state of their assurance practices and recommending a desired state and path forward.
For more information, contact us using the link the For More Information box at the bottom of this page.
1 This example is adapted from Ultra-Large Scale Systems: The Software Challenge of the Future.
2 The concept of an assurance case has been derived from that of a safety case. Safety cases have been used successfully for more than a decade to argue that safety-critical systems in areas such as flight control, railroad signaling, and nuclear reactor shutdown systems meet their safety properties. It also has origins in the concept of a dependability case, described by the Performance-Critical Systems (PCS) Initiative at the SEI in the technical note Dependability Cases. Both safety cases and dependability cases are types of assurance cases: a safety case supports a safety claim; a dependability case supports a dependability claim.
3 In the context of assurance cases, ground truth can be taken to mean elemental, basic, or fundamental.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.