私が共有したいアイデアは、深く呼ぶことはできません。むしろ、それは表面にありますが、誰もがそれに気付くわけではありません。
アルゴリズム分析と同様の方法を使用して、追加機能の開発にかかる合計時間やコストなど、ソフトウェア製品を開発するためのプロジェクト管理システムの特性の漸近的な動作を評価できます。
たとえば、製品の利点のリストでは、「スケーラビリティ」という言葉がよく使われますが、この曖昧な用語の代わりに、システム/プログラムモジュール/インスタンスのユーザー数に対する漸近的なパフォーマンスまたは管理コストは、たとえば、
一方、彼らは別のプロジェクトについて、「自重でバラバラになっている」と言う。 このプロジェクトは順調に開始できましたが、アーキテクチャは、変更の貧弱な漸近的価値によって台無しになるように構築されました。
3つの例を考えてみましょう。これらは、外部的にはさまざまな効果を説明していますが、綿密な調査には多くの共通点があります。
例1、取るに足らない
かつてキャリアを始めたすべてのプログラマーは、小さな初期データセットでのタスクにうまく対応しているように見えるプログラムが、情報量が増えるにつれて信じられないほど「減速」し始めたという事実に直面しました。 トラブルを予感させるものは何もありませんでした。すべてのエラーをデバッグし、10個のレコードのテストセットはすべての可能なオプションを考慮に入れていたと確信しました。 将来のユーザーも満足していました。彼らは初期データセットのすべてをチェックし、コメントを削除し、プログラムが作業環境で使用できると信じていました。 プログラムが起動し、大災害が発生します。実際の状態ではシステムを使用できず、すべてが「ハング」します。
もちろん、それは次善のアルゴリズムまたはデータ構造です。 少数の要素（動的な配列に要素を1つずつ追加する）で迅速に機能する便利なメソッドを呼び出す、無害な入れ子のループ-を提供するシステムがあります
例2
開発プロジェクトマネージャーは、新しい開発者をプロジェクトに導入すると、「分離可能な」「孤立した」タスクを何とかしていない限り、一般的な状況がどれほど悪化し混乱するかを知っています。 F.ブルックスの古典的な本「 神話上の男の月 」で説明されている法律は、「新しい従業員を引き付けることは、ソフトウェア製品を作成するためのスケジュールを削減するのではなく、延長する」と述べています。 このステートメントには、非常にシンプルで数学的に正確な説明があります。
開発プロジェクトに必要な時間の関係するアーティストの数への依存性、ブルックスは次のように設定します。
- 分離できないタスク-これらのタスクを完了するのにかかる時間は従業員の数に依存せず、常に等しい
;
- 共有タスク-従業員数の増加に伴い、タスクを完了する時間が短縮されます。
;
- 情報交換-ブルックスは文字通り次のように書いています。「すべてのタスクを相互に個別に調整する必要がある場合、
「。 利用可能な場合
「全員と全員」の調整に関与する従業員の数は、フルグラフ（頂点の各ペアが接続されているグラフ）の接続数に比例します。
これらの人件費は。
したがって、プロジェクトの合計実行時間は、次の形式の曲線によって決まります。
そのようなスケジュールを持っている：
工数のコストは、フォームの式によって決定されます
F.ブルックスの主なアイデアは次のとおりです。チーム内の開発者の数を増やすと、プロジェクトの条件が特定の制限までしか減少せず、それを超えると条件が増加します。 得られたパターンにO表記を適用すると、Brooksプロジェクトでは、パフォーマーの数が増えると、実行時間が次のように増加します。
新しい従業員を期限までにプロジェクトにつなぐかどうかによって決定が決まるマネージャーにとって貴重な知識ではありませんか？
例3
「ひどく成長する」依存のもう1つの古典的な例は、 エクストリームプログラミング方法論に関するすべての書籍に記載されています。これは、プロジェクトの段階に応じて変更コストが増加することです。
開発中のソフトウェアプロジェクトが完全なグラフに似ていることを理解していれば、この依存関係を再度説明することは難しくありません。グラフの頂点は、プロジェクトに関連するアーティファクトです：ソフトウェアモジュール、要件、テスト、ドキュメント：
そのようなグラフに次の各頂点を追加することは、既存の頂点との接続がますます増えるにつれて、毎回ますます高価になっています。 さらに、多くの場合、既存の複数の頂点を更新し、関連する新しい頂点（変更インターフェイス、テスト、ドキュメント）を更新する必要があります。その後、平衡に達するまでカスケードおよび雪崩のようにシステム全体で変更が発生し始めます。 プロジェクト内のアーティファクト間の関係がどのように機能するかに応じて、高指数の多項式を取得できます
そのような活動の結果、ある時点で、プロジェクトの開発は「行き詰まり」、古い問題を取り上げ始めるたびに、新しい変更は容認できないほど遅く、非常に困難で、「これはすべて書き直されるべきです」、言い換えれば、プロジェクトはバラバラになります自重で。
結論
上記の例は完全に異なる効果を説明しているという事実にもかかわらず、それらはすべて共通点が多いことが容易にわかります。すべてがうまく始まり、ひどく終了し、イベントのさらなる開発中にシステムの主要なパラメーターの漸近的挙動を推定できないことは非難です。
最初の例では、適切な漸近性を持つアルゴリズムまたはデータ構造を選択することで問題を解決します。
2番目と3番目の例では、問題は完全なグラフでの接続の非線形成長にあります。システムが完全なグラフに似ている場合、要素の数が増えてもイベントの適切な発生は期待できません。 もちろん、接続を含むグラフのモデルは定量的ではなく、例示的であり、定性的です。したがって、接続のグラフは厳密な意味で完全である必要はありません。 一方、のグラフに存在できる最小数のリンク
システムに接続を「星形」に、または直線的に、またはその他の方法で生成した
実際にこれを達成する方法についてのいくつかの言葉。 一般原則を使用して、ソフトウェアアーキテクチャからプロジェクトに携わる専門家の労働組織まで、プロジェクトはあらゆる面で最適化される必要があります。
アプリケーション設計レベルでは、「プラットフォームアドオン」または「プラットフォームプラグイン」の「星型」アーキテクチャを活用できます。 このアーキテクチャには、アプリケーションの「コア」または「プラットフォーム」という基本的な部分があり、可能な限り細心の注意を払って開発され、ほとんど変更されません。 すべてのアプリケーション機能は、カーネルサービスを使用し、カーネルの助けを借りてのみ相互に対話する独立した「プラグイン」の形式で開発されます。 コア自体はアドオンに依存しません。 オブジェクト指向開発環境では、「ソース-サブスクライバー」パターン、特に「メディエーター」デザインパターン（別名「メディエーター」）を使用して、この原則の非常に便利なソフトウェア実装が可能です。
前述に基づいて、アドオンの開発者間の相互作用を節約し、アドオンを相互に一致させることで、このようなアーキテクチャをプログラミングするための初期オーバーヘッドの一部が将来的に報われることはすでに明らかです。 タスクはそれ自体で分離可能になり始め、新しい開発者をプロジェクトに接続することは簡単で安全になります。
Brooksが説明する効果は、プロジェクトでコミュニケーションを確立することによっても軽減する必要があります（人件費の「2次」部分を削減します）。 「セントラルピーク」 、目的の目的地の検索に時間を無駄にすることなく。 プロジェクトマネージャーは、コミュニケーションの問題が巨大なプロジェクトの問題であるだけでなく、4人の参加者の間でも発生し、成長とともに真の宇宙規模に達することを知っています。
Extreme Programming Methodologyは、達成するためのさまざまな手段を提供します
すでに述べたように、この記事で提示されたアイデアは表面にあります。 開発者がタスクが複雑なときにアルゴリズムの動作を評価できる場合、その成長と開発の過程で開発プロジェクトのパラメーターの動作を同様に予測し始めませんか？ アルゴリズムを最適化して、不要なサイクルと計算を取り除くことができたら、開発プロジェクト全体を同様の方法で最適化し、不要な関係と依存関係を削除してみませんか？
UPD：続きを読む
優れたアーキテクチャの兆候に関するこの記事をお勧めします。 システムのスケーリングを提供する有能な分解についてそこに提示されたアイデアは、実際、私の記事からの非常に一般的なアイデアのより実質的な議論です。