フィーチャモデルによる共通性／可変性分析

フィーチャ(feature)は、ユーザーが識別できるシステムの目立った特性(characteristics)や様相(aspect)であり、「機能」でも「非機能特性」でもよい。これがSoftware Factories／プロダクトライン／FODAでいわれるところのフィーチャだ。

フィーチャを分割してAnd/Orの階層で表現することで、システムの共通性(commonality)と可変性(variability)が識別できる。将来変化が予測されるロジックや情報、将来も変化がないと考えられるロジックや情報を識別するのだ。共通性とは共通部分をくくりだすという「共通化」ではない。将来も変化しないと考えられる部分に対して「共通性」という特性を見出しているに過ぎない。

共通のフィーチャの実装である固定資産と、可変のフィーチャの実装である可変資産とで構築されたプロダクト(ソフトウェア)がプロダクトラインのベースとなる。次回からは、同一のフィーチャを持ちながら要求が異なる新たなプロダクトを、可変資産をカスタマイズするだけで開発できるようになる。

共通性／可変性分析は、固定資産／可変資産を切り出す際の根拠を明確化するためのものだ。分析のためのフィーチャのツリー構造図を「フィーチャモデル」という。このモデルでは、機能と非機能特性の両方が扱われる。モデル上の特定のフィーチャは、配下にある機能を利用し、配下にある非機能特性を満足する必要があることを表現している。

ここまでは理解した。kondoumhさんからの、SOAを体系的に語るにはFODAが欠かせないとの指摘から少し調べてはみたが、まだどのような視点と粒度でフィーチャを階層化すべきかを解説できるレベルではない。機能と非機能の混在が、本当に必要なのか、本当に解りやすいのかという疑念は残ったままだ。

※関連記事：Function vs. Feature