実践的 ソフトウエアプロダクトライン開発  

ソフトウエアプロダクトライン開発(SPLE)の実践運用を通じて得られた知見がBlog記事として紹介されています。多くの先進的な顧客と関わることで得られた賢人のノウハウを知り、独自の技術力への昇華に活用くださると幸いです。オリジナル(Product Line Enginering Blog by Dr.Danilo)

Dr. Danilo氏は、独マグデブルグ大学、及び1995年からのGMD First(現、フラウンホーファー研究所)における、組み込みシステムに関する研究、フィーチャベースの開発ツールに対する取組みを基に、2001年に、pure-systems社を設立しました。組み込みシステムを中心に、プロダクトライン開発を支援する、バリアント/バライアビリティ管理ツールの開発を行い、コンサルタントとして顧客のプロダクトライン導入を支援しています。

Article (1) Versions, Variants and all the rest - Basic definitions

 

バージョンとバリアントを区別する

 
 プロダクトラインエンジニアリング(SPLE)やバリアント管理に言及する場合、基本的な用語の共通理解は重要なことです。そして、バージョンとバリアントの区別は最も混乱しているものの一つだと経験してきました。なぜならプロダクトラインエンジニアリング(SPLE)以外の領域では、これらは多少なりとも混同されて用いられているので。それで私はカンファレンスなどのデモブースに訪れる方にいつも次のことを伺うことにしています。 ”なるほど、何らかのバージョン管理をされているのですね。そこで、そのxxx(バージョン管理システム名)で、何を個々に比較されているのですか?” 今後のディスカッションのために、以下、バージョンとバリアントに関わる用語について簡単な定義付けを行います。そしてそれらの相関関係の紹介や、同じものとして扱われてしまう理由などを説明します。
 
一資産の一バージョンA version of an asset )は、あるタイミングで記録されたその資産の状態・内容。一資産に対する2つのバージョンは、同一あるいは異なる資産内容を取る。従って複数のバージョンは、異なる時間・タイミングにおける同一資産となる。多くの場合複数のバージョンは、ラベルや番号で識別される。時として、リビジョン(部品が変更された場合に作られる)とバージョン(ラベル・指定されたリビジョン)の間で相違がある。
 
一ベースライン(A baseline )は、一連の資産群からなるバージョンのある断片・スナップショット(指定された)。
 
一バリエーション(A variation )は、単純に複数の資産間の相違。
 
一バリエーションポイント(A variation point )は、一資産の異なるバリアントを指し示す判断・選択肢のこと。一つのバリエーションポイントは、複数の選択可能なインスタンスから構成される(バリエーションポイント上の有効となるバリエーション)。バリエーションポイントには、通常インスタンスへの選択が行われるバインディングタイムがある。バインディングタイムの例は、コンパイル時、インストール時、ランタイムなど。
 
バリアントの導出(variant derivation )とは、可能な資産群から資産を組合わせて、定義されインスタンス化されるバリエーションポイント群を包含させるアクションのこと。複数のバインディングタイムをとるバリエーションポイント群があれば、バリアントの導出は各バインディングタイムごと段階を追って起こる。その導出の結果は、提供されている資産の組合せである。導出は、多くの技術的手段でもって行われる。最も単純な(そして基本的にお勧めできない)方法は、資産群をコピーして(手動で)部分修正すること。例えばコンフィグレーションのパラメータなど。そのような導出の結果は、コンフィグレーション(a configuration)とも呼ばれる。
プロダクトラインエンジニアリング(SPLE)ではバリアントの導出は中心的部分となる。理由は、プロダクトラインの資産への変更(バグフィックス)後は、たいていの場合、その資産を持つ全ての製品(バリアント)を再生成する必要がある。そしてこの工程を最小限にするために、自動導出をサポートするツールが用いられる。
 
もし資産 X’ が資産 X を基にしていて、同じXから派生した他のバリアントの資産と顧客等の観点で異なる特性を持つならば、その X’ は、バリアント(variant)を象徴することになります。これらの違いにより、同じ資産 X から派生する他の資産群との区別ができます。例えば色を塗り分けて青と赤のボール(色以外の点は全く同じ)を作る機械であれば、青ボールと赤ボールの2つのバリアントを生成できる。このとき、赤、青で塗り分けられるボールの数は問題ではありません。
 
ここでバリアントという用語の定義には、バリアントを導出した時期は含まないことを留意してください。バリアントは、時間に依存しません。
 
重要なのは、異なる資産間の僅かな相違全てが個々のバリアントを作るのでは無く、製品の利害関係者(顧客など)から見えるバリエーションが個々のバリアントを形成するということ。例えば、最初にシャツを一枚買い、翌週同じブランド・同色・同じ縫製・同じサイズの二枚目を買った場合、これらはもしかすると洗濯ラベルに多少の違いがあれども、それはたいした問題ではなく、それらを同じものとして扱えるでしょう(ボロボロになるまでは)。しかし自分用と友達用に違ったサイズを購入したなら、それらはバリアントです(相対するバリエーションは服のサイズ)。ソフトウエアシステムで考えると、たいていの場合、一資産に対するバグフィックスは新しいバージョンを作りますが、それによって新しいバリアントが出来るわけではない。バグフィックスによって、顧客の観点で望んだり要求される資産の特性が変わるわけではないので。
 
最後になりますが重要なのは、バライアビリティ(variability )はバリエーションポイントで資産群から得られるバリエーションを表現します。多くの場合、全てのバリアント群をリストすることはその数が多すぎて不可能です。フィーチャモデルやコンフィグレーションルールなどのバライアビリティモデルなら、システムのバライアビリティを表現し得えます。
 
次のブログではフィーチャモデル、さらにフィーチャとは何か?といった事を紹介いたします。
 
このブログのオリジナルはこちらから LinkIconVersions, Variants and all the rest - Basic definitions
 
 

Article (2) Feature Models and Features - What’s this?

 

フィーチャモデリングについて

 
 バライアビリティについてインフォーマルに言及することは面白いのですが、最終的にはバライアビリティの情報を標準的な方法で得ることが必要です。もちろん研究や産業界から、そのための多くの方法が考え出されています。様々な理由から、最もポピュラーなバライアビリティの記録・保存手段は、feature modeling と呼ばれています。今回の解説では、フィーチャモデルの極めて基本的なコンセプトについて説明します。そして興味深い質問である ”フィーチャって何ですか?”への答えの手がかりも提供するつもりです。
 
一言で言えば、フィーチャモデルはプロダクトラインのコモナリティとバライアビリティを保存(記録)するシンプルで、階層的なモデル。問題空間(problem space )上の各関連した特性がモデル上の一つのフィーチャとなる。ひとつのフィーチャ(feature)はここで、利害関係者に関連性がある一システムの一特性である。利害関係者の興味次第で、フィーチャは一要件、一テクニカルファンクション、ファンクショングループ、非ファンクショナル(品質)特性となる。悪いニュースは、フィーチャモデルはコモナリティとバライアビリティを記述・描写するための抽象概念であるということ。各プロダクトラインを個別に決定するのに、フィーチャーが明確にされる必要がある。しかしながら一般にはフィーチャは実際の実装コンセプトからは、ある意味切り離されて定義されている(すなわち解決空間 solution spaceから)。 例を挙げると、自動車の色が一フィーチャなら、それは立派な名前を持つことになるが(“dark marine blue” とか) 、しかしその色の特定メーカに対する注文番号はここでは言及されません(それは解決空間 solution space)。ソフトウエアでも同じ。一フィーチャが一関数にマップしていようが、何十ものコンポーネントに展開されていようが、ここでは関係なし。もし利害関係者が関連する一つの特性とみなし、それがバライアビリティに相当するならば、それは単一のフィーチャである。
 
フィーチャモデルは、フィーチャの集まりでノードを形成するツリー構造です。フィーチャのバライアビリティは、グループからなるフィーチャー群とそれらへの弧で表される。最近の殆どのフィーチャモデリングの試みでは、4つのタイプの異なるフィーチャグループを利用可能としています。“mandatory(必須)”, “optional(選択自由)”, “alternative(どれか一つ)”、“or(少なくとも1つ)” 各フィーチャは複数のフィーチャグループを子として持つことが出来る。バリアント (variant) にどのフィーチャを加えるかを指定するとき、以下のルールが適応される。もし一つの親フィーチャが一バリアントに含まれるなら、
 
 ・全ての mandatory な子フィーチャ群は必ず含められること (”n from n”),
 ・いくつかの optional なフィーチャを含めることが出来る (”m from n, 0 <= m <= n”),
 ・唯一のフィーチャが、 alternative なフィーチャグループから選択されなければならない (”1 from n”),
 ・少なくとも1つのフィーチャが、 or なフィーチャグループから選択されなければならない (”m from n, m>=1″).
 
明らかなのは、“optional” や “alternative” などこれらの用語(表現)は、上限、下限数の指定によって表現されてグループのカーディナリティ(その種類の絶対数)のコンセプトにマップされる。そして、これら4つは最も一般的に用いられています。これら用語のコンセプトは、正確な定義を読まなくても一般的に正しく理解されています。(“or” のフィーチャーグループは、“alternative”と混同されがちですが)
 
たいていのアプローチは追加のコンストレインツ(制約)も指定できる。フィーチャ間の相互排除(素敵なシャツと、ピンクのシャツは対立する)や、求められる関係(素敵なシャツは、白色シャツか黒色シャツのいずれかを要する)。これらコンストレインツはツリーの階層を横断(さらに複数のフィーチャモデルを用いている場合はモデル間さえも)する。アプローチとツールによって、このようなコンストレインツを表現する言語は、その表現力と複雑さから、これを専用目的とするものから、一般に利用可能なXPath や OCL まで選択肢がある。しかしながらそのようなコンストレインツは控えめにするべきでしょう。コンストレインツが多くなるに従い、モデル内のコネクションを視覚化し理解することは人間には困難になってきます。
 
いくつかのアプローチではfeature cardinality(フィーチャのカーディナリティ)と呼ばれるコンセプトをサポートしています。そして多重のルールをフィーチャモデル上のサブツリー(下位木)に持たせることが出来ます。例えばシステムに対して複数のセンサーの設定が可能な場合、各センサーごとのフィーチャーのサブツリーを個々に作るより、センサーと一つ記載して例えば1~3のカーディナリティ数を与えて、最小1から最大3つのセンサーのサブツリーを選択させる。feature cardinality(フィーチャのカーディナリティ)とそれに関連する課題については、今後のブログで特別に紹介することにします。それまでは、以下の Read On にリンクを紹介した Kryzstof Czarnecki さんの資料を読まれることをお勧めします。
 

残念ながら標準的なフィーチャモデルに対するグラフィカル表記は、まだありません。多くの異なる表記が存在しています。しかしながら文字通りである、FODA(Feature-Oriented Domain Analysis) メソッドのグラフィカル表記の拡張形式が最も一般に使用されています。ただこれは標準テキストツールとグラフ・ライブラリーからなり、ただ難しいだけなので、もっとシンプルなものを選り好んでいます。

 
上述したフィーチャーに対して非常に抽象的な定義をすると、ほぼ全てがフィーチャーとなり得ます。そしておおよそこれは正解でしょう。 そしてフィーチャは何か、それからどのフィーチャをフィーチャモデルに選択するかを、どのようにして見分けるか。
 
ここで最も重要な作業は、そのフィーチャモデルの利害関係者を明確にすることです。誰のためにフィーチャモデルを作るのか? プロダクトラインから生み出される製品のエンドユーザにフィーチャが定義されることがあるなら、それらフィーチャは顧客に対してわかり易くなければなりません。良い例は、自動車メーカーのウエブサイトで今日提供される自動車の構成ツールです。またフィーチャモデルの構造は、エンドユーザの考えに沿っているべきでしょう。
 
簡単に聞こえますが、実際は完璧に行うことは非常にハードです(正直無理でしょう)。多くの場合、ユーザのタイプによりシステムの構成の異なるアプローチがあります(”特別な小さなフィーチャを探す” VS ”自動車のエンジンタイプ、サイズ、色などといった一般的な決定・判断をする”)。一般にフィーチャモデルは自由にナビゲーションできるのに(決まった順番でフィーチャを選択することは必要ない)、判断・決定はモデルの根幹によってしまう傾向があることもより一般的で、それはユーザをそれへ(あるいはツリーのパートへ)深く導いてしまうことになる。
 
それでもし、異なる言語の利害関係者が存在したら?各利害関係グループごとに複数のフィーチャモデルを作りましょうか?あるいは、最も重要なグループのみに作るのか?かさねて、明解な答えはありません。小さくてシンプルな依存関係がよりよいでしょう。多くのプロダクトラインアプリケーションにとっては、一つのフィーチャモデルが良い選択となります。しかしながら、プロダクトラインの部品群が個別のプロダクトラインを形成するなら、複数のフィーチャモデルはもはや必然となるでしょう。
 
コンフィギャブルなミドルウエア上で走るアプリを考えた場合、ミドルウエアのバライアビリティはアプリケーション開発者が用いる言語に取り込まれる必要があり、同じフィーチャモデルをそのミドルウエアを用いる全てのアプリで使うべき。明らかに、このケースではアプリケーションドメインのバライアビリティと、ミドルウエアドメインのバライアビリティのマッピングが必要です。このマッピングを作ることは、アプリケーション・プロダクトライン・エンジニアの役割です。ミドルウエアが、唯一の特定コンフィグレーションに使用される場合は、マッピングは全く無いかもしれません。それ以外は、それらは全く複雑となる。例えば、アプリケーション層にセキュアとノンセキュアなアプリ動作の選択がある場合、あるミドルウエアのフィーチャ(例えば暗号化サポート、SSLプロトコルをサポートしした認証によるデータ確認)は、セキュアなアプリ動作のフィーチャを選択する時には有効にされる必要があります。携帯電話で走るアプリなら、そのような認証管理アプリが無いために、そうでないかもしれませんが。
 
考慮すべき他の側面は、フィーチャの粒度。もしフィーチャが粗い粒度のバライアビリティのみを表現するなら、有効な構成による個々のインスタンスは恐らくシステムの詳細を十分に表現できないでしょう。細かすぎる粒度では、多くの管理されるフィーチャが増大、そして複雑性。ここで再び、背景は何か?:自動製品構成には、製品ロードマップのプランと検討よりも、高度な詳細化が求められる。そして後から詳細を追加するほうが、削除するより容易。
 
経験では良いフィーチャモデルを取る簡単な方法は、とにかく一つ作ることから始めて、そしてそれを用いてプロダクトラインの既知/想定できる製品バリアントを記述すること。たいていの場合、全くの瞬時にいくつかの決定は非常に賢くないことが判る。時に選択されたフィーチャがバライアビリティを十分に表現しない(詳細のレベル)。あるいは、ツリー構造が間違っていた。例えば、あるオプションAはフィーチャBの子供として用意されていた。しかしAの親フィーチャであるBが、Aを選択されたときに選択されないなど。
 
しかしながらこれらの間違いは、次への糧になります。多くの場合、問題なのはフィーチャそのものよりは構造である。
 
フィーチャとフィーチャモデルについて、まだまだあります。今後このブログで書くことにしますので、お楽しみに。
 
しかし、一つ言い残しがあります。プロダクトラインのバライアビリティを表現するには、フィーチャモデルは非常に重要なエレメントであると考えています。しかしながら、フィーチャモデルのみでは十分ではないケースがあり、フィーチャモデルが取るべき手段ではないケースもあります。もしバライアビリティがどちらかというと合成的なタイプだと、多数の基本エレメントがあり、それらはフォーマルなルールで組み合わされる(家を建てる時のレンガをイメージ)。これらのルールでは無制限のブロックの使用が可能です。この場合、フィーチャモデルではこれらを効率的に表現できないでしょう。しかしながらレンガの取り得るプロパティなら(色、材質など)、フィーチャモデルは可能なバライアビリティを上手く表現できるでしょう。
 
そして全く数え切れないくらい、フィーチャモデルのみを取るべきケースもある。
 

 Read On

 
 
A short paper explaining different feature model notations (FODA, Czarnecki-Eisenecker, FeatuRESB, …)LinkIcon This makes a nice reference for those among us who tend to forget the graphical notations easily.
 
 
Feature Models are Views on Ontologies A paper by Kryzstof Czarnecki et al, introduces basic and advanced feature modeling concepts like feature cardinalities and then relates those to the ontologies world. Even if you are not interested in the ontologies stuff, the feature modeling concepts part is worth reading.
 
 
Software Product Line Engineering with Feature ModelsLinkIcon An article I wrote together with Mark Dalgarno of Software Acumen, gives an introduction to software product lines with feature models on a concrete example.
 
 
このブログのオリジナルはこちらから  LinkIconFeature Models and Features - What’s this?
 

Article (3) Knowing where you are: Product Relation Patterns

 

現状を知りプロダクトライン開発へ移行する

 
 現状の開発アプローチから、ソフトウエアプロダクトライン開発(SPLE)への興味をお持ちでしたら、その移行に際して、そして移行中に対する多くの考察がありますが、シンプルな確認で、現状を理解し移行方法を知ることができます。この資料では、製品間の関連パターンと、それによるプロダクトライン開発(SPLE)への移行策の関わりについて紹介します。

 
The Product Forest

 殆どの製品が個々に独立して開発されている。しかしながら幾分の共有する機能がある。これら製品の問題領域(problem domain )は非常に似通っています。例えば、それら製品の全てがエアコンの制御をする(異なった方式で)。この場合、Product Forest 型と呼ぶことができるでしょう。UIのウィジットや算術処理などの基本ライブラリを共有することは再利用の基本系として存在するが、共有するアプリケーションロジックは無い状態。このパターンは、同一ドメインの異なった顧客に複数のプロジェクトを個別に、かつ同時に進行させる場合に良く見受けられる。下図のように、 (P0 ~ P3) の製品が時間とともに登場し、変更やバグフィックスなどにより、(P0’-P1’’’)のように進化する様子がわかります。


 Product Forest 型の他の例は、早期リリース時のMicrosoft Office。それに含まれるアプリケーションであるExcel, Word, PowerPoint など基本コンセプトを共有し、関連製品としてセットで販売されました。しかし、それらは全く異なったコードをベースにしていました。アプリケーションが同じように振舞うのに、それらは統一されなかったという経験をお持ちでしょう。このようなすれ違いを感じる振る舞いこそ、Product Forest 型で出くわす問題なのです。時間の経過とともに、製品間の一貫した振る舞いはより難しくなる。そしてサポートとメンテナンス費用が次第に増大する。(個々の製品で個別の対処と知識が求められるので) そして同じ会社ということで同一感を求めて購入した顧客の満足度を下げることになる。

The Product Bush

 Product Bush型では、製品間の結び付きがより強くなります。そこでは製品が共有する原型があり、それを複製して個々の製品が開発される。新製品は基本的に既存製品のコピーに対して開発(というより微調整)され、新規のあるいは変更された要件が満たされます。


 このパターンで何が問題か?Product forest 型では、時として共有は全くありませんでしたが、新製品のための適切な原種を選択するだけで(低コスト、少ない時間で新製品へ発展させられる)、とても良いプランであるかに思えます。コピーを取る事にコストは殆どかかりません。必要なツールもコピーだけなので無料です。そのためクローンに要する部分は、安く上がるのですから。
 
 しかしながら初期段階では良く見えても、後からしっぺ返しを喰らうことになります。例えばP0の顧客が旧製品であるP0と新しい P1の統合したものを希望した場合。もしも個々に進化・発展を遂げてきたシステムのコードをマージした経験があるならば、この事の重大さを想像することは容易です。多くの場合、必要な機能のコンビネーションを改めて実装するほうが安く上がるでしょう。もしProduct bush 型が長期にわたって発展していて、バグ対応が多くの製品に反映されている場合、これは悪夢となるでしょう。数百・数千に枝分かれしている Product bush 型を見たことがあります。もしその枝分かれの様子を描写すれば、ペンの使い方を学んでいる子供が描くようなランダムな絵になるでしょう。そのようなものを正しく理解し、メンテナンスすることはできません。
 
 でも必ずしも、どのような場合でも Product bush 型が問題であるとも言えません。長期に亘るメンテナンスの必要が無く、同時並行して開発される製品が無い(一つの開発が終わってから次の製品開発をするような場合)、あるいは新製品が必ず旧製品機能のスーパーセットを持っている。このような場合であれば、Product bush 型で上手く運用できるでしょう。
 
 このProduct bush 型シナリオが進捗中で、でもなぜ bush (やぶ、茂みなどの意味)型なのかと気になられたら、紙に製品間の関係を描いて見ると良いでしょう。。

The Product Gang

 次のレベルの製品間の血縁関係は、Product Gang 型です。再利用資産の構成と誂えで製品群が構築されます。 再利用の意味する所は、新製品に対して再利用資産を組合せ、新製品に必要となる部分を開発するという状態。再利用資産(ここでは“Platform” PF)に対する変更は、アプリの開発者が新しいバージョンのPFを取り入れないと、製品には反映されない。Product gang 型における製品群は、より多くの資産を共有し、それらはプラットフォームの資産に由来すると言えます。それ故、製品はプラットフォームのインスタンスであり、ここでは製品という代わりに製品バリアント(PV0-PV3)と呼ぶことにします。バリアントとバージョンの違いに関しては、私の別のポストで紹介しています。 this post.


 高度に構成可能なアプリケーションフレームワーク、再利用コンポーネント上に構築される製品群、どのようなものでも。基本的に多くの再利用を意図した開発アプローチは、これに属するでしょう。 ”かなり良いと思うけど、何か問題でも?” はい、確かに上記2つより再利用に関して良さそうですが、本当のソフトウエアプロダクトライン(SPLE)に対して何か足りません。まさしく現実世界のギャングのごとく、全メンバー間には強固な関係が存在しています。しかしながら、シークレットも存在する。誰も自身のことを他のメンバー(ギャング)に明らかにしない。そしてこのアプローチの根本的な課題は、ギャングのメンバーに対する情報が殆ど、あるいは全く無く、共通資産に対する変更の影響を見積もることは困難で、またその調整も非常に厄介です。例えばコンポーネント内のインターフェイス方式を変更する必要がある場合、他のアプリケーションからコールされることが無いことを確認できると良いのですが、ギャングのメンバーは個々に活動(進化)しているので(別の離れたブランチで、あるいは異なったバージョン管理ツールのリポジトリで)、そのようなことを確認することは容易ではありません。そして一般に、product gang のメンバーに提供される再利用部品の用法に関する十分な情報が無い場合、非常に控えめな想定しか出来ないでしょう。多かれ少なかれ全メンバーが現存のやり方で利用しているかもしれないことを想定しなければなりません。そして変更された場合には、それを用いる全メンバーで正しく動くことを検証出来るといいのですが、そのためには変更をリリースする前に少なくとも幾分のギャングメンバーでテストをする必要があります(あるいは他の手段によって取り得る全てのケースを確認すること) しかしながら、わずかに異なる個々の製品に対するビルド処理、他のプロジェクトのリポジトリにアクセスできないこと、あるいは現実的に時間上の制約から、たいていの場合は不可能です。そして製品個々のソリューションを優先することで再利用はやがて低減されることになる。(それらソリューションは局所的であるために、、)

The Product Family

 そして最後のパターンは、おおよその最終目標となるソフトウエアプロダクトライン開発(SPLE)であり、これは Product Family 型と言えます。前に見た Product gang 型との主な違いは、開発組織全体で製品ファミリー(PV0-PV3) に対する認識が得られることです。そして Product Family 型のアプローチでは、製品ファミリーの資産が進化する中で、全ての関連製品に対する継続的な配慮もされ得ます。どの時点でも共有資産に変更があった場合、(その時点で関連する)ファミリーの全てのメンバーがそれに関わることになります。これはもちろん技術的なプロセスのみならず、資産や製品(バリアント)の個々の担当者間における検討、優先順位付け、変更の却下なども関わってきます。


 再利用コア資産とそれからなる製品との間の双方向なリンクこそが、ソフトウエアプロダクトライン開発(SPLE)での再利用と従来型の再利用アプローチとの根本的な違いです。もちろんこれは、ただで得られるわけではありません。大規模なファミリーを抱えておられるのなら、このことはご想像できるかと思いますが、、、

From here we go

 すでに紹介してきた全てのパターンには、それぞれのユースケースがあります。常に問題と言うことではありません。しかしながらプロダクトラインということであれば、それは Product family 型しかありません。そして要は、どのように他のパターンからProduct family 型へ移行できるかです。これには基本的に2つのシナリオがあり、そのひとつは “Separate Product Merger” と私は呼んでいますが、それは個別の製品群(多くの場合全く個別に開発される)がスタートポイントとなります。既存製品間で共通の問題空間(problem space)を有しているが、解決空間(solution spaces)は全く依存関係が無いか、少なくともある程度の逸脱があり、解決空間(solution spaces)のマージには多くの努力が必要となります。しかしながら、なにはともあれ1つか2つ程度の製品の解決空間(solution spaces)の資産を新しいプロダクトラインのベースとして用いることを考えることです。例えば2つのベスト製品を選択、その一つは最もシンプルな製品、そしてもう一つは最も複雑な製品を。


 Product bush 型、Product gang 型では、再利用は既に行われています。それゆえ、私はもう一つのシナリオを単純に、”再利用の改善(Reuse Improvement)”と呼んでいます。なぜなら問題空間(problem space)も解決空間(solution)の資産も、多くの既存資産に密接で、それらを新しいプロダクトライン開発(SPLE)に用いることが出来るからです。多くの場合、この再利用改善シナリオでのゴールは、殆ど不変な全既存製品が新しいプロダクトラインの資産で生成できることです。シンプルで直ぐにかかれるアプローチは、解決空間(solution space)のバリエーション(コードレベルで比較して得られる情報 これに関しては後日詳しく述べるつもりです)から始め、そして問題空間(problem space)のバリエーションへと繋げることです。別のアプローチは問題空間(problem space)から始めて解決空間(solution space)へと進むことで、これはソフトウエアプロダクトライン開発(SPLE)を開発の全く始めの段階で開始するのと同様の手段です。この場合、問題空間(problem space)のバリエーションを解決空間(solution space)に存在するバリエーションにマップすることは容易ではないので、問題空間(problem space)と解決空間(solution space)のマップは幾分複雑な作業となります。しかしながら、多かれ少なかれこのアプローチは、“Separate Product Merger” のシナリオでも必須な作業です。
 
 バリエーションポイントを解析し、そして問題空間(problem space)と解決空間(solution space)をドキュメント化することは、容易な作業ではないので、今後改めてご紹介する予定です。
 
このブログのオリジナルはこちらから LinkIconKnowing where you are: Product Relation Patterns
 
 

Article (4) Moving targets – Change Management for Software Product Lines

 

プロダクトライン開発と変更管理

 
 ソフトウエアプロダクトライン開発(SPLE)に於ける変更管理について紹介する。それはチャレンジングな課題であり、多くの場合プロダクトライン開発(SPLE)の成功に関わること(製品群の構成よりも)。 ソフトウェアプロダクトラインは、まるで生物のように継続的に変化し続ける。ソフトウェアプロダクトライン開発(SPLE)について聞きかじった人の多くは、それは慣れ親しんだ通常のソフトウェア開発よりずっと複雑になると信じている。しかし驚くなかれソフトウェアプロダクトライン開発(SPLE)の多くの側面は従来方式の開発に似通っている。主な違いは同時に配慮するべき製品の数。そしてこれは疑いも無しに複雑性と課題をもたらすことになる。

Sources of Change

 変更要求やプロダクトラインへの変更には非常に多くの異なるソースがある。1つのソースは製品から出た不具合。欠陥はすぐに削除する必要があるが、ビジネス上で欠陥の影響をこうむる製品群へのインパクトを見積もることはとても重要な課題。出荷済みや開発中の製品など。ここでは迅速であることがキーであり、即座に(そして正確に)インパクトを見積もることでのみ、適正な判断・決定をすることができる(いつ、どのようにして、プロダクトラインのどの製品群の欠陥を直ぐに修正するか、後回しにするか、しないなど)。
 
変更の2番目のソースは、新製品のアイデア。多くの場合、マーケティング、製品管理、あるいは顧客からアイデアはもたらされる(GPS受信機と携帯電話でナビゲーションアプリケーションをサポートするといったような)。そしてアイデアが必要とする新しい機能がプロダクトラインへ統合される必要がある。(この例ならハードウェアの変更とドライバソフトウェアの一部など) しかし多くの場合、製品のアイデアは単に既存の機能と要件の新しい組み合わせを求めるのみ(ビジネス電話にMP3プレーヤーとFMラジオアプリケーションなど)
 
技術的トレンド(携帯電話のタッチ画面操作のような)は、この点で異なっている:プロダクトラインに新しい技術トレンドを取り込むことを考えるには多くの時間を割くべき。なぜならそれがもたらす変更は非常に大きなインパクトをプロダクトライン内の既存フィーチャ、要件、そしてソリューションスペース上の様々な要素(資産)に与えることになるので。それゆえ1つの技術トレンドは、プロダクトラインの既存の情報へ多大な変更をもたらすこととなる。

Change Management Challenges

 プロダクトラインの変更管理の主要な課題は?それは明らかに変更のインパクトが単一の製品開発に比べて高いということ。変更が市場に出荷された製品や開発中のものにまで影響を与えるので。変更を伴う一つの問題が多くの製品に影響するということ。しかしながら、その逆のケースもある。一つの修正が影響を受ける全ての製品の修正となる。いずれにせよ変更によるインパクトは増加するので、より注意深い扱いが求められる。多くの資産にインパクトを及ぼす一つの変更だけでなく、一般には各共有されている資産ごとへの多くの変更要求もある。なぜなら単一製品に比較してより多くの利害関係者が関わることになるので。そしてインコンパチな(両立できない)変更要求なども多く含まれる。それらが変更管理プロセスで正しく扱われないと、変更要求の確認に追われ、実装やテストなどの作業どころではなくなってしまう。
 
しかしながら問題や欠陥の数は、単一製品の資産を開発することに比べて同等、あるいはいずれ減少することとなる。理由はシンプル。問題の数はコード行数におよそ比例するので。共有されるコードはそうでない単一製品用のコード(バリエーション)に比べて多くなるが、その増加は一般に穏やかな傾向となるので。そして共有されるコードはより良くテストされるし、堅牢でもある(より多く運用されることで問題を出し尽くすなど)。結果、プロダクトライン開発の効果を得ることが出来る。問題がより少ない良いコード。あるケースでは、プロダクトラインのやり方で部品をマージして共有することで、製品間に関わる問題を全体の10%に削減している。
 
変更の速度を管理しコントロールすることは興味深い課題。あるプロジェクトが共通資産への新機能や修正を出来るだけ早くに必要としても、他のプロジェクトは頻繁に変更されない安定性を望むことになる。なぜなら共有される資産への変更には、再テスト・再リリースが全ての製品に伴われるので。このような利害関係は避けようが無く、妥協して(歩み寄って)解決されなければならない。とにかくはプロセスや採用される技法により、できるだけこのような課題を緩和できるようにすること。また利害関係者が増えるということも、さらに複雑な要因となる。ある意味 SPLE の取組みによる成果を得るためは(失敗しないために)、上手な意思疎通と協調が必要。
 
要は意思疎通と情報交換のインフラ作りが大切ということ。プロダクトライン開発(SPLE)では全ての利害関係者がプロダクトラインの全ての関連情報(要件、テスト結果、変更要求、バリアント定義、フィーチャモデルなど)に、バージョン管理される共有コードと同様に簡単にアクセスできなければならない。それには中央集権で統一された情報管理が求められる。そして殆どの要件管理・変更管理・テストツールは、自身でプロダクトライン開発(SPLE)を支援するようにできていない。それゆえ要件管理や変更管理のための専用ツールと、バライアビリティやバリアント情報を維持管理するためのソフトウエアプロダクトライン(SPLE)を支援するツールが必要となる。
 
このデータベースの情報は継続的に変更され続ける。そして多くの場合十分な情報が無かったりする。またアーキテクチャ図や顧客リクエストや各種情報などの補完的なドキュメントへの参照もあったりする。そしてこれら全ての情報は、プロジェクトマネージャやアーキテクトなど異なる利害関係者に異なった見え方で提供する必要がある。例えばある製品開発の開発者は、それに関わる要件と機能についてのみ知りたいだけで、全プロダクトラインの全機能を知りたいのではない。プロダクトラインマネージャなら異なる製品バリアントの比較や、共有フィーチャの特定グループに対する変更要求に関する状態などに興味を持つことになる。
 
プロダクトラインの情報モデルからそれぞれの観点の情報が得られることで、関係者ごとのタスクが単一製品開発に比較しても追加の負荷がなく、高度に実施できるようにされるべき。
 
プロダクトラインに関わる変更を阻害する対処されるべき顕著な違いがあることは明らかであるが、製品固有の課題や変更要求は通常の単一製品開発のものと同様に扱える。

Getting it right

 SPLE における変更管理に銀の弾丸は無いが、プロダクトラインの変更プロセスをどのように行うかの幾つかのアイデアを、その役割や組織上の構成の点から紹介する。
 
SPLE に特有の変更管理の複雑さに対応するためには、組織上の一定の要求、変更に対する市場や顧客の要望、その他多くを打ち合わせるための、適正な基盤・インフラをお膳立てすることが必要となる。しかしながら基本は実績の多くある従来からのアプローチと殆ど同じ。例を用いて変更管理の役割とプロセスを説明する。共通のコア資産を提供するプラットフォームがあり、それらを使用する複数の製品開発プロジェクトがあると仮定。これら異なる全てのプロジェクトやプラットフォーム開発の管理は、プロダクトライン・マネジメント・オフィス(Product Line Management Office)によってコントロールされる。このオフィスに必須の役割はプロダクトラインマネージャで、プラットフォームとプロジェクトをコーディネイトして調和させ、プロジェクト間のレポートや査定などもプロダクトラインのタスクとして取り計らう。そして基本的には全ての意思決定のトップとなる。他の重要な役割にプロダクトライン品質マネージャがあり、全ての開発資産・成果物の品質を管理・メンテナンスすることの責任を持つ。これはソフトウエアプロダクトライン開発で特別の役割ではないが、通常よりも重要(重責)となる。またドメインのエキスパートはプロブレムドメイン(問題空間)と具体的なソリューションドメイン(解決空間)へのマッピングに必要となる知識を提供する。
 
この筋書きでは変更要求は一つの変更管理委員会によって取り扱われる。この委員会は全プロジェクトとプラットフォームに対する意思決定をまかなう。なぜ、それが重要となるか?もし変更要求が先にプロジェクト内で対処されてから、プロダクトラインに重要であるという考えから変更管理委員会にフォワードされるとすると、a)少なくとも他のプロジェクトが課題を認知するまでに遅延が生じる、b) 多くの関連トピックの可能性が変更管理委員会に全く知らされなくなってしまう。このような管理体制では上手く行かない。プロダクトライン変更管理委員会は、単なる一製品のみの問題はそのプロジェクトに即座に一任しながらも、複数製品やコア資産にインパクトをもたらす全ての変更を管理しなければならない。
 
変更管理委員会が得られる情報のフィルターとなりながら、アーキテクチャレビュー委員会が、アーキテクチャが常に安定して活用できることを受け持つ。一般には製品の進化によりコア資産も進化されるので、この業務は継続的に必要となる。そしてアーキテクチャのガイドラインやパターンの詳細記述もアーキテクチャレビュー委員会の活動となる。基本的に、ソリューションスペース(解決空間)の実装を管理することになる。
 
そしてプロダクトライン管理委員会はプロダクトラインマネージャとプロジェクトマネージャで構成される。それはプロダクトラインに影響する戦略的決断(プロダクトラインのスコープ・範囲の定義、プロダクトライン組織構造の決定、製品開発の優先付け)など上位レベルの意思決定を担う。また製品スポンサーもプロダクトライン管理委員会に関与することができる(この場合は上述の役割は負わないが)。製品スポンサーはユーザや顧客を代表することになる(なのでプロダクトマネージャの役割ともいえる)。いくつかの決定にはドメインの熟練者も関与することになる。しかしながらプロダクトライン管理委員会はコンセプトのレベルでプロジェクトをコーディネイトして調整することが目的なので、通常はマネージャやスポンサーのみで担われる。
 
ドメインの熟練者は変更管理委員会に関与して、ドメイン内の変更の一貫性を保ち、異なって来る変更要求をまとめて再利用の最大化、重複の排除に努めることになる。可能なら、製品スポンサーも変更管理委員会に関わるべき。製品ラインの戦略に変更の悪影響が出ないように確認をするため。アーキテクチャレビュー委員会には、テクニカルなアーキテクトや場合によってドメインのエキスパートが関与する。そして、それ以外の開発者は(幸か不幸か)、これら委員会に関わることはない。
 
これら各委員会はいつもあるわけではないので、その間を取り持つような作業者も必要となる。プロダクトライン管理委員会の一部として、プロダクトライン・タスクフォース(特別委員会)は、日々の業務を担う。そして深刻な課題が浮上したなら、タスクフォースは個々の委員会に通告する。このタスクフォースは、ドメインの熟練者、テクニカルなアーキテクト、場合によってはビジネス上のエキスパートや個々の製品の熟練者などで構成される。このタスクフォースは新機能を認識して評価し、変更管理委員会にそれらを提案する。ドメインのモデルを詳細に定義することに加え、関わる技術的トレンドも特定する。そしてアーキテクチャにも関わる。しかしながら最も重要なタスクは、ソフトウエアプロダクトライン開発(SPLE)で各プロジェクトが恩恵を受けるようにすること。

Is Your Change Management Fit for Product line Development?

 たとえ素晴らしいアーキテクチャがあり、またpure::variants のような優れたプロダクトライン開発(SPLE)支援ツールを有していても、変更に対する安定した仕組みを取れないなら全ては泡と化す。ソフトウエアプロダクトラインで変更管理の取り組みに重要な特性・要素とは?
 
(1)変更要求から影響を受ける製品群にトレースできること
 
 もし変更管理が単に変更があることを通告するだけで、その変更要求が関与する既存製品群が記録されないなら、プロダクトライン開発にはあわない。単一製品のみ影響を受けるか全製品がその対象となるのかのどちらかのみ。しかしながら製品のサブセットも影響を受けることがある。影響を受けるサブセットを知ることで、その対処や意思疎通に関わる工数を軽減できる(特にテスト)。この情報無しでは、全ての問題が例えそれが単一製品のみに関わるものであっても、全ての製品にわたって問題が通達されることになってしまう。
 
(2) コア資産からそれを用いる製品にトレースできること
 
 ある修正を目的にした変更要求によってコア資産を変更するならば、それによって影響を受ける製品群を特定できなければならない。さもなければ非常に多くの製品のテストをする羽目になり、工数が掛かって製品リリースが遅延してしまう。あるいはその資産を使っていない製品の顧客にまでリコールをするような事態に陥りかねない。ビジネスへの悪影響は計り知れない。
 
(3) 変更要求から関係するコア資産にトレースできること
 
 多くの場合、変更から既存製品にトレースできることだけでは不十分。変更管理に問題を登録した後に新製品を構成しビルドするとしたら。コア資産のどれが問題の影響を受けるかを特定できて、それらを使用する各製品にトレースすることが出来るなら(上述 2)、新製品開発にも影響するかもしれない問題を特定できる。
 
(2)、(3)は両立できれば(1)はそれほどの課題ではなくなる。製品群の一覧は殆ど自動で生成できるようになるので。
 
これらはプロダクトライン開発の取り組みに必須と言ったものにはなってないが、無くては完全な失敗となる。特にプロダクトライン開発の初期段階で成功して、多くの変更要求と共に派生製品が多く生み出されるようになると、正しい変更管理が無ければ当初の成功は直ちに裏目となってしまう。なので備えることが賢明。

A Sample Change Management Process for Product Line Development

 広範に異なる製品ドメイン、プロダクトラインに対する取組みのバライアティ、などから単純に全てにフィットする変更管理のプロセスは無い。しかしながら、以下に説明するサンプルプロセスは大抵のプロダクトラインに適用できる。そして多くのケースでプロセスは十分簡易化できることを、コアとなるプロセスの紹介の後説明する。
 
筋書きとして、プロダクトライン内で多くの製品が並行して開発されメンテナンスされていることを前提とする。製品はユーザの観点でわかるフィーチャや機能性でもって定義され、共有されるコア資産と幾つかの製品特有の資産で構築される。顧客・ユーザは特定製品の欠陥をレポートし、多くの場合影響を受ける機能を挙げる。同様に機能の追加、変更、削除などの変更要求は、多くの場合製品顧客・ユーザに関わるが、他にもプロダクトライン・マネジメント委員会などから特定製品にのみ関わらない要求も来る。問題(issue)への対処・取り組みのワークフローや状態は、一般的な問題(issue)をトラッキングするためのツールのそれと同様(“New”, “Assigned”, “Fixed”, “Verified” などの状態、そして問題(issue)間の単純な依存関係)。例えば バグ管理ツールであるBugzilla のようなシンプルな問題(issue)トラッキング(追跡)ツール。
 
ここで用語として”問題(issue)”とは、欠陥、要処理事項(アクションアイテム)、変更要求などを意味する。
 
一製品の欠陥に対して一つの問題を提起するだけの単一システムの取組みはプロダクトラインのシナリオとはならないことは明白。共有されるコア資産の欠陥は複数製品に影響するので。ただ単一製品のみではなく全ての影響をこうむる製品へ問題をリンクさせることは良いことではあるが制約もある。問題が全製品で修正され動作することを検証されるまでクローズできないこと。もし修正の検証作業がグループからなる製品群に対して分かれて実施される場合、幾つかの製品では修正が正しいことが検証され、他の製品にはその情報が行き渡らないなど。これは問題(issue)トラッキング(追跡)ツールでは記録して管理することが複雑で困難。なぜなら”部分的に検証済み” といったような中間状態、検証済みの製品リストなどが問題(issue)内に記録される必要があるので。そして検証済みの製品のリリースも、全ての製品で検証が確認されるまで問題(issue)を正式にクローズできない。
 


 
このような場合、一つの問題(issue)を関連するタイプに振り分ける方法がある。WorkIssue は、問題(issue)解決の進捗を記録するために用いる。ProductIssues は、個々の製品に関して問題(issue)の状態を記録するために用いる。すなわち各ProductIssue は一つの製品にリンクされる。ProductIssue の目的は主に、製品の問題(issue)への検証と、その製品への問題(issue)解決策の適正さを、トレースすること。そして大事なのが、MasterIssue を用いてWorkIssue と 全てのProductIssues を一つにまとめること。なぜなら問題(issue)は、WorkIssue と 関連した全てのProductIssues の両方がクローズされて始めて完全にクローズできることになるので。MasterIssueはその為に使用され、全ての問題(issue)への正しい解決が記録される。
 
 

変更管理のアクティビティ図 問題(issue)の登録・更新


上のアクティビティ図では、最初の問題(issue)が登録されてからの手続きを示している。問題(issue)に対する初期確認から得られる情報に基づいて関連の問題(issue)が定義される。当初の問題(issue)はWorkIssueになる。シンプルに事を進めるために、MasterIssueはProductIssues がある場合のみに定義されるようにする。(すなわち、問題(issue)の影響をこうむる複数の製品がある場合)。そしてWorkIssueへの変更がある場合はいつでも同じプロセスが実施される。
 
このアプローチでは様々なゴールをサポートする。共有される資産への問題(issue)修正と、それを製品群に反映させることを適正にモニタできること。(これは一製品のみが関わるならシンプル。単一製品開発と変わらないので) そして品質に対する妥協無しの迅速さが求められるような各製品ごとに、同じ問題(issue)でも異なる状態を持たせられる。
 
もちろん、このようなワークフローを実施するには変更・修正のインパクトを評価できる適切なツールのサポートが欠かせない。そして状態の変更への対処を自動化できることも必要(不要なマニュアル作業を削除する工夫)。ここで pure::variants は、製品間にまたがる問題(issue)の状態を視覚化し評価するための優れた表示機能を持つ .

Final Remarks

 以上は、当然ながら開発チーム(プロダクトライン)ごとで固有の変更管理の課題に対して完全な解となるわけではないが、配慮するべきことへの何らかのヒントになると思う。場合によってはワークフローの単純化も可能。例えば全製品の同時リリースを実施しているなら、各関連製品ごとで別々の状態に対処する必要は無くなる。
 
変更管理の課題は、プロダクトライン開発(SPLE)の学術研究や文献には余り紹介されていないように思う。そして、より多くの実践者や研究者の考え、経験を知り理解したいと思っている。是非とも考え・知識・概念などを知らせて欲しい。
 
leave a comment
 
このブログのオリジナルはこちらから LinkIconMoving targets – Change Management for Software Product Lines
 
 

Article (5) What’s the difference? A Closer Look at Configuration Management for Product Lines


プロダクトライン開発と構成管理

 
 プロダクトライン開発(SPLE)の構成管理は複雑になりかねない? はい確かに! 複雑にするしかない? いいえ、全く!
過去のブログでは variants not being version (バリアントとバージョンの違いの定義)や、クローン&オウン(コピペ)が招く product bush (最も普及した方法で、当初は安上がりに見えるものの、、、)について触れてきた。そこで今回はプロダクトライン開発に於ける構成管理について紹介する。
 
単純に言って、単一の製品開発とプロダクトライン開発(SPLE)に大差はない(重要となるような)。間違いなく正しく実施できれば。しかしこれだけでは十分な説明とは言えないので、以下に詳しく説明する。
 
まず始めにプロダクトライン開発(SPLE)で構成管理を実施するうえで犯してしまう大きな間違いについて。それは構成管理ツールをバライアビリティとバリアントの管理に用いること。一般に構成管理システム(あるいはバージョン管理システム)は、ブランチングを提供する。それは一連のセットからなる成果物のコピーを作り、そのオリジナルとは別個に変更すること。ブランチングの適正な使用法は様々あるが、全く不適切な使用法が一つ有る。それは一連のセットからなる再利用資産内のバリエーション管理の主要なコンセプトとしてブランチングを用いること。もしバリエーションが最初にブランチを作ることで扱われて、オリジナルとブランチされた成果物のいずれかが製品を識別するものになると、それ以外の再利用の手法と比較して不必要なオーバヘッドに見舞われることになる。なぜなら一般にブランチされた成果物は(単純化するために1つのファイルがブランチされたとして)、全てが変更されるわけではなく、オリジナルから変更されないままの箇所を含むので(殆どの場合多くの部分が)。
 
ブランチかオリジナル側かで問題が見つかった場合(ここではオリジナル側を仮定する)、修正が行われてバージョン管理システムにチェックインされる。ここまではOK。さてブランチに何か行わなければ。第一に、ある製品に使用されているブランチされた成果物にも修正を考慮しなければならないことを考える。バージョン管理システムによっては、変更がいくつものブランチにある場合、関連するブランチされた成果物を探す支援機能があるでしょう。それは良し。そして修正がブランチとオリジナルの両方で同じに見えるファイルのどこかで見つかった場合、単純に修正をコピーするだけで簡単に済みそうであるが、、
 
でもちょっと待って!ファイルのこの部分がブランチ内で変更可能であることを知りえるでしょうか?バリエーションの管理粒度はファイルです。なのでオリジナルとブランチされたファイル内で同一の実体(ソース行、ファイルなど)が同じであるべきなのか(バリエーションではなく共有される部分)、あるいは実体の一部はバリエーション(ブランチングの目的)に属していて変更できないのか。例を挙げると、構成のための定数のパラメータ(バッファサイズとか)。もしパラメータがオリジナルのアルゴリズムとブランチ内で修正後のアルゴリズムの両方で使用されていたなら、そのオリジナル側への変更は、ブランチされたコピー内の修正済みのアルゴリズムの同じ定数の変更が必要かとか、可能であるかなどのわかる由も無い。それゆえ修正のどの部分がブランチされた成果物に適応されるのかをチェックしなければならない。たとえその修正がバージョン管理上衝突を起こさないように見えても。適正に自動化されたテストスイートがある場合は、マージされた成果物を含む全ての製品にテストを実行して影響をこうむらない事を確かめるべきでしょう。そうで無い場合(ドメインによっては自動化テストスイートは不可能)、それは人手に頼った当て推量になってしまう。
 
これはブランチされた成果物が共有コードを含むことなくバリエーションだけで成り立っている場合は当てはまらない。つまりバリエーションがファイルの粒度で適切に包含されているということ。このような場合一つのファイルはオリジナルとブランチされたコピー間で共有することもしないこともできる。そして全てのファイルがそうであるのなら、共有される・されないファイルセットの両方に含まれる変更のセットに対処するのみ。そしてこれらを共有されるファイル群にだけ関わる変更セットと、単一ブランチに固有の変更セットに分散すること。共有されるファイル群への変更セットには、変更は共有される全ての実体で行われるべき。もし後日、以前にブランチされたコピーからさらに枝分かれしてブランチ・コピーする場合、その枝分かれのコピーが基のブランチのコピーと共有され、しかしオリジナルとは共有されない場合、それらをバージョンコントロールシステム内で追跡することは複雑で込み入ったものになるので。
 
ここまでは一つのファイルを例にしてきたが、実際は数百・数千に上るファイルにこの問題が当てはまる。そして多数のブランチによって作業は劇的に増加する。各変更ごとで各ブランチに同じ作業ルーチンを実施することが必要なので。共有成果物もブランチも少なければ多分大丈夫であるが、前者が少ないということは再利用できる成果物が制限される。後者はバリエーション数が制限される。
 
この筋書きを図にすると複雑さが見えてくる。典型的なバージョンコントロールシステムから派生されるブランチング/マージのログ(左からの時系列)。7つの製品(P1~P7)が 良くあるブランチ&マージ の手順で実装され、それは既存システムのクローンを作って各々独自にメンテナンスされる。全てのブランチされたインスタンスに変更をきちんと同期させ続けることは全く厄介であることは明らか。マージするために必要な作業量から、多くの場合2つの製品間のみでマージが取られることになる(いくつかのパーツを別の製品から取ってくるだけ) システマチック(体系的)な再利用とは言えそうに無い。
 
 


 
要するにバージョン管理される資産の粒度がバリエーションのものと同等で無い限り、バージョン管理内のブランチングはバリエーションポイントの表現には向いていない。それゆえ、たとえバージョン管理システムのベンダーがバリエーション管理にも使えますと言っても、粒度のミスマッチがあることをご用心。そしてファイルの資産に関しては、粒度のミスマッチは殆ど不可避。資産への変更をその寿命にわたって追跡するために適正なバージョン管理ツールを使うことべきであるが、バライアビリティとバリアントの管理は一緒にはできないということ。バライアビリティは別個のものとして、一時にバリアント内で使用可能なものと使用中のものを直行する表などで表現される。
 
プロダクトライン開発(SPLE)にとっての適切なブランチの扱いにお迷いでしたら、それはシンプルに次の2点。単一製品開発で有効なメインブランチ(トランク(主系)、HEAD)から短期間の分岐で独立した開発活動(“feature branches”といわれる)と、メインブランチ上の進行中の変更から(直ぐの)リリースへの分岐(“release branches”といわれる)。
 
これら両方のコンセプトについての良い説明は(good description )無償で公開される Subversion eBook (ここでは“trunk” を “main development branch”として読み替える必要がある)。これらコンセプトを適応すれば、より簡潔でわかりやすい図式となる。開発の主系より上側のブランチはリリースのためのものであり、下側は新機能開発用である。一般にブランチはより短期間であり、マージは殆ど開発側のブランチから開発の主系に行われ、リリースブランチからやそれへのものは殆ど無い。このアプローチはわかりやすい図式になるだけではなく、実質的な再利用が容易にできるようになる。
 
下図は上図のP(製品)に対してV1~V4(製品バリアント)が共通のベースから生産されている状況。共有されるベースからのバリアントの実際の導出は、コンフィグレーションあるいはpure::variants のような適正なバリアント・バライアビリティ管理ツールによって、独立した活動として実施される。この派生導出/インスタンス化の活動はバージョン管理される成果物の上で取り計らわれる。そこでバージョンコントロールシステムはインスタンスの記録に使われはするが、バリエーションポイントの仕組みは提供しない。
 
 

 
以上から最初の主張であった、もしバライアビリティとバリアントの表現がバージョン管理で行われていなければ(これは名案:上記参考)、プロダクトライン開発でバージョン管理に特別なことは無い。(より多くのユーザと変更によるパフォーマンスやスケーラビリティの課題があるにしても)
 
leave a comment
 
このブログのオリジナルはこちらから LinkIconWhat’s the difference? A Closer Look at Configuration Management for Product Lines
 

Article (6) Strategies for Releases, Development, and Maintenance in Product Line Engineering: Part 1 Product Development Organization

プロダクトライン開発の戦略 Part 1 製品開発組織

 
ソフトウエアプロダクトライン開発には極めて多彩な取組みの選択肢がある。例えば製品系列のドメインによって異なった製品リリース、開発、メンテナンスの戦略がある。取り得る選択を知り、最も適したものを注意深く選択することでソフトウエアプロダクトライン開発を成功に導くことができる。この記事ではいくつかの基本的な戦略とユースケースを手短に紹介する。
 
各章が長くなるので、いくつかのポストに分けて掲載します。最初はプロダクトラインにおける製品開発組織について。

Development Strategies for Products 製品と開発戦略について

 
Joint Development、 Parallel Development、One by One Development. の開発戦略3種について紹介する。
 


 
joint development 戦略では、製品群、再利用可能な(コア)資産、そして製品ごとの固有資産は共同で開発される。組織はプロダクトラインを主眼に総括して、まるで一つの大きな仮想チームとしての役割を演じる。戦略の実施にあたり多くの場合、なんでもこなす万能型のエンジニアからなる比較的小さなチーム、あるいは大きなシステムにはそのシステムの異なるパーツごとのスペシャリストのチームを擁することになる。
 
このスペシャリストのチーム同士、あるいは個々の万能エンジニア達は、開発中のいくつかの製品、あるいは全ての一定のテンポのリリースのために協調する(以下のコア資産と製品のリリース戦を要参照)。各チームやそのメンバー達は基本的に適切な意思伝達を行って協調できるので効率がとても良い。
 
これは一般に、その製品ビジネスがある一定範囲の複雑さまで上手く行く。もし並行して開発される製品数が非常に多くなるとか、再利用されないパーツの製品ごとの比率が大きくなると、基礎部分(全体への再利用資産)を賄うチームと、特定製品/製品グループを担うチームへの分割が要求されるようになる。
 
それでもなお、この戦略はプロダクトライン全体に重点を置くので、多くの場合複数製品間で高い再利用率を得る非常に効率の良いプロダクトラインとなる。協調・連携への努力(骨折り)、特に既存機能に対する変更は大抵の場合相対的に軽く済む。なぜなら多くの変更要求が単一チームあるいは開発者の担当領域に関わって、それらの衝突と依存は容易に検討して処理されるので。これは本質的に大抵のソフトウエアプロダクトライン開発のケースで最適の戦略である。しかしながら、この戦略をサポートできるように開発組織の変化を求めることは容易ではない。多くの場合プロジェクトマネージャにとって失うものがある:このシナリオではリソースへの独占的なアクセス(==権力)が無くなり易い。
 
parallel development戦略 と私が呼ぶふたつ目のシナリオでは、一つ以上の製品あるいは資産群を開発する複数のプロジェクトチームが各々独立して、製品や資産を開発する。一般に各プロジェクトには製品ごとの顧客やリリーススケジュールがある。そして平行して開発している各チームの主な焦点は各々の製品リリースであってプロダクトライン全体ではない。
 
この場合(多少の)コア資産開発にはjoint developmentもしばしば伴われるが、最も極端な例ではjoint developmentは全く行われない。たとえ再利用可能な資産が独立したプロダクトチームで開発されていても。そして結果的に、既存資産に対する変更や新しい再利用機能の実装や優先順位などに対する意思伝達、調整、適切なマネジメントの必要性が大きくなる。
 
従来(旧来)のプロダクトラインの試みでは再利用資産には joint development (for reusable assets) して、各製品・バリアントの開発には parallel development (for products/variants) をプロダクトラインの資産に対して混成することを推奨されていたふしがある。そしてドメインエンジニアリングとアプリケーションエンジニアリング間がはっきりと分離されることになる。
 
しかしこれら両サイド間の意思伝達は制限される。parallel developmentの時に見られるのと同様に全チームがあっち側とこっち側といった具合になるので。
 
この意思伝達の制限は良い面と悪い面を持つ。良い面は製品チームが再利用資産の実装を要求するまでに何らかの敷居があること。これはコミュニケーションの頻度と量に歯止めをかける。しかしながら、時にコア資産の開発でプロジェクトでのユースケースが無いのに再利用資産が作られてしまうことや、要件がプロジェクトチームによって適切に協議されなかったことである意味役に立たない再利用資産が作られる。また、コア資産開発チームに特定のユースケースに関わる知識が十分で無いなど。
 
しかし一方で、本質的に製品プロジェクト内の開発は利潤(あるいは顧客)と密接であるので最も多く実施される戦略でもある。
 
そして最後はとってもシンプルな“One by One”アプローチ。この場合一製品を開発し、その開発が終了すれば次の製品に進む。基本的に一つ以上の製品を同時に開発することは無い。もちろんこのシナリオは殆どのケースで縁が無さそうではあるが、明らかに最もシンプルなアプローチである。適応できる場合には極めて効率が良い。単一製品に明確に焦点をあてることができるので。
 
しかしながら旧製品のことを全く忘れても良いということではない。通常組織内の誰かがそれらの保守とサポートを受け持たなければならない。もしone-by-oneアプローチがクローン&オウン(コピー&ペースト:既存製品のコピーを基に次製品を開発する)で行われるなら、旧製品に欠陥が見つかった時に、大抵の場合に問題となる。基となってきた既存製品の一つから見つかった欠陥は、その製品から遡って幾度となく修正されなければならなくなる。次に紹介する製品メンテナンスの戦略でこの問題について触れる。
 
次回はリリースとメンテナンスの戦略について
 

Article (7) Strategies for Releases, Development, and Maintenance in Product Line Engineering: Part 2 Release and Maintenance

プロダクトライン開発の戦略 Part 2 リリースとメンテナンス

 
プロダクトライン開発の基本戦略である製品リリース、開発、メンテナンスについての後編. もちろん現実はこの記事で紹介するほど単純ではないが、これらの戦略を基にして各組織で主となる取り組みを類別できるでしょう。今回の記事では、内部のコラボレーション(コア資産の開発と、製品/バリアントへの使用)と、外部のコラボレーション/展開(製品リリースとメンテナンス)について紹介する。

Release Strategies for Core Assets コア資産のリリース戦略

開発戦略は製品やプロジェクトとの関連で観察してきたが、製品開発プロジェクトに使用されるコア資産の、いくつかの異なったリリース戦略について紹介する。
 


 
良く取られる戦略の一つにがHeartbeat Releaseある。手短に言うと、プロダクトラインの全てのコア資産はテストとリリースが同時に行われる。多かれ少なかれ定期的な周期で。例えば2週間ごと、あるいは6カ月ごとのリリース。それぞれのドメインで変更が必要となるスピード次第。一時にリリースされる全ての資産は相互に動作するはずなので、良いアプローチである。また製品はコア資産のハートビートリリースの一つに頼っているので、依存関係の複雑さも少ないであろう。
 
問題は製品への新しい機能を正式に使用できるまでにハートビートでリリースされるのを待たなければならないこと。製品リリースやサポートなどの速度が損なわれてしまう。もちろん顧客を満足させる方法もある。もし少数の製品間で重大な欠陥が見つかれば、それら影響を受ける製品の修正をリリースブランチに作り(あるいはリリースタグ/ラベルを基準にした追加のブランチ)、テストして修正した製品を出荷し、その修正を次のコア資産の正式リリースに反映させる。このような不良に対する修正がリリース間で頻発するのなら、ハートビートのタイミングを短くすることやコア資産の品質を改善させることなどが必要となる。
 
速度重視ならIndependent Release 。システムの個別部品、一つのコア資産、あるいは関連するコア資産群は、幾多に渡る変更が統合され、その資産のサブセットを担うチームがリリースに値する(製品に使用できる)と判断することでリリースされる。これはプロダクトラインの資産への一時的なアップデートを認めるので、当然変更の速度が増すことになり、結果より複雑な依存関係を持つ。コア資産群は非常に多くの独立したリリースバージョンを持ち、かつ異なる製品の異なったリリースに用いられることになる。これはparallel development戦略を採用していて、頻繁に非同期の製品リリース(後述:asynchronous product releases)をする場合に顕著になる。極端な場合、各製品が独自のバージョンからなるコア資産を持つことになる。そうなると問題への修正は途方もなく遅くなる。なぜなら全ての異なるバージョンが修正され再テストされなければならないので。あるいは影響を受ける資産の新リリースへのアップグレードが必要な製品への修正など(さらにそれらへのテストも必要であることも厄介)
 
もっと極端な戦略は“Continuous Release” 。この戦略ではコア資産のリリースそのものは無い。主となる一つの開発の流れがあり、全てのコア資産は最新版の開発と伴に絶え間なくアップデートされる。各製品開発はコア資産の最新のものをベースとする。リリースに向けての製品成熟段階にのみ、これら製品は主なる開発の流れから個別のブランチに入る。これによって製品は更なる開発から切り離されることになるが、それら進捗から多くの影響無く完成させることが許可される。このアプローチでは管理できそうにないと感じる方も居ると思うが、大規模開発組織でも上手く成功している事例がある。例えばHP社インクジェットプリンターの独自の製品ラインは、この手法で開発されている。<有償資料が公開中:http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4339270>
 
当然この戦略は確固たるjoint development戦略と同時に行われ、かつ製品リリースへの成熟段階が相対的に短い場合に最上の結果を得る。深刻なメンテナンスを要しない製品に適している。とは言いながら、製品群とメンテナンスが必要なコア資産間でかなり複雑な依存関係を生むことになる。既存製品を最新にする作業(労力)は低くされるべきで(製品固有のソフトウエア部品を新しいプロダクトラインソフトウエアリリースに適応する作業)、メンテナンス状態の製品数も少なくするべき。 旧バージョンのプロダクトラインソフトウエアで開発された製品群は問題と共に開発のヘッド(最新)に移動させて、それらの新しいリリースブランチを作る。

Release Strategies for Products 製品のリリース戦略

コア資産のリリース戦略(これは内部プロセス)同様に、プロダクトラインから生産される各製品にも異なるリリース戦略がある。基本的に同期、非同期の2種類のリリース戦略がある。
 


 
Synchronous Product Release(同期)戦略では、(殆ど)全てのアクティブな製品を同時に市場リリースする。例えば多くの汎用ソフトウエアツール(pure::variants のような)の市場出荷と同じ手法。
 
この方法なら依存関係をシンプルにできるし、テストや検証作業も低減できる(特にユニットテストやコンポーネントテスト)。なぜなら多くのテストが複数実行されないで済む。テスト入力とテストされたコンポーネントが、他製品で既にコンポーネントテストされたものと同じであれば、同じことを繰り返す必要が無いので。
 
しかしながら、この戦略下ではテストと検証作業に開発リソースのピークをもたらす。恐らくこのピークはとても高く、特に製品ごとに人手に頼ったテストをしていたり、テスト実行に長時間を要する場合は顕著になる。
 
Asynchronous Product Release(非同期)戦略では、各製品のリリースは個々に任せられる。異なる顧客やユーザが全く別々に要求するような場合に有効。また製品リリース前のテスト部門の検証作業の負荷を軽減できる。一方、同期戦略なら、一般にメンテナンスの工数・尽力の軽減に功を奏す。なぜなら全製品は同じリリースのコア資産をベースにしているので。これは非同期型では保証できない。
 
ところで念の為、ここで言うリリースとは顧客へ製品を実際に出荷することとは限らない。出荷できる状態にすることも含まれる。多くの場合、顧客は新しい製品リリースを頻繁に提供されることを望まない。例えば数千以上に上る組込み製品に搭載されるフラッシュメモリへのアップデートなどのような、物理的な課題・尽力が求められる場合など。
 
たとえ全製品が新しいリリースを直ぐに得ない場合でも、全製品がリリースできる状態にすることは製品メンテナンス戦略であると言える。次のセクションでは、最新の修正を全製品にもたらすことや需要に応じて使用できることを確かにするメンテナンス戦略を紹介する。

Maintenance Strategies for Products 製品のメンテナンス戦略

この記事のしめくくりに、メンテナンスやサポートといった製品の市場出荷後のフェーズについて言及する。ここでもまた、基本的に2つの選択肢がある。
 
一つ目はEvent Triggered Maintenanceで、ある製品の不良が報告されると、この製品(及び関連する製品)をアップデートする。つまりメンテナンス期間中は、ある問題の影響を受ける製品のみを再ビルドして、テストし、リリースする。ここで追加の選択肢としては旧コア資産に対して問題修正をするのか、旧製品を最新のコア資産で更新するのか。
 
別の方法はContinuous Maintenance。旧製品への新プラットフォームリリースへのアップデートは新製品のリリースと同時に行われる。すなわち基本的に、以前リリースした製品と新しく開発された製品との間に違いは無く同じに扱う。これは飛躍的にサポートの尽力を削減する。いつでも全製品にリリースしたものが反映されるので。ただこれは全ての製品を出荷しないといけないということではない。殆どの顧客は頻繁にわたるリリースを望まない。特に問題に直面していないときはなおさら。一方、顧客が望むなら修正された製品を直ちに出荷できる状態にあるということ。
 
多くの場合、これら2つのアプローチのコンビネーションが最も賢明な選択肢となる。新しい製品にはcontinuous maintenanceで最新版を提供する。しかししかるべき期間が市場で経過した旧製品であれば、event trigger maintenanceに移して保守し、メンテナンス終了を待つことになる。

Putting it together

上述してきた選択肢から、ちょっとしたフィーチャモデルを描ける。3つのオルタナティブがある2つのグループと、2つのオルタナティブがある2つのグループの組合せ。
 


 
これから3x3x2x2 = 36通りの選択肢が取れる。ただし、どのアプローチを取るべきかの正解は無い。一般に製品開発のビジネス上の戦略として最もシンプルな手法を選択する。開発組織の全サイズは重要な重要な懸案事項となる。少ないチームの小さな組織なら協調やコミュニケーションによる意思伝達が非常に有効。大きな組織ならドメインエンジニアリングと製品開発プロジェクトの分離によって、コア資産開発に対する個々のプロジェクトからの要求に都合よく(そして望ましい)壁を設け、より良いバランスを保つ。