id:aufheben:20090403 の続き。
システムへの要求はユースケースとドメインモデルで整理するのは良しとして、サブシステム分割、共通機能の洗い出し、コンポーネント分割など、全体のアーキテクチャを構築する過程で、共通性／可変性分析の手法として、フィーチャモデルが使えそうな気がします。
- 連載：次世代開発基盤技術“Software Factories”詳解 第3回 長期的な要求を定義するフィーチャ・モデル（1/2） - ＠IT
- 八角研究所 : Ruby on Rails によるシステム開発をモデリングで効率的に行う（3） - 分析・設計編（フィーチャモデリング）
あと、これらのモデリングは事前にすべてやる必要はなくて、事前設計とリファクタリング、新規開発時と運用・保守開発時にバランス良く行うのが良いと思います。アーキテクチャのリファクタリングとか良い文献ないでしょうかね?
蛇足ですが、これらを身軽に実施できるように、ソースコードと1対1で書かれているような詳細設計書は廃止したいですね(^^;)。JUnit などによる自動テストの粒度も、クラス単体のカバレッジを上げることに躍起になるより、機能レベルに重点を移した方が良いと思っています。
