ソフトウェアプロダクトラインと構成管理、ソフトウェアパターンの関係

ソフトウェアプロダクトライン(SPL)を分かりやすく解説された記事があった。
考えたことをメモ。

【元ネタ】
ZACKY's Software Engineering Laboratory: プロダクトラインとは(1)

ZACKY's Software Engineering Laboratory: 共通性と可変性，スコーピング

ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(1)

ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(2)

ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(3)

研究室｜株式会社エクスモーション 組込みシステム開発を現場から支援する「実践型トータルコンサルティング」

Untitled - eXmotion 株式会社エクスモーション｜組込みシステム開発を ...

SPLC 2008 概要紹介

【1】SPLC 2008 概要紹介で面白かったのは、SPLとAgileの関係。
SPLはドメイン(コア資産)開発、Agileはアプリケーション資産開発に向いている、という議論になったらしい。
これは理解しやすい。

SPLはコア資産をベースに製品ファミリーを次々に開発していくスタイルだから、ベースとなるドメイン開発が一番重要。
ドメイン開発はウォーターフォール型開発よりも反復型(イテレーティブ)開発の方が向いているだろう。
システム全体を薄く作りながら、品質やアーキテクチャを作りこんでいく。
製品の骨格となるフレームワークを作り込む開発スタイル。

逆にAgileは、スクラッチ・アンド・ビルドが得意。
例えば、RailsやSeasarのような優れたフレームワークをベースに、UIのように顧客の要求の変更が多い箇所をアプリケーション層に押し込めて作る。
Agile開発の基本は漸進型(インクリメンタル)開発。
小規模リリースをベースに、2～4週間の短いサイクルで、サブシステム単位あるいは機能単位に機能拡張していく。
フレームワーク層はいじらす、アプリケーション層をひたすか改造する開発スタイル。

反復型開発と漸進型開発を意識して使い分けてもいいかもしれない。

【2】SPLは構成管理と密接に関係する。
成功した一つの製品をベースに、複数の製品ファミリーを展開していくには、コア資産と製品特有の機能を区別してソース管理する必要がある。
実際、複数のコードラインを管理しなくてはならないし、コア資産の一つの変更は他の製品にも影響するからマージ作業も発生する。
つまり、高度な構成管理が必要になる。

SPLでは、フィーチャという機能あるいはコンポーネント単位に製品をばらし、フィーチャを組み合わせて製品ファミリーを増やす戦略を取る。
そして、それらのフィーチャを組み合わせて、製品ごとのビルドスクリプトによって、別々にビルドされる。

SPLの構成管理では、trunkがフィーチャの数だけ存在し、ビルドスクリプトによって、製品に必要なフィーチャをチェックアウトしてビルドすることになるだろう。
例えば、ビルド処理はHudsonのジョブを使い分ければいいだろう。

又、コア資産は「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」にあるベンダブランチで管理すればいいかもしれない。
製品ごとにコア資産であるフレームワークに手をいじる場合もあるから、厳格な構成管理手法を選択しておかないと、すぐに品質が劣化するだろうから。

【3】SPLはソフトウェアパターンとも密接に関係する。
ここで言うソフトウェアパターンは、デザインパターンよりも、コンポーネント間の依存関係のパターンを指している。
例えば、「リリース再利用等価原則」「共通閉鎖原則」「共通再利用原則」「非循環依存関係原則」「安定依存関係原則」「安定抽象原則」などだ。

「アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技」や「プログラマのためのJava設計ベストプラクティス」に詳しく書かれている。
これらのパターンを意識すれば、ソースコードや関数のもう一つ上の層であるコンポーネントを疎結合に作ることができるので、再利用しやすくなる。

又、SPLでは戦略的再利用という発想も生まれる。
コア資産とアプリケーション資産を分離する観点は、マーケットやビジネスモデルから決まる割合が大きいのだ。

これらの観点を見直すと、SPLはこれまでのソフトウェア工学の知識をすべて網羅した体系であるとも言える。
だから、中身はとても当たり前な部分も多いし、とても膨大になりやすいから、分かりにくい点もある。

SPLについては、開発プロセスではなく、構成管理やソフトウェアパターンの観点から追いかけてみようと思う。