統一プロセス(UP)

ソフトウェアをどのように作り上げるかについて，手順や工程，要因，成果物，進め方に関する基本的な考え方を定義した開発プロセスには，ウォータフォール型開発プロセス，プロトタイプ型開発プロセス，スパイラル型開発プロセス，反復型開発プロセスなどがある．

UPの特徴

統一プロセスは次の5つから成っている．

ユースケース駆動

アーキテクチャ中心

管理された反復

カスタマイズ可能

4つのフェーズ

ユースケース駆動とは，ユースケースがシステムを構成するクラスやその振る舞いを識別し，分析モデルを作成する基本情報となる．また，設計・実装の検証やテストケースの作成，ユーザマニュアルの情報源として利用される．さらに，反復型開発の各サイクルを駆動する基本単位にもなる．

図:

アーキテクチャ中心とは，机上のモデリングだけではなく，実際に動作させて，機能性・信頼性・安定性等のソフトウェア特性を確認しながら，システムの「アーキテクチャ」を進化させていく．また，このアーキテクチャの上に段階的に個々のアプリケーションを実現するクラスを搭載する．

図:

管理された反復とは，各繰り返しごとにリスクを減らしたい項目，実現したいユースケース，ミドルウェア等の技術的課題の優先順位を設定して基準点とする． また，各サイクルの中で分析・設計・実装・テストがそれらの目標に対して行なわれるのはもちろん，サイクルの最後でその成果物をユーザと開発者が評価し，次のサイクル計画立案にフィードバックすることができる．さらに，ベースアーキテクチャが繰り返し検証されて安定し，再利用可能コンポーネントも生成される．

カスタマイズ可能であるとは，ワークフローが各アクティビティのワーカの役割と担当範囲，各作業内容，その成果物および依存する次のアクセスビリティを指定できる．つまり，抽象的な作業者役割であるワーカを，実際に何人必要で誰に割り当てるか，各アクティビティの作業順序をどう決めるか，成果物の具体的な定義，省略するアクティビティ，より詳細化するアクティビティ等を定義することができることである．したがって，よく管理された反復型開発によるリスク管理，プロジェクト管理を実現する上で不可欠なプロセスのテンプレートを提示する．

4つのフェーズ $\rightarrow$ $\rightarrow$ $\rightarrow$

方向付け

推敲

構築

移行

UML

要求

ユースケース図 アクティビティ図

分析

クラス図 コラボレーション図 シーケンス図

$\Rightarrow$

$\Rightarrow$

$\Rightarrow$

設計

クラス図 オブジェクト図 コラボレーション図 シーケンス図 状態図

実装

1

2

3

$\cdots$

テスト

方向付け

方向付けはいろいろな形をとる．あるプロジェクトでは，喫茶店での会話程度のものかもしれない．また，もっと大きなプロジェクトでは，数ヶ月間を要するような実行可能性の研究かもしれない．

方向付けの段階では，プロジェクトの金銭的な部分，つまり，儲かるのか儲からないのかについての算出をする．また，プロジェクトの大きさについても感じを掴む必要がある．プロジェクトの大きさについての感じを掴むためには，初期分析を必要とするかもしれない．

推敲

さて，プロジェクトの開始にOKがでたとしよう．この段階で，ほとんどの場合，要求に関してはぼんやりとした考えしかないだろう．例えば，

「A社に対して，次世代の顧客サポートシステムを作ろうとしている．そこで，オブジェ

クト指向技術を用いてより柔軟なシステムを作成するつもりだ．特に，顧客の料金の合併

処理が可能なものを作るつもりだ．」

と言ったとしよう．

当然，要求定義書はもっと広がりがあるものとなるが，全然違うものとなることはない． ここで，問題に関してよりよい理解が必要となる．

• あなたが作成するものは何なのか．
• どのようにそれを作成するのか．

この段階で，どの問題について調査するのかを決めるには，まず第一にこのプロジェクトが抱えるリスクによって判断するべきである．何がこのプロジェクトの足を引っ張るか．リスクが大きければ大きいほど注意を払うべきである．

リスクは，一般に次の4つに分類できる．

1. 要求リスク : このシステムへの要求は何か．このことをよく考えないと，顧客の要求とは関係のないシステムを作ってしまう恐れがある．
2. 科学技術的リスク : どんな科学技術的な問題に直面するか．この仕事を行なう上で必要な科学技術を選んだか．
3. 技術リスク : 必要とするスタッフと熟練者を集められるか．
4. 政治的リスク : このプロジェクトに致命的な影響を及ぼすような政治的な力が及ぶ可能性があるか．

構築

制作では連続した反復でシステムを作り上げる．それぞれの反復は小さなプロジェクトである．つまり，それぞれの反復に割り当てられたユースケースにおいて，分析，設計，コーディング，テスト，結合を行なう．最後に，ユースケースが正しく作り上げられたことをユーザへのデモとシステムテストの実行により反復を終える．

このプロセスの目的はリスクの軽減にある．制作における反復は積み重ねであり，また，繰り返しである．

• 反復は積み重ね(incremantal)である．それぞれの反復は，以前の反復で作られたユースケースの上に作られる．
• コードを基本とすると反復は繰り返しである．それぞれの反復はすでに存在するコードをもっと柔軟なものにするための書き直しを伴う．

移行

反復による開発の要点は，全体の開発工程を規則正しく行なうことにより，開発チームが完成したコードの引き渡しに慣れることである．