|
RUP の拡張: 稼動フェーズ |
By Scott W. Ambler.
 |
このホワイトペーパーの題材は、Scott W. Ambler、John Nalbone、Michael Vizdosによる「エンタープライズ統一プロセス: IT 業務の全体最適化のためのプロセスフレームワーク」から抜粋したものです。 |
ラショナル統一プロセス (Rational Unified Process: RUP) のプロジェクトライフサイクルは、移行フェーズにおいて、システムのリリースがユーザに導入される「製品リリース (Product Release: PR) マイルストーン」で終わります。しかし、情報技術 (IT) は、システムを構築して導入するだけではありません。システムを導入した後には、運用及びサポートが待っています。エンタープライズ統一プロセス (Enterprise Unified Process: EUP) では、RUP を拡張し、稼動フェーズを追加しています。図1を参照してください。
図1. EUPのライフサイクル(2004年版)
稼動フェーズの目的は、ユーザの人々に導入した後のシステムを、使いやすく生産性の高い状態に保つことです。このプロセスは組織によって、ときにはシステムによって異なりますが、基本となる目的は同じ、つまりシステムを稼動させ続け、ユーザの利用を手助けすることです。たとえば店頭で市販する製品の場合には、運用サポートは必要ないでしょうが、通常はユーザを補助するためのヘルプデスクが必要になります。社内で使用するシステムを実装している組織の場合は、システムを動作させ、監視する運用担当者が必要です。稼動フェーズも、EUP の他の部分と同様に、各組織が自分特有のニーズに合わせてカスタマイズする必要があります。
稼動フェーズが終わるのは、システムのリリースが引退することになった場合か、そのリリースのサポートが終わった場合です。後者は、新しいバージョンのリリース直後のこともあれば、新しいバージョンのリリース後しばらくたってからのこともありますし、単に会社がサポートをやめると判断したときのこともあります。後のセクションで詳しく述べますが、リリース引退のマイルストーンは、リリースが稼動フェーズから出るための最後の認証です。
このフェーズには通常、1回の反復しかありません。ソフトウェアの1つのリリースの運用期間に対して適用されるものだからです。ただし、時間の経過によりソフトウェアのサポートのレベルを複数に分ける場合には、複数の反復になることもあります。
図2に示すのは、稼動フェーズのワークフローです。これらのタスクのほとんどは、運用及びサポートの作業分野で行われます。この作業について、以下に簡単に説明します。
図2. 稼動フェーズのワークフロー
稼動フェーズで行われる、運用及びサポート以外の作業分野の作業には、以下のようなものがあります。
1 つのリリースの稼動フェーズは、その製品の後続リリースの開発プロジェクトが始まったからといって、必ずしも終わるとは限りません。開発作業と並行して、前のリリースの運用やサポートを行う必要もあるでしょう。実際に、複数のリリースが同時に稼動状態になることもあります。たとえば、バージョン 1.1 がリリースされた後しばらくの間は、バージョン 1.0 と 1.1 の両方の運用およびサポートが続けられ、バージョン 1.0 のサポートが打ち切りになるのは、バージョン 2.0 がリリースされた後になるといったことが考えられます。
実際に、複数のリリースを並行して開発することもあるでしょう。ソフトウェアのリリース N が完成して導入される前に、リリース N+1 の開発を始めるのは、珍しいことではありません。これによって、新しいリリースの導入や引退の速度は上がるでしょうが、開発作業は複雑になります。同じコードベースを 2 つのチームが更新することになるからです。製品の新しいバージョンをリリースしても、古いバージョンのサポートは、通常すぐには終わりません。たとえば××製品のバージョン 2.0 を一般にリリースした場合にも、バージョン 1.1 をしばらくの間(たとえば 18 ヶ月など)と、バージョン 1.0 をもう少し短い期間 ( 6 ヶ月など) 、サポートし続けることになるでしょう。古いバージョンより v2.0 のサポートの方に多くのリソースを割くことになるでしょうし、本当に古いバージョンに関してはサポート料を取ることもできるかもしれませんが、それなりの期間が経つまでは、まだアップグレードが間に合っていない顧客の ( あるいはサポート継続のためには料金を支払おうという顧客の ) サポートを打ち切るわけにはいきません。
システムの複数バージョンのサポートは、きちんと管理しなければ厄介なことになりがちです。ほとんどの場合、後続のリリースは前のリリースの作業製品を発展させて作成します。古いバージョンは、たいてい、新しいリリースの作業とは別にサポート・更新する必要があります。多くの場合、これは「分岐とマージ」という技法で行われます。この技法は、新しいリリースのプロジェクトチームが新規作業の開発ベースを選ぶところから始まります。関連する成果物すべてのコピーを作成し ( ユースケース、設計モデル、コード、テストケースなど )、それに対して作業を行います。これを「分岐」と呼びます。すべての作業は、このコピーを発展させて新しいリリースを作成することで行います。たとえば、ユースケースの更新や追加、設計の改良、コードの更新などです。もとの成果物は、それとは別に保守します。これが必要なのは、開発作業とは別に、もとのリリースをサポートなければならないためです。
新しい開発を進めている間にも、製品の現行バージョンの運用やサポートは、これまで通り行わなければなりません。製品に重大な問題点が見つかったら、顧客は修正を望むでしょう。サポートチームは、開発作業に影響を及ぼすことなく、現行バージョンの修正を作成して配布できなければなりません ( 逆も同じです )。しばらくの間、コードベースを始めとする成果物は、2 つのコピーが存在することになります。2 つの作業が異なる目標で行われているからです。
どこかの時点で「マージ」を行います。新しいリリースの開発作業が終わりに近づいたら、サポートチームが行なった変更をマージして、できるだけ多くの修正を取り込まなければなりません。これは、新しいコードが作成される作成フェーズの後期か、移行フェーズで行われます。このときに、分岐の後で行われた成果物に対する変更を見直し、ベースコードにマージします。古いバージョンのサポートを打ち切る場合には、古いコードベースをアーカイブして削除しますが、打ち切らないのであれば、両方のコードベースを引き続きサポートし、発展させなければなりません。
図3に示すように、稼動フェーズはリリースリプレース (Release Replacement: RR) マイルストーンで終わります。RR マイルストーンでは、システムのリリースの運用及びサポートを終了するかどうかを決定します。このマイルストーンでは、以下の問いに答えなければなりません。
このマイルストーンのレビューでは、利害関係者は、システムのこのリリースで提供されている機能を今後提供しないことにするかを判断します。理由はいくつか考えられます。システムの後続バージョンによる置き換え、別のシステムによる置き換え、ビジネスの方向転換などです。このマイルストーンを通過するには、この機能を取り除くべきであると利害関係者が合意しなければなりません。プロジェクトがマイルストーンレビューを通過できなければ、引退フェーズへの移行は延期されることがあります。
 |
本ページの原文 ( 改訂されている可能性があります ) : www.enterpriseunifiedprocess.com/essays/template.html Copyright 2004-2007 Scott W. Ambler
|