モデルの品質
あなたのモデルは、どのくらい”メソッド＆スタイル”のガイドラインに準拠しているでしょうか？いくつかのベストプラクティスに基づく品質評価基準に従って、あなたのモデルを評価してみましょう！
モデルの品質は、あなたが設定したモデル化の目標に大きく依存します。すべてのモデラーが共有する目標の１つは、明瞭でかつ読みやすいBPMN モデルを作成することです。 プロセスモデラーは、次の「優れたモデリングの原則」に従って、あなたのモデルを評価します:
- 正確性 (Correctness)
- 妥当性 (Relevance)
- 効率性 (Efficiency)
- 明解さ (Clearness)
- 同質性 (Comparability)
- 良い構成 (Good composition)
上記の原則の再検討はもちろんのこと、品質評価基準の適用は、しっかり定義され、矛盾がない、完全で、読みやすいモデルにあなたを導きます。
品質評価基準は、３つのセクションに分割され、広範囲の統計値を取り上げています。以下に、この品質評価基準を紹介します：
評価指標は、以下の５つのカテゴリに分かれています：
違反度
ここでは、あなたのモデルに対する情報/警告件数を基にBPMN仕様と”メソッドとスタイル”に対する違反の統計を取得します。
| 名前 | 説明 | 評価基準 | 総合品質への関連性 |
|---|---|---|---|
| メソッド＆スタイルの違反件数 | ”メソッド＆スタイル”のルールは、読みやすく、一貫性のあるダイアグラムを求めます。
良いモデルを作成するためのヒント：すべての”メソッド＆スタイル”の違反をなくすようにしてください。 |
違反件数が ゼロならば： グリーン 1以上ならば： レッド |
あり |
| エラー表示件数 | BPMN仕様は、使用する各要素のルールを定義します。したがって、モデルの読み手の大多数が理解できるように、BPMNのルールを順守する必要があります。
良いモデルを作成するためのヒント：各BPMN仕様の違反のすべてを取り除きます。 |
エラー件数が ゼロならば： グリーン 1以上ならば： レッド |
あり |
| 警告表示件数 | BPMN仕様にいくつかの曖昧な部分があります。明確に定義されていないパターンを使用している場合は、あなたに警告で注意を促します。
良いモデルを作成するためのヒント：意味のあるモデルパターンを１つだけにしてみてください。 |
警告表示件数が ゼロならば： グリーン 1-5ならば： オレンジ 6以上ならば： レッド |
あり |
| 情報表示件数 | 情報（ブルーの情報アイコンで示す）は、いずれを使用するか/しないかの忠告です。
良いモデルを作成するためのヒント：組織によって、使用しなければならないパターン/要素と使用してはいけないものをモデリングの規則として定義する必要があります。 |
色なし | なし |
複雑性
複雑性の評価は、あなたのモデルがいかに読みにくいか、どのくらい複雑かを示します。この評価基準はモデルを簡素化するのに役立ちます。
| 名前 | 説明 | 評価基準 | 総合品質への関連性 |
|---|---|---|---|
| 開始イベント数（最大: 5） | メインレベルの開始イベント数が多すぎると、ダイアグラムが読みにくくなります。異なった多くの開始点は、必要以上にダイアグラムの断片化を招く恐れがあります。
注：開始イベント数は、５以下にすべきです。 |
開始イベント数が 6以上ならば： オレンジ それ以外ならば： グリーン |
あり |
| プロセスレベルあたりのアクティビティ数（最小: 5, 最大: 9） | シンプルなダイアグラムにするには、各プロセスレベルのアクティビティ数は、少なくとも５以上、多くても９にすべきです。プロセスの構造化機能を使用して、詳細をサブプロセスに圧縮してみましょう。階層的なモデリングスタイルをしっかり適用すると、読み手は容易にモデルを理解できるようになります。
注：主なアクティビティ（サブプロセスを含め）は、９を超えないように定義してみてください。 |
アクティビティ数が 5-9ならば： グリーン 1-4、または10-15ならば： オレンジ 16以上ならば： レッド |
あり |
| サププロセスのレベル数（モデルの深さ、最大: 3） | サブプロセスレベルの数が多すぎると、BPMNプロセスが読みにくくなります。サブプロセスレベルがあまりにも多くなる可能性は： モデルをあまりにも多くの小さいレベルに分割して階層構造を定義しているか、モデルをあまりにも詳細に定義している場合に起こります。
注：あなたが３つ以上のサブプロセスレベルを定義した場合、モデルをどのようしたら、より明確に分割することができるか、あまりにも詳細にモデル化しているかどうか、再検討する必要があります。 |
モデルの深さが 3以下ならば： グリーン 4-5ならば： オレンジ 6以上ならば： レッド |
あり |
| ５つ以上の流出パスを持つゲートウェイ数 | モデルの最上位レベルは、プロセスに概要を説明しますので、読み手が容易に理解できるようにすべきです。ゲートウェイの数が多いことは、あまりにも多くの例外パスをトップレベルで表記していることを示しています。
注：トップレベルでは、最も重要な例外のみを表記するようにします。 |
できるだけプロセスの継続に関連するゲートだけを表記 | なし |
| ブラックボックスのプール数 | ブラックボックスプールは、プロセスとモデル化されたプロセスと対話関係者を表します。繰り返しになりますが、その関連性と重要性を検討してください。
注：プロセスの各パートナーをすべてモデル化することを避け、プロセスを理解するために必要なものだけに絞ってください。あなたのダイアグラムが、あまりにも多くのプールを持っている場合、理解するのが難しくなります。 |
関連性のあるブラックボックスプールのみを表記します | なし |
一貫性
モデリング過程の最終段階で一貫性のあるダイアグラムを入手したい場合、この一貫性の評価基準はダイアグラムの欠落情報箇所を示します。
| 名前 | 説明 | 評価基準 | 総合品質への関連性 |
|---|---|---|---|
| 非接続のサブプロセス数 | サブプロセスは、プロセスの詳細を階層的に構造化するために使用されます。したがって、サブプロセスは、階層構造に沿って下位に、より詳細なプロセスフローを示します。
注：サブプロセスが空か、その詳細を参照していない場合、モデルは”作成途中”であり、すなわち完成していないと見なされます。 |
未接続のサブプロセス数と 未参照のコールアクティビティ数 の両値の合計が 0ならば： グリーン 1-10ならば： オレンジ 11以上ならば： レッド |
あり |
| 非接続のコールアクティビティ数 | コールアクティビティは、プロセスモデリングの重複の無駄を排除するために使用されます。コールアクティビティは、中央で一元的に定義された再利用可能なプロセスステップを参照します。
注：コールアクティビティがその詳細を参照していない場合、モデルは”作成途中”であり、すなわち完成していないと見なされます。 |
未接続のサブプロセス数と 未参照のコールアクティビティ数 の両値の合計が 0ならば： グリーン 1-10ならば： オレンジ 11以上ならば： レッド |
あり |
| 終了イベントに関係する開始イベントの数 | プロセスは、外部関係者のメッセージによって開始される場合、プロセスが終了したとき、通常はこの関係者に通知されます。この通知は通常、メッセージ終了イベントを使用して表記されます。 | 最低１つのメッセージ開始イベントと最低１つのメッセージ終了イベントが あるならは： グリーン ないならは： オレンジ |
あり |
| タイプを指定した/されていないタスクの数 | タスクのタイプを指定することによって、このタスクが実行される方法を示します。あなたがタスクタイプを指定する場合は、すべてのタスクにタイプを指定するようにしてください。一部のタスクだけにタイプを指定した場合、あなたのモデルは不完全と見なされます。
注：一部のタスクにタイプ指定があり、他のタスクにない場合、モデルは”作成途中”であると見なされます。 |
いずれかの値（タイプを指定した/されていないタスクの数）をゼロにすべきです。 | なし |
| 読み取り/書き込みのみのデータオブジェクトの参照数 | データオブジェクトがアクティビティによって使用（読み取り）されている場合、同じプロセス内でそのアクティビティをインスタンス化する必要がある場合があります。この場合、データオブジェクトのインスタンス（データの繰り返し）がプロセスの１サイクル(開始から終了まで)の単位を限定します。
注：データオブジェクト（およびデータオブジェクト参照）は、それを読み取るモデルと同一のモデル内で記述する必要があります。 |
各データオブジェクト参照には、少なくとも１回の書き込みデータ関連があるようにします。 | なし |
| 無名のデータオブジェクト数 | データオブジェクトの要素は、そのデータ詳細がXML形式で定義されているため、目には見えません。その代わりにラベル名がデータオブジェクト参照によってダイアグラム上に表示されています。したがって、複数のデータオブジェクト参照は、１つのデータオブジェクトに関連付けることができます。これらのデータオブジェクトのすべてをバックグラウンドで（データオブジェクト参照の属性]ダイアログボックスを使用して）定義する必要があります。
注：データオブジェクトのラベルが記述されていない場合、モデルは”作成途中”であると見なされます。 |
無名のデータオブジェクト数がゼロになるようラベルを追加します。 | なし |
| 無名のデータストア数 | データストアの要素は、そのデータ詳細がXML形式で定義されているため、目には見えません。その代わりにラベル名がデータストア参照によってダイアグラム上に表示されています。したがって、複数のデータストア参照は、１つのデータストアに関連付けることができます。これらのデータストアのすべてをバックグラウンドで（データストア参照の属性]ダイアログボックスを使用して）定義する必要があります。
注：データストアのラベルが記述されていない場合、モデルは”作成途中”であると見なされます。 |
無名のデータストア数がゼロになるようラベルを追加します。 | なし |
| レーンに割り当てられていないアクティビティの数 | レーンは、タスクの実行責任（役割）を示すために使用することができます。
注：あなたがレーンを使用する場合は、各タスクをふさわしいレーンに割り当てるように心がけてください。 |
１つ以上のレーンがある場合は、すべてのタスクをそれらのレーンに割り当てる必要があります。 | なし |
曖昧さ
BPMNは、あなたがビジネスプロセスを正確に定義できるようにします。あなたが高度な標準化を目指す、あるいは頻繁に例示参照されるプロセスをモデリングしている場合は、この評価基準を活用して自由に定義できる要素（たとえば、アドホックなサブプロセスのような）の使用を避けをことができます、本当にふさわしい場合にのみ、これらの要素を使用します。曖昧さの評価基準は、あなたがビジネスプロセスをどのように定義したか正確に見積もるのに役立ちます。
| 名前 | 説明 | 評価基準 | 総合品質への関連性 |
|---|---|---|---|
| 全フロー要素数に占めるテキスト注釈数の割合（最大:3%） | あなたのモデルが、たくさんのテキスト注釈を割り当てている場合は、そのモデルは多くの解説を必要をとしているように思われます。繰り返し処理のアクティビティ（ループ、パラレル）や複合ゲートウェイは、読み手がそのロジックが理解できるようテキスト注釈でコメントが必要ですが、その他の一部は、プロセスフローやロジックとともに他のドキュメント属性に移しモデル化すべきです。テキスト注釈は読み手の理解を促進する部分にとどめ、解説はドキュメント属性で定義することをお勧めします。
注：テキスト注釈の数を最小限にするようにします。 |
テキスト注釈数／全フロー要素数の割合が 0-3%ならば： グリーン 4-10%ならば： オレンジ 11%以上ならば： レッド |
あり |
| 包括ゲートウェイと複合ゲートウェイの数 | 多数の包含（OR）ゲートウェイや複合ゲートウェイの使用は、モデルを曖昧にします。プロセスのロジックは、排他（XOR）ゲートウェイを使用した方が、より正確に、あるいは明確に定義できる可能性があります。
注：包含ゲートウェイと排他ゲートウェイの適切な使い分けを意識しましょう。 |
説明を要するゲートウェイ数をもっと少なくします。 | なし |
| 3つ以上のメッセージフローを接続したタスクの数 | １つのタスクに多くのメッセージフローが接続されている場合は、そのタスク詳細をサブプロセスを使用してモデル化すべき、またはできることを示しています。さもなければ、関係者間の相互作用に関する詳細があまりにも多すぎることを示している可能性があります。
注：プロセスフローの理解に本当に必要なメッセージフローだけを示しましょう。 |
タスクごとのメッセージフロー数を少なくします。 | なし |
その他
このカテゴリは、あなたに統計的な性質のものであるいくつかの評価基準を示しています。
| 名前 | 説明 | 評価基準 | 総合品質への関連性 |
|---|---|---|---|
| 関連するドキュメントの数 | この測定値は、統計的な性質のものだけです。 | プロセスがどのくらい文書化されているか、その度合いが分かります。 | なし |
英語
ドイツ語
日本語