mod / techproject / view / concepts / associations

索引

マッピング(団体)

プロジェクトの実行中に収集される説明の多くは、プロジェクトの同じ部分についての説明です。仕様は多くの場合要件に関連しており、タスクはいくつかの仕様を達成または実装しています。タスクの完了は成果物を生み出します。

マッピングは、実行中の作業について自動チェックを実行できるように、エンティティユニット間の依存関係を記述します。ユニットを他のユニットに割り当てると、すべてのプロジェクトの説明内でスムーズにブラウズでき、非常に複雑な作業であってもモジュールは時間と労力を制御できる全体的な監視ビューを生成できます。

ツリー状のエンティティ内のマッピング

プロジェクト管理の概念は、初心者にとって非常に扱いにくいもので、記述子は多くの場合複雑なアーキテクチャーです。このモジュールは、そのような複雑さをよりよく理解するのに役立ち、それを管理するための実用的なツールを提供します。

ツリー内のマッピングは、階層がどのように使用されるかについていくらか知っておく必要があります。

一般的なケース

3レベルの精密化ツリーを考えます。レベル1はルートカテゴリです。レベル2はサブカテゴリです。レベル3はアイテムです。ルートレベルの要素に 、そのすべてのサブツリーが含まれています。それはこのブランチ内のより詳細な要素によって改良されるかまたは作られます。

techprojectツリー理論1.gif

今度は、以前と同じレベルの概念を共有する、別の3レベルの改良ツリーを考えてみましょう。

これで、後者の任意の単位を前者のある単位にリンクしたいと考えることができます。非常に一般的な単位を選択した場合、たとえソース単位が非常に特殊なものであっても、ほぼすべてのサブ要素がソース単位との関連付けに貢献すると考えます。いくつかのサブユニットが関連ルールを処理しない場合、ここでリンクするのではなく、下位ノードにリンクします。

techprojectツリー理論2.gif

上の図では、Nodeがエンティティエントリを認識している場合、SubnodeはNodeを構成しているので、そのSubnodeもそれを認識することを確認できます。

ここに本質的な結論があります:木の形をした実体からのユニットが別の木の中のユニットに関連しているとき、それは実際のターゲットの子孫でも優勢で他のどのユニットとも関連付けることができません。

techprojectモジュールのステップ1は、この規則をチェックしません。ステップ2は行います。

マッピング:仕様への要求

要件は、その意味での仕様にマッピングされます。仕様は、要件を実現する技術的サブセットの説明です。

マッピング:タスクへの仕様

仕様は、ある意味でタスクにマッピングされます。つまり、タスクとは、システムのサブセットを構築して関連する仕様を実現するために計画したアクションの説明です。

マッピング:成果物へのタスク

関連するタスクの結果として成果物が作成されるという意味で、タスクは成果物にマッピングされます。

特別な場合:タスクからタスクへ

タスクによっては他のタスクにマッピングされます。アクションによっては、以前に実行した別のタスクが必要になる場合があるためです。このタスクを相互依存と呼びます。