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


8

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

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

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


7
なぜそれは「枯れ木」でなければならないのですか?なぜwikiやPDFではないのですか?
フィリップリーガン、2011年

@フィリップ:原則的に理由はありません。非常に正式な文書は、特に私が描いているような大きな官僚組織では、枯れ木に書かれる傾向があるというだけのことです。
dsimcha

ソフトウェアの仕様は、プログラマーが自分で使用するのに最適ですが、最終製品に対する期待を具体的に定義して、魔法をかける前に、顧客に使用するのがさらに良いでしょう。
ToTheBeach

2
私は高水準の仕様を支持しています。クライアントが何を取得しているかを理解し、開発者がクライアントが何を望んでいるかを理解するのに十分な詳細。これ以上の詳細は、コードの代わりにドキュメントを維持することになります。
Berin Loritsch

@Berin:そうですね、これは私が非公式な高レベルの仕様で意味したものです。この質問を書いたとき、私はビジネスソフトウェアよりも標準(たとえば、C ++コンパイラ)について考えていました。
dsimcha

回答:


37

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

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

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


13
私の唯一の後悔は、私にはこの知恵を与えるための賛成票が1つしかないことです。
ダン・レイ

3
+1。知恵。とは言っても、私が最後に取り組んだのはサブスクリプションベースのビジネスモデルで、クライアントは既存のライセンスの支払いを続けながら、必要な他の機能について叫び続けました(たとえば、スコープクリープ-しかし、彼らは同時にあなたにお金を払っているので、あなたは彼らを幸せにしたいです。しかし、通常、スコープクリープを実装している間は報酬は支払われません。また、そのビジネスモデルは、開発者を行き止まりのコードモンキーのように感じさせることができます。
Bobby Tables

1
+1エンジニアリングのHVAC制御システムを介してプログラミングに行きました-建物の一般的な仕様は数百ページになります。プロジェクトはすべてのポイントがチェックされたときにコンサルタント/クライアントによって受け入れられました-バリエーションはコストと延長された期限を招くでしょう。問題は-何らかの理由で、一般的なソフトウェア開発では仕様が実装者によって書かれるべきだと思われます-私はこれは間違っていると思います-HVACでは、仕様は建築コンサルタントを介して来ました(ただし、実装者はクエリして挑戦することができます)いつでも仕様)。
HorusKol

1
「完了時間が近づくにつれて、彼らは絶対に必要な10,000の小さなものを発見するでしょう」しかし、それはカスタムメイドのソフトウェアにのみ当てはまります。シュリンクラップされたソフトウェアまたは社内ソフトウェアを開発する場合、それが完了したと言ったときに完了します。追加機能のリクエストは常にあります。それらのいくつかは、将来のリリースに含まれる予定ですが、含まれないものもあります。詳細な仕様のメリットはここではわかりません。
nikie、2011年

2
@nikie:Duke Nukem設計チームに伝えてください。あなたはQA、マーケティング、あまりにも多くの雑誌を読むphbsに対処しなければなりません...それはまだ重要です。
Satanicpuppy

8

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

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


8

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

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


1
プロジェクトの全期間を通じて仕様を維持するための+1。
Chuck Stephanski

6

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

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


1
OPが詳細設計仕様の有用性について質問していたと思います。よく書かれた要件ドキュメントがプロジェクトの成功に不可欠であることは誰もが知っています。細部の設計仕様が、はるかに低レベルのプログラミング言語を使用していたときと同じくらい今日でも役立つかどうか、私にはよくわかりません。その当時、詳細な設計仕様は、コード化する必要があるものを疑似コードで示していました。実装されたコードは、コードレビュー中に疑似コードと照合され、正確であることを確認しました。この指向には、仕様からコーディングしたアンダークラスのプログラマーを生み出すという副作用もありました。
bit-tiddler 2011年

3

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

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

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

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


3

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

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

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

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

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

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

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


2

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

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


+1-これは、技術者と非技術者がさまざまな方法で全体像を把握しているビジネスであることを理解する必要がある場合があります。
JeffO 2011年

2

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

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

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

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


1

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

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

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.