概念 反復
トピック
これまで、プロジェクトは、各分野をたった 1 度だけ順にたどるように編成されていました。
この場合、ウォーターフォール (滝) ライフ・サイクルへと導かれます。

その結果、製品を初めて構築してテストを開始したときに、実装段階の後半で統合が「積み重なり」あってしまいます。
分析、設計、実装の段階では現われなかった問題が突然表面化して、プロジェクトを停止せざるをえなくなり、バグ修正の長いサイクルが始まります。
作業の進行を柔軟化する (しかもリスクを減らして) には、さまざまな開発分野を何度も行き来し、要件に関する理解を深め、堅牢なアーキテクチャーを作り、開発組織を成長させて、最終的には、徐々に完成に近づきながら一連の実装を次々に行うという方法があります。
これを反復ライフ・サイクルと呼びます。
一つながりのプロセス分野を通過する各工程を反復と呼びます。

したがって、開発の観点から見れば、ソフトウェア・ライフサイクルとは、ソフトウェアを段階的に発展させる過程である反復の連続であるということになります。
どの反復も、実行可能製品のリリースで完結します。
その製品は、完成度について言えば未完成であっても、一部のエンジニアリングまたはユーザーの観点にたてば有用であることもあります。
どのリリースにも、役に立つ成果物が添付されます。つまり、リリースの説明、ユーザー説明書、計画など、システムの更新モデルなどです。
このような反復アプローチでは結果として、下図に示すように、上述の一連の成果物が時間の経過とともに成長して成熟していきます。

開発フェーズの進行にともなった情報の進展
反復には、製品のリリース、つまり安定した実行可能なバージョンの製品へとつながる開発アクティビティーが関わってきます。またこのリリースには、製品の利用に必要な周辺エレメントが付属しています。
つまり開発の反復とは、ある意味で、少なくとも要件、分析、設計、実装、テストなどのすべての分野へと通じる 1 つの完全なパスのことであり、
本質的に小さなウォーターフォール・プロジェクトのようなものです。
評価基準は、反復の計画のときに確立されることに注目してください。
そのリリースは、計画通りの実証可能な能力を備えることになります。
反復の持続時間はプロジェクトの規模と特性によって異なりますが、反復の統合ビルド計画での指定どおりに、各反復ごとに複数のビルドが組み立てられると考えられます。
これは、RUP (Rational Unified Process) で推奨されている連続的な統合アプローチで生じる結果です。このアプローチでは、単体テストを受けたコンポーネントが利用可能になると、それらを統合してビルドが完成し、統合テストを受けられるようになります。
このようにして、統合されたソフトウェアの能力は、反復の進行に従って、反復計画時に定めた目標に向かって向上していきます。
各ビルドそのものが小さな反復であるとも言えますが、必要な計画と実行する評価手続きに違いがあります。
プロジェクトによっては、毎日ビルドを作成するのが適切であり便利であるかもしれません。しかし、RUP による定義ではこれは反復にはなりません (担当者が 1 人の非常に小規模なプロジェクトなどを除く)。
また、複数の担当者の小規模なプロジェクト (たとえば、10,000 行のコードを 5 人で分担する場合) でも、1 週間以内の反復期間を達成することは難しいと思われます。
リリース
リリースは、内部または外部のどちらもありえます。
内部リリースは、マイルストーンの一環として開発組織でのみ使用されるか、またはユーザーあるいは顧客に対するデモンストレーションで使用されます。
外部リリース (つまり納品) は、エンド ユーザに配信されます。
リリースとは、必ずしも完成した製品であるというわけではなく、あるエンジニアリング的見地からのみ有用性が測定された、一歩前進した製品であるということができます。
リリースは、「90%完了、残り90%」という悪習慣を排除して、開発チームが定期的に作業の区切りをつけるきっかけを提供します。
反復とリリースを利用すれば、時間はかかりますが、設計者、テスト担当者、ライターなどのチーム内の各種専門家をより有効に活用することができます。
また、定期的なリリースを利用すれば、統合やテストに関する懸案事項を仕分けして、それを開発サイクル全体に広めることができます
これまで、そのような懸案事項が、大規模プロジェクトの破綻の原因となることがよくありました。なぜなら、大規模な統合を行ったときにあらゆる問題が一度に発見されてしまうことがあり、しかもそれがサイクルの終了間際であったり、たった 1 つの問題でもチーム全体を停止させてしまったりするからです。
反復ごとに、成果物は更新されます。
それは、ソフトウェアを「育てる」のに似ていると言われます。
つまり、パイプライン方式で次々に成果物を開発するのではなく、サイクル全体を通して、その速度は一定ではありませんが、それらの成果物を進展させていくことになります。
副マイルストーン
各反復は副マイルストーンで完結し、その地点でその反復に対して既定されていた客観的成功基準に照らして反復の結果が評価されます。

フェーズ中の各反復ごとに、実行可能なシステムのリリースが生成されます。
RUP のどのフェーズも、さらに反復に分解することができます。
反復は完全な開発ループであり、最終的には、開発中の最終製品の前段階である実行可能な製品の (内部または外部の) リリースを生じます。これは、反復から次の反復に進むにつれ徐々に成長して、最終的なシステムになります。
反復パターン:段階的ライフ・サイクル
「段階的戦略では、ユーザーのニーズを特定し、システム要件を定義してから、一連のビルドの中で残りの開発作業を実行します。
最初のビルドでは計画どおりの能力の一部を取り込み、次のビルドでさらに能力を追加するというように、システムの完成までこれを続けます。」
参考資料 [DOD94]
以下に、特徴的な反復の例を示します。
- 範囲とビジョンを確立してビジネス・ケースを定義するための短い方向付け反復
- 要件の定義を行ってアーキテクチャーを確立するための 1 回のみの推敲反復
- ユース・ケースを具体化してアーキテクチャーに肉付けをするための数回の作成反復
- ユーザーのコミュニティーに製品を移行させるための数回の移行反復

この戦略は、次のような場合に適しています。
- 問題領域をよく知っている
- リスクを十分了解している
- 経験豊かなプロジェクト・チームである
反復パターン:発展的
ライフ・サイクル
「発展的戦略は、段階的戦略とは異なります。それは、ユーザーのニーズが完全には理解されておらず、すべての要件が事前に定義されているわけではなく、ビルドの連続の中で手を加えていくことが認識された戦略であるからです。」参考資料 [DOD94]
以下に、特徴的な反復の例を示します。
- 範囲とビジョンを確立してビジネス・ケースを定義するための短い方向付け反復
- 各反復ごとに要件にさらに手を加えるための複数回の推敲反復
- ユース・ケースを具体化してアーキテクチャーを拡張するための 1 回の作成反復
- ユーザーのコミュニティーに製品を移行させるための数回の移行反復

この戦略は、次のような場合に適しています。
- 問題領域が新しいものか、またはよく知らない
- 経験の浅いプロジェクト・チームである
反復パターン:段階的納品ライフ・サイクル
やはり顧客に対して段階的機能をフェーズに分けて提供する方法を述べた著書もいくつかあります。
参考資料 [GIL88]
このような方法が必要になるのは、市場に出すまでの期間が短い場合や、特定の主要機能の提供を早めれば企業が大きな利益を得られる場合です。
フェーズ・反復アプローチに関して言えば、移行フェーズが早期に開始され、反復の回数は一番多くなります。
この戦略の場合、「前例がない」システム用として、初期の開発サイクルでは達成の困難な、非常に安定したアーキテクチャーが必要になります。
以下に、特徴的な反復の例を示します。
- 範囲とビジョンを確立してビジネス・ケースを定義するための短い方向付け反復
- 安定したアーキテクチャーの基本線を確立するための 1 回のみの推敲反復
- ユース・ケースを具体化してアーキテクチャーに肉付けをするための 1 回の作成反復
- ユーザーのコミュニティーに製品を移行させるための数回の移行反復

この戦略は、次のような場合に適しています。
- 問題領域をよく知っている
- 開発サイクルの初期段階でアーキテクチャーおよび要件を安定化できる
- 問題の中に新しい点が少ない
- 経験豊かなチームである
- 機能の段階的リリースが、顧客に大きな利益をもたらす
従来のウォーターフォール・アプローチは、作成フェーズに 反復が 1 回のみという縮小ケースであると見なすことができます。
[DOD94] ではこれを「グランド・デザイン」と呼んでいます。
実際、移行フェーズで反復を追加しないようにすることは困難です。
以下に、特徴的な反復の例を示します。
- 範囲とビジョンを確立してビジネス・ケースを定義するための短い方向付け反復
- ユース・ケースを具体化してアーキテクチャーに肉付けをするための 1 回の非常に長い作成反復
- ユーザーのコミュニティーに製品を移行させるための数回の移行反復

この戦略は、次のような場合に適しています。
- 入念に定義された機能を、細かく段階に分けて非常に安定した製品に追加する
- 新規機能が入念に定義されていて、よく理解されている
- 問題の領域と既存の製品に関して経験豊かなチームである
実際には、1 つの戦略だけに厳密に従うプロジェクトはほとんど存在しません。
最初はある程度の発展で始まっても、段階的な構築、複数の納品などの、ハイブリッドで終わることがよくあります。
フェーズ・反復モデルの利点は、次のように特定のフェーズ中の反復の数と期間を増すだけで、ハイブリッド・アプローチを取り入れることができる点にあります。
- 探査の割合が高くなる複雑な問題領域やよく知らない問題領域の場合、推敲フェーズでの反復の数と期間を増やします。
- 設計をコードへ変換するという煩雑さを伴ったさらに複雑な開発関係の問題では、作成フェーズでの反復の数と期間を増大します。
- 一連の段階的リリースでソフトウェアを納品するためには、移行フェーズでの反復の数と期間を増大します。
|