反復型開発

反復型開発（はんぷくがたかいはつ、Iterative and Incremental Development）とは、より古典的なウォーターフォール・モデルの弱点を克服すべく開発されたソフトウェア開発の手法である。反復型開発の中でもRADとDSDMは、よく知られたフレームワークである。反復型開発は、エクストリーム・プログラミングや他のアジャイルソフトウェア開発フレームワークの基本的要素でもある。

ライフサイクル

反復型開発の基本的考え方は、ソフトウェアシステムを徐々に開発していき、ソフトウェア開発者が過去の開発から学んだことを生かして、使用可能なシステムを段階的にリリースしていくというものである。開発者は、開発そのものと実際のシステムの使用から学ぶ。重要な点は、要求仕様の単純なサブセットから開発を始め、徐々に改良を加えていき、最終的に完全なシステムを実装するということである。反復ごとに設計が修正され、新たな機能が追加されていく。

手続きは、初期段階と反復段階から構成され、プロジェクト制御リストが付随する。初期段階では、基本となるシステムを作成する。初期段階の目標は、ユーザーがとりあえず使ってみることができる製品を実装することである。解決すべき問題の本質を捉え、簡単に実装可能な解決策を見出して、それを提供する。この工程を導くため、プロジェクト制御リストを作成し、必要な作業を全てリストアップする。これには、実装すべき新たな機能や、既存の解決策の再設計すべき箇所などが含まれる。制御リストは、分析フェーズの結果を受けて継続的に更新される。

反復段階では、プロジェクト制御リストやシステムの現状の分析から再設計や実装などの必要な作業を抽出して行う。反復ごとの作業量やその複雑さはなるべく小さく抑え、影響が広がらないようにモジュール化も考慮して、実装すべき機能を選択する。このとき、コード自体がシステムのソフトウェアドキュメンテーションの主要な源となることもある。各反復における分析は、主にユーザーからのフィードバックに基づいて行われる。プログラム解析ツールも利用可能で、構造、モジュール性、ユーザビリティ、効率、目標達成率などを分析する。このような分析結果に基づいて、プロジェクト制御リストが更新される。

実装と分析のガイドラインには次のような項目が含まれる:

何らかの変更によって、設計/コーディング/テストで問題が発生した場合、再設計や再コーディングの必要である。
修正は、一部の独立性のあるモジュール群に簡単に適用可能でなければならない。そうでない場合、再設計が必要である。
テーブルの修正は、特に容易に実行できるようにする。テーブル修正が簡単でない場合、再設計が必要である。
修正は、反復を繰り返すにつれて容易なものになっていくはずである。そうならない場合、設計の流れに根本的な問題があり、パッチの増殖につながる。
パッチは1、2回の反復の間だけ存在するのが普通である。パッチは、実装において再設計の必要が生じたときに、応急処置として使われる。
現状の実装を頻繁に分析することによって、プロジェクトの目標達成率を測る。
プログラムを分析するために、プログラム解析ツールを可能な限り利用する。
現状の実装の問題点を明らかにするために、ユーザーの反応は是非とも必要であり、分析すべきである。

特徴

分析と計測によって改良の指針を得るという点が、反復型開発とアジャイルソフトウェア開発の大きな違いである。これにより、工程の効率を明らかにし、製品の品質を向上させる。また、開発チームは、分析と計測によって、そのプロジェクトを学び、その環境に適応していく。もちろん、同様の分析と計測をアジャイル的手法に取り入れることも可能である。

実際、反復型では、計測の活用に利点がある。一般に計測したとしても、比較対象がないとその結果を評価できないが、反復型開発では反復ごとの計測結果を比較することが可能であり、それによって目標達成状況が明らかとなる。例えば、ある時点の製品について各種計測を実施すれば、そのサイズ/複雑さ/結合度/凝集度などが良くなっているのか悪くなっているのかがわかる。

このモデルを使って、さまざまなソフトウェアが開発されてきた。当初は単に動くだけの製品だが、リリースを経るに従って機能が追加され、バグが少なくなっていく。この種のモデルの典型例として、Yahoo! Messenger、Azureus、各種セキュリティソフトウェアやP2Pソフトウェアがある。

参考文献

History Of Iterative

外部リンク

SRA RUPホームページ

ライフサイクル

特徴

参考文献

関連項目

外部リンク