ITプロジェクトの要件をAからZに形成する実践。パート6。システムの動作。 完璧な要件

IXシステム動作の定義。

非常に多くの場合、その振る舞いは...その理由が、非常に合理的かつ徹底的に他人から隠されているため、ばかげているように見えます。

フランソワ・デ・ラロシュフカウ

主なシナリオとサブジェクトエリアのエンティティのリストを決定したら、それらを互いに比較する必要があります。



この一連の作業の目的：特定されたエンティティとプロセスに基づいて、開発中のターゲット製品がシステムの動作を設計し、クラスに配布します。



このプロセスは、標準的なシーケンス図を使用して便利に実行されます。 このタイプのチャートは、あるオブジェクトがプロセスを使用して別のオブジェクトにメッセージを送信し、このインシデントに応答するように強制するイベントのチェーンをシミュレートするために使用できます。 このようなイベントの結果として、要求されたオブジェクトは応答を返すか、次のプロセスを開始できます。 したがって、システムの低レベル機能を形式化すると便利です。 イベントに対する反応の連鎖が長く複雑になるほど、シーケンス図を使用せずに行うことは難しくなります。



図9.1は、ターゲットシステムの要件を形式化するプロセスを示し、その動作を決定するためのサブプロセスが追加されています。







図9.1-システムの動作を決定するプロセスのモデル

1.シーケンス図を使用してシステムの動作をモデル化する

「ジョブアカウンティング」回路の設計を続けて、例として取り上げましょう。ジョブを実行者に割り当てるときのシステムの動作を図9.2に示します

シーケンス図は左から右、上から下へと読まれることを思い出させてください。







図 9.2-タスクのシーケンス図の形成



この操作は、以前に開発されたタスクカードテンプレート（以下ShKZ）を選択することから始まります。このテンプレートに基づいて、プロジェクトの新しいアクティビティがユーザー用のタスクカードの形式で形成されます。 図のタスクカードのコピーは上の行ではなく、検討中のプロセスで実際にそれを生成するイベントの矢印のレベルにのみあることに注意してください。 しかし、私たちは少し先を走りました。 ダイアグラムに戻って、順番に検討していきましょう（シーケンスダイアグラムです）。



クラス図（この記事の最後の部分で説明します）では、図8.4を参照してください。ShKZでは、ネイティブポジションのディレクトリが参照されています。 タスクマップの実装の責任者を決定する必要があります。 したがって、シナリオの2番目のステップでは、確立されたポジションに従って現在ポジションを保持している特定の従業員を決定します。 ちなみに、2番目のステップに言及して、私は間違いに気づきました。私の図では、矢印の近くに数字がなく、通常は下に置かれています。これは非常に便利です。 したがって、2番目のステップで特定された従業員がタスクマップのキュレーターになります。 実際、モデリングのこの段階で、新しいシステム関数（前のセクションで説明したビジネス関数と混同しないでください）を定式化しました。その入力はネイティブの位置に設定され、従業員へのリンクは出力に返されます。 ほとんどの場合、このような関数は複数回便利になります。



先に強調したように、上から下へ、左から右へと進みます。 ShKZはタスクテンプレートをリンクし、実行者の操作の構成と順序を決定します。 したがって、ShKZに従ってタスクマップを作成した方法と同様に、作成したタスクテンプレート-タスク（操作）を作成したばかりのタスクマップに結合します。 ただし、1つのマップには多くのタスクが存在する可能性があるため、図ではループシミュレーション手法（ループステレオタイプのフレーム）を使用します。 同様に、このタイプのダイアグラムでは、条件付き遷移、前提条件、およびその他の条件付き構成を表示できます。



ShKZだけでなく、ジョブテンプレートにも、通常のポジションのディレクトリへのリンクが定義されています。 この接続は、マップに含まれるタスクの直接実行者を決定するために必要です。 各タスクについて、このリンクはアーティストを定義します（可能な場合）。 この機能が図の2番目のステップですでに特定され、特定されていることに気付くのは難しくありません。



この例の別の重要なプロセス：割り当ての特性を決定するパラメーターの入力。 タスクの形成中に、そのテンプレートの受信として定義されているパラメーターには、システムエンティティの現在の値が入力されます。 このプロセスは、抽象メタデータクラスを通じて抽象的に表示されます。 このプロセスのステップのより詳細な定義については、別の図が作成されます。



したがって、シーケンス図のプロセスを段階的にモデル化することで、プログラムコードに実装する必要のあるシステム関数、それらの受信および送信パラメーター、および実行シーケンスを決定します。



シーケンス図は、オブジェクトを変更するプロシージャが順番に自動的に次々に実行されるトリガー構造で飽和したシステムで特に役立ちます。 長いチェーンでは、同じオブジェクトが異なるトリガープロシージャによって変更され、モデリングせずに最終結果を追跡することが問題になる場合があります。

2.システムの動作をモデル化する際に、オブジェクトの状態の変化を分析します

イベント駆動型システムの要件を実装するには、さまざまなイベントが発生したときのオブジェクトの状態（特定の時点でのプロパティのセット）の定義と管理に特別な要件が課されます。 たとえば、特定の時点で特定の条件が発生したときにオブジェクトのプロパティを自動的に変更するシナリオの開発。 標準的な状態図を使用してこのような問題をモデル化すると、イベントを状態に関連付けることができます。 このタイプの図は、イベントを明示的に検出するシーケンス図と組み合わせて効果的に使用できます。



状態図を使用したモデリングの基本的な仮定を思い出させてください。 状態図の主要な要素であり、当然問題のオブジェクトの「状態」です。 1つの図では、1つのオブジェクトのみの状態遷移をシミュレートできます。 ダイアグラム内の1つの状態は1回のみ発生します。



下の図9.3は、「Task」オブジェクトの状態遷移のモデリング例を示しています。 このタイプのチャートには、オブジェクトの生成を決定し、そのライフサイクル（以降LC）の開始を示す要素が常にあります。 私たちの場合、新しいタスクを作成するとき、その次の状態を定義する重要な属性はエグゼキューターになります。 設定されている場合、タスクは実行のために提案され、そうでない場合、タスクは初期状態のままになります。 この例では、オブジェクトの残りの属性を埋めるルール（これも行われる可能性があります）は、特定の場合には不可欠ではないため考慮されません。







図 9.3-タスクステータスチャート



図の角括弧内の矢印の横に、遷移条件がマークされています。 この条件が満たされると、次の矢印状態への遷移が実行されることを示しています。 また、括弧のない矢印の近くの碑文は、状態変更を実行するイベントを示しています。 状態を示す長方形の中に、遷移を引き起こす可能性のあるすべてのイベントがリストされます（それらは矢印上のイベントに対応する必要があります）。 ダイアグラム上の各状態は、矢印への遷移と、1つ以上の矢印（遷移）を必ず取得する必要があります。 したがって、イベントや移行条件を見失うことは非常に困難です。



たとえば、タスクのマークが完了していれば、「作業中」状態から「完了」状態に移行できます。 そして、そこから州に行くことができます：

• レポートが受け入れられ、確認された場合は「クローズ」、
• タスクを中断する決定が下された場合、「遅延」
• 進行状況レポートが受け入れられず、タスクを完了する必要がある場合は、「進行中」状態に戻ります。

図では、LCオブジェクトの終わりを常に決定する必要があります。



実際には、状態図の代わりに、状態遷移表を使用すると便利な場合があります。 プロジェクトのほとんどの利害関係者にとってより理解しやすく、複雑で複雑なプロセスがない場合に使用されます。 たとえば、以下は、検討中のプロジェクトのジョブのステータスの簡易遷移表です。







ただし、テーブルをコンパイルするときは、重要なものが欠落する可能性が高いことを理解する必要があります。 したがって、ダイアグラムを使用してモデリングを実行し、それらに基づいて、すでにテーブルに記入する方が適切です。 たとえば、正直に言うと、最初に表を作成しましたが、この章では図を含む図を含めるつもりはありませんでした。 しかし、気が変わって、すぐに多くの矛盾を見つけました。具体的には何も修正し始めなかったので、あなたは自分でそれを見ることができます。

3.システムの過剰な「過剰管理」を避ける

システムに記録されたデータに基づいて、それらの処理方法を決定できるメカニズムを設計する場合、これらの決定を選択するための条件を作成するためのルールが変更される可能性に特に注意を払う必要があります。 より簡単に説明します。顧客が特定のルールが常に適用されると言った場合、これはシステムの実装後にこの「鉄筋コンクリート」ルールに例外を追加する客観的な理由がないことを意味しません。 この場合、厳密に設計された意思決定メカニズムは、すべてのプロジェクト参加者にとって大きな頭痛の種になります。



私の練習では、販売を含む顧客関係を自動化するシステムを作成することを目的としたプロジェクトがありました。 開発中のシステムは、経理が手動で行われた（しかし当然、特定の規則に従って）時代遅れのシステムを置き換えることになっています。 設計のために、会社の販売ルールを確立する承認済みの規制文書が作成されました。 ドキュメントに基づいて、これらのルールを処理するようにシステムを柔軟に構成できるメカニズムが開発されました。 しかし、複雑なマルチレベルの割引システムを使用して請求書を自動的に生成できるシステムを導入すると、マネージャーの裁量でルールがなくても販売が行われる場合があり、開発されたソフトウェアではこれが許可されていませんでした。 「懐中電灯から」アカウントを形成できるようにシステムを再設計するには、さらに変更を加える必要がありました。 この例では、カプセル化が複雑すぎると管理性が低下し、モジュールの適用範囲が狭くなることを強調したかったのです。 これは、VIII章ですでに言及されています。



したがって、このような場合、次の推奨事項を使用することをお勧めします。

• 処理ルールを選択するための値を定義するとき、必要に応じてユーザーが簡単に変更できる定数を使用します。
• 「ロールバック」モードを提供する-意思決定メカニズムに基づいてシステムによって実行された操作（トランザクション）のキャンセル。
• 複雑なプロセスを単純なプロセスに分割し、単純なインターフェースで互いに接続されたオブジェクトに責任を分散させることにより、プロセスを細分化します。 この場合、意思決定サブシステムの動作を変更したり、新しいサブシステムやサービスに置き換えたりするのが簡単になります。

たとえば、タスクをエグゼキュータに割り当てるためのモジュールでは、テンプレートに従って次のプロセスが実行されます。

1. ジョブとジョブのマップは、テンプレートに従って形成されます。
2. 実行者と、割り当てられた割り当ての責任者に通知されます。

これら2つのプロセスを順次実行する1つのオブジェクトを作成できます。 ただし、時間の経過とともに、実行者にタスクの割り当てを一度にではなく、前のタスクが完了するたびに通知する必要が生じる可能性があります。 この場合、2つのオブジェクト間の責任の分割により、最初のオブジェクトはタスクの形成のみを担当し、2番目のオブジェクトは実行の「成熟」に伴い、タスクの割り当てを実行者に通知する一定の周期性を持ちます。

X要件の改善

私は、実際には、いくつかのパスで要件を形成する手法を使用しています。 つまり、最初にドラフトバージョンの概要を説明します。高品質の製剤をすぐに取得しようとはしません。 言葉は説明の中で繰り返すことができ、表現は「ぎこちない」ことができます。 主なことは、主要なアイデアを述べ、接続された構造、つまり仕様のフレームワークを形成することです。 後で、仕様をもう一度読んで、テキストを「くし」にして、耳でよく認識できるようにします。 認識を超えて説明が変わる場合があります。 それで、私は仕様が4〜5回（時にはそれ以上）通過し、それらが調和のとれた容易に知覚される構造になるまで繰り返します。 ところで、この出版物は同じように書かれました。



この一連の作業の目的は、要件の形式を正規化して、知覚を可能な限りシンプルにし、使いやすくすることです。

1.トレーサビリティ要件を確認します

上記のように、最も初期の段階から、すべてのプロジェクト成果物間のリンクを維持することが非常に重要です。 私たちのプロジェクトでは、後続の各ステージに移動して、前のステージのアーティファクトを使用して、明示的にリンクを示しました。 したがって、たとえば、ユーザー履歴に従って、要件仕様を選択し、実行するタスクとその実装の程度を簡単に決定できます。



アーティファクトの追跡可能性のために、アーティファクトに識別子を使用します。 他のアーティファクトの識別子へのアーティファクトリンクを配置します。 これらの関係に基づいて、他の要件、ユーザーストーリー、他のアーティファクトとはまったく関係のない要件を追跡し、その使用の適切性を再度分析したり、要件の完全性のギャップを特定したりできます。

2.テスト容易性に取り組む

要件をコンパイルするときは、それらを使用するすべてのチームメンバーの注意を払い、仕様が可能な限り役立つようにする必要があります。



テスタビリティの観点から、要件には正確な検証基準が含まれている必要があるという事実に注意を払う必要があります。 つまり、「要件が顧客の希望を満たしているかどうか」という質問に対する明確な回答を許可する必要があります。



要件を形成し、それらに基づいて受け入れテストを開発するのが簡単で便利になるような方法でそれらを構成してみてください。 基準は、実装の完全性と正確性の両方の検証を許可する必要があります。 このような手法は、柔軟な設計のスクラム、XPの方法論で非常に効果的に使用されます[10]。 たとえば、処理アルゴリズムの選択の境界となるオプションでデータを入力するためのルールを表示する要件のテキストでの説明の形成を使用します。 たとえば、ある列に動作のアルゴリズムを選択するための境界となる値をリストし、別の列にこの場合のシステムの動作に関する指示を作成することができます。 例：







受け入れテストを作成するとき、テスターは準備された値を使用します。

さて、要件の開発プロセスを教えている本では、テスト容易性の観点から、次のような要件の特性に注意を払う必要があることを読むことができます。

• 明瞭さ（曖昧さ、確実性、一意性）;
• 実現可能性（実行者による実現可能性）;
• 完全性（要件のテキストは、実行者にとって追加の詳細を必要としません）;
• ユニティ（要件は1つだけの「もの」を記述する必要があります）;
• 一貫性（要件が他の要件と矛盾してはなりません）;

3.要件に同意する

シミュレーションの主な効果は、設計の初期段階で、得られる製品のアイデアと顧客と開発者の間の不一致を特定することによって達成されます。 時には、これにより開発チーム内での理解が可能になります。 また、シミュレーションを使用すると、ユーザーは製品の機能に関する仮定の一部をより明確かつ詳細に提出し、最初の要望に改良や変更を加えることができます。 このプロセスがうまく行けば進むほど、実装済みの製品に変更を加える必要が少なくなります。 したがって、顧客との要件の調整は見逃してはならない非常に重要なポイントであり、さらに、各重要なプロジェクトの進展後に定期的に調整を行う必要があります。



私自身もそのような推奨事項を繰り返し読んでおり、ほとんどの場合、個人的に感動するまで私の耳をすませてくれました。 どういうわけか、すべてが十分にスムーズに進み、要件が十分に開発されていないプロジェクトが採用され、開発中に既に確定されていたため、常にそれを逃れました。 しかし、遅かれ早かれ、リラックスする瞬間が来て、注意が徐々に鈍くなってきます。パートナーや顧客は常に、形式化されていないが非常に予算上の合意に基づいて、完全に異なる何かをすることを要求し、手をひねって絶望に導くパートナーや顧客がいます。 そして神は禁じます、それは国家構造であることが判明します-あなたは「ヒット」を持っています...これに持ってこない方が良いです。



すべてのスキーム、図、ビジネスプロセスの説明に関連する仕様を顧客に示すことを恐れないでください。 そして、単に見せるためだけでなく、彼が質問をするようにその内容を説明し、議論への関心が生じました。 これは複雑で骨の折れるプロセスであり、すぐには解決しません。



お客様は、説明に耳を傾け、提示されたドキュメントの本質を理解するために、徐々に、そして執lentに顧客に慣れる必要があります。 それらによって最もよく知覚される図の構成を決定します。



多くの場合、製品の最初のプロトタイプを見たユーザーは、主な希望を変えます。 また、この場合、要件はプロジェクト参加者によってすでに正式に承認されているため、それらへの修正の導入は、別個の、より厳密な承認手順を経る必要があります。 結局のところ、これらの変更は、関連するプロセスまたは他のユーザーの機能に影響を与える可能性があります。



要件を変更するメカニズムについては、「要件の変更に関する問題の解決」の章で詳しく説明します。



調整は、要件に基づいてだけでなく、その実装の優先度にも基づいて実行する必要があります。 このため、チームは顧客とともに、要件の「重要性」などの特性を定義します。

4.要件開発プロセスのリスクを決定する

「一般に」プロジェクトのリスクを伴う作業を省略し、要件の開発におけるリスク管理のトピックのみに触れます。 上記のように、モデリング方法自体は、製品に不要な機能や不適切な機能を開発するリスクを軽減します。 これは、設計の初期段階で、設計者と開発者が顧客と製品のプロトタイプモデルの機能について話し合うことができるためです。 したがって、モデルの開発が適切であればあるほど、そのような議論の中で主題分野の理解を深めることができます。 逆に、高品質で深い要件を作成する十分な時間がない場合、顧客のニーズを満たさない製品を作成するリスクがあります。 これは、開発後に明らかになり、追加コストが必要になり、顧客を大きく混乱させる可能性があります。



初期の段階で、設計された機能の複雑さと実現可能性を判断することができない場合、効果的ではないが予測可能な代替オプションを開発する必要があります。 これにより、メインの実装オプションで障害が発生した場合、迅速に代替に切り替えることができます。 また、リスクの可能性についてチームに通知し、実装が困難であっても驚くことではありません。



一般に、要件に関連するリスクは、主にその特性の1つが標準から逸脱しているためです。 これは：

• 要件間の一貫性。
• 解釈の一意性;
• テスト容易性基準の定義。
• 顧客および関係者との調整。

通常、リスクは別のドキュメントに文書化されており、プロジェクトマネージャーの責任であるため、これに個別に焦点を当てることはせず、ドキュメントでこれがどのように見えるかを示します。







リンクの要件を指定するのに次の部分を捧げるでしょう。