廃棄するために1つを構築する対第2システム効果

一方では、「捨てる人を作る」というアドバイスがあります。ソフトウェアシステムを完成させて最終製品を確認した後にのみ、設計段階で何がうまくいかなかったかを理解し、実際にそれを行う方法を理解します。

一方、設計されている同じ種類の2番目のシステムは通常、最初のシステムよりも悪いという「2番目のシステム効果」があります。最初のプロジェクトには収まらず、2番目のバージョンに組み込まれた多くの機能があり、通常は非常に複雑で過度に設計されています。

ここで、これらの原則の間に矛盾はありませんか？問題に対する正しい見解は何ですか？また、これら2つの境界はどこですか？

私は、これらの「良い習慣」が、フレッド・ブルックスによる独創的な本「The Mythical Man-Month」で最初に宣伝されたと信じています。

これらの問題のいくつかはアジャイル方法論によって解決されることを知っていますが、根本的には、問題は依然として原則のままです。たとえば、重要な設計変更を3回スプリントすることはありません。

捨てるためのビルド1は、最初は「知らないことを知らない」ことに由来するため、最初に行うべきことを進めながら学びます。

2番目のシステム効果は、「今は知らないことを知っているが、まだ知らないことを知らない」ことから得られます。つまり、2番目のシステム効果は、開始時に必要-最初のシステムで何が起こるかとよく似ています。

したがって、2番目のシステム効果は矛盾ではありません。最初のシステムと同じ機能を持つ2番目のシステムを構築することは（私の知る限り）決して行われません。2番目のシステムは常に「より良い」ものでなければならず、したがってより複雑であるため、最初のシステムと実質的に同様の問題が予想されます。

したがって、1つを構築して捨て、それを捨て、スコープを拡大せずに再構築すれば、2番目のシステムの問題は発生しません。（これは、紫の空、ピンクの海、空飛ぶ豚の惑星でより頻繁に行われます。）

あなたが言及している問題は、いくつかのことをスキップしたことを意味します。そのため、結果のシステムはうまくいきませんでした。欠落しているステップのいくつかを説明しましょう。

品質管理-最初から正しく行う！一時的なハッキングや一時的なハッキングを決して使用しないでください。再作業は必要ありません。すべてのリソースが効率的に使用され、あなたがすることはすべてプロジェクトへの適切な貢献です。

実行可能性分析-ビジネスニーズを発見します。プロジェクトのビジネスケースを作成します。

プロジェクト計画-初期スコープを明確に定義し、ソリューションの提供方法を​​計画し、ベースラインを作成し、計画を守ります。クリティカルパスにないものに時間を費やさないでください。

要件エンジニアリング-ビジネス要件を引き出します（つまり、ビジネスプロセスをキャプチャし、コンピューター化されたシステムでサポートする必要があるビジネスオペレーションを決定し、1：1のビジネスオペレーションをシステムユースケースに変換します）。検証と検証！（正しいものを構築していますか？正しいものを構築していますか？）すべての要件は、元のビジネスニーズにリンクする必要があります。

ソフトウェア設計-ユースケースとドメインモデルをコンポーネント設計とソリューションアーキテクチャに変換します。すべてのコンポーネントは、REの要件にリンクする必要があります。

実装-ソフトウェアを設計どおりにコーディングします。すべてのコードは、SDのコンポーネントにリンクする必要があります。

検証-ユニットテスト、統合テスト、パフォーマンス、...（REのすべてのユースケースをテストする必要があります）

これらは、ソフトウェアプロセスの重要な側面です。言及されたアクティビティは、ソフトウェアエンジニアリングの一部です。これは、実際のビジネスニーズに適したソフトウェアソリューションを構築する方法であり、スケジュール通りに、予算通りに、仕様どおりに構築します。

これらの用語を調べて、より良いソフトウェアを構築し、最初から適切に使用してください。

• 実行可能性分析（特にビジネスケースの作成方法）
• プロジェクト管理（特にプロジェクト計画とリスク軽減機能付きリスク登録）
• 要件エンジニアリング（誘発、分析、仕様、検証）
• ソフトウェア設計（UMLおよびコンポーネントベースのソフトウェアエンジニアリング）
• ソフトウェア構築（設計パターン、フレームワーク、防御的プログラミング）
• ソフトウェア検証（ユニットテスト、UATなど）