ITプロジェクトの要件をAからZまで作成する方法。パート3.システム機能とプロジェクト境界

VIシステムの機能とプロジェクトの境界を決定する

各モデルの回答には制限がありますが、人間の思考には制限がないため、モデルのモデル化方法やモデルに制限はありません。

ダグラス・T・ロス

ユーザーの基本的なニーズが収集され、すべての参加者と合意したら、開発されたシステムの主要な機能の決定を開始し、それらに基づいて、最終製品の作成を目的としたプロジェクトのコストと期間を概算します。 このプロセスの結果、原則として、規定の時間枠内で高品質の結果を得るのに十分な時間、リソース、またはその両方がないことがわかります。 この場合、プロジェクトの境界を効果的に決定し、それらを管理する機能は非常に役立ちます。



この一連の作業の目的：識別された顧客のニーズを満たすために、ターゲット製品が実行する必要がある一連の機能を可能な限り完全に決定すること。 現在のプロジェクトの一部として実装できるものを選択します。



プロジェクトスコープは、最終製品のどの領域が現在のプロジェクトに実装されるかを示します。 言い換えれば、現在何をするかと、あとで延期するか、完全に拒否できるかとの間の境界線が決定されます。 これを行うには、作成した製品のモデルを構築できるだけでなく、自動化されたプロセスのフレームワークを視覚的に概説し、プロセスを簡単に海外に移動したり、有効にしたりできる機能を備えたツールを武器にする必要があります。 これは、作業量の認識とより良い計画のために非常に重要です。 このようなツールは、顧客の法外な欲求との「闘争」だけでなく、開発者による管理操作にも役立ちます。



初期段階とプロジェクト全体の両方でプロジェクトの境界を管理するには、機能モデリングまたはプロセスモデリングを使用すると非常に便利です。 このタイプのモデルを使用すると、ビジネスプロセスのイベントおよび実行シーケンスを時間内に記述することができます。



場合によっては、境界を決定するために、開発者のグループは機能ではなくサブジェクトエリアの本質を使用しようとします。 このアプローチには次のような結果が伴うため、警告を発したいと思います。

• 不十分な形式化のため、一部のプロセスは完全に実装されない場合があり、これは製品の最初のバージョンがリリースされたときにのみ明らかになります。
• 関連するプロセスがプロジェクトに実装されていないため、一部の自動化されたプロセスは使用されません。
• 一部のシステムオブジェクトは、それらを処理するプロセスがないため使用されません。

図6.1は、ターゲットシステムの要件を形式化するプロセスを示しています。ターゲットシステムは、実行する機能を決定するためのサブプロセスによって補完されています。





図6.1-関数を定義するプロセスのモデル

1. IDEF0表記を使用して、システム機能とプロジェクト境界を定義します

私の意見では、プロジェクトの境界を定義するという観点から、機能モデリングの最も便利な方法は、階層分解を上から下に使用する「古き良き」SADT設計方法論です。 IDEF0ダイアグラムの使用には、類似物に対して次の利点があります。

• 自動化プロセスの分析における分解は、最上位から最下位まで実行されます-最高レベルの1つからそのサブプロセスまで。 レイヤーごとの明確化によるプロセスの順次分岐により、一方ではチームの視野から重要なビジネスプロセスを見逃すことがなく、他方では常に少数の要素を含む選択されたノードで作業できます。
• 着信データストリームとそれらに作用する制御が行われるモデリング方法により、これらの着信データを処理するプロセスに埋め込まれたすべてのサブプロセスを最も正確かつ完全に識別し、プロセスの出力で結果、発信ストリームを提供できます。
• プロセスの各結果（発信ストリーム）に必須なのは、入力でそれを消費する（着信ストリームとして）別のプロセスの比較です。これにより、データ処理および変換チェーンの機能を見逃すことがなくなります。

IDEF0標準を使用して、システムによって実行される主な機能と、外部環境を含む情報フローの形でのそれらの相互作用を記述するモデルが構築されます。 したがって、システムとその環境の境界は、IDEF0ダイアグラムで簡単に読み取れます。 このタイプの図のもう1つの利点は、前述のように、1つの大きくてかさばるモデルを開発する代わりに、いくつかの小さくて比較的単純なモデルが段階的に挿入され、入れ子人形として互いに入れ子になっていることです。



したがって、複雑なプロセスの構造は、高レベルの機能の抽象化として表され、より詳細なプロセスに分解され、レイヤーごとに精度が向上します。



このタイプのシミュレーションにより、前の段階で視野から解放されたプロセスを特定することもできます。



プロセスモデリングの段階で、情報収集の段階で説明されていないプロセスを見つけた場合は、ユーザーストーリーの形成段階に戻ってギャップを埋める必要があります。 そして今、このような情報の蓄積がすべて意識により良く収まるように、特定の例を見てみましょう。

2.機能「要件管理」の説明の例

IDEFO標準の基本的な仮定を思い出させてください。 標準のグラフィックデザインは、次の要素で構成されます。ブロックの形で表示されるアクションを示す「作業」（アクティビティ）の概念。 4つのタイプのインターフェイス：「入力」、「出力」、「制御」、および「メカニズム」。円弧の形で表示されます。 ブロックの左側は入力用、上部は制御用、右側は出力用、下部はメカニズム用です。 このトピックの詳細な調査については、[2]を参照してください。



モデリングの最初のステップでは、外部からシステムに入るすべてのデータフロー（入力信号）を決定する必要があります。 私たちの場合、それは次のとおりです。

• プロジェクトの目的;
• プロジェクト参加者と利害関係者。
• プロジェクトの対象製品の機能に対する参加者のニーズ。
• 要件を作成するための方法論。

次に、システムが外部で使用するために生成したすべての「製品」を決定します（出力信号）。

• 要件、モデル、計画などを含むプロジェクトの成果物。
• プロジェクトの対象製品。

上記のデータストリームと、これらのストリームを処理するシステムのグローバルな抽象機能が図に表示されます。図を参照してください。 6.2。





図6.2-最上位の要件管理システムの機能モデル



関数の内部（「作業」ブロック）に分類されると、システムの機能の次のレベルの抽象化に到達します。 最初は、前の段階（レベル）で特定されたデータフローのみが表示されます。図を参照してください。 6.3。





図6.3-ITプロジェクト管理の機能の詳細の開始



そのような各ストリームについて、それを処理（変換）または使用するプロセスを決定し、それに関連する新しい「ジョブ」ブロック（関数）を図に追加する必要があります。



したがって、後続の各ステップ（プロセスの内部をたどる）では、前のレベルで識別された各データストリームについて、その処理のために関数（プロセス）を比較する必要があります。 そのようなモデリングの結果として、より高い抽象プロセスを詳述する関数のリストを取得します。図を参照してください。 6.3。





図6.4-ITプロジェクト管理機能のサブプロセスの定義



このプロジェクトでは、第IV章で設定した目標と第1段階で特定したデータストリームに従って、次のプロセスグループを自動化する必要があります。

• 製品の機能に対する顧客のニーズに関するデータの収集。
• ターゲット製品のシステム要件の考慮。
• システム要件の実装を目的とした作業プールの管理。その結果、ターゲット製品の作成。
• システム要件の実装に関する作業の実装を説明し、その結果、プロジェクトは目標に向かって進んでいます。

1つのプロセス「ジョブ管理」は、外部からデータを受信せず、外部環境に何も提供しません。 それは判明-それは他の人の機能を保証する補助的なプロセスです。 まだバラバラです。図を参照してください。 6.4。



ほとんどのプロセスは論理的に相互接続されているため、これらの接続を提供するすべてのデータストリームを確立する必要があります。 したがって、ダイアグラム上で機能から機能へとアークが表示されます。 後で、「ジョブ」ブロックに含まれるそのような各アーク（リンク）は、次のネストされたレベルをモデリングするときに、その処理プロセスを「取得」する必要があります。



すでに確立された関係を持つこれらの機能のモデルの例を図に示します。図を参照してください。 6.5。





図6.5-要件管理システムの機能モデル



このような図がドキュメントで使用されている場合は、詳細な説明を添付する必要があります。 以下に説明の例を示します。



この図は、プロジェクトの機能アーキテクチャが4つのドメインの形式で提示されていることを示しています。

1. 顧客のニーズを収集します。 製品開発目標、その使用の主なシナリオ、およびアクター-製品のユーザーの会計と分析のためのプロセスのグループ。
2. 要件仕様を管理します。 顧客およびターゲット製品の将来のユーザーの特定されたニーズに基づいて機能要件を形成するプロセス。
3. タスクの形成の管理。 機能要件を実装することにより、特定された顧客のニーズを満たすことを目的としたタスク形成のプロセス。 実行者がタスクを実行するとき、それが形成される要件の状態を変更することにより、結果を修正します。
4. パフォーマンス管理。 ターゲット製品のユーザーのニーズを実現できる機能の増分を監視および記録するプロセス。

最初の機能ブロック「A1」では、入力パラメーターとして、顧客、利害関係者などの目標と希望に関するデータを送信します。 データはシステムの外部環境からドキュメントの形で取得されます-開発用アプリケーションまたは口頭で。 このプロセスの目的は、ブロック「A2」-「要件仕様の管理」への送信に適した情報に変換することです。 ユーザーストーリーおよびレポートの形式での最初のブロックのアクティビティの結果は、外部使用にも適しており、印刷形式またはファイルへのデータエクスポートの形式で外部システムおよびユーザーが利用できます。 したがって、ブロックからの矢印は分割され、ダイアグラムの境界を越えて、より高い機能になります。



図から、「A1」ブロックには、「A2」ブロックからのフィードバックが、ユーザーストーリーによって生成された要件の実装の程度を知らせる制御情報の形式であることがわかります（「要件の実装に関するレポート」）。 この関係により、要件仕様を通じて、チェーンに沿った最終製品でのユーザーストーリーの実装の進捗と完全性を追跡できます。



2番目のブロックは、図に示すように、処理された顧客の要望をユーザーストーリー、ユーザーニーズなどの形式で受け取ります。 すでに正式な形式になっています。 これらのデータに基づいて、開発中の製品の機能要件を形成し、要件仕様の形式で形式化されます。 さらに、これらの仕様は4番目の「A4」ブロックに転送され、実行者がそれらを実装するためのタスクを設定します。 図から、要件を使用して作業を実行するようにタスクを設定することもできます（コントロールとして「A2」ブロックに含まれるアーク「タスク」）。 2番目の機能ブロックは、仕様によるタスクの実行に関するデータを返すことに注意してください。これにより、このドメインでの開発中に取得した機能の増分を決定できます。



3番目のブロックでは、ブロック「A2」から、制御命令として、仕様の主要なインジケータを送信します。 それらに基づいて、これらの仕様に合わせて設定されたリアのパフォーマンスに関するレポートを使用して、特定の機能の達成度を判断することができます。 レポートは、「A4」ブロックからの入力パラメーターの形式で提供されます。



私のすべての努力にもかかわらず、このセクションは困難で退屈であることが判明しました。 しかし、この概念を理解するには、すべてがどのように機能するかを理解することが重要でした。 次に、ネストされた関数の詳細を説明します。

3.機能「顧客ニーズの収集」の説明の例

明らかになった関数の分解を続け、各ドメインをより小さく、より詳細な関数に分解します。 これを行うには、ユーザーストーリーを使用します（これらは、この記事の前の部分で説明しました）。 それらを説明する際に、顧客のニーズをどの程度完全に「カバー」するかを決定します。



図6.4のブロックA1を見てみましょう。これは、「顧客ニーズの収集」というドメインを表しています。 その詳細を図6.5に示します。 図6.4のブロックA1にそれぞれ含まれていたすべてのデータストリームは、詳細図に分類されました。図を参照してください。 6.6。





図 6.6-顧客のニーズを収集するドメインスキーム



機能的には、ドメインを4つのプロセスに分割しました。

1. ターゲット製品の顧客とユーザーへのインタビュー。 ユーザーストーリーを修正するプロセス（目的を含む）。 以前に記録された同様のストーリーの存在を確認します。 矛盾するシナリオが決定されます。 このブロックは、ユーザーストーリーUS01、US02を「カバー」する必要があります
2. ユーザー履歴を変更します。 関連するシステム要件を変更するプロセスの開始を含む、製品の顧客のニーズを記述する変更管理プロセス。 このブロックは、US02ユーザーストーリーを「カバー」する必要があります。
3. プロジェクトの利害関係者の固定。 プロジェクトに何らかの形で関係しているすべての人が特定されます。 このプロセスは、US04ユーザーストーリーを「カバー」する必要があります。
4. 定義、ユーザーストーリーの実装レベル。 ユーザー履歴に関連付けられたシステム要件が監視され、最終製品のフレームワーク内での現在のステータスと実装レベルが決定されます。 このブロックは、US11ユーザーストーリーを「カバー」する必要があります。 制御インターフェースとしてのブロックは、ブロック「A2」からの「要件の実装に関するレポート」-「要件仕様の管理」を受け取り、これに基づいて実装レベルが計算されます。

4.「要件仕様の管理」機能の説明の例

ドメイン「プロジェクト要件仕様の管理」（A2）を使用して、次の改良を行います。 このモデルの図を図6.7に示します。



機能的に、ドメインは4つのプロセスに分割されます。

1. ビジネスプロセスの定義。 ターゲットプロセスの機能アーキテクチャの開発が実行されます。これには、自動化プロセスの重要性と優先順位（プロジェクト境界の管理）が決定されます。 このブロックは、ユーザーストーリーUS05、US06を「カバー」する必要があります。 制御インターフェースとして、ユニットは「タスク」を受け取ります。これは「A4」ブロック-「タスク管理」から来て、作業を開始します。
2. 仕様要件の開発。 製品の論理的および物理的構造の表記法が開発され、プロジェクトの内容は、すべての参加者が対話するターゲット製品の要件の詳細な説明で形成されます。 このブロックは、US07ユーザーストーリーを「カバー」する必要があります。 制御アクションとして、ユニットは仕様が準拠しなければならない標準の説明を受け取ります。
3. 要件管理を変更します。 ターゲット製品の以前に承認された特性を変更するためのアプリケーションが記録されます。 これらの変更を実装するためのタスクを形成するプロセスを開始しました。 このブロックは、US10ユーザーストーリーを「カバー」する必要があります。
4. 要件ステータスの管理。 プロジェクトの推進プロセスは、要件の実装に関して監視されます。 この機能は、US11ユーザーストーリーを「カバー」する必要があります。 制御インターフェースとして、ユニットはブロック「A4」から「タスクの完了」-「タスク管理」のレポートを受け取り、プロジェクトの現在のステータスとレベルを決定します。

図 6.7-プロジェクト要件仕様を管理するためのドメインスキーマ

5.機能「ジョブ管理」の説明の例

図6.8は、プロジェクト管理（A4）のドメインを表す図を示しています。 機能的には、ドメインを4つのプロセスに分割しました。

1. 要件仕様に基づくジョブ構成。 設計、開発、テスト、展開、パイロット実装など、要件を実装するためのタスクが形成されます。 このブロックは、US08ユーザーストーリーを「カバー」する必要があります。
2. 反復のためのタスクの形成。 タスクの割り当ては、反復計画に従って実行されます。 これらの要件は、反復アプローチを使用した標準プロジェクト管理プロセスから取得されます。
3. リスクのあるタスクの形成。 リスク軽減計画の下でのタスクの割り当てが管理されます。
4. タスクの完了を説明します。 タスクの完了に関するレポートが生成されます。 タスクの結果に基づいて、プロジェクトオブジェクトのステータスに変更があります。 このプロセスは、US09ユーザーストーリーを「カバー」する必要があります。

図 6.8-プロジェクトタスク管理ドメインスキーム



このドメインをモデル化するとき、ユーザーストーリーのいずれにも一致しないプロセスがあります。 したがって、ギャップを埋めます。 これを行うには、チームと顧客との共同議論に問題を持ち込み、新しいユーザーストーリーを作成する必要があります。



プロセス5.2では、次のユーザー履歴について説明します。



US12。 プロジェクトの反復計画に基づいて、この段階で実装する必要があるタスクのプールを選択します。

目的：プロジェクトの現在の反復で実装するタスクのリストを取得します。



プロセス5.3には、いくつかのユーザーストーリーが含まれます。



US13。 予測されるリスクが発生したときに実装する必要がある要件を準備します。

目的：問題が発生した場合に、顧客のニーズを満たす代替ソリューションを開発する。



リスクが発生した場合、US8ユーザー履歴が実行されます。

6.機能「実行制御」の説明の例

図6.9は、プロジェクト管理オフィスのドメインを表す図を示しています。 このドメインの実装は、プロジェクトの範囲をわずかに超えていますが、密接に関連しています。 したがって、我々はそれを考慮します。





図 6.9-プロジェクトのドメイン管理スキーム



機能的には、ドメインを4つのプロセスに分割しました。

1. プロジェクト製品管理。 製品のリリースは修正されています。 リリースレポートが生成されます
2. 品質管理。 前のチェックのコメントの修正の分析が実行されます。 問題の要件への準拠が決定されます。 品質管理レポートが発行されます。 新しい問題が明らかになります。
3. 問題管理。 プロセスの実行中の逸脱への対応。 エラーが優先され、変更要求が生成されます。
4. プロセスの監視と分析。 主要な指標の計画値は、実際の指標と比較されます。 たわみ値が決定されます。 インジケータが監視されます-トリガー（「リスク兆候」、「リスク症状」）、リスクイベントが発生したこと、または近い将来発生することを示します。 このプロセスは、US11ユーザーストーリーを「カバー」する必要があります。

7.システムの機能とプロジェクトの境界を決定するプロセスを要約する

このように、レイヤーごとの複数のパスで、開発された製品の機能モデルが洗練され詳細化され、その輪郭の境界が決定されます。 このアクティビティの結果として、実践する必要がある詳細なプロセスモデルを取得します。 図からわかるように、自動化された機能のリストに加えて、それらを接続するすべての情報フローも示されています。



プロジェクトまたはそのステージの範囲から機能を取り出したい場合、依存関係を分析し、技術プロセスラインの残りの機能の「たるみ」を回避できます。



その結果、私たちが開発した図に基づいて、最初の段階で、「実行制御A3」グループの機能、および「A4.2反復のためのタスクの形成」および「A4.3リスクのあるタスクの形成」の機能だけでなく、プロジェクトの範囲から移動できます。 図から、結果として、リスクを平準化するための作業により、システムはデータストリーム、つまり「エグゼキュータのジョブ」を失うことがわかります。



現在、顧客が製品に新しい機能を含めるように提案するたびに、まずプロセス図（機能）の変更を記録し、システム全体の変更の程度とその影響を判断する必要があります。



次のパートでは、 リンクシステムのフレームワークに含まれるプロセスについて詳しく説明します。

。