English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Tools annual

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Tools monthly

Global: Zendy Plus monthly

Presents the access of premium content as premium feature

Premium Content

Global: Zendy Plus annual

Global: Zendy Free Plan

At the 1990 ACM Computer Science Conference, the great debate about the use of formal methods in software development showed that there is probably no informed computer scientist who believes that using formal methods eliminates the need for testing altogether, and none who believes that formal methods have no place in software evaluation. One can adopt the view that evaluation should be as formal as possible, but research has shown sometimes that random testing is better than more systematic methods. In addition to the unclear place of formal methods, the software developer is faced with a barrage of "evaluation dichotomies":-white-box vs. black-box testing-static vs. dynamic evaluation-unit vs. integration testing-verification vs. validation Adding questions of formality to this list serves not to further cloud the picture, but rather to clear it up. As the figure below shows, one can visualize an evaluation "space" defined by two dimensions: time of evaluation and degree of evaluation formality. The formality dimension is marked with various techniques that might fall along the scale. The proposal here is that the shaded region may serve as an approximate guide to appropriate evaluation. Early on, close to specification, formal methods are more suited; one is trying to work with a program more as a mathematical object than as an active agent running on a real machine with real users. Later, when users become more involved, evaluation naturally moves toward informal, but realistic, tests. Further, the region can help make sense of the many evaluation dichotomies: At the end marked A one finds evaluation that is static, white-box, unit-focused, and verification-oriented. As one approaches B, evaluation becomes more dynamic, black-box, integrated, and validation-oriented. This view of evaluation might help students and professionals see how all common evaluation techniques have a niche in software evaluation.

Where do formal methods fit in software evaluation? (abstract and figure only)