[2004 年 11 月号] |
[技術講座]
前回より始まったこの連載では、代表的なソフトウェア開発プロセスである UP のライフサイクルモデルについて解説しています。前回は UP のライフサイクルモデルの基本的な構造(サイクル、フェーズ、反復、ビルド)について、またプロジェクト(サイクル)と反復の計画について解説しました
今回は UP を適用するプロジェクトで最初に訪れるフェーズ、方向づけフェーズの範囲と計画について解説します。
本題の前に、まだ説明が済んでいない重要な概念、作業分野を説明します。
作業分野とは、開発プロセスで定義している作業や成果物を目的別にまとめたものです。典型的な作業分野を以下に示します。
この作業分野を見てみると、ウォーターフォールモデルのフェーズと似ていることに気づくかもしれません。ウォーターフォールモデルのフェーズは成果物の単位で区切られています。UP の作業分野も成果物を目的別に分けているために、自然とウォーターフォールモデルと似た名前になるわけです。
前回でも説明しましたが、UP のフェーズは、方向づけフェーズ、推敲フェーズ、作成フェーズ、移行フェーズといったように、作業分野とは違う観点で区切られています。UP では反復型開発であるため、図 1 のように、それぞれの反復で、さらにはそれぞれのフェーズで同じ作業分野を実行することもあります。
例を挙げましょう。
推敲フェーズではユースケースの詳細を定義するために作業分野「要求」の作業を行います。作成フェーズでは、要求が変更されるとユースケースの詳細を再定義するために作業分野「要求」の作業を行います。ただし、推敲フェーズと作成フェーズでは、作業分野「要求」の作業にかける時間の量が異なります。
図 1 作業分野
このように、UP は反復型開発であるがゆえにフェーズと作業分野が分かれているのです。
4 つのフェーズの中でも方向づけフェーズは、なじみが薄いフェーズです。方向づけフェーズとは何を達成するためのフェーズで、そのために何をしなければならないでしょうか?
ROI を評価する
方向づけフェーズの目的はプロジェクトの開始です。プロジェクトを開始するためには、そのプロジェクトの正当性を保証できなければなりません。プロジェクトの正当性を保証するためには、二つの数値、つまりソフトウェアを作ることによって得られる利益と、そのためにプロジェクトに投資する金額を明らかにしなければなりません。そして、この二つの数値からプロジェクトの ROI ( Return on Investiment ) を導くことによって、プロジェクトを開始するべきかどうか分かるのです( 図 2 参照 )。
図 2 ROI
この ROI を算出するためにビジネスモデリングを行います。ビジネスモデリングでは、ソフトウェアが支援する対象のビジネスをモデリングし、ビジネスのどの範囲をソフトウェアで自動化するか、支援するか決定します。
ビジネスモデリングを行うことで、ユースケースの大部分が見つかります。そして、ユースケースをもとにプロジェクトの予算を大雑把に見積もることができ、またユースケースによってビジネスにどのような効果と利益が得られるのか判断できるようになります( 図 3 参照 )。
図 3 ビジネスモデリング
要求以降から始まるプロジェクトの方向づけフェーズ
プロジェクトによっては、要求から始まるもの、分析から始まるもの、設計から始まるものもあるでしょう。例えば、ビジネスモデリングや要求の作業をユーザー企業のシステム部門が行っている場合などです。これらのプロジェクトに方向づけフェーズは必要なのでしょうか。
結論から言うと、これらのプロジェクトでも方向づけフェーズは必要です。方向づけフェーズとは、プロジェクトの開始を目的としたフェーズです。プロジェクトのインプットとなるビジネスモデルや要求仕様書をもとに見積もりを行い、そのプロジェクトの採算性を評価する期間として、方向づけフェーズを用意する必要があるでしょう。
方向づけフェーズは、プロジェクトの正当性を評価することの他にもう一つ大事な目的があります。それは開発プロセスを用意することです。
UP や RUP などの開発プロセスを採用するとしても、これらの開発プロセスをそのままプロジェクトに適用できるわけではありません。これらの開発プロセスはどんなプロジェクトでも共通する作業や成果物だけしか定義されていないこともあれば、特定のプロジェクト( Web システム用、組み込みシステム用など)にしか必要とされない作業や成果物が定義されていることもあります( 図 4 参照 )。
図 4 開発プロセスの範囲
この開発プロセスをそのまま適用してしまうと、プロジェクトはどうなってしまうのでしょうか?
もし、プロジェクトメンバーが開発プロセス通りにプロジェクトを進めたとすると、不必要な作業を行って不必要な成果物を作成してしまうことになります。このために、本来であればかかるはずのなかった時間やコストがかかってしまいます。また、不必要な成果物を作成してしまうことで、顧客の要求とはかけ離れたソフトウェアが出来上がってしまうこともあります( 図 5 参照 )。
図 5 開発プロセスを修正しない場合の例 1
もし、一部のプロジェクトメンバーが開発プロセスを独自に解釈して、開発プロセスとは違うやり方でプロジェクトを進めると次のような問題が起きるでしょう( 図 6 参照 )。
一部のプロジェクトメンバーが不必要な作業を行い、他のプロジェクトメンバーが不必要な作業を行わなかった場合には、それぞれの成果物ごとの品質にばらつきが出てしまい、最終的なソフトウェアの品質にもばらつきが出てしまいます。
また、プロジェクトメンバーが必要な作業を行わなかった場合には、顧客の要求とはかけ離れたソフトウェアが出来あがってしまいます。
図 6 開発プロセスを修正しない場合の例 2
プロジェクト特有の特徴や制約を考慮して開発プロセスを修正し、その開発プロセスを実践できるようにプロジェクトメンバーを指導しなければなりません。
開発プロセスを用意するためには次の手順で行わなければなりません。
プロジェクト特有の特徴や制約といっても、その内容はプロジェクトによって様々です。ここではその一例を挙げます。
プロジェクトの開始に関する問題
プロジェクトはどこから開始されますか?
ビジネスモデリングの問題
組織、人の問題
プロジェクト組織、メンバーにどのような問題がありますか?
ソフトウェアアーキテクチャの問題
技術的な制約として開発プロセスに影響を与える要素はありますか?
例に挙げたような問題に対応するために、以下のような開発プロセスの修正が必要になります。
ライフサイクルモデルの選択
プロジェクトの特徴に合わせて、どのフェーズに重点をおいてプロジェクトを進めるのか判断します。
研究・開発の色が強く、ソフトウェアの要求がなかなか決まらないプロジェクトであれば、推敲フェーズの期間を長く取ります。
ソフトウェアの要求が早い時期から詳細に決まっていて、ソフトウェアアーキテクチャ上の問題も少ないプロジェクトであれば、作成フェーズの期間を長く取ります。
早い時期から運用テストを始める必要がある、一部のユースケースを早い時期にリリースしなければならないプロジェクトであれば、移行フェーズの期間を長く取ります。
作業・成果物の追加、削除
プロジェクト特有の特徴、制約のため、特別な作業を実施する必要がある場合には作業や成果物を追加します。また不必要な作業や成果物がある場合にはこれを削除します。
作業・成果物の修正
プロジェクトメンバーのスキルレベルが低い場合には、作業手順や成果物の基準をより詳細に定義しなければなりません。プロジェクトの期間が短い場合には作業手順や成果物の基準をより簡潔にすることでスケジュールの短縮を図らなければなりません。
レビューの修正
プロジェクトメンバーのスキルや、ソフトウェアに求められている品質の水準に合わせてレビュー対象の成果物、レビューの参加者と頻度、レビュー項目の詳細度を定義します。
各フェーズで行う作業、作成する成果物の選択
選択したライフサイクルに合わせて、どのフェーズでどの作業を実施し、どの成果物を作成するのか選択しなければなりません。
ビジネスモデリングの目的はソフトウェアが支援するビジネスの範囲を決定することです。これにより、プロジェクトの予算を見積もることができ、またソフトウェアを導入することでビジネスにどのような効果と利益が得られるのか判断できるようになります。
そのためには 図 7 のように、現行業務のビジネスモデルを作成し、現行業務を評価して問題を把握し、新業務のビジネスモデルを作成し、新業務を評価するという手順を踏まなければなりません。
図 7 ビジネスモデリングの流れ
今回の記事はこれらの手順の詳細についての解説は別の機会とし、実際にどのようなビジネスモデルを書いていくのか説明します。
ビジネスモデリングでは、ビジネスユースケースモデルとビジネス分析モデルを作成します。
ビジネスユースケースを特定する
まず初めに対象業務のビジネスユースケースを特定します。
ビジネスユースケースとは何でしょう。
ビジネスユースケースとはビジネスについてのユースケースです。なんだか禅問答みたいですが、つまりはこういうことです。
ユースケースとはソフトウェアのユーザーに価値をもたらす機能で、その価値を達成するためのフロー(シナリオということもある)を含みます。これをビジネスに当てはめたものがビジネスユースケースです。ビジネスユースケースとは、ビジネスのユーザーに価値をもたらすビジネス上の機能で、その価値を達成するための業務フローを含むわけです。
ユースケースとビジネスユースケースと同じような関係のものが他にもあります。ビジネスモデリングでは、ビジネスアクターというものを定義します。ビジネスアクターとは、上記のビジネスユースケースの説明で登場したビジネスユースケースによって価値をもたらされるビジネスの外にいる利害関係者です。ビジネスの顧客などは典型的なビジネスアクターです。
ビジネスユースケースとビジネスアクターの関係は、図 8 のように記述します。
図 8 ビジネスユースケース図
ビジネスアクターと関係を持たないビジネスユースケースもあります。会計系の業務や人事系の業務のビジネスユースケースなどはビジネスアクターと直接の関係を持つことはありません。しかし、これらのビジネスユースケースはビジネスアクターに直接の価値をもたらしていませんが、ビジネスの内にいるユーザーに対して価値をもたらしています。例えば、人事系のビジネスユースケースは社員に価値をもたらしています( 図 9 参照 )。
図 9 ビジネスアクターと関係しないビジネスユースケース
ビジネス分析モデルの業務フローを作成する
ビジネスユースケースが特定できたら次は、ビジネスユースケースごとに複数の業務フローを作成します。
業務フローは UML のアクティビティ図を使って記述します。業務フローでは、以下のことを定義しなければなりません。
この 4 つを定義するために、最低 4 つのモデル要素を覚える必要があります( 図 10 参照 )。
図 10 アクティビティ図を使った業務フロー
「どのような作業があるのか?」を定義するために、アクション状態を用います。
「どのような順番で作業するのか?」を定義するために、遷移を使います。
「誰が作業するのか?」を定義するために、スイムレーンを使います。スイムレーンは例のようなアクティビティ図上の枠です。作業を担当する役割の枠を作り、その中に作業を配置することで、誰がどの作業を行うのか明示します。
UP では、作業を担当する役割を定義するために、ビジネスアクターやビジネスワーカーを使います。ビジネスアクターはビジネスの外にいる利害関係者を定義する概念であることに対し、ビジネスワーカーはビジネスの内にいる利害関係者を定義する概念です。
「どんなものや情報がやりとりされるのか?」を定義するために、オブジェクトフローを使います。オブジェクトフローは例のような、作業に入る矢印先のアイコン、作業から出る矢印先のアイコンです。
UP では、ものや情報を定義するために、ビジネスエンティティを使います。ビジネスエンティティは次の説明にあるクラス図で詳細を定義します。
ビジネス分析モデルのクラス図を作成する
ビジネスモデリングで作成するクラス図には 2 種類あります。1 つがビジネスワーカーとビジネスエンティティの関連を定義するクラス図で、もう 1 つがビジネスエンティティ間の関連を定義するクラス図です。
ビジネスワーカーとビジネスエンティティの関連を定義するクラス図では、業務フローの情報をもとにして、ビジネスユースケースの単位に作成します( 図 11 参照 )。
業務フローでは作業の遷移から、どのビジネスワーカーとどのビジネスワーカーが、またはどのビジネスワーカーとどのビジネスアクターがコミュニケーションを行っているか識別できます。また、作業とオブジェクトフローの関係からどのビジネスワーカーがどのビジネスエンティティを使って作業をしているか識別できます。
図 11 ビジネスワーカーとビジネスエンティティのクラス図
ビジネスエンティティ間の関連を定義するクラス図も、業務フローの情報をもとに作成できます。業務フローの中でオブジェクトフローとして登場するビジネスエンティティには何らかの関連が存在しています。それぞれの作業で何を行っているか調べることによってビジネスエンティティ間の関連を識別します。ビジネスエンティティのクラス図は、1 つの業務フローを調べるだけでは完成しません。ビジネスエンティティは様々な業務フロー、様々なビジネスユースケースに登場するため、それらのすべてを調べることによって、ビジネスエンティティのクラス図が完成します( 図 12 参照 )。
図 12 ビジネスエンティティのクラス図
前回の記事で、UP を適用したプロジェクトでは反復を単位として計画を立てると説明しましたが、方向づけフェーズに限り反復を行いません。そもそも、反復とは一定の期間内に動作するソフトウェアをリリースすることです。方向づけフェーズでは、必ずしも動作するソフトウェアをリリースする必要がないため、反復を計画する必要がないのです。
だからといって、方向づけフェーズは計画が必要ないわけではありません。プロジェクトを開始するためのプロセスの修正やビジネスモデリングなどの一連の作業を計画しなければなりません。
方向づけフェーズで行わなければならない作業を分類すると以下のようになります。
どの作業分野からプロセスを修正するか
これらの作業の中で、一番初めに取り掛かり完了しなければならない作業は「ビジネスモデリングの修正」です。この作業が完了しなければビジネスモデリングの作業を開始できません。
「ビジネスモデリングの修正」についで「ライフサイクルモデルの選択」や「プロジェクトマネジメントの修正」などの作業は優先度が高いです。方向づけフェーズの終了間際には、プロジェクトの計画を立てなければならないためです。
その他の作業については「要求の修正」、「分析の修正」、「設計の修正」、「実装の修正」、「テストの修正」、「導入の修正」といった順番で行っていけばよいでしょう。推敲フェーズの計画によっては、これらの一部の作業を推敲フェーズ中に行うことも可能です。
何の単位にビジネスモデリングを計画するか
プロセスの修正結果によりますが、基本的にはビジネスユースケース単位に作業者を割り当てていけばよいでしょう。
表 1 は、方向づけフェーズの計画のサンプルです。
表 1 方向づけフェーズの計画
今回は、方向づけフェーズの範囲と計画について説明しました。次回の記事では、推敲フェーズについて、深く掘り下げて説明する予定です。
どうぞ、お楽しみに。
[1] 『UMLによる統一ソフトウェア開発プロセス―オブジェクト指向開発方法論』Ivar Jacobson・James Rumbaugh・Grady Booch/著, 藤井 拓/訳, 翔泳社
[2] 『The Rational Unified Process; An Introduction; Third Edition』Philippe Kruchten/著, Addison-Wesley
[3] 『The Rational Unified Process Made Easy; A Practitioner's Guide To The RUP』Per Kroll・Philippe Kruchten/著, Addison-Wesley
[4] 『ラショナル統一プロセスによるJ2EEアプリケーション構築』 Peter Eeles・Kelli Houston・Wojtek Kozaczynski/著, 堀井 未来/訳, 新紀元社
© 2004 OGIS-RI Co., Ltd. |
|