開発後にソフトウェア設計ドキュメントを作成することは正当化できますか？
現在、「ソフトウェア開発」研究の卒業に取り組んでいます。この研究では、外部の会社で複雑なソフトウェアを個別に開発する必要があります。これはすべて構造化された方法で行われ、対応するすべてのドキュメントが作成されます。
このプロジェクトでは、IEEE標準ドキュメントであるソフトウェア要件ドキュメント（SRS）、ソフトウェアアーキテクチャドキュメント（SAD）、およびソフトウェアデザインドキュメント（SDD）を使用することを選択しました。学校では別の方法で教えましたが、このプロジェクトでは、SDD after開発（前ではなく）を作成することを選択しました。私の推論は：
私がインターンシップを行っている会社から、特定の要件を満たす複雑なソフトウェアを実験的に作成するように指示されました。彼らがプロジェクトの定義で私に与えた自由の量のために、ほとんど何も事前に確実ではなく、開発プロセスで実験しているときに最もよく遭遇することができます。さらに、私はソフトウェアを作成しています個別の方法で、私がこのソフトウェアデザインを事前に作成することは、社内の他の誰にとってもメリットがありません。事前に行うと、後で変更するのにかなりの時間がかかります。プロジェクトの不確実性のために、私が事前に作成した設計は確かです大幅に変更する必要があります 。これは私にとって逆効果です。
これは、開発後にSDDを作成する正当な理由ですか？そうでない場合、そのための正当な根拠はありますか？
編集：SDDを後で作成する理由は、将来の開発者がプロジェクトを続行するためです。卒業期間にプロジェクト全体を完了することはできないので、他の開発者は現在のコードベースを継続する必要があります。
IEEE Std 1016セクション3.1ソフトウェア設計のコンテキストでは、次の段落を見つけることができます。
SDDは、さまざまな設計状況で準備および使用できます。通常、SDDは、問題を解決するためのソフトウェア項目の開発をサポートするために用意されており、この問題は一連の要件の観点から表現されています。 SDDの内容は、これらの要件までたどることができます。他の場合では、SDDは、設計文書がない既存のシステムを理解する準備ができています。そのような場合、SDDは、関心のある情報が取得、整理、提示され、すべての関係者に配布されるように準備されます。この重要な情報は、重要な設計上の懸念事項を特定して対処することにより、ソフトウェアシステムの計画、分析、実装、および進化に使用できます。
IEEE Std 1016の作成者は、SDDを事前に作成できないことを認識しています。関係者のために情報を取得するために、ソフトウェアシステムが存在した後に作成することができます。
セクション1.1スコープでは、興味深い情報も提供されます。
この標準は、設計、構成管理、または品質保証のための特定の方法論を規定していません。
この質問に関連して、キーワードは「構成管理」です。構成管理は、作成されるソフトウェアシステムだけでなく、関連するドキュメントにも適用されます。
個人的な状況や多くの状況で、SDDを事前に作成することは無駄です。 David Arnoの答え は、私が正しい答えと考えるものに近いです。ソフトウェアシステムの真の設計はコードです。ただし、「SDDを前に作成する」または「SDDを後で作成する」だけが選択肢ではありません。 3番目のオプションがあります-ソフトウェアシステムでSDDを進化させます。
IEEE Std 1016などの規格に従っている場合、SDDの要件があります。具体的には、この標準のセクション4は、ユーザーが所有するコンテンツを定義しています。設計の決定を進めるときは、さまざまな視点、ビュー、およびオーバーレイの作成を開始します。決定を下すときに、それらの設計の根拠を把握します。
これにより、関係者はコードを掘り下げる必要なく、ソフトウェア設計の進化を追跡できます。もちろん、人々はコメントや提案があるかもしれません。 SDDを更新している場合、彼らは進捗状況を追跡し、アプローチに関するフィードバックを早期に提供できます。フィードバックは、製品やSDDに組み込むことができます。プロジェクトから移行するときに、ソフトウェアコードとSDDが同期している場合は、誰かが容易にオンボードして作業をピックアップできるはずです。
SDDから探しているのがデザインを他の人と通信することだけであれば、はい、開発後に作成できます。唯一のことは、それがドキュメントと呼ばれることです。
ただし、SDDは別の目的にも使用できることを指摘しておきます。また、設計について推論し、「すぐに失敗する」ことを確認するのにも役立ちます。これは良いことです。特に、実装全体で機能しないアプローチを早い段階で破棄できるため、事前に多くのことが不確かな場合はそうです。また、設計を理解するまで何もコーディングしないことで、技術的な詳細にすぐに集中するのを防ぐことができます。
少なくとも事前にSDDを試すことをお勧めします。どのように機能するかわからない場合は、解決しようとしている問題の小さなプロトタイプを作成できます。これにより、プロジェクトの特定の問題を解決する経験が得られ、長期的には完全なソリューションの品質にメリットがあります。
作成する真の詳細な設計ドキュメントはコードです。アプリケーションのビルド方法をコンパイラーに正確に伝えます。そのため、出荷前の最終ビルドが1つになるまで、デザインを完成させることはできません。
SDDなど、作成したその他の設計ドキュメントは、設計（コード）の完了後に更新する必要があります。したがって、SDDを後で作成することには説得力のある理由があります。それは、一度だけ行う必要があります。
これに対する明らかな反論は、「実際にどのくらいの頻度でSDD afterイベントを書き込むか」です。アプリは出荷されているので、その段階で文書化に時間を費やすことはあまりありません。しかし、これは既存のものを更新することに等しく当てはまります。さらに悪いのは、SDDがないか、SDDが間違っていて信頼できないということですか？
ただし、事前に作成する理由は2つあります。第一に、そうすることはあなたにとって強制的な要件かもしれません（ニースではありませんが、それは起こります）。次に、そのようなドキュメントを作成すると、設計の全体的な戦略を策定するのに役立ちます。しかし、絵を描くこと、メモを落書きすることなどを非公式な方法で行うことで同様にうまくいくことができます。そして、後で書き換える必要があるため、その先行マクロ設計プロセスへの「迅速かつダーティー」なアプローチには多くのメリットがあります。
私にとって、それは良い議論ではありません。
本当に必要な場合は、未知の問題領域をよりよく理解するために、プロトタイプ開発に重点を置いて議論します。ただし、そのような場合でも、以前は一部のデザインが役立ちます。
とにかく前もって行うの場合があります。これは、このようなドキュメントの記述についてlearnを行うためです。ここで100％必要ではない可能性があるため、この作業をスキップすると、学習がスキップされます。
妥協はそれを書くことである可能性があります中実装。プログラムの各コンポーネント/モジュール/画面またはその他のサブディビジョンの前に、それをどのように作成するかについて考える必要があります。次に、決定事項を設計ドキュメントに追加して、実装します。
後で何か変更があった場合は、ドキュメントを更新します。
これには、事後の記述に比べていくつかの利点があります。
要件が変更されたときに設計ドキュメントを最新の状態に保つ方法を学習します。これは便利な習慣です
実装前に設計について考えることを学びます
事実が終わった後に設計ドキュメントを書くほど、面倒なほど退屈ではありません。
時間が足りなくなった場合、他の人があなたの仕事を続けることができるように、あなたが今まで持っているものを説明するデザインドキュメントを手に入れます
この方法では余計な手間はかかりません
プロジェクトが進むにつれ、2か月前に自分がなぜそのように何かをしたのかよくわからないかもしれません。