{"title":"Trust or verify?","authors":"B. Meyer","doi":"10.1145/2602576.2611460","DOIUrl":null,"url":null,"abstract":"Software quality should be built in from the start: a priori. Software quality can only be guaranteed through verification: a posteriori.\n It is easy to find arguments for either of these views. Is quality an a priori or a posteriori attribute? Saying \"both\" does not answer the question, only turns it into a new one: how should we combine the two approaches?\n Building on both my experience with the Eiffel method and the verification work at ETH I will try to define what exact doses of, respectively, \"correctness by construction\" and modern verification techniques can, at a realistic cost, yield the best possible quality.\n The ETH work is based on the idea of \"Verification As a Matter Of Course\": make verification available to all developments, not just the most critical applications. Integrated in the Eiffel Verification Environment (EVE), the approach combines many different forms of verification, some static (proofs, based on Boogie), some dynamic (tests, based on the AutoTest automatic test framework. The talk will include some of the results from the EVE effort to discuss future trends in the production of reliable architectures.","PeriodicalId":110790,"journal":{"name":"International ACM SIGSOFT Conference on Quality of Software Architectures","volume":"1 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2014-06-27","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"International ACM SIGSOFT Conference on Quality of Software Architectures","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/2602576.2611460","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 0
Abstract
Software quality should be built in from the start: a priori. Software quality can only be guaranteed through verification: a posteriori.
It is easy to find arguments for either of these views. Is quality an a priori or a posteriori attribute? Saying "both" does not answer the question, only turns it into a new one: how should we combine the two approaches?
Building on both my experience with the Eiffel method and the verification work at ETH I will try to define what exact doses of, respectively, "correctness by construction" and modern verification techniques can, at a realistic cost, yield the best possible quality.
The ETH work is based on the idea of "Verification As a Matter Of Course": make verification available to all developments, not just the most critical applications. Integrated in the Eiffel Verification Environment (EVE), the approach combines many different forms of verification, some static (proofs, based on Boogie), some dynamic (tests, based on the AutoTest automatic test framework. The talk will include some of the results from the EVE effort to discuss future trends in the production of reliable architectures.