|
[2004 年 8 月号] |
[技術講座]
今日、UML やオブジェクト指向は、パイロットプロジェクトや小・中規模プロジェクトに試験的に適用されてきた時代から、大規模プロジェクトに適用される時代へと移行しています。
大規模プロジェクトへの適用以前は（そして今も）、UML やオブジェクト指向は使っていても、開発プロセス不在のプロジェクトや、旧来のウォーターフォールモデルの開発プロセスを適用したプロジェクトが多く見受けられました。そして、意外にもそのようなプロジェクトもいくつかは成功しています。なぜ成功したのでしょうか？筆者は以下の理由によるものと判断しています。
このような成功要因は小・中規模プロジェクトゆえの特徴です。しかし、今後増えてくるであろう大規模プロジェクトではこのようにはいきません。大規模プロジェクトは大規模であるがゆえ、大人数の普通のエンジニアで開発しなければなりません。また、さまざまなリスクが存在します。大規模プロジェクトで成功するためには、このような大規模プロジェクト特有の要因を考慮したプロセスを用意する必要があります。このプロセスの候補となるのが UP ( Unified Process ) です。
UP は中・大規模プロジェクトを成功させるための仕組みを持つ開発プロセスです。本連載記事では 全 4 回に渡って、UP のライフサイクルモデルや、プロジェクトの成功の要となる「フェーズ」と「反復」をどう計画し実行すれば良いのか、説明します。
ソフトウェアライフサイクルとは、その名のとおり、ソフトウェアが生まれてから死ぬまでの流れを表す用語です。生まれてから死ぬまでとは、ソフトウェアが構想され、開発され、運用され、保守され、廃棄されるまでを指しています。ソフトウェアライフサイクルモデルとはソフトウェアライフサイクルをある一定のモデル（典型的なライフサイクルのパターン）で表現したものです。ウォーターフォールモデルは最もメジャーなソフトウェアライフサイクルモデルといえるでしょう。
UP は、ソフトウェアライフサイクルのうち、ソフトウェアの構想から納品までをサポートするプロセスで、運用や廃棄は含んでいません。
UP のソフトウェアライフサイクルは、サイクル（ Cycle ）、フェーズ（ Phase ）、反復（ Iteration ）、ビルド（ Build ）で説明されます。
UP のライフサイクルの概念において最も長い期間を表すものがサイクルです。サイクルとは、ソフトウェアが構想されてから納品されるまでを表す概念です。
特に、新規にソフトウェアシステムを構想して納品するまでを初期開発サイクル （ Initial Development Cycle ）と呼び、既にあるソフトウェアシステムに機能拡張を行う場合のサイクルを発展サイクル （ Evolution Cycle ）や保守サイクル ( Maintenance Cycle ) と呼びます。
図 1 初期開発サイクルとそれ以降のサイクル
UP は、対処しなければならない問題の視点から、サイクルを 4 つのフェーズに分けてコントロールします。
図 2 サイクルとフェーズ
方向づけフェーズは、ソフトウェア開発プロジェクトを開始しても問題ないか判断することが目的です。この目的のために、ソフトウェアに開発する価値があるか見極め、ソフトウェアのスコープ（ユースケース）を決定し、フィージビリティスタディによりソフトウェアの実現可能性を検証して、その上でプロジェクトを正式に開始します。もし、ソフトウェアに開発する価値がない、実現可能ではない場合には、プロジェクトを中止することもあります。
また、次の推敲フェーズを円滑に進めるための準備もします。例えば、推敲フェーズで行う作業についてプロセスを策定します。
推敲フェーズは、プロジェクトに存在するさまざまなリスクに対処することが目的です。特に、技術リスク、要求リスク、プロセスのリスクに対処します。この目的のために、ソフトウェアアーキテクチャのベースラインを確立し（技術リスクに対処）、要求を詳細化し（要求リスクに対処）、作成フェーズ移行で行う作業についてプロセスを策定します（プロセスのリスクに対処）。もし、作成フェーズまでにこれらのリスクが対処されていなければ、実際に問題が起きた場合の影響は、作成フェーズを再計画しなければならないほどになるでしょう。
作成フェーズでは、すべての要求を実現するソフトウェアを構築することが目的です。推敲フェーズで構築したソフトウェアアーキテクチャ、定義した要求、修正した開発プロセスに従い、開発を行います。
移行フェーズでは、運用が可能な状態でソフトウェアを納品することが目的です。バグへの対応、ソフトウェアの改善、納品に伴う作業を行います。
UP の最大の特徴は、反復型開発であるということです。反復型開発では、プロジェクトを 1 ヶ月から 3 ヶ月程度の反復に分割し、その反復中に要求を実現する動くソフトウェアを構築します。プロジェクトは複数回の反復を経て、完成したソフトウェアをリリースすることになります。
図 3 反復型開発
反復には以下のような特徴があります。
反復型開発を行って、短い期間で目標を達成していくことにより、プロジェクトに存在するさまざまなリスクを早期に解決できます。
反復では、ビジネスモデリング、要求、分析、設計、実装、テストなどの作業を行って、動くソフトウェアを構築します。この動くソフトウェアをビルドと呼びます。反復では、一連の作業を何度も繰り返します。そして、最後の一連の作業で構築したビルドをリリースします。 それぞれの作業にかける時間は、フェーズごとに異なります。また、フェーズによっては、まったく行わない作業もあります。例えば、作成フェーズの反復ではビジネスモデリングの作業を行いませんし、他のフェーズの反復と比べ実装やテストの作業に時間を多く取ります。
図 4 反復とビルド
UP でプロジェクトの計画を立てる上で、方向づけフェーズの開始時に、移行フェーズが終了するまでの詳細な計画を立てようと思ってはいけません。詳細な計画をプロジェクトの最初から立てることは不可能です。では、UP ではどのようにプロジェクトの計画を立てるのでしょうか？
UP では、フェーズの開始時にそのフェーズの計画を立てます。推敲フェーズの開始時には推敲フェーズの計画を立てる、作成フェーズの開始時には作成フェーズの計画を立てるといった具合です。推敲フェーズの開始時には、作成フェーズ、移行フェーズの計画は仮でしかありません。というのは、推敲フェーズが終わらないと、要求のボリュームも分かっておらず、また利用するアーキテクチャがどのくらい複雑かも分かっていないため、詳細な見積もりをしようにもできないのです。以下に、どのフェーズの開始時にどのくらいの精度でそれぞれのフェーズの見積もりができるか示します。
| 方向づけフェーズ の見積もり |
推敲フェーズ の見積もり |
作成フェーズ の見積もり |
移行フェーズ の見積もり |
|
|---|---|---|---|---|
| 方向づけフェーズ開始時 （ドメインの知識が 不足している状態） |
詳細見積もり （開発の企画から 見積もる） |
超概算見積もり （経験から見積もる） |
超概算見積もり （経験から見積もる） |
超概算見積もり （経験から見積もる） |
| 推敲フェーズ開始時 （ユースケースの一覧、 アーキテクチャメカニズムが 分かっている状態） |
― | 詳細見積もり （ユースケースの一覧、 アーキテクチャメカニズムから 作業工数を見積もる） |
概算見積もり （ユースケースの一覧から 大体の作業工数を見積もる） |
概算見積もり （ユースケースの一覧から 大体の作業工数を見積もる） |
| 作成フェーズ開始時 （ユースケースが詳細に 定義されている状態） |
― | ― | 詳細見積もり （ユースケースの詳細から 作業工数を見積もる） |
詳細見積もり （ユースケースの詳細から 作業工数を見積もる） |
| 移行フェーズ開始時 （ユースケースが 実現されている状態） |
― | ― | ― | 詳細見積もり （ユースケースの詳細から 作業工数を見積もる） |
それぞれフェーズの開始時には、フェーズで反復の回数と期間、要員の人数とスキルの目安を決めます。それぞれの反復で誰にどのような作業を担当させ、どのような順番で作業を実行するのかといった詳細な計画は立てません。そして、それぞれの反復の開始時にそのときの状況を考慮して計画することになります。
それぞれのフェーズで何に気をつけて計画を立てるべきかについては、次回以降の記事で説明します。
反復の計画は、プロジェクトと違い、より詳細な計画を立てます。反復の計画では、以下のことを考慮しなければなりません。
このどれから決めてもよいですが、一般的には反復の目標か、反復の期間から決めます。
作成フェーズの反復を、反復の目標主導で計画する場合
まず、目標として反復で実現するユースケースを選択します。仮に 2 つのユースケース（UC01、UC02）を実現することを反復の目標にします。また、この反復では、ユースケースの統合テストだけではなく、2 つのユースケースに関連した業務についてシステムテストを実施することを目標にしました。また、統合テスト、システムテストで見つけたすべての障害に対応することを目標にしました。
要員には、設計のスキルを持つ A さん、B さん、実装しかできない C さん、 D さん、 E さん、 F さん、業務全体を良く知っている G さんがいるとします。
目標を達成するために行わなければならない作業と作業工数を見積もり、設計作業に 5 日、実装作業に 5 日、統合テストケース分析作業に 5 日、統合テスト実施に 5 日、システムテストケース分析に 15 日、システムテストケース実施に 5 日かかると分かりました。また、統合テストやシステムテストで見つけた障害に対応する障害対応作業も必要になります。
ここまでで分かっている反復の目標、要員の人数とスキル、作業工数をもとに図 5 のように要員に作業を割り当て、スケジュールを立てました。その結果、反復の期間は 4 週間に決まりました。
作成フェーズの反復を、反復の期間主導で計画する場合
はじめに、反復の期間を 4 週間と決めます。
作成フェーズの反復であるため、いくつかのユースケースについて実現し、そのユースケースに関連した業務フローのシステムテストを実施したいと考え、これらのために行わなければならない作業と作業工数を見積もりました（結果は上記の例と同じ）。
また、要員は上記の例と同じメンバーがいるとします。
ここまでで分かっている反復の期間、要員の人数とスキル、作業工数をもとに、要員に作業を割り当て、スケジュールを立ててみた結果、2 つのユースケースを実現できると分かりました。そのため、反復の目標として、 2 つのユースケース（UC01、UC02）を実現すること、統合テストとシステムテストを実施すること、統合テストとシステムテストで見つけたすべての障害に対応することを定めました。
図 5 反復のスケジュール
作成フェーズのように、何人ものエンジニアが平行して同じ単純な作業を行うようなフェーズでは、反復の期間主導で計画を立てると良いでしょう。
方向づけフェーズや推敲フェーズのように、複雑な作業を行うようなフェーズでは、反復の目標主導で計画を立てると良いでしょう。
今回は、UP のライフサイクルモデルと、プロジェクトの計画、反復の計画について説明しました。
残り 3 回の記事では、方向づけフェーズについて、推敲フェーズについて、作成フェーズと移行フェーズについて、深く掘り下げて説明する予定です。
どうぞ、お楽しみに。
[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] 『Building J2EETM Applications with the Rational Unified Process』 Peter Eeles・Kelli Houston・Wojtek Kozaczynski／著, Addison-Wesley
| © 2004 OGIS-RI Co., Ltd. |
|
