AからZまでのITプロジェクトで要件を作成する方法。パート5。主題分野の本質と戦略について少し説明します。

VIII対象領域の本質を決定します

表示されるのは、1つの可視性のみです。

世界の表面から底まで。

世界の取るに足らないマニフェストを考慮し、

物事の秘密の本質は見えないため

オマール・カヤム

抽象製品ストレージを定義することにより、詳細なデータモデルを構築するためのバックボーンが得られます。 製品エンティティの構造を設計する場合、標準的なEntity-Linkダイアグラム（ERD）、論理ダイアグラム（論理ダイアグラム）、またはクラスダイアグラム（クラスダイアグラム）を使用すると便利です。



この一連の作業の目的は、製品で使用するデータウェアハウスのモデルを設計し、システムの本質とそれらの相互作用を文書化することです。



このタイプのダイアグラムを設計する理論は、UMLを使用した作業を説明している文献に詳細に説明されています。 たとえば、このトピックは[11]で非常によく提示されています。 したがって、私は私の意見で興味深いいくつかの側面にのみ焦点を当てます。



図8.1は、サブジェクト領域のエンティティを決定するためのサブプロセスによって補完される、ターゲットシステムの要件を形式化するプロセスを示しています。





図8.1-サブジェクトエリアのエンティティを決定するプロセスのモデル



システムでモデル化されたエンティティの性質をよりよく理解するために、エンティティを次のタイプ（リソース）に分類できます。

• 物質\物質-すべての物質、「体」、質量、範囲、空間内の局在化、微粒子特性を示す。
• エネルギーは、さまざまな形の運動と物質の相互作用、物質の変動性の反映、ある種から別の種への遷移の単一の尺度です。
• 情報-コミュニケーションのプロセスにおける物質世界の事実の反映として人または特別な装置によって知覚される情報。
• 人間は最高レベルの知性の運搬人です。 経済的、社会的、人道主義的な意味で、社会の最も重要でユニークな資源であり、理性、知性、意図的な行動の尺度、社会的原則の尺度、物質の最高の形の反射（意識）として機能します。
• 組織は、社会における資源の形態であり、人間社会の制度やその上部構造を含むその構造を決定するグループは、資源の秩序の尺度として機能します。 システムの組織は、たとえば、生物学的、情報的、環境的、経済的、社会的、時間的、空間的など、さまざまな形をとることができます。
• スペースは、物質（イベント）の範囲、環境内での分布の尺度です。
• 時間は、物質、イベントの可逆性（不可逆性）の尺度です。 時間は現実の変化と密接に関連しています。

ほとんどのリソースは、本質的に密接に相互接続されており、互いに存在し合うことはできません。 したがって、検討中のサブジェクトエリアで1つのリソース（エンティティ）を識別する場合、上記の類型を使用して、関連するリソース（エンティティ）-衛星を決定できます。 また、開発中のモデルの観点から重要な場合は、このモデルにそれらを含めるようにします。 また、さまざまなタイプのエンティティを記述するための特定のテンプレートを開発して、重要なプロパティ、ライフサイクルの状態などを見逃さないようにし、単一の標準に従うことができます。



モデルにエンティティを含める/除外する決定を行う場合、「システム分析」の主要原則の1つに導かれる必要があります。システム全体の要素の全体を考慮するか、または反対から、システムを要素の単純な組み合わせと見なすことの禁止です。



忘れてはならないもう1つの重要な原則は、システムをその環境と統一してのみ考慮する必要があるということです。 つまり、すべてのシステムは、より一般的なグローバルシステムの一部と見なされる必要があります。

1.カプセル化を使用する

「カプセル化」という用語には、いくつかの解釈と解釈があります。 私は次のオプションが好きです：カプセル化-主要なものの可用性を確保し、干渉するすべてのものを条件付きカプセル（ブラックボックス）に二次的に配置することで主要なコンテンツを強調します。 システム分析の観点から、それは抽象化プロセスの要素です。



ご存知のように、カプセル化は、オブジェクト内の実装を隠し、製品全体のエラーの広がりを局所化するため、システム全体の「脆弱性」を低減します。 このトピックは本[8]で非常にうまく述べられています。 この原理に基づいて構築されたシステムは、簡単にアップグレードでき、構造全体を簡単に置き換えることができます。 また、異なるチームによる個々の製品モジュールの開発にも非常に効果的です。



したがって、システム構造を開発するときは、特定の専門化を担当する自給自足のモジュール、サービスなどに分割してみてください。 これらの構成体は、明確に定義されたインターフェースを介して互いに通信することが望ましい。

モジュール（システムの一部）の自己完結型セグメントへの断片化の例を図8.2に示します。 システムの要素とそれらの相互作用を視覚的に把握するには、「アプリケーションアーキテクチャ」の図に基づいて構築されたモデルを使用すると便利です。





図 8.2-モジュールプロジェクト管理のアーキテクチャのフラグメントの図



図からわかるように、「プロジェクト実行管理」モジュールは3つのセグメントに分割されています（図では緑色の「パズル」で示されています）。

• タスクテンプレートの形成;
• ジョブ管理;
• タスクの実装の会計。

モジュールには、このモジュールの実装をシステムの他の部分から分離し、他の（システム）要素と「通信」できるようにするインターフェースメソッド（左側に表示）があることに注意してください。



検討中のモジュールで3つのセグメントを識別したので、3つの別々の図でデータ構造を設計することも便利です。 一部のセグメント用に設計された要素は、他のセグメントの図で使用できます（セグメントの署名で強調表示されます）。 大規模なプロジェクトでは、これは非常に重要なポイントであり、設計されたオブジェクトの海に「drれ」ないようにします。



図8.3は、利害関係者管理セグメントのクラス図の例を示しています。 クラスに注意してください：「タスクマップ」と「タスクマップのステータス」は、上記で検討した「プロジェクト実行管理」モジュールの別のセグメント「タスク管理」に属します。 この場合、他の図で設計された要素には通常、親図へのリンク（署名）があり、要素（クラス）の名前の下に括弧で示されています。





図 8.3-利害関係者管理セグメントのクラス図



先に進んで図8.5を見ると、上記の別のセグメントのクラス図の例-「タスクテンプレートの作成」があります。



ただし、カプセル化が複雑すぎると管理性が低下し、モジュールの適用範囲が狭くなることに注意してください。 これについては、次の章で詳しく説明します。



したがって、「アプリケーションアーキテクチャ」の図を抽象化の開始点（トップ）として使用し、システムを提示するのが便利です。システムの各要素は、たとえばクラス図の形式で提示される構成です。

2.事業体の分解を効果的に使用する

システム分析の観点からの分解は、調査中のシステムをサブシステムに、タスクをサブタスクに分割するなどの方法であり、それぞれが独立して解決されます。



分解は、切断のプロセスとして、検討中のシステムを複雑なものと見なすことができます。これは、相互接続された個別のサブシステムで構成され、サブシステムは部分に分割することもできます。 システムは物質的なオブジェクトであるだけでなく、プロセス、現象、概念でもあります。



エンティティを設計するときは、さまざまなイベント中にその属性の一部が変更されると、エンティティがこれらのイベントに対応する部分に分割されるように分解してみてください。 たとえば、エンティティ要件には次の属性があります。

1. 識別子
2. 作成日;
3. 見出し
4. 説明;
5. 状態;

この例では、属性IdentifierおよびDate createdは、レコードが作成されたときにのみ変更されます。 属性の説明とタイトルは、要件が明確になったとき、または顧客のニーズが変化したときに変更される場合があります。 また、タスクがオンデマンドで設定されて完了すると、ステータス属性が変更されます。 すべての変更の履歴があると便利です。 したがって、エンティティ「要件」は3つのリレーショナルテーブルに分割できます。1）要件の仕様、2）要件の内容、3）要件のステータス、図8.4を参照





図 8.4-要件クラス図



ただし、この手法を使用して、Coddの9番目のルールをサポートすることを忘れないでください。

ルール9：論理データの独立性：

アプリケーションでのデータの表示は、リレーショナルテーブルの構造に依存するべきではありません。 正規化プロセス中に1つのリレーショナルテーブルが2つに分割される場合、ビューはこのデータが結合され、リレーショナルテーブルの構造の変更がアプリケーションの動作に影響を与えないようにする必要があります。

私の練習では、チームが500を超えるフィールドを持つテーブルを使用した場合があり、異なるイベントが属性の一部のみを変更し、データタプル全体が記録されました。 また、このようなテーブルの履歴を保持することは非常に無駄です。 ソーステーブルの1つのフィールドを変更すると、すべての属性の値とともに新しい行が履歴テーブルに書き込まれます。



しかし、コインには裏返しがあります。 非常に細かく分解して、複雑なエンティティを限られた数の属性を持つ多くの単純なエンティティに分割すると、最終的には大規模なプロジェクトで、理解して把握するのが難しく、したがって維持するのが難しい構造になる可能性があります。



私の意見では、構造の複雑さは、プロジェクトに関与する開発者とアナリストの資格、およびチームが使用するツールの能力に比例するはずです。 しかし、複雑な構造を使用する立場を採用する場合、強力なチームがあっても、遅かれ早かれ、チーム（チーム）またはそのメンバーを失い、製品のサービスと開発が困難になる可能性があります。

3.適応データモデルの使用

多数のエンティティの使用によって引き起こされる複雑さを軽減するもう1つの機会は、データ処理のユニバーサル化メカニズムの使用です。 たとえば、テンプレートの使用、どのインスタンスが作成されるかに基づいた典型的なエンティティ。 このようなモデルは適応型と呼ばれます。 適応を伴う管理の概念は、制御されたプロセスに関する事前情報が不完全なシステムでの管理を意味します。情報は蓄積され、システムの品質を改善するために使用されます。



ただし、ここで同じジレンマが発生します。ユニバーサル化メカニズムは、対応するメカニズムなしで使用できるデータ構造の複雑さを超えてはなりません。



システム設計時には、製品の機能開発の見通しを決定する必要があります。 最初の段階でのユニバーサル処理の特定のメカニズムが部分的にのみ関与することがわかっているが、さらにロードする可能性がある場合、そのようなメカニズムをすぐに設計および構築する必要があります。 これにより、製品のさらなる開発中に大幅な補償と時間の節約が実現するだけでなく、サポートされるエンティティの数も削減されます。



適応システムの設計と実装における避けられないコストを削減するには、ソリューションの選択において次の側面を考慮する必要があります。

1. 固定アルゴリズムによる基準の最適な選択。
2. 固定基準に最適な適応アルゴリズムを選択します。
3. アルゴリズムと基準のバリエーション。

テンプレート割り当てメカニズムの使用例を簡単に確認しましょう。図8.5を参照してください。 図では、青色はテンプレートまたは典型的なエンティティをモデル化するエンティティを示し、緑色はこれらのテンプレートに基づいて形成されたオブジェクトをシミュレートするエンティティを示します。





図 8.5-テンプレートによるジョブの形成のクラス図



サブジェクトエリアの用語を統一的に認識するために、用語集を補充します。







したがって、典型的なエンティティ「タスクマップテンプレート」（以下、ShKZという名称を使用）は、その構造に基づいて、エンティティ「タスクマップ」のインスタンスを形成することを目的としています。 つまり、タスクカードテンプレートの特定のセットを作成したので、将来それらを使用して、プロジェクトで作業するための新しいタスクカードをすばやく入力できるようになります。



次に、ShKZの構造について詳しく説明します。 ShKZには、集約として典型的なエンティティ「リアテンプレート」が含まれ、そのインスタンスを1つのビジネスシナリオにリンクします。 ShKZでは、プロセスの責任者を決定するために、確立された位置（位置）が示されます。 この要件は、新しいタスクカードであるShKZに基づいて形成する場合、現在組織内のポジションに割り当てられ、タスクグループのキュレーターの役割を申請しているユーザーを自動的に識別します。



上記の次の典型的なエンティティは、新しいタスクを生成するように設計された「タスクテンプレート」であり、そのような属性によって特徴付けられます：中等学校でのタスクの順序、タスク実行者の位置、アクティビティのタイプ、および（ボーナスとして）構成可能なパラメーターのリスト タスクテンプレートのパラメーターは、アプリケーションの可変性を拡張する追加のメカニズムとして使用され、着信または発信として割り当てることができます。 原則として、パラメータはシステムの他のエンティティに関連付けられており、タスクを設定すると、これらのエンティティの現在の状態（引数値）に置き換えられます。 さらに、パラメータのトピックに戻り、それらについてさらに詳しく説明します。



ここで、このすべての類型化を開始したもの、つまり、インスタンスがモデルエンティティに基づいて形成されているエンティティについて考えてみましょう。 たとえば、「タスクマップ」はShKZに基づいて作成され、関連する段階的な操作として実行者に割り当てられたタスクをグループ化することを目的としています。 次のそのようなエンティティは「タスク」であり、典型的なエンティティ「タスクテンプレート」によって形成されます。 タスクカードの責任者を自動的に決定することができます（これについては、ShKZの説明で前述しました）。 標準の位置によれば、タスクを配置するとき、システムの「ロボットエージェント」を含めて、タスクの実行を任命された請負業者が自動的に決定されます。 ロボットまたは人のタスクのタイプによって、実行する手順を特定できます。



したがって、ターゲット製品で標準タスクを設定すると、パフォーマー用のタスクカードを自動的に生成するシステムが得られます。 現在、新しいビジネスプロセスを設定する必要が生じた場合、最小限の開発者の介入が必要になるか、まったく必要ありません。 そして、私たちが開発しているシステムは、同じプロセス内の異なるシーケンスを含む、異なるタイプのタスク（開発、テスト、実装など）を形成できるはずなので、そのようなメカニズムの作成は興味を持って報われるはずです。



明らかに、コーディングなしでBPMNモデルとその実装をサポートする本格的なライブラリが存在することは明らかです。 しかし、私たちはあなたとのトレーニングプロジェクトを検討しています、寛大を行います。

4.デザインパターンを使用します

モデリングプロセスのリファクタリングを使用して、独自のテンプレートの作成など、設計パターンを参照します。 このトピックは、[12]で詳しく開示されています。 特定の設計パターンの再利用は、製品開発プロセスの時間を節約するだけでなく、そのサポートと近代化を促進します。



アナリストが、すでに解決されている問題に類似した問題を克服する必要性を満たした後、テンプレートの助けを借りてこのソリューションを普遍化しようとすることが非常に重要です。 このようなテンプレートは、プロジェクトチームと共同で開発および承認する必要があります。 次に、開発者と設計者のグループ全体が、それらの使用と正しいアプリケーションの必要性を「思わず」監視します。



たとえば、前のセクションで説明した構造に基づいて、設計文書を段階的に作成するためのメカニズムを作成するのに役立つ「技術ライン」テンプレートを開発できます。 生産ラインは、特定のイベントに応じて、実際に形成された「製品」（この場合は設計文書）を処理場所に配送するコンベアの役割を果たします。



彼の説明をします：



技術ライン（生産ライン）







「テクノロジーライン」テンプレートのデータ構造の実装例を図8.6に示します。



図からわかるように、データ構造は図「パターンによるバックの形成」をほぼ完全に繰り返しています。図8.4を参照してください。 テンプレートの動作を決定するメカニズムの説明は、前のセクションで説明した「テンプレートによるジョブの形成」のプロセスにほぼ類似しています。 上記で強調されていないポイント、特にアクションパラメーターを決定および形成するメカニズムについてのみ詳しく説明します。





図 8.6-グレード図テンプレート生産ライン



各アクションテンプレートについて、パラメータのリストは、テンプレートに割り当てられた「ジョブタイプ」に基づいて決定されます。 パラメーターは、タスクの「基礎」またはその実行の「結果」のいずれかです。 各パラメーターには、Technologicalラインによって処理される「製品」（この場合は設計文書）の本質を定義するタイプがあります。 テンプレートに定義されたパラメーターに基づいて、アクションが形成されると、特定のエンティティインスタンスが識別され、そのインスタンスへのリンクがアクションの「Foundations」パラメーターとして記録されます。 アクションが完了した後、「結果」パラメーターが定義されている場合（アクションがドキュメントを作成または変更する場合）、その特定のインスタンスへのリンクがこのパラメーターに保存されます。



1つのアクションの発信パラメーターを、生産ラインの次のアクションの入力パラメーターとして割り当てることができることが重要です。 したがって、形成された「製品」は生産ラインのノードを通過します。

5.製品ライン開発戦略を忘れないでください

実際には、多くの場合、新しいソフトウェア製品を開発するだけでなく、古いソフトウェアを置き換える必要があります。最悪の場合、別の開発チームから継承されます。 この場合、作業の性質が変化し、プロジェクト全体の複雑さが増します。 これは、このセクションで検討するいくつかの理由によるものです。 そのようなシステムを設計するときは、次の要素を考慮する必要があります。

1. すでに使用されている製品の技術の可用性、実装の経験、運用上の問題。
2. 置き換えられたソフトウェアと長い間やり取りしてきたユーザーの確立された習慣と伝統。
3. 古いシステムから新しいシステムにデータを転送し、場合によっては両方のシステムの動作をしばらくの間同期させる必要があります。

変更に関連するプロジェクトを実行する場合、変更のプロセスを管理することは非常に重要であり、その実装中に発生する問題を「掘り下げる」ことはできません。 したがって、設計を開始する前に、使用されるシステムの監査を可能な限り完全に実施し、それに基づいて、古いシステムから新しいシステムへの移行戦略を策定することが望ましいです。



移行戦略を定性的に開発するためには、それぞれの場合にそのようなニーズの発生の性質を考慮する必要があります。 自動化ツールの変更の主な理由は次のとおりです。

• システムに関連して、その機能に影響する外部条件の変化。 たとえば、法律の変更。
• 情報の急速な蓄積とその品質要件の変化に関連したシステムの混乱との闘い。
• 元の設計と矛盾する頻繁な変更によって引き起こされるソフトウェアの「疲労」、「脆弱性」、「冗長性」との闘い。
• システムインフラストラクチャの質的な変化。 たとえば、セキュリティ要件を厳しくします。

したがって、変化に関連するプロジェクトでは、技術的側面だけでなく、人間的、組織的、さらには政治的要因も考慮する必要があります。



変更を導入するための重要な条件の1つは、古いプロセスから新しいものへの移行のための戦略の議論および開発のプロセスにおけるすべての関係者の積極的かつ重要な感情的関与です。



まず、近代化するプロセスのエグゼキューターには、その機能を維持するための実際の作業ツールが既にあり、新しいテクノロジーの作成と実装は、このツールの破壊に対する脅威であることを認識する必要があります。 また、顧客の従業員にとって、近代化の結果として既存のソリューションの適切な代替が得られることはまったく明らかではありません。 したがって、多くの場合、新しいシステムに対する将来のユーザーの否定的な態度は単なる防御的な反応です。 私たちは彼らにあなたを信頼させなければなりません。



プロジェクトの初期段階からの変更の影響を受ける従業員は、イノベーション後に生産プロセスがどのように編成されるべきかを決して意識してはなりません。 それどころか、彼らは新製品の設計に関与すべきです。 彼らに新しいシステムの作者であり、それがどうなるかについて責任があると感じさせてください。



できるだけ多くの人々を変化のプロセスに引き付けるには、これらの変化の背景を視覚化し、感情的に魅力的に提示する機会を与える必要があります。 すなわち、変更可能なプロセスのリスト、古いプロセスと新しいプロセスの対応、移行のステップと条件など。 前述の古いシステムからターゲットへの移行戦略のモデルを視覚化するには、図「アプリケーションアーキテクチャ」を使用します。 検討中のプロジェクトの戦略プレゼンテーションの例を図8.7に示します。





図 8.7-使用済みアーキテクチャからターゲットへの移行戦略のプレゼンテーションの図



この図は、システムの2つの表現を示しています。現在動作している（青色で強調表示されている）Actingと、それを置き換える（黄色で強調表示されている）Targetです。 点線の矢印は、ターゲットシステムのモジュールと機能と、現在のモジュールと機能を置き換える必要があるものとの比較を示しています。



このスキーム（および他のドキュメント）の議論の結果、現在のシステムからターゲットシステムに移行できるステージとアクティビティのリストが表示されます。



このような図は、たとえば、古いシステムでしばらく機能し、新しい（ターゲット）システムがそれらと対話できるようにする比較的自給自足のサービスを強調するのに役立ちます。これは、プロジェクトでの新製品の段階的な実装を計画するときに非常に役立ちます。



古いソフトウェアを新しいソフトウェアに置き換えるプロセスは長く、予測が困難な多くのリスクの発現を伴うため、移行の進行状況を常に監視する必要があります。ソフトウェアへの必要な変更のタイムリーな導入が絶えず延期されると、その停滞の問題は急激に悪化します。ソフトウェアの変更に割り当てられたリソースのボリュームへの依存性は非線形であるため、停滞しているソフトウェアを変更するコストも非線形に増加します。修正のコストが非常に高くなり、顧客がソフトウェアをさらに変更できなくなると、条件付きで「変更されない」状態になります。これは[8]で非常に明快に説明されました。



このような問題に対処するために、プロジェクトのマイルストーンを事前に決定し、その開始（または開始ではない）を明確に追跡できます。高い確率で変更プロセスを遅らせると、プロジェクト全体が中断する可能性があります。結局のところ、各段階の実装は、ほとんどの場合、ユーザーのストレスとユーザーへの追加の負荷にも関連付けられます。いずれかのステージの実装が失敗した場合、前のステージに「ロールバック」する必要がある場合があります。これらの「ロールバック」の2つまたは3つと、変更のコストが重要になるため、顧客は新しいソフトウェアへの移行を継続することを拒否できます。



上記のすべてにより、変更を行うプロセスを停止または大幅に遅くする障壁となることが判明した問題に対する明確かつ迅速な対応の問題を真剣に受け止めています。



戦略的変更に関するアクションを実行する場合、計画された目標の達成を妨げる障壁を常に監視することが重要です。これを行うために、そのような事実はすべて記録され、関係者の注意を喚起し、それらと共に、それらを排除するための行動計画が開発されます。



ジョンコッターの変更管理アプローチによると、「変更は、何度も何度も発生する短期的な成功を通じて実装され、懐疑論者や皮肉屋に反対する総エネルギーを蓄積します。そのため、従業員およびプロジェクトのすべての関係者に対して、あらゆる方法で成功を実証しなければなりません。これにより、イノベーションの実施において尊敬と信頼を得ることができます。」



次のパートでは、リンクシステムの動作を決定します。