概要多くの共通性を持つ複数のソフトウェア集約型製品の開発や保守には体系的な再利用を支える戦略が要求されるこの課題にはプロダクトライン開発の考えに根差したバリアント管理が実用的な解決策となる本編ではプロダクトラインエンジニアリングの原理が応用された産業界の3つの異なる製品事例 ( 工業

Size: px

Start display at page:

Download "概要多くの共通性を持つ複数のソフトウェア集約型製品の開発や保守には体系的な再利用を支える戦略が要求されるこの課題にはプロダクトライン開発の考えに根差したバリアント管理が実用的な解決策となる本編ではプロダクトラインエンジニアリングの原理が応用された産業界の3つの異なる製品事例 ( 工業"

こごろういなおか
5 years ago
Views:

1 先進的な設計検証技術の適用事例報告書 2016 年度版 SEC プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例 1 Manage Variants and Variability: Benefiting from Product Line Engineering ソースを再利用するつもりだったのに苦労を再体験してしまったやっとバグをつぶしたと思ったらコピペ先でバグが突然変異何度も何度も同じ改修を繰り返している悪い夢を見ているようだブランチバージョン = 爆発! これはバージョン管理にバリエーション ( 製品間の違い ) の管理を混同したことに起因する症状 P4 R P2 R R P5 P1 R R R P7 P3 R R R P6 Px Product Branch Merge R Release Development Maintenance Integration pure-systems GmbH 図 59-1 バージョン管理にバリエーションの管理を混同です多くの組織ではこうした経験をしたことがあるのではないでしょうかソフトウェアプロダクトライン開発は製品系列の資産を体系的に再利用することにより派生製品の開発工数を削減して市場投入時期を早めています同時に品質改善や製品間のトレーサビリティによるメンテナンス性向上などの相乗効果も期待されています 1 事例提供 : pure-systems GmbH Dr. Danilo Beuche 翻訳 : 富士設備工業株式会社電子機器事業部小山美樹氏浅野義雄氏 1

2 概要多くの共通性を持つ複数のソフトウェア集約型製品の開発や保守には体系的な再利用を支える戦略が要求されるこの課題にはプロダクトライン開発の考えに根差したバリアント管理が実用的な解決策となる本編ではプロダクトラインエンジニアリングの原理が応用された産業界の3つの異なる製品事例 ( 工業オートメーションや車載システム ) を基にプロダクトラインエンジニアリングとバリアビリティ ( 変動性 ) に対するモデリングについての基本原理を紹介するそしてこの理解をベースにして3つの事例を紹介してこれらに共通する側面と異なる部分そしてそれらの効果や得ることのできた教訓について論じる 1. 導入の背景似通った複数のソフトウェア集約型製品のコラボレーション開発は多くの組織にとって課題になっているなぜなら多くの場合体系的な再利用戦略は製品固有のバリエーションを共有資産から迅速に実装することの必要性とはそりが合わず結果的に共通資産は異なるチームごとで勝手に変更されメンテナンスや大規模な再利用は非常に困難になるそしてコピーによる資産の再利用はメンテナンス費用の増加を招くなぜなら修正を全ての異なるコピーに反映させなければならないためであるプロダクトラインエンジニアリングの考えを基にしたバリアント管理を通じた体系的な再利用はこれらの課題の解決を目指しているプロダクトラインエンジニアリングの鍵となる原理は既存の複数製品と将来の製品を視野にした再利用の全体的な見通しであるバリエーションバリアビリティは常に製品を特長付ける側面として捉えることができるいつか役に立つかもと機械的にバリアビリティを増やしていくやり方とは違ってちょうどぴったりのバリアビリティを与えるのがこの原理の考え方であるただ機械的にやっていたのでは非常に柔軟かつ複雑すぎるが故に再利用の困難な部品を生み出してしまうことになる市場志向の製品政策や体系的再利用にプロダクトラインエンジニアリングのコンセプトを用いることはチャンスでもありチャレンジでもあるプロダクトラインエンジニアリングは新たなユースケースに応じてインクリメントに改変される共有資産に強く依存するプロダクトラインエンジニアリングではビジネスの可能性と開発の複雑性の間 ( 例えばプロセス利害関係者間の意思疎通技術上の再利用アーキテクチャ実装などで ) やシステムの高い品質と生産性の向上の間で適切な妥協が必要になる他の再利用のコンセプトからプロダクトラインエンジニアリングを区別する中心的役割は取組みになくてはならない部分としてバリアビリティと製品インスタンスであるバリアントを系統だって管理することであるこれにより汎用的な資産を修正なしにそのまま使うという通常であ 2

59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例れば困難な再利用が可能になる新製品の要件には多くの場合以前の製品に対して追加または一部変更がある事前にこれら新しい要件を知ることやそれに気を配ることは殆ど不可能であるそれゆえ全てを満たす単一の標準部品は多くの場合実行可能な選択肢ではない図 59-2 Product Line

3 59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例れば困難な再利用が可能になる新製品の要件には多くの場合以前の製品に対して追加または一部変更がある事前にこれら新しい要件を知ることやそれに気を配ることは殆ど不可能であるそれゆえ全てを満たす単一の標準部品は多くの場合実行可能な選択肢ではない図 59-2 Product Line Engineering Overview (from ISO 26550:2015) 図 59-2 にプロダクトラインエンジニアリングの主な活動の概要を示す一般にプロダクトラインエンジニアリングにはウォータフォールのようなプロセスは無い一般には最初にビジネスゴールとマーケットセグメントが分析されてアーキテクチャを定義してからコンポーネントとサービスが開発されはするがしかし現実的には多くの作業がイテレーティブかつインクリメントに行われる例えばマーケットの需要は継続的に変化するしいくつかのアーキテクチャ上のコンセプトも新たな技術導入で変更されるプロダクトラインエンジニアリングの大切な資質の一つとして挙げられるのが多くのバリエーションはあらゆる種類の資産を横断することと継続的な進化の対象であることを前提にすることである複数の製品インスタンス ( バリアント ) を横断するプロダクトライン内の進化を扱うにはエンジニアリングの資産の一部としてバリアビリティとそのコンフィグレーションの体系的で効果的な表現が必要になるこの情報の表現には実践活用できる多くの手法があるその中で最も一般的なアプローチはフィーチャモデルを資産固有のバリエーションポイントと組合せて使用することである 3

4 2. フィーチャモデルとバリエーションポイントにおける変動性の説明事例紹介の前にフィーチャモデルを用いたプロダクトラインエンジニアリングの基本コンセプトと用語について解説するフィーチャモデルについて理解するためにその小さな例を紹介する以下の図 59-3 は自動車のある機能のフィーチャモデルである ( バリアント管理ツール (pure::variants 2 ) のフィーチャモデルの図 ) 図 59-3 A small model of a Car フィーチャモデルはプロダクトラインのプロパティを表現するフィーチャ ( 機能 ) 群で構成されるシステムのオプション機能 (User Driving Mode Selection) やそのオプションに対する複数の機能選択肢 (Comfort/Eco/Sportive Driving Mode) 製品インスタンスのテクニカルでオールタネイティブな選択肢 (Gasoline Engine, Electrical Engine, Diesel Engine からいずれかを選択 ) などだそしてフィーチャによっては構成のみの情報を提供する (Engine Type, Gear Box のような mandatory( 必須 ) の機能 ) であるこれらフィーチャは相互にグループ化されまたリンクされてバリアビリティは識別しやすいツリー構造で表現される図 59-3 ツリー構造では親から子へのラインで階層が表され各フィーチャ名の前に付くアイコンはバリアビリティのタイプを示す ( 図 59-3 内の Legend: を参照 ) Mandatory なフィーチャはその親が選択されると必然的に含まれる Alternative なフィーチャはその中でどれか一つだけである Or なフィーチャは一つ以上いくつでも選択可能であり Option の各フィーチャは単独に選択可能だフィーチャモデリングはフィーチャ間のより複雑な関係性の表現に対する追加のコンセプトを提供するこれについてはこの資料内で後述する 2 4

5 59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例 2.1. なぜフィーチャモデルのバリエーションの資産管理が必要なのか同じプロダクトラインからの異なる製品インスタンスを比較する場合ソースコードの資産やコンフィグレーションパラメータドキュメントモデル一連の資料など多くのエンジニアリング上の資産に大小の違いが存在する詳細を調査することでこれら違いの一部はプロダクトラインの進化に起因することがわかる複数の製品インスタンスは異なった時期に開発される ( 例えばバージョン管理上の異なったベースライン ) 現にベースライン間でドキュメントのアップデートや欠陥の修正が行われるこの手の違いはプロダクトラインエンジニアリングのコンセプトを導入していない開発においても起こり得るしかしながら一般に違いの多くは再利用資産がそれぞれの製品インスタンスの固有の要件を満たすように洗練されたポイントでドメインの資産を構成することに起因するこれらのポイントはコンフィグレーションパラメータとして識別できる箇所でアーキテクチャ上のエレメントとして使用できる一連のコンポーネント群から一つの実装部品を選択することができるこれら違いが生じるポイント ( あるいは場所 ) をバリエーションポイントと呼ぶこれは実質的に異なるバリエーションである単一のバリエーションポイントは一つ以上のバリエーションを組成するプロダクトライン内のバリエーションポイントはバリエーションの実現に様々な異なるアプローチを取ることができるそれはシステムモデルやソフトウェアキテクチャモデルにアノテションを用いて表現することやプログラミング言語のプリプロセッサ命令を用いることさらにファイルシステムの構成を使って表現することやテキストドキュメントなどへマニュアルで修正することへの指示などであるバリエーションポイントの依存性通常現実のプロダクトラインでは資産となるバリエーションポイントの量は相当多くなる単に二者択一な選択要件でそれがユーザ視点で単一のバリエーションポイントを表現するのに使用されるだけでもデザインコードテストドキュメント等にバリエーションが作られることになるこれら異なる資産内のバリエーションポイントは相互に関連することは明らかであるこれらの関連に加えて追加の相関も存在する例えば特定のサービス品質への要求を満たす場合にはある固有のコンポーネントのバリエーションが使用できないなどだバリエーションポイントと対応するバリエーションの量加えてそれらの関連によりソリューション ( 解決空間 ) の資産のバリアビリティが定義されるこのバリアビリティの複雑性は ( 多くの製品インスタンスを構成できる ) 多かれ少なかれ指数関数的に増加する( 新規のオプショナルなエレメントごとに構成可能なインスタンスが倍増する ) そして全ての構成可能なインスタンスのテストが不可能な状態に陥るまたコントロールすべき依存関係のためにバリエーションポイントの構成が非常 5

に複雑になるしかしながらバリエーションポイントのコンセプトは追加の複雑性を生むように見えるがそれは真実ではないバリエーションポイントはプロダクトライン内に既に存在するバリエーションを単一の形式で明らかにするだけであるもちろんプロダクトラインの資産のほうが再利用可能にするためのバリエーションがあるので単一製品開発の資産と比較すればより複雑となる

6 に複雑になるしかしながらバリエーションポイントのコンセプトは追加の複雑性を生むように見えるがそれは真実ではないバリエーションポイントはプロダクトライン内に既に存在するバリエーションを単一の形式で明らかにするだけであるもちろんプロダクトラインの資産のほうが再利用可能にするためのバリエーションがあるので単一製品開発の資産と比較すればより複雑となる効率的にドメイン資産内のテクニカルなバリエーションポイントの再利用を管理すること加えて通常大量に上るソリューション内のバリエーションポイントの複雑性が露呈しないように単純化されたビューが求められるそのようなビューは固有資産のバリエーションポイントを How の観点から What の観点で抽象化することで得ることができるこのような観点のシフトによって導かれる問題空間志向のバリエーションポイントは製品インスタンスの定義に使用する言語内で表現される多くの場合このビューはフィーチャモデルによって非常に効果的に提供される Feature Model Evaluation Variability Configuration Domain Asset Variation Points Derivation Product Instance (Application) 図 59-4 Basic Process of Feature-based Product Instantiation フィーチャモデルでの用例十分に用意されたフィーチャモデルベースのプロダクトラインではフィーチャモデル内の各フィーチャの選択によって作られたフィーチャリストによって製品インスタンスが定義されるその結果であるバリアビリティの構成は資産内のバリエーションポイントへのマップ情報と結合する ( フィーチャやフィーチャの組み合わせとシステムの各要件や設定部品との紐付け ) この段階でバリエーションポイントを構成 ( 依存排他関係等を加味して ) することで ( インクリメントに行われる ) 最終的に製品インスタンスを生成することができるこのプロセスの概要を以下図 59-4 に示すフィーチャモデルはバリアビリティを記述して管理するだけの手段では無くコンフィグレーシ 6

7 59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例ョンファイルあるいはドメインスペシフィック言語と組み合わせて使用される異なる観点から要約するとフィーチャモデルとフィーチャの選択はエンジニアリングライフサイクルにおいて利用可能なバリアビリティ ( フィーチャモデル ) とその活用 ( フィーチャの選択やバリアビリティの構成 ) といった新たな資産になるそして様々な側面から要求仕様や設計ドキュメント等と同様に管理されなければならない変更や進化を構成管理することや課題があれば変更管理にも紐付けなければならないフィーチャモデルはプロダクトラインの仕様の一部でありバリアビリティの構成は製品インスタンスの仕様の一部である 3. 事例実例は課題やコンセプト成果を説明する上で極めて重要である包括的であるがゆえに抽象的な概念の理解に役立つので総合的な事例を介してどのようにして各コンセプトが開発の課題の様々な側面に対応しまた相互に作用するかを理解することができるこの資料では工業用オートメーション車載システムのアプリケーションドメインから 3つの実践的な事例を紹介するこれらの複雑な事例を通じてコンセプトの拡張性や現実の問題への適応力も理解することができるこれらは今日の組込みシステムを象徴する以下の特徴を持つ高度に分散化された機能機能安全性リアルタイム要求ソフトウェア集約型システム : ソフトウェアが機能実装の主要な要素機械メカトロニクス電気電子などの各要素の組み合わせリアクティブ / コントロール動作各事例は複雑であり全ての詳細説明は適さないその代わりに以下に各事例の概要とバリアント管理の応用についての主な側面を紹介する 3.1. 事例 1: Danfoss Frequency Converter Product Line Danfoss 社は周波数コンバータと関連製品の主要メーカの一つである周波数コンバータは高出力モータ用の電子制御装置だそのアプリケーションは非常に広範でファクトリーオートメーション空調設備送水ポンプクレーン ( 起重機 ) などであり広範な電力範囲と電圧また多様なアプリケーションに固有な構成のモータに活用される Danfoss 社は 10 年以上前に従来の取組みでは問題が増加の一方であったことからプロダクトラインエンジニアリングの取組みへの移行を開始した当初の開発は同じコードと共通の制御ハードウエアをベースにしたものの異なる製品間でコードはバージョン管理システムの個別のブランチに分岐されてしまい同じ課題の修正が何回も必要になるといった結果に陥っていた [1] 7

3.1.1. プロダクトラインエンジニアリングへの移行製品開発の中でもソフトウェア開発は多くのバリエーションを抱えていたので効果的で質の高い再利用への需要は当初から明白であったオリジナルのソフトウェアから分岐したブランチがかなり多く存在していてかつ製品開発は中断させられない状態であったそのため異なる製品間でコードを

8 プロダクトラインエンジニアリングへの移行製品開発の中でもソフトウェア開発は多くのバリエーションを抱えていたので効果的で質の高い再利用への需要は当初から明白であったオリジナルのソフトウェアから分岐したブランチがかなり多く存在していてかつ製品開発は中断させられない状態であったそのため異なる製品間でコードをプロダクトラインの取組みで共有する再利用コード資産にどうやってマージするかということが課題となった全製品の (10 機種以上 ) 全ての既存コードをマージするのは現実的ではないので( 全部で数百万行のコード製品ごとで少なくとも数十万行 ) 移行を担当するチームは 60/40 のアプローチを取ることにした最初に2つの主力製品の約 60% のコードを再利用資産にマージするために小さなチームに2か月が与えられ次にマージされたコード資産を全製品が以前と同様に動作するように全製品のコード基盤に統合したこの 60% については主にバリエーションが少ない箇所やバリエーションが許容できそうな箇所などの知見を基に決定されたまた検討の上実現が見込まれる箇所も追加されたこの取り組みの詳細は [1] に紹介されている残りの 40% は各製品で独自のコードをキープするこの分割方式で結集した開発を迅速かつ比較的少ない労力で進めることができるといった恩恵を受けることができた残りのコードをマージするには数年要したが既にプロダクトラインエンジニアリングの恩恵を得ることができていた図 59-5 PL Development Process at Danfoss 8

9 59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例最終的にバリアビリティの管理にフィーチャモデルを活用することは当初から予定していたしかしこのプロダクトラインのフィーチャモデリングは製品コードの 80% がプロダクトライン資産ベースになるまで開始されることなく製品間のコードの違いを見出すために必要な多くのバリエーションが露呈することになった (600 にも上る C++ の #defines) それらの多くは単純にソースコードの派生でありそのまま進めることができるものもあれば削除することで製品の振舞いを変えてしまいかねない理由から維持すべきものもあったこれらの #defines から最初のフィーチャモデルを自動生成させて pure-systems 社のバリアント管理ツールである pure::variants [pv] で管理した pure::variants は異なる製品を組上げるソフトウェア資産に必要なコンフィギュレーション (make ファイルやヘッダーファイルなど ) を導出して開発ワークフローの中心的ツールとなっているフィーチャモデルの完全利用は製品の特有な部分 ( パラメータデータベースと呼ばれる ) をプロダクトラインへの取組みに統合した後に実施されたこのデータベースは各製品の一部分で製品のテクニカルな観点及び非常に重要なこととしてユーザ視点 ( 使用される用途固有の ) で調整するパラメータを持つそのためユーザの眼に触れるパラメータの選択肢は異なる製品間で多くの違いがありそれはコード内にも反映する pure::variants のプラットフォームはプロダクトラインに則したカスタムパラメータのデータベース管理ツールとして使用された当然ながらプロダクトラインエンジニアリングの導入で変わるのはツールやコードだけでない開発組織の変化も求められる安定していることよりよくテストされたソフトウェア新しい機能の採用と製品の修正を迅速化するといった需要を満たすために図 59-5 に示す標準的なプロダクトラインのリリースプロセスを採用したこのプロセスは非常に上手くいったサイクルタイムは変動するが通常数週間程度このプロセスの詳細は [2],[3] に紹介されているソフトウェア資産にプロダクトラインの原理を採用した成果は要件など他の資産にも拡張されたバリアビリティ情報内の異なるレベルの詳細をカバーするために要件とコード間のバリアビリティのリンクを介した階層化されたフィーチャモデルを pure::variants 内で整備した図 59-6 にバリアビリティ管理において異なるレベルの成果物間のフィーチャの関係性およびその効果を図示するこの詳細は [3] で報告されている 9

図 59-6 Illustration of product engineering using the reusable assets: Portfolio-Requirements- Implementation 3.1.2.

数年先を見越した製品開発と保守ができる高度なコードの共有により新しいハードウエアプラットフォームへの置換えも実現できるようになったもちろん新しいハードウエアプラットフォームへの移管には多くの労力を伴うがその費用等は同じコードや要件を共有する複数の製品で分割できる

10 図 59-6 Illustration of product engineering using the reusable assets: Portfolio-Requirements- Implementation 適用の効果 Danfoss 社でプロダクトラインは大きな成果を得たその成果の一つにプロダクトラインの寿命が想定より長かったことが挙げられる継続的に新機能を統合して市場の需要に順応できるのでこのプロダクトラインからの製品は 15 年たっても強い競争力がある数年先を見越した製品開発と保守ができる高度なコードの共有により新しいハードウエアプラットフォームへの置換えも実現できるようになったもちろん新しいハードウエアプラットフォームへの移管には多くの労力を伴うがその費用等は同じコードや要件を共有する複数の製品で分割できるプロダクトライン手法への取り組みにより新機能を追加することで全製品の用途応用範囲を進化させることとサプライチェーンの変化に対応するために変更されるハードウエアの要求に対処することが同時に行えるようになったその他興味深い効果として製品の欠陥が減少したことがある共有されるコード資産内の欠陥は飛躍的に減少し殆どの欠陥は共有化への移管段階にある共有されない資産であった 10

11 59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例 3.2. 事例 2: Embedded Security Product Line 2つ目の事例はプロダクトラインエンジニアリングにおける興味深い課題を例証するプロダクトラインエンジニアリングの導入には様々な変化が求められるまた組織の体制やよりテクニカルな部分への新たな挑戦的課題ももたらすこの事例の課題はこれら両方の組み合わせでそれは組織の体制変更とテクニカルなプロダクトラインのインフラを築くといった比較的シンプルなコンセプトを用いることで難易度を下げることができる適用したプロダクトラインの概要この事例のプロダクトラインは組込みシステムのプラットフォームである各製品は基本的にマイクロコントローラや外部通信機能とそれに対応するソフトウェアパッケージでよりよく定義された標準化プラットフォームをベースにする顧客ごとで異なる需要には様々なマイクロコントローラや顧客ごとで解釈される特定スタンダード ( サブセット ) への対応といったプロダクトライン内のバリエーションが必要だこれにより標準化パーツにも僅かな変化をもたらすことに加えて顧客ごとで固有のソフトウェアが追加でバンドルされるプロダクトラインで同時に開発される製品はx10 種程度で開発チームに 100 人以上の開発者が関わる他の似通ったプロダクトラインとの違いからくる課題は最終製品を開発して出荷するだけでなく製品開発プロセスに顧客やサードパーティが直接関わることである一部の顧客は製品ソースコードを定期的に検査するシステムの一部は外部監査に提供されてコードの品質や安全性について検査されスタンダード準拠であることの認証を受けなければならない定期的な検査は数週間以内の間隔で行われる監査と認証は顧客によるレビューや現行の反復開発における内部レビューほど多くは実施されないただし失敗すると深刻な遅延と費用増大を招くことになる事例 2 の課題一製品を扱う場合はこれらの取組みに必要な資産は比較的容易に生成できていた基本的にソースコードはリポジトリからドキュメントとひとまとめにして引き渡されたプロダクトラインの取組みではこれが困難になったプロダクトラインのソフトウェア部品は様々な標準プログラミング言語 (Java C 複数のアセンブラ) で構成されるドキュメントは部分的にソースコードから Doxygen 3 を用いて生成され一部は Microsoft Office ツールや LaTeX 4 で人手によって記述されるこれらいずれの言語やツールも独自にプロダクトラインを意識しないしかしながらこれらに対してバリエーションポイントのコンセプトを用いてスーパーセットな扱いを実施することができる以下の表 59-1 で資産に用いられたバリエーションポイントのコンセプトの概要を示す 3 ソースコードドキュメンテーションツール : 4 テキストベースの組版処理システム / A document preparation system: 11

12 表 59-1 Variation point concepts of used languages 言語バリエーションポイントのコンセプト Java Java annotations C/C++ #if flogical expressiong #elif flogical expressiong #else #endif Assembler a51 #if flogical expressiong #elif flogical expressiong #else #endif Assembler arm $if flogical expressiong $elif flogical expressiong $else $endif IF flogical expressiong ELIF flogical expressiong ELSE ENDIF 製品レベルのバリエーションの静的な最小変位と結合は性能やメモリ制限などの特定のテクニカルな制約に対する根本的要素であり最終製品の結合負荷を軽減することを主眼にした仕掛けであるこれらのコンセプトは上手く働いて性能を満たしメモリ制限も維持されて再構成も容易でまたこれらツールや言語の標準的なアプローチをベースにしたためこれらの使用によって開発者が困るようなことはなかった異なるツールや言語内のバリエーションポイントの調整は pure::variants 内のフィーチャモデルとバリアントモデルに実現されてメンテナンスされたここまでは教科書どおりのプロダクトライン成功例であるある意味でプロダクトラインの標準的な成功事例に見えるでも実はそうでもない多くの資産が単一製品には使用されないバリエーションも含むので一製品のソースパッケージのサイズが増大した更なる進化とバリエーションでさらに多くの関係ないバリエーションが引き渡されるコードに含まれるこれは必要以上にソース資産が大きくなる上に製品構成のみに照らして評価しなければならないので検査や認証作業がより困難になるしかしこれらは成果物のソースなので作業を容易にするツールの支援あるいは単純に時間をかけるかのいずれかの選択になる ( しかし市場のスピードに遅れを取るわけにはいかない ) ただこれは大きな問題では無い厄介なのはバリエーションポイントからどのような機能が実装されているかわかるので IP( 知的財産 ) として保護されるべきパーツが含まれることになるがこのプロダクトラインは同 12

59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例一ビジネスで競合となる複数の顧客に供給されるので完全なコード全てをさらけ出すということが許されないビジネスの観点として個々の顧客にプロダクトラインの 150% 資産を配布することは認められない効率の良いコード ( 性能要件を満たさないとビジネスにならないので ) に着目したアプローチ (

13 59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例一ビジネスで競合となる複数の顧客に供給されるので完全なコード全てをさらけ出すということが許されないビジネスの観点として個々の顧客にプロダクトラインの 150% 資産を配布することは認められない効率の良いコード ( 性能要件を満たさないとビジネスにならないので ) に着目したアプローチ ( 静的な結合に標準的なコンセプトを使用する ) を選択する一方で 100% のソース資産を顧客や監査に提供する必要があることに問題が生じた要求されるパッケージの構成や処理を人手によって行われなければならなかった頻繁に生じる顧客とのやり取りとタイミング要求の組合せによるストレスやコスト増は深刻であった異なるアプローチに使用するために 150% ソース資産をリファクタリングすることに疑いの余地はなかった百万行に及ぶコード資産がありその多くがハンドコードされたものでリファクタリング対象とされてきた事実を踏まえたプロダクトラインの取組みを行わなくてもやれてきたがそれはビジネス上の目標を犯すことになっていた ( 開発コストが高騰していたので議論するまでもなくまた製品ごとの 100% 資産の為にもリファクタリングは必要であった ) それゆえテクニカルな解決策が求められた本質的に必要とされたのは製品の全てのタイプの資産 (C Java 2 種類のアセンブラ ) に対して 150% ソースから 100% ソースへの変換であった解決策プロダクトラインのバリアント固有の資産の生成は pure::variants で行われたそれは資産を選択してバリアント変換に固有製品バリアント以外の資産を除外することに使用されるこれはバリアント固有の構成をバリアントモデルに設定して 150% ソース資産内のバリエーションポイント情報と結合させる図 59-7 に pure::variants のバリアントデータ生成フローの概要を図示する図 59-7 Variant Generation Dataflow with pure::variants 13

14 解決策の一つは pure::variants で選択した製品バリアント固有に関連するファイルのみを使用することこれにより製品データの規模と製品に寄与しないファイルを飛躍的に削減したこれは選択されるファイル内に存在するバリエーションについては放置する仮のソースコード例 ( 選択されるファイル内に存在する ) でこの課題を説明する編集されなければコード片は存在するし目に触れるファイル内のこれらパーツは必ずしもオプションとは限らないと解釈できる必要なことはオリジナルのファイルをツールが入力として取り込んで 2つのバリエーションポイントの構成 (VP_SEC_PROTO13 と VP_CUSTOMER_X) によってバリエーションを解決するソースファイルを生成することであるまた一方 #ifdef SYS_WINDOWS は製品のバリエーションポイントではないので残る #ifdef VP_SEC_PROTO13 #ifdef VP_CUSTOMER_X /* customer specific protocol implementation, protected IP */ #else /* standard specific protocol implementation */ #ifdef SYS_WINDOWS #endif #endif #endif 図 59-8 仮のソースコード例 : 顧客ごとで異なるコード片が存在する標準の C プリプロセッサは全ての #defines を解決する出力の生成に使用できるしかしソースコードが結果として読めないので 100% ソースコード生成の選択肢にはならないただし C ソースコードを読んで解析することができる良い C 言語の構文解析ツールがあるそのような解析ツールを用いてバリエーションポイントに関連する #ifdef 等のみを解決することで 100% ソースコードを生成できるこのアイデアを基にして最終的なソリューションが pure::variants への拡張として多くの既存ブロックを踏まえて開発された図 59-9 でデータフローを図示する一つのソースファイル ( いずれのタイプでも ) が Variant Result Model (VRM)(= バリアント構成をモデル化したもの ) の情報を基にするセレクタに渡されるそして pure::variants の他の変換ステップによる処理のために単純にファイルをいつも通りの結果 (150% から 100% 変換への対象で無いデータ ) として受け渡すかあるいはブラインド化と称するプロセスに渡されるブラインド化はバリエーションポイントの抽出 (Analyzer) からなりその出力はバリエーションポイントを汎用バリアビリティ交換言語で記載するそしてソルバーがどのようにバリエーションポイントを有効にするかを決定してブラインダーに結果を伝達するブラインダーは基になるソースファイルから関連しない全てのバリエーションポイントを取り除く 2つの出力方式があ 14

59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例るひとつは使用されないバリエーションをブラインドテキストで置き換える ( それゆえブラインダーと称される ) もう一つはそれらをファイルから削除するブラインド化は行番号を維持できることなどから全製品バリアントで同期する利点がありまた内部の監査には十分と考えられている

15 59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例るひとつは使用されないバリエーションをブラインドテキストで置き換える ( それゆえブラインダーと称される ) もう一つはそれらをファイルから削除するブラインド化は行番号を維持できることなどから全製品バリアントで同期する利点がありまた内部の監査には十分と考えられているブラインドテキストの存在そのものが余計な情報源になるなら削除の手段を講じることができる図 % Source to 100% Source data flow in the pure::variants Source Transformation 上述のサンプルコードの場合ブラインド化と削除方式の出力結果の違いは以下のようになる (Configuration: VP_SEC_PROTO13 == true and VP_CUSTOMER_X == false) /* * Blinded */ /* standard specific protocol implementation */ #ifdef SYS_WINDOWS #endif /* standard specific protocol implementation */ #ifdef SYS_WINDOWS #endif 図ブラインド化 ( 左 ) と削除方式 ( 右 ) の違い 4 つの異なる言語 (C Java 2 種類のアセンブラ ) に対するこの方式の実装は pure::variants のフレームワークとオープンソースの構文解析ツールの十分な品質のお陰で多くの作業は必要なかったまたソースコードには余分なものがなく製品内容を正確に反映しているそのためこの変換を使用可能とすることで API ドキュメント生成ツールの Doxygen もまた一切の修正なしに使うことができる 15

16 結果と効果労力に見合った成果を得たか人手によるパッケージングは数百に上るファイルのマニュアル検査に何日も必要でありまた一部の IP が見過ごされてファイル内に残ることなど保証も取れない自動変換方式なら一貫した品質のパッケージの情報生成が数分で済むファイルの 2/3 がブラインド化の前に除外され ( 図参照 ) インクルードされるファイルの 10~15% 部分 ( 製品ごとでバリアント構成が異なる ) がブラインド化されるこの自動化で顧客からの要求に対してソースを提供できるまでの時間を飛躍的に改善することができたまたバリアントの進化もより良くサポートされるようになったソース資産内の製品に関わらない全ての変更はブラインド化できるので全製品に対して変更による影響から再検査や再認証が必要かどうかソースレベル上での判断が容易になった図 Selected/Blinded Lines of Code per Variant Comparison 3.3. 事例 3( 自動車システムの例 ): Exterior Lighting and Speed Control 3つ目は自動車システムの研究プロジェクト SPES-XT( 独 ) の事例を紹介する対象の車載システムは外装部品のアダプティブライティングシステムとスピードコントロールシステムの2 つからなるライティングシステムの主な機能は以下の通り方向指示灯 ( 方向指示とハザードライト点滅 ) ヘッドライト : ロービーム ( 昼間走行灯とコーナーライト ) 16

59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例ヘッドライト : ハイビーム ( 対向車が無い場合の自動動作機能 ) スピードコントロールシステムの主な機能は以下の通りクルーズコントロールとアダプティブクルーズコントロール車間警告ブレーキアシストとアシストブレーキ速度標識検出とスピード制限機能 Version 1 Version 2

17 59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例ヘッドライト : ハイビーム ( 対向車が無い場合の自動動作機能 ) スピードコントロールシステムの主な機能は以下の通りクルーズコントロールとアダプティブクルーズコントロール車間警告ブレーキアシストとアシストブレーキ速度標識検出とスピード制限機能 Version 1 Version 2 Version 3 Version 4 図 Evolution steps of the automotive system cluster Time 2つのシステムを用いた主な動機は機能間の何らかの相互作用を具体化することであるアダプティブクルーズコントロールによって決定される速度情報の影響を受ける自動ハイビーム機能相互作用の課題に加えて事例では主に進化についてフォーカスした一般的に新しいプロジェクト ( モデルチェンジや新モデル ) はスクラッチ開発では無く既存製品をベースにするので従って新しい機能は追加されるし既存機能は変更されるか削除される自動車の事例は連続する4バージョンの仕様について考察することでシステム進化の様相を示している顧客視点の各フィーチャに基づいてこれら異なるバージョンを図に示すこの事例およびそのような進化をサポートするための挑戦的課題は一貫したバリアント管理と再利用でありこれは全ての成果物 ( 要求仕様モデルコードテスト安全性ケース各種ドキ 17

18 ュメントなど ) が正しい順序で正しい手順で扱われることで一貫性が維持されることである課題に取組むために詳細なプロセス 56 を定義して進化の要求から変更が持ち上がった際に一貫した結果を得るために誰によっていつ遂行されるべきかを明確に記載したこのプロセスの定義には複数の開発の役割担当者を巻き込むなぜなら開発される製品の複雑さからその責任範囲が分割されてしまうからであるこのプロセス定義の抜粋 ( 図 59-13) に 3つの異なる役割が示されている Product Line Manager Perform Product Line Scoping --> Define Variability for Product Line Functional Requirements aligned Check and Release Requirements Functional Requirements accepted Approv e Functional Extension Approved Product Manager Describe and Deposit Functional Extension for Variant Functional Co Requirement Described Requirements Engineer Define Requirements Requirements specified 図 Consistent Variant Management throughout the development process 一般に変更要求が開始点になる ( 例えばブレーキアシスタント機能の追加 : 図内の Bremsassistent) 要求はその関連性を吟味して固有のバリアントのみかプロダクトラインに実現させるのかを決定するためにプロダクトラインの責任者に伝達されるそして決定内容に応じてプロダクトラインのバリアビリティモデル ( フィーチャモデル ) をそれに順応させるかあるいは変更しないその後要求は要求仕様の担当者に通達され要求仕様に追加修正削除等を行いまたそれに属するバリアビリティモデル ( ファミリーモデル ) を更新するそしてその他の開発段階 ( モデリング実装テストアプリケーションなど ) もバリアビリティモデルを必須の作業として取り入れて実施するプロセスの定義に加えて pure::variants Doors Matlab/Simulink Jira を用いたビルド環境でその有効性を評価したこの中で Jira は変更管理ツールとして使用され課題のワークフローとしてプロセスを実施するのに役立った他のツールは Jira と連携するように拡張されてタス 5 プロセスの詳細は参考文献の [4][5][6] を参照してください 6 Due to space limitations, the process is not fully described in detail and just a brief overview is given here. To get a closer look and a deeper understanding the reader is referred to [4],[5] and [6]. 18

19 59 プロダクトラインエンジニアリングのバリアビリティ ( 変動性 ) とバリアント管理の海外事例クをフェッチして変更要求のステートを更新してワークフロー定義内の次のステップへの始動のきっかけとなるこの設備構成で上述した進化のシナリオで実エンジニアによって評価が開始された全てのプロセス上の役割や業界で採用される全てのツールを使用したわけではないが成果を確認できたプロセスやそれをサポートしたツールに対して大いに役立ったとエンジニアからポジティブな反響を得ることができた例えばプロセスの定義やツールによって支援されるワークフローを起因にした成果物上の間違いは無く独断的に開発された資産とバリアビリティモデルの一貫性は担保される 4. 考察事例からプロダクトラインエンジニアリングによってビジネスと技術面の両方に効果が得られるという結果が得られている共通するのは高品質になってレポートの課題が削減されたことによるメンテナンス作業の軽減新しい製品バリアント開発期間の飛躍的な加速コード量や製品開発のための資産を減少できたこと市場により多くの製品を投入できるようになったことなど事例ごとで改善の核となる部分に違いはあるが多くの共通点が相互に見受けられる 19

20 参考文献 [1] Jepsen, H.P. and Dall, J.G. and Beuche, D Minimally Invasive Migration to Software Product Lines. In Proceedings of the 11th International Software Product Line Conference (SPLC '07). IEEE Computer Society, Washington, DC, USA, [2] Jepsen, H.P. and Dall, J.G. and Beuche, D Running a software product line: standing still is going backwards. In Proceedings of the 13th International Software Product Line Conference (SPLC '09). Carnegie Mellon University, Pittsburgh, PA, USA, [3] Krzysztof Sierszecki, Michaela Steffens, Helene H. Hojrup, Juha Savolainen, Danilo Beuche: Extending variability management to the next level. SPLC 2014: [4] Methodik für ein durchgängiges Variantenmanagement und Wiederverwendung im Engineering von Embedded Systems, André Heuer, Tobias Kaufmann, Thorsten Weyer, Michael Käßmeier, Peter M. Kruse, Michael Himsolt, Christian Manz, Martin Große-Rhode, Sebastian Schröck, Michael Schulze, SPES-XT project result, 2015 [5] Advanced Model-Based Engineering of Embedded Systems, Klaus Pohl, Heinrich Daembkes, Harald Hönninger, Manfred Broy, Springer, 2016 [6] SPES_XT Abschlussveranstaltung /EC5: Durchgängiges Variantenmanagement und Wiederverwendung 英語訳付き掲載されている会社名製品名などは各社の登録商標または商標です独立行政法人情報処理推進機構技術本部ソフトウェア高信頼化センター (IPA/SEC) 20

どのような便益があり得るか? より重要な ( ハイリスクの ) プロセス及びそれらのアウトプットに焦点が当たる相互に依存するプロセスについての理解定義及び統合が改善されるプロセス及びマネジメントシステム全体の計画策定実施確認及び改善の体系的なマネジメント資源の有効利用及び説明責任の強化

どのような便益があり得るか? より重要な ( ハイリスクの ) プロセス及びそれらのアウトプットに焦点が当たる相互に依存するプロセスについての理解定義及び統合が改善されるプロセス及びマネジメントシステム全体の計画策定実施確認及び改善の体系的なマネジメント資源の有効利用及び説明責任の強化 ISO 9001:2015 におけるプロセスアプローチこの文書の目的 : この文書の目的は ISO 9001:2015 におけるプロセスアプローチについて説明することであるプロセスアプローチは業種形態規模又は複雑さに関わらずあらゆる組織及びマネジメントシステムに適用することができるプロセスアプローチとは何か? 全ての組織が目標達成のためにプロセスを用いているプロセスとは : インプットを使用して意図した結果を生み出す