開発後にソフトウェア設計文書を作成することは正当化できますか？

現在、「ソフトウェア開発」の研究のために卒業に取り組んでおり、外部企業で複雑なソフトウェアを個別に開発する必要があります。これはすべて、構造化された方法で行われ、対応するすべてのドキュメントを作成する必要があります。

このプロジェクトでは、IEEE要件文書（ソフトウェア要件文書（SRS）、ソフトウェアアーキテクチャ文書（SAD）、ソフトウェア設計文書（SDD））を使用することにしました。別の方法で学校で教えられましたが、このプロジェクトでは、開発前に（代わりに）開発後にSDDを作成することにしました。私の推論は：

私がインターンシップを行っている会社は、実験的な方法で、特定の要件を満たす複雑なソフトウェアを作成するよう指示をくれました。プロジェクトの定義で彼らが私に与えた自由の量のために、事前にほとんど何も確実ではなく、開発プロセスの実験中に最もよく遭遇することができます。さらに、私はソフトウェアを個別に作成していますが、このソフトウェア設計を事前に行うことは、社内の他の誰にとってもメリットがありません。プロジェクトの不確実性により、事前に作成したデザインを大幅に変更する必要があることを確信できるため、事前にそれを行うと、後で変更するのにかなりの時間がかかります。これは逆効果だと感じています。

これは、開発後にSDDを作成する正当な理由ですか？そうでない場合、そのための正当な理由はありますか？

編集：SDDを後で作成する理由は、将来の開発者がプロ​​ジェクトを継続するためです。私は卒業期間中にプロジェクト全体を終了することはできませんので、他の開発者は現在のコードベースを継続する必要があります。

IEEE Std 1016 Section 3.1ソフトウェア設計のコンテキストでは、次の段落を見つけることができます。

SDDは、さまざまな設計状況で準備および使用できます。通常、SDDは、問題を解決するためのソフトウェア項目の開発をサポートするように準備されています。この問題は、一連の要件の観点から表現されています。次に、SDDの内容をこれらの要件にトレースできます。それ以外の場合、SDDは、設計文書がない既存のシステムを理解する準備ができています。このような場合、SDDは、関心のある情報がすべての関係者に収集、整理、提示、および配布されるように準備されます。この重要な情報は、重要な設計上の問題を特定して対処することにより、ソフトウェアシステムの計画、分析、実装、および進化に使用できます。

IEEE Std 1016の著者は、SDDを事前に作成できないことを認識しています。関係者の情報を取得するために、ソフトウェアシステムの存在後に作成することができます。

セクション1.1スコープには、いくつかの興味深い情報もあります。

この規格は、設計、構成管理、または品質保証のための特定の方法論を規定していません。

この質問の文脈では、キーワードは「構成管理」です。構成管理は、作成されるソフトウェアシステムだけでなく、関連するドキュメントにも適用されます。

あなたの個人的な状況において、そして多くの状況において、SDDを前もって作成することは無駄です。デビッド・アルノの答えは、私が正しい答えと考えるものに近い。ソフトウェアシステムの真の設計はコードです。ただし、「前にSDDを作成」または「後にSDDを作成」が唯一のオプションではありません。3番目のオプションがあります-ソフトウェアシステムでSDDを進化させます。

IEEE Std 1016などの標準に従っている場合、SDDの要件があります。具体的には、この標準のセクション4で、所有するコンテンツを定義しています。設計の決定を進めながら、さまざまな視点、ビュー、オーバーレイを作成し始めます。決定を下す際に、それらの設計原理を把握してください。

これにより、関係者はコードを掘り下げることなく、ソフトウェア設計の進化を追うことができます。もちろん、人々はコメントや提案をするかもしれません。SDDを更新している場合、彼らはあなたの進行状況を追跡し、アプローチに関するフィードバックを早期に提供することができます。その後、製品とSDDに組み込むことができます。プロジェクトから移行するときに、ソフトウェアコードとSDDが同期していれば、誰かが簡単にオンボードして作業を開始できるはずです。

SDDから探しているのがデザインを他の人と通信することだけであれば、はい、開発後に作成できます。唯一のものは、ドキュメントと呼ばれることです。

ただし、SDDは別の目的にも役立つことを指摘したいと思います。また、設計について推論し、「早く失敗する」ことを確認するのにも役立ちます。これは、特に実装全体で早期に機能しないアプローチを破棄できるため、事前に多くの事柄が不確実な場合に特に便利です。また、設計を理解するまで何もコーディングしないことで、技術的な詳細にすぐに焦点を合わせることができなくなります。

少なくとも事前にSDDを試すことをお勧めします。どのように機能するかわからない状況に遭遇した場合、解決しようとしている問題の小さなプロトタイプを作成できます。これにより、プロジェクトの特定の問題を解決する経験が得られ、長期的には完全なソリューションの品質に役立ちます。

作成する1つの真の詳細設計ドキュメントはコードです。コンパイラにアプリケーションのビルド方法を正確に伝えます。そのため、出荷前の最終ビルドまで設計を完了できません。

SDDなど、作成する他のデザインドキュメントは、デザイン（コード）の完了後に更新する必要があります。したがって、後でSDDを作成する説得力のある理由があります。1回だけ作成する必要があります。

これに対する明らかな反論は、「イベント後にどれくらいの頻度で実際にSDD を作成するのですか」です。アプリは出荷されているので、その段階でドキュメントを作成するのに時間をかけたくないでしょう。ただし、これは既存のものの更新にも同様に適用されます。どちらが悪いのか、SDDがないのか、SDDが間違っていて信頼できないのですか？

ただし、事前に作成する理由は2つあります。第一に、そうすることはあなたにとって必須の要件かもしれません（いいことではありませんが、起こります）。次に、このようなドキュメントを作成すると、設計の全体的な戦略を策定するのに役立ちます。しかし、それは非公式の方法で絵を描いたり、メモを走らせたりすることによって同様にうまくいくことができます。また、後で書き直す必要があるため、その事前のマクロ設計プロセスに対する「迅速で汚い」アプローチには多くの利点があります。

私にとって、それは良い議論ではありません。

本当に必要な場合は、未知の問題領域をよりよく理解するために、プロトタイプ開発に重点を置いて議論します。ただし、そのような場合でも、以前はデザインの一部が有用でした。

とにかくそれを前もって行うために作られるべきケースがあります。このようなドキュメントを書くことを学ぶためにこれをしているからです。ここで100％必要ではない可能性があるため、この作業をスキップすると、学習をスキップすることになります。

妥協案は、実装中に作成することです。各コンポーネント/モジュール/画面またはプログラムの他の細分化の前に、それをどのように作成するかについて考える必要があります。次に、設計文書に決定を追加してから、それらを実装します。

後で変更があった場合は、ドキュメントを更新します。

これには、事後の記述に比べていくつかの利点があります。

• 要件が変更されたときに設計文書を最新の状態に保つことを学びます。これは便利な習慣です

• 実装前に設計について考えることを学びます

• 事実の後にデザイン文書を書くほど退屈ではありません

• 時間がない場合は、他の人が作業を続行できるように、これまでに持っているものを記述した設計ドキュメントがあります

• このように多くの余分な仕事ではありません

• プロジェクトが進行するにつれて、2か月前に自分がなぜそのようにしたのかがよくわからない場合があります。

システム設計文書。基本設計の記録に加えて、プロジェクトが新しい設計およびソリューションの属性とともに前進するときの（新機能）の更新。プロジェクト/ソリューションが提供されるまで維持されます。役に立つ、それは関係者全員と通信する。