業務分析
はじめに業務分析として、業務の流れを整理していきます。
業務の流れは以前から業務フローと呼ばれていて、情報システムを構築する際には、大抵作成されていました。しかし、標準化された表記方法ではなく、コンピュータのディスクや帳票などのシステム構成も混ぜてしまった図を作っていたのが実情です。
通常、業務を整理している段階では、どこをシステム化すればよいかを検討します。しかし以前の状況は、システム化するための資料の作成段階で、すでに導入するシステムが決まっているという、おかしな話になっていました。さらに、流れは役割ごとに整理するべきですが、従来の業務フローではきちんとされていませんでした。
また、UML以外の表記としてはIDEF（Integrated DEFinition methods）というものも使われてきました。ところが、そのあとの工程ではDFD（Data Flow Diagram）などの構造化手法の表記方法を使うため、現在のオブジェクト指向の開発環境にはマッチしません。UMLを使うメリットとしては、その後のオブジェクト指向の開発工程に成果物を引き継げます。
最近では、SOAの普及によって業務フローはビジネスプロセスと呼ばれ、注目されています。ビジネスプロセスは、後の工程でBPEL（Business Process Execution Language）などのビジネスプロセス用の言語としてコンピュータに実装して動作することになります。
ビジネスプロセスはUMLの他に、BPMN（Business Process Modeling Notation）という表記方法もあります。こちらも標準化はOMGが行っていますので、最終的にはどちらで作成してもほぼ同じ意味付けになります。
それでは、具体的にUMLによる業務フローを見ていきましょう。
（画像をクリックすると別ウィンドウに拡大図を表示します）
業務フロー
業務フローはUMLのアクティビティ図を使って表現します。アクティビティ図は、レーンと呼ばれる縦の区画があります。図3の例では、出張申請をする申請者とそれを受け付ける承認者、経理担当者が該当します。この区画は役割ごとになっていて、UMLではロールと呼ばれています。
アクティビティ図では、このロールごとのフローを書いていきます。フローは皆さんがよく知っているフローチャートと同じです。行われるアクティビティをUMLではアクションと呼びます。そして、アクション間の遷移であるフローや分岐、さらに並行処理を示すジョインなどがあります。
図3のフローは申請者の黒丸からはじまります。申請者が「出張申請を登録する」というアクションを起こして、さらに「出張旅費を計算する」「出張申請を提出する」というようにフローが進んでいきます。
そして、承認者は申請者から出張申請を受け取って「出張申請を確認する」を行います。その結果、「承認」「却下」「修正」のいずれかのフローに分かれます。この分岐に書く条件をUMLではガード条件と呼びます。
そして、「承認」の場合は「出張申請を承認する」に移り、経理担当者に出張申請を渡します。経理担当者は「申請内容を確認する」を行い、その後でフローは2つに分かれます。
分かれたフローは、平行に行われます。「仮払い金を用意する」「チケットを手配する」の両方が終了してから、次の「出張旅費を渡す」がはじまります。これをフォーク／ジョインと呼びます。最後に出張旅費を申請者に渡して、申請者が「出張旅費を受け取る」を行って終了です。終了は黒二重丸で表します。
今回は、開発プロセスのはじめの業務分析について解説しました。次回は、システムに必要な機能を決める要求分析を解説します。
タイトルへ戻る
