反復型開発

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

ライフサイクル

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

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

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

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

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

特徴

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

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

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

参考文献

History Of Iterative

外部リンク

SRA RUPホームページ

ライフサイクル

特徴

参考文献

関連項目

外部リンク