なぜ詳細な仕様に悩むのですか？

ソフトウェアを書くとき、正式で詳細なデッドツリー仕様を書く意味は何ですか？明確にするために、コードを読みたくない人のためのやや非公式な高レベルの仕様は私には理にかなっています。十分にコメントされた読みやすいソースコードのリファレンス実装は、コンピュータが実行できる必要があるため、取得するあらゆるものの最も明確な仕様についてのものです。形式的な仕様は、コードと同じくらい読みにくく、ほとんど書くのが難しいです。

正式な仕様は、リファレンス実装に比べてどのような利点がありますか。リファレンス実装での動作に関係なく、未定義/実装定義の動作についての小さなドキュメントが提供されます。

編集：または、テストが正式な仕様であることの何が問題になっていますか？

完了時にどのように表示されるかわからない場合、どのように完了したかを知ることができますか？

機能クリープがあなたを捕まえます。あなたはクライアントのために提供しようとするでしょう、そして完了時間が回るにつれて、彼らは絶対に持っていなければならない10,000の小さなものを発見するでしょう。

支払いを受けるためには、締め切りはセーリングの過去を行くとき、あなたの背中を離れてあなたの上司を得るために、あなたはスペックを引き出し、すべての私の時間とコストの見積もりがためだった」と言うことができる必要があり、この新しい、ないもの誰もが彼らが望んでいると決定したこと。」

仕様を使用すると、仕様が変更された場合に変更する必要のある大量のコードを事前に記述しなくても、物事をじっくり考えることができます。黒板と実際のコーディングの間にあると考えてください

また、複数の独立したパーティがコンポーネントを一緒に作成する必要がある場合にも、この方法を使用することをお勧めします。

既に述べた他の非常に良い理由のいくつかに加えて、正式な仕様があるとCYA-お尻をカバーできます！マネージャー/アナリスト/テスターがあなたが何かを正しく構築しなかったと言った場合、仕様をポイントして、「私はあなたが望むようにそれを構築しました！」と言うことができます。これには、「AXX_RGVテーブルに保持されるすべてのデータは大文字でなければならない」、「入力フィールドが3つ未満のWebフォームは左下に「送信」ボタンがなければならない」などの低レベルのものが含まれます。

また、非常に長くて大きなプロジェクトで人々が物事を忘れた場合にも、参照する詳細な仕様があると非常に役立ちます。仕様はリビングドキュメントである必要があることを覚えておいてください。要件が変更された場合（文書化された正式なプロセスを通じて）、仕様も変更される必要があります。はい、これにはさらに時間がかかる場合があります。私の経験では、それは価値があります（正しく行われた場合）。

ソフトウェアエンジニアは何を実装するかを知る必要があるため、プログラムの要件の正式な仕様が必要です。QAエンジニアは何をテストするかを知る必要があり、顧客は何を期待するかを知る必要があります。

スペックがあれば、プログラミングがいつ終わったかを知ることができます。

主なメリットの1つは安全性です。制御システムの仕様がリファレンス実装である旅客機で飛ぶのは嫌です。ソフトウェアに精通していない人でも理解できる形で、システムが何をする必要があるのか​​を誰かに明示してもらいたいです。各要件はテストによって完全に検証されていると思います。

安全性がそれほど重要でないシステムでは、仕様は通信ツールです。彼らは、システムを構築してテストするためにシステムが何をする必要があるかを詳細に説明する必要があります。システムがこれを行う方法は、コードの責任です。必要な詳細は、開発チームのドメインの専門知識とドメインの専門家へのアクセスによって異なります。

仕様は常に実装されたシステムと一致する必要があります。仕様にエラーが見つかった場合は、仕様を更新する必要があります。

私が見たエラー原因の見積もりは、テストの失敗が仕様、コード、テストのエラーに比較的均等に分割されていることを示しています。

この質問は、アジャイルとウォーターフォールのライフサイクルの問題の核心だと思います。

アジャイルを行う場合、基本的な前提は、詳細な仕様よりも、開発者との密接な相互作用を組み合わせたコードの方が優れており、高速であることです。チームは、詳細な設計仕様などの正式なコミュニケーションメカニズムなど、他のものよりも新機能と高品質のリリースを優先します。ただし、ここには取引があります。チームメンバー間には、ニュアンスや詳細な設計意図について必要なときに質問できるコミュニケーションチャネルが必要です。

ウォーターフォールを行う場合は、詳細設計の下でコードを入力してからテストする作業が重要であるという想定の下で作業しています。そして、この作業がどのように進行するか、そして作業がどのように行われるかについて関係者に早期の洞察を与える必要があります。それは、顧客に設計を精査して、意味のある機能の範囲を確認している可能性があります。また、安全レビュー、セキュリティレビュー、コードと統合する必要があるチームメンバーによるレビューなど、他の分野の専門家と精査することもあります。これらのレビューは、間違ったものを開発する際に大量の時間を調査する手間を省くため、長期的にはこれらのレビューによって時間を節約できると想定されています。

最近、詳細な設計とコードコメントツール（JavaDocなど）の間に本当に素晴らしい融合が見られました。ほとんどの詳細な設計はコードのフットプリントとそれが何をするかについての短い説明なので、これは多かれ少なかれ、コードのコメントとして期待するものと同じです。したがって、コードのコメントを詳細な設計仕様に変換するツールを用意することは素晴らしいことです。手動で行うよりも、最新の状態に保つためのはるかに優れた方法です。

プロジェクトの詳細設計の不正確な評価は、コスト増加の主な要因であると思います。最悪の部分は、あなたがそうするならあなたはのろわれ、そうでなければあなたはのろわれます：

• チームのサイズ、作業の複雑さ、および通過する必要があるゲートの要件（セキュリティレビュー、安全レビューなど）に対して設計が詳細すぎる場合、貴重な時間とお金を無駄に費やしています。決して使用しないアーティファクト。
• 設計の詳細が不十分な場合、チームメンバーが統合の問題につながる誤った仮定を行うため、費用が無駄になり、最終的なセキュリティまたは安全性の監査により、早期に安価に修正された可能性のある問題が発見された場合、多大なやり直しのリスクがあります。実装前の設計の明確な側面。

私はそれが白黒のケースだとは思わない-他の人が厳密な詳細な作業を必要とする一方で、いくつかのコンポーネントは高いレベルで設計された場合「十分」である場合がしばしばあります。また、チームやプロジェクトの環境が変化すると、プロジェクトの進展に伴って新しい設計のニーズが決まる場合があります。

現在大規模なプロジェクトに取り組んでいます。これまでの仕様では、QAがテストする対象を特定するのに役立ち、ユーザーテストの際に顧客に請求する金額を（数百万に相当）増やすことができました。コードレビューを行ってコードが要件を満たしているかどうかを確認し、開発者に、それらが終了したかどうかを確認し、仕様にポイントして、モジュールに何が含まれるべきかに関する紛争を解決することを許可することを許可しました。また、クライアントが製品を見る前にクライアントが必要とするものを生産していなかった開発者を特定することもでき、それは仕様に忠実に従えなかった一部の人々を排除するための根拠となった。スペックの複雑さは、コストと時間の見積もりにおいて私たちが法外なことをしていないことをクライアントが理解するのに役立ちました。

追加したかったのですが、スペックが良く、スペックがなく、スペックのないプロジェクトに取り組んできました。開発チームとクライアントは常に最終結果について異なる内部ビジョンを持っていたため、最悪の結果となったのは仕様のないものでした。これらは、「マインドリーディングモジュールはどこで入手できますか？」顧客が何を望んでいるかを推測することは恐ろしい経験です。悪いスペックはそれほど良くはありませんが、少なくとも「ここであなたが何を意味していたのかよくわかりません。」間違ったものを作るのに時間を無駄にする前に、より多くの情報を得るために。私が今取り組んでいる大きなプロジェクトは、驚くほど優れたスペックを備えており、それによって生活が楽になり、ストレスが大幅に軽減されます。

個人的には、詳細スペックは過大評価されていると思います。

私の経験では、顧客が必要とするものと顧客が必要と考えるものは、多くの場合2つの異なるものです。要件を早い段階で凍結すると、実際に必要なものではなく、彼らが必要と考えるものを構築することになります。法的には、あなたは安全な側にいて、あなたは支払いを受けます、しかしあなたは幸せな顧客を持っていません。

一方、ソフトウェア開発がある程度の探索的活動であることを受け入れる場合は、要件をできるだけ長く開いたままにしようとします。現在のイテレーションで何を知っている必要があるか、ユーザーと話し合ってください。そして、時には、後の反復でこれらの決定を再検討する必要があることを知っています。最も重要なこと：それが起こっても、それはクライアントの責任ではないことを覚えておいてください。ユーザーもソフトウェア開発者でない限り、要件の収集は職務記述の一部ではありません。それはあなたの仕事の説明の一部です。

では、機能のクリープを防ぐにはどうすればよいでしょうか。理想的には、機能のリクエストの受け入れまたは拒否を担当し、他の誰によっても却下されない健全な製品マネージャーがいることです。

アジャイルは10歳以上なので、これは新しい現象ではありません。

仕様がコードよりもはるかに短くなることを願っています。そのため、どれだけの詳細が必要かわかりません。チームメンバーをループに保つのに十分なはずです。お互いのコードをすべて読むことは実用的/必要ですか？

同意し、死んだ文書は必要ありません。私はむしろ、不正確なドキュメントよりもドキュメントのない見慣れないコードベースにアプローチしたいと思います。

コンピュータがコードの実行に非常に優れている場合は、独自の変更を行わせてみませんか？箱の裏側にあるレシピに従うことはあなたを料理人にするわけではありません。