ITプロジェクトの要件をAからZに作成する方法。パート4.システムによって自動化されたビジネスプロセス

VII。プロジェクトフレームワークに含まれるプロセスを詳しく説明します。

結果としてすべてが簡単になるように、複雑にする必要があります。

結果として物事をより難しくするために物事を単純化するのではなく。

ウェスラフ・ブルジンスキー

プロジェクトの主な機能と範囲を決定したら、システムによって作成された機能アルゴリズムの詳細な説明に進むことができます。 この作業単位では、途中でプロセスとストレージの間の接続を「決定」できる手法を使用します。 これにより、プロセスモデルからデータモデルにスムーズに移行できます。



この作業グループの目的：特定された機能に基づいて、開発されたターゲット製品のユースケースを決定します。



このような目的には、アルゴリズム図（ビジネスモデリング）を使用してビジネスプロセスのグラフィカルイメージを使用すると便利です。 アルゴリズム化は、「システム分析」という分野のもう1つの手法です。



ビジネスプロセス図の使用による追加のボーナスは、受け入れテストの開発に非常に役立つことです。 それについては後で詳しく説明します。



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







図7.1-システムの使用シナリオを決定するプロセスのモデル



プロセスを説明するアルゴリズム図には、次の要件があります。

• プロセスロジックを十分に詳細かつ正確に記述する必要があります。 各ケースで必要に応じて詳細かつ正確に。
• プロジェクトの利害関係者のさまざまなグループが等しく理解する必要があります。 これは、まず第一に、彼らが仕事を説明するビジネスの人々であり、実行者：ビジネスアナリスト、開発者などです。

ビジネスプロセス図は標準的なアクティビティ表記（アクティビティ図）に基づいていますが、この章で説明する追加機能があります。

1.ビジネスプロセス図を使用します

このセクションでは、対象領域を別の角度から見て、プロセスではない、つまり「ビジネスレベル」プロセスの説明を検討することを明確にしたいと思います。

• 顧客（開発中のターゲット製品のエンドユーザー）が十分に理解している。
• 顧客のサブジェクトエリアの概念（「ドキュメント」、「タスク」、「計画」など）で操作する。

ダイアグラム内のプロセスをビジネストランザクションに分割することをお勧めします（ビジネストランザクションを参照）。図7.2を参照してください。これにより、主なシナリオのリストを取得できます。 つまり、図の各ビジネストランザクションは、システムを使用するユーザーのシナリオの形式で提示される1つの最終操作に対応する必要があります。



図7.2は、ビジネストランザクション別に分類されたプロセス図をグループ化する図コンテナーの例を示しています。







図7.2-プロセスをビジネストランザクションに分割する



他のアクティビティ図と同様に、プロセスの開始と終了（完了オプション）を示す必要があります。 たとえば、図 7.4、「固定された要件」または「拒否された要求」プロセスを完了するための2つのオプションがあります。 しかし、このタイプの図では、正準図とは異なり、プロセスはいくつかのイベントで開始できます。図7.3を参照してください







図7.3-プロセスへの2_myエントリポイントを持つダイアグラムのフラグメント



例として、前の段階で特定した「A1.1顧客ニーズの収集」プロセスをより詳細に説明します。 後続の各ステップでは、前のステップの結果（製品）を使用することに注意してください。 図7.4は、顧客のニーズを収集するビジネスプロセスを説明する図を示しています。 IDEFOダイアグラムとは異なり、ビジネスプロセスダイアグラムでは、条件付き遷移をシミュレートすることができます。これは、機能するアルゴリズムを記述するために重要です。「条件が満たされた場合、これを行います。 このタイプのチャートでは、パフォーマーとシステムが使用するリソースを指定できます。 たとえば-ストレージ。







図 7.4-顧客のニーズを収集するビジネスプロセス図



開発中のソフトウェア製品のビジネスコンポーネントに関連するプロセスを検討しているという事実にもかかわらず、システム要素も図で区別できます。 たとえば、図7.4では、「ユーザーストーリー」ストレージがマークされています。

• ユーザー履歴システムに記録された正確性を分析するためのデータサンプリング。
• 新しい検証済みユーザー履歴のシステムへの登録のために直接。

矢印（図7.4で破線で示されています）は、プロセス中のストレージへのデータ転送を表示でき、転送される特定のデータタイプと、他のプロセスの結果としてストレージから差し引かれたデータのタイプを示します。 したがって、修正するのは、どのプロセスで、どの種類のストレージが使用され、システムがユーザーとどのようなビジネスデータを交換するかです。

2.ビジネスプロセス図を使用してロールとデータストアを定義する例

ビジネスプロセスを説明する別のより複雑な例を見てみましょう。 図7.5は、関係者からの要求を処理するプロセスをシミュレートする図を示しています。







図 7.5-利害関係者アプリケーションを処理するビジネスプロセス図



このタイプの図のもう1つのプラスは、消費者、イニシエーター、プロセスエグゼクティブを識別する機能です。これにより、設計の初期段階でターゲット製品のユーザーの役割を識別し、それらの機能セットを概説できます。 このため、各プロセスはエグゼキューター（ユーザー（ロール）またはシステム）に（矢印で）接続されます。



それだけではありません。 前述のように、図は（矢印の方向に）一部のプロセスがストレージに書き込む方法と、他のプロセスがそこからデータを選択する方法を示しています。 そして、このタイプのダイアグラムを使用するもう1つの便利な機能は、データを取得して記録するためのストレージへのアクセスのすべての「ポイント」を決定することです。 これらのプロセスを分析することで、データベースレコードでのデッドロックの発生を最小限に抑えるように最適化できます。



たとえば、図 7.6ストレージ「アーキテクチャの要素」は、複数のビジネストランザクションおよび複数のプロセスで使用できます。







図 7.6-ダイアグラムを使用してリポジトリを形式化する



その結果、使用されているすべての図に従って収集されたウェアハウスの依存関係のテーブルを取得できます。図7.7を参照してください。







図 7.7-リソース依存関係テーブル



ビジネスプロセス図は、ストレージ内のデータを変更する機能の不整合を特定するのにも役立ちます。 その他のフクロウ：要件の一貫性をチェックします。 したがって、モデリングの前の段階で特定された機能を実装するすべてのプロセスの詳細な順次説明と、データウェアハウスの構造のモデルとの関係の決定が行われます。 ICONIX方法論では類似のものが使用されますが、シーケンス図のみが基礎として使用されます。

3.リエンジニアリングにビジネスプロセス図を使用します

図の助けを借りて顧客に存在するビジネスプロセスをモデリングする場合、次の問題が発生することがよくあります。

• 異なる部門による機能の重複。
• 実行者間の責任の非効率的な配分。
• 請求されていない製品を生産するプロセス;
• プロセスの合流点での責任範囲の「たるみ」。
• プロセス内の力の交差など

そのような場合、チャートは、ビジネスプロセスの最適化またはリエンジニアリングの問題について顧客の担当者と話し合う際の出発点となります。 顧客の側に、存在するプロセスを自動化するのではなく、新しい「正しい」プロセスを開発して自動化するよう説得できることが非常に重要です。 しかし、同時に、これに関連する問題を隠してはいけません。少なくとも、企業の基盤を壊すことや、システムを導入する際に、古いビジネスプロセスと新しいビジネスプロセスの両方をサポートするための時間が必要です。 おそらく、移行を緩和し、不便を最小限に抑える3つ目の一時的なオプションを受け入れます。



プロセスを変更する必要性を顧客に明確に納得させるために、これらのプロセスの重要な指標のシステムを開発して、代替の効果を定量化することができます。 プロセス自体の有効性と、プロセスによって生成された製品の両方を測定できます。



そのような研究を提示することは、比較表の形でより良いです。 列として、プロセスを示します。現在とターゲット、またはターゲットのいくつかのバリアントです。 文字列として-承認されたインジケータ。 交差点で、プロセスのインジケータ値が入力されます。

たとえば、ベンチマークテーブルは次のようになります。







そのような指標の形成とその価値の決定は、顧客の代表者の直接の参加で行われるべきです。 インジケータの数は20を超えてはなりません。

4.予備プロジェクトの強度を計算します

この章で検討する図のタイプには、もう1つの非常に重要な利点があります。 それらに基づいて、ターゲット製品を開発するプロセスの予備的な労力をかなり正確に推定できます。 たとえば、「リスト形式」、「カード形式」、「機能」、「レポート」など、チャートの各要素でステレオタイプに署名すると、実装する必要がある要素の数を簡単に計算できます。 チームで確立された技術を使用して、各タイプの要素の実装の複雑さは一般的に知られています。 精度を上げるには、複雑度係数を使用できます。



たとえば、労働強度の予備計算の表は次のようになります。







便宜上、3種類の「複雑な」、「中程度」、「単純な」係数を使用でき、各種類の要素には独自の値があります。 例：

• エンティティの場合：0.3-シンプル。 0.7-平均; 1-複雑;
• 選択用：1-シンプル。 1.5-中; 2-複雑な;
• フォームの場合：0.7-シンプル; 1.5-中; 2-複雑な;
• 手順の場合：1-シンプル。 3-中; 6-複雑;
• レポートの場合：0.5-シンプル。 1-中; 3-複雑な;

最初の段階で同様のテーブルを開発したので、設計全体で将来使用することができ、要件を指定して確定するときに変更することができます。 これは、「手首を軽く振る」ことで、アナリストがプロジェクトマネージャーに、新しく洗練された要件のリソースコストの更新および更新された予測を提供する場合に非常に効果的です。

5.プロジェクトの境界を修正します（必要な場合）

前の章では、プロジェクトの境界と、変更できることについて説明しました。 たとえば、検討中のプロジェクトでは、プロセスのリストを明確にした後、最も重要な機能の1つであるチームでのコミュニケーションを見逃したことがわかります。 顧客のニーズを収集して議論するには、会議、集会、議論などを整理する必要があります。したがって、関係者とのコミュニケーションの管理をサポートする機能のブロックを設計する必要があります。



前の章で説明したシステムの機能モデルの図に、新しいプロセス「Meeting Management」を追加しました。図7.8を参照してください。これは紫色で強調表示されています。

プロセスは、以前に策定された要件の実装に関する情報を受け取り、機能の結果は、会議、反復などの計画になる場合があります。たとえば、このモジュールは、招待された参加者に会議に関する情報を含む手紙を送信できます。







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

6.プロセスモデルの使用を要約する

システムの機能とその使用シナリオを詳細に改良する段階では、多くの場合、システムがどのように機能するかを理解する糸を失ってしまうような感覚があります。 これを恐れて絶望しないでください。 引き続き要件を明確にし、システムの最初の理解を再考します-これは正常です。 徐々に、すべてのもの自体が所定の位置に収まります。



したがって、自動化のために設計されたビジネスシナリオの完全な説明とデータウェアハウスの予備構造を取得したら、データモデルの開発に進むことができます。 実際、このタイプのダイアグラムは、プロセスの説明と並行して、より早く構築することができますが、それにもかかわらず、この作業の大部分は、すべてのビジネス機能を特定した後に行う必要があります。



私の実践では、上級管理職の助けを借りて、ビジネスモデリングチャートが中間管理職の間で普及したプロジェクトがありました。 人々は関与し、それらを使用する能力においてすでに積極的に競争していた。 これはファッショナブルなだけでなく、現在のビジネスプロセスを議論したり、新しいビジネスプロセスをモデリングしたりする際にも非常に便利です。



ビジネスプロセス図を使用する必要性をよりよく理解するために、地理的な地図から類推できます。 目的地間の最適なパスを選択するために地形マップを使用することで得られるすべての同じ利点は、ビジネスプロセス図から取得できます。ビジネスプロセス図は、プロセスの進捗とリソースの計画結果（製品）への変換のマップとして機能します。



この類推をすべてのプロジェクト参加者に伝えることが望ましい。 準備された図の品質とすべての利害関係者への有能なプレゼンテーションを証明する理想的なオプションは、戦略に反対する将軍のように、図の上に群がるチームメンバーの会議と彼らに沿った先導のように見えます。 類推をさらに発展させると、前述のIDEFO図は、地域（この場合は主題）によってグループ化された地図の地図と比較できます。



次のパートでは、サブジェクトドメインリンクのエンティティを特定します。