正式な方法の広範な採用を妨げる障壁は何ですか？
正式なメソッドを使用して、アプリケーションのコードを指定、証明、および生成できます。これはエラーが発生しにくいため、主に安全/重要なプログラムで使用されます。
日常のプログラミングやWebアプリケーションなどで、もっと頻繁に使用しないのはなぜですか？
参照：
エンジニアは、どんな馬鹿でも10でできるのと同じように、1ドルでできる人です。
リソースの制約、予算の制約、時間の制約、それらはすべて重要です。
形式的な方法を使用してソフトウェアを開発することは、通常、かなり高価であり、それがない場合よりもはるかに時間がかかります。また、多くのプロジェクトで最も難しいのは、ビジネス要件を理解することです。その場合、正式な方法を使用することですべてが購入できるため、コードがビジネス要件の不完全で不正確な理解に100％対応していることが証明されます。
そのため、正式な方法、証明、プログラム検証、および同様の手法の使用は、通常、「重要なもの」、つまりアビオニクスソフトウェア、医療機器の制御システム、発電所などに限定されます。
プログラムするかしないか？
ソフトウェア製品の問題を解決するには、要件を理解した後、[〜＃〜]どちらか[〜＃〜]プログラミング言語を使用するプログラム[〜＃〜]または[〜＃〜]は、正式な言語を使用してプログラムを指定し、コード生成ツールを使用します。後者は、あるレベルの抽象化を追加するだけです。
正しいことを行うか、正しいことを行うか？
正式なアプローチは、ソフトウェアが仕様に従って動作していることを証明します。だからあなたの製品は正しいことをします。しかし、それは正しいことをしますか？
作業している要件が不完全またはあいまいである可能性があります。彼らはバギーかもしれません。最悪の場合、本当のニーズは表現されていません。しかし、写真は1000語の価値があります。たとえば、 this article の「顧客が望むもの」のgoogle画像だけです。
フォーマルのコスト
完璧な世界では、最初から完全に詳細で完璧な要件があります。その後、ソフトウェアを完全に指定できます。フォーマルに行けば、コードが自動的に生成され、生産性が向上します。生産性の向上は、正式なツールのコストを相殺します。そして、今や誰もが正式な方法を使用するでしょう。それでは、なぜでしょうか。
実際には、これが現実になることはめったにありません。これが、多くの waterfall プロジェクトが失敗した理由であり、 iterative 開発方法（アジャイル、RADなど）が主導した理由：不完全で不完全な要件、設計、実装を行い、問題がなくなるまで調整します。
そして、ここがポイントです。正式な方法では、各反復で完全に一貫した正式な仕様が必要です。形式的な論理は寛容ではなく、不完全な思考を好まないため、これには注意深い思考と追加の作業が必要です。この制約の下では、単純な使い捨て実験は高価になります。また、バックトラッキングにつながる各反復（たとえば、機能しなかったアイデア、または誤解された要件）も同様です。
実際には
法的または契約上の理由で正式な方法を使用する義務がない場合は、たとえば 契約ベースのプログラミング やその他の適切な方法（コードレビューなど）を使用することにより、正式なシステムなしで非常に高品質を達成することもできます。 、 [〜＃〜] tdd [〜＃〜] など...）。ソフトウェアが機能することを証明することはできませんが、ユーザーはより早くソフトウェアを使用できるようになります。
更新：測定された労力
2018年10月号の Communications of the ACM に興味深い記事があります 実際に正式に検証されたソフトウェア 見積もりの見積もり。
興味深いことに（軍事機器のOS開発に基づいて）、正式に証明されたソフトウェアを作成するには、従来のエンジニアリング手法よりも3.3倍の労力が必要と思われます。だからそれは本当に高価です。
一方、高セキュリティソフトウェアを入手するのに必要な労力は2.3分の1この方法で、従来の技術によるソフトウェアを使用する場合と比べて、そのようなソフトウェアを作成する努力を加えることになります。高セキュリティレベル（EAL 7）で認定されています。したがって、信頼性やセキュリティの要件が高い場合は、正式なビジネスケースが決定的に存在します。
seL4の設計とコード開発には2人年かかりました。長年にわたるすべての血清特異的証明を合計すると、8,700行のCコードで合計18人年になります。比較すると、L4ファミリーのもう1つのマイクロカーネルであるL4Ka :: Pistachioは、サイズがseL4に匹敵し、開発に6人年かかり、重要なレベルの保証はありません。これは、検証済みのソフトウェアと従来から設計されているソフトウェアとの間に因数3.3しかないことを意味します。 ColbertとBoehmによる推定方法8によると、8,700行のCコードに対する従来のCommon Criteria EAL7認定は45.9人年以上かかります。つまり、正式なバイナリレベルの実装検証は、Common Criteriaの最高の認証レベルよりもコストが2.3の係数を超えていますが、はるかに強力な保証が提供されます。
任意の言語のすべてのプログラムは、正式な仕様（いくつかの旋盤に相当）と考えることができます。正式な正しさを証明するために使用されるより高いレベルの「正式な仕様」も、単なる別のプログラムです。しかし、それは（通常）悪い、不完全、あいまいで、プログラムを通して十分に考えられていません。偶然ではありませんが、通常、プログラミングの方法を知らない人々（通常はドメインの専門家です）によって書かれています。
また、1つのプログラムが上位レベルの正式な要件と互換性がある（同じ回答を生成するか、または特性化する）ことを証明すると、不変要素は、上位レベルの正式仕様のあいまいさを解決する方法に帰着します。それを行うための良い汎用的な方法はありません。
高レベルの要件を低レベルの詳細にマッピングすることは、実際のプログラミングの要点です。プログラマーが仕様を読んで解釈することによって行われている中心的な作業を、手を振って「この高レベルの正式な仕様がこのサンプルプログラムに準拠しているかどうかを確認してください」と置き換えることはできないのは当然です。
この概念が最初に非常に有望であるように思われた（高レベルの仕様と実際の基礎となるプログラムの両方を同じ言語で書くことができるため）ロジックプログラミングの初期の頃でさえ、このコアの問題は扱いにくいことがわかりました。