プロダクトライン開発におけるソフト品質の確認方法の提案
宇都宮
浩之, 山本 修一郎
名古屋大学
愛知県名古屋市千種区不老町
Proposal of confirming software quality in product line development
Hiroyuki Utsunomiya and Shuichiro Yamamoto
Nagoya University
Furo-cho Chikusa-ku, Nagoya Aichi Japan
概要
ソフトウェアプロダクトライン開発において，製品間の可変性を示すフィーチャモデルが利用される． 本稿では，フィーチャモデルのから保証ケースに変換する手法を用い，保証ケースから各製品の品質を確認する 手順を紹介する．
Abstract
In software product line development, a feature model showing variability between products is used. In this paper, we introduce a procedure for confirming the quality of each product from the assurance case, using a method of converting from a feature model to the assurance case.
1. はじめに
近年のソフトウェアシステムは，IoT（もののインター ネット）デバイスのように様々なデバイスと繋がって協調 動作する．このような環境では，ターゲットシステムを静 的に保証する境界を定めることはとても難しくなる． 一方，車業界においても，様々な車両に対応するために 少しずつ特徴の異なる多数の製品を短期間で開発するよ うになってきている．複数の製品群を対象としたSPL の 導入も検討されているが，その保証方法は各々の製品（バ リアント）に対して全テストで保証することが多くなって いる．このようなやり方では，テスト段階で不具合が発見 されて大きな手戻りを発生させ，納期の達成も難しくなる． 本稿では，SPL 開発手法において実際のソフトウェア コードを記述する前段階となる，フィーチャモデルを使っ て出来上がり製品の品質を確認する手法を提案する．2. 関連技法
2.1.
ソフトウェアプロダクトライン 複数のソフトウェアプロダクトで共通に利用できる機 能を，予め資産化して再利用する技術にソフトウェアプロ ダクトライン[1]がある．ソフトウェアプロダクトライン のモデルを記述する代表的な手法として，フィーチャモデ ル[2,3]がある．フィーチャモデルでは AND/OR ノードか らなるフィーチャ ツリーを用いて，システムの機能特性 の構成を定義することにより，システムの共通性と差異を 識別することができる．特定の市場領域もしくはミッショ ンについての指定されたニーズを満足するように，コア資 産として事前に開発された共通管理機能集合（Common Managed Features）を共有するソフトウェアシステムの 集合が，ソフトウェアプロダクトライン（Software Product Line, SPL）である． プロダクトラインエンジニアリング[1]には２つのライ フサイクルプロセスがある．ドメイン開発（領域開発, Domain Engineering）ライフサイクルでは，コア資産と してのドメイン成果物を開発する．このコア資産がアプリ ケーション開発（適用工学，Application Engineering） ライフサイクルで，製品（Product）としての新規システ ム構築のために再利用される． ドメイン固有再利用成果物がコア資産である．コア資産 の要素として，再利用要求，再利用設計，再利用コード， 再利用可能試験項目がある． アプリケーション開発で作成されたプロダクトは，反復 的な発展過程で，プロダクト情報としてフィードバックさ れ，ドメイン分析と製品分析で利用される．2.2. 保証ケース
保証ケース（Assurance case）では GSN（Goal
Structuring Notation）に基づいて，システムの安全性や ディペンダビリティについての議論をゴール木で表現す ることにより，合意形成を支援できる[4-6]．安全性につい ての保証ケースが安全性ケース（Safety case）である． 保証ケースを記述する代表的な手法には，Kelly による GSN と，Bloomfield による CAE（Claim Argument Evidence）がある．GSN の主要なノードは Claim, Strategy, Context, Evidence である．CAE の主要なノー ドは，Claim, Argument, Evidence である．いずれも Claim をゴールとして段階的に分解することにより最終 的なEvidence に到達する階層的なゴール図である． GSN や CAE では，アーキテクチャの安全性やセキュ リティについての主張を定性的な議論によって確認でき る．
2.3. フィーチャモデルと保証ケース
フィーチャモデルの品質やフィーチャモデル自体の 安全性を論じるために，フィーチャモデルをGSN 表 記の保証ケースに変換する手法が提案されている[7]． 本稿では，プロダクトラインに含まれる各製品の品質の 妥当性を確認するために，フィーチャモデルを保証ケース に変換し，変換された保証ケースを用いて各製品の品質を 確認する手法を提案する．3. 研究課題
3.1. 上流工程で製品品質を見通せること
テスト工程，あるいはソフトウェアコードの作成工程で の品質確保は難しく，設計段階で品質を見通すことは行わ れている．しかし，さらに上流の仕様を定義する段階や製 品の企画段階で品質を見通すことが望ましい．3.2.
SPL 製品群に対し開発前に製品品質を見通
せること
SPL においては，個々の製品の共通部分と可変部分を 明らかにし，それらを見越した共通アーキテクチャを設計 することが肝要となる．共通アーキテクチャ，または共通 仕様の品質を確認することで，個々の製品の品質も確認で きれば生産性の向上に繋がると予想される．4.
提案手法
本稿では，以下のステップによってSPL に含まれる 個々の製品の品質を分析段階(＝フィーチャモデル作成 時)に見通す手法を提案する． 図 1 ：提案手法4.1. 製品群に対するフィーチャモデルの作成
ある製品群の特徴を整理し，フィーチャモデルを作成す る．4.2. 保証ケースへの変換
参考文献[7]に示される保証ケース作成規則，ならびに 作成手順に従ってフィーチャモデルを保証ケースに変換 する．4.3. ソフトウェア製品群の品質確認
製品群に対して確認すべき品質特性を保証ケースの前 提に付与し，保証ケース全体が品質特性を満たすように証 拠を揃える．4.4. ソフトウェア製品
(バリアント)の品質確認
可変点に製品ごとのパラメタを組み込み，バリアントモ デルを作成する(図 1：決定)．バリアントモデルを基に対 応する保証ケースを作成し(図 1：選択)，単一製品の品質 を再確認する(図 1：品質確認)．5. ケーススタディ
本稿では，車両に搭載されるメータパネルの品質確認を事例として取り上げる．車両に搭載されるメータパネルの
うち3 製品を選択し，それぞれの特徴を整理した結果を表
1 に示す．これをもとに，4 章のステップに従って製品の 品質を確かめる．
表 1 ：メータパネル製品群
Element Meter panel product group
Meter A Meter B Meter C
Speedometer analog analog digital
Tachometer analog none Digital
Water temp.
gauge analog analog Digital
Fuel gauge analog analog Indicator only Odometer
display digital digital digital Odometer switching digital Type-1 digital Type-2 digital Type-1 High beam
indicator present present present Winker
Indicator present present present
Element Meter panel product group
Meter A Meter B Meter C
Shift range indication
"PRINDL"
indicator none digital
5.1. 製品群に対するフィーチャモデルの作成
表 1 に示すメータ製品群に対し，フィーチャモデルを 作成する．表 1 のうち，全ての製品で同じ特徴を示すも のは省略している．(図 2)5.2. 保証ケースへの変換
図 2 に示すフィーチャモデルに対して，参考文献[7]に 示される保証ケース作成規則，ならびに作成手順に従って フィーチャモデルを保証ケースに変換する． 変換した保証ケースを図 3 に示す．5.3. ソフトウェア製品群の品質確認
今回は品質特性に「全てのテストに合格していること」 を選択し，末端のサブゴールに対して品質特性を満たす証 拠を紐付けた．(図 4) 製品群の品質特性「全てのテストに合格していること (C1)」に対して，それを満たす証拠が揃っているため，製 品群は品質特性を満たしていると言える． 図 2 ：メータ製品のフィーチャモデル図 3 ：フィーチャモデルから変換した保証ケース 図 4：品質特性を満たすことが証拠を用いて確認された保証ケース
5.4. ソフトウェア製品
(バリアント)の品質確認
可変点に製品ごとのパラメタを組み込み，バリアントモ デルを作成する(図 5)．図 4 に示す保証ケースを図 5 の バリアントモデルに合わせて必要なノードのみ残して他 を削除する．(図 6) メータA に対応する保証ケースが作成され，かつ，品 質特性を満たす証拠が揃っていることから，メータA が 品質特性を満たしているということができる．図 5 ：メータA のバリアントモデル 図 6 ：メータA の保証ケース
6. 議論
6.1. 有効性
上流工程で製品品質を見通せるか ケーススタディにおいて，フィーチャモデルを入力に可変 要素全てにおいて品質特性を満たすことが確認できている． フィーチャモデルは，ソフトウェアプロダクトライン開発の 初期フェーズで作成されるものであるため，これは即ち上流 工程で品質を見通せることに他ならない． SPL 製品群に対し開発前に製品品質を見通せるか ケーススタディにおいて，バリアントモデルを入力に各メ ータ製品が品質特性を満たすことが確認できている．フィー チャモデルは，ソフトウェアプロダクトライン開発の初期フ ェーズで作成されるものであり，個別製品の製品品質を開発 着手前に見通せる可能性がある．6.2. 新規性
複数の製品群の開発に対してプロダクトライン手法を導 入する際の手順や注意点を紹介した事例は展開されているが，多くの場合は全てのソフトウェア部品を開発して組み合 わせた後にテストで品質を確認する手段を取っている[23,24]． しかし，本提案手法のように品質確認のためにフィーチャモ デルと保証ケースを組み合わせた事例は報告されていない．
6.3. 課題
分析段階で準備できる証拠について整理する必要がある． テスト報告書などを証拠として必要とする場合，提案手法の 要点となる上流工程で品質を見通すことができなくなる．分 析段階で準備できる証拠を整理，分類し，どのレベルまで品 質を確認できるのか定量的に計測する必要がある．6.4. 提案手法の限界
提案手法においては，製品間で可変しない機能に関して通 常のソフトウェア設計，ならびにソフトウェアテストで品質 が保証される前提としている．また，可変性間の関連はなく， 各々独立であることを前提としている．7. 結論
複数の製品群を対象としたソフトウェアプロダクトラ イン開発を実行する際に，本稿で述べた手法を用いること で各製品間の特徴を分析する段階で各製品の品質を見通 すことができる可能性がある．その結果，従来のようにテ スト段階で不具合が発見されて大きな手戻りを発生させ， 納期遅延に至るといった事故を防ぐことができる可能性 もあると考えられる． 謝辞 保証ケースに関して多くの助言をいただいたDEOS 協 会の方々，ならびに名古屋大学山本研究室のメンバに感謝 いたします．参考文献
[1] Paul Clements and Linda Northrop, Software Product Lines- Practice and Patterns, Addison-Wesley, 2002 [2] Michael Schulze, Jan Mauersberger, Danilo Beuche,
Functional safety and variability: can it be brought together , SPL Conf., pp.236-243, 2013
[3] Kang., K., Cohen, S., Hess, J., Novak, W., Peteson, A., Feature-Oriented Domain Analysis(FODA) feasibility study, technical report CMU/SEI-90-TR-21, SEI Carnegie Mellon University, 1990
[4] Kelly, T. P, A Six-Step Method for the Development of Goal Structures, York Software Engineering, 1997 [5] Kelly, T., “Arguing Safety, a Systematic Approach to
Managing Safety Cases”. PhD Thesis, Department of Computer Science, University of York, 1998
[6] Shuichiro Yamamoto, Yutaka Matsuno, and Toshinori Takai，Introduction to D-Case - Let's write a dependability case!, DAITEC Holding Co., Ltd., 2012 ， ISBN 978-4-86293-079-8
[7] Hiroyuki Utsunomiya and Shuichiro Yamamoto, Proposal of GSN creation method for feature model, KBSE Conference, IEICE-KBSE2016-34, vol.116, no.418, pp.19-24, 2016(in Japanese)
[8] Hiroyuki Utsunomiya, Nobuhide Kobayashi, and Shuichiro Yamamoto, A Safety Knowledge Representation of the Automatic Driving System, Procedia Computer Science Vol.96, 2016
[9] Habli, I., “Model-based assurance of safety-critical product lines,” Ph.D. Dissertation, Department of Computer Science, University of York, 2009
[10] Habli, I., and Kelly, T., A Safety Case Approach to Assuring Configurable Architectures of Safety-Critical Product Lines, 2010
[11] Shuichiro Yamamoto，Research assignment of assurance case for software product line, KBSE Conference, IEICE-KBSE2015-8, vol.115, no.54, pp.39-44, 2015 [12] M.Tokoro, Dependable Operating Systems for Embedded
Systems Aiming at Practical Applications, 2010 Japan Science and Technology Agency, 2010
[13] GSN contributors. GSN community standard version 1.0, http://www.goalstructuringnotation.info, 2011
[14] Y.Matsuno and S.Yamamoto, A Framework for Dependability Consensus Building and In-OperationAssurance, Journal of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications (JoWUA), vol.4, no.1, pp.118-134, 2013 [15] V.Patua, S.Yamamoto, How to develop Security Case by
combining real life security experiences (evidence) with D-Case, 17th International Conference in Knowledge Based and Intelligent Information and Engineering Systems-KES2013, 2013
[16] M.Matsumura, S.Morisaki, N.Astumi, S.Yamamoto, A Comparative capability analysis on the context description methods for CDM, KBSE Conference, IEICE-KBSE2014-30, IEICE-114, no.292, pp. 13-18, 2014(in Japanese)
[17] S,Yamamoto, A knowledge integration approach of safety-critical software development and operation based on the method architecture, 18th International Conference on Knowledge-Based and Intelligent Information & Engineering Systems-KES2014, 2014
[18] F.Ding, S.Yamamoto, N.Abrahim, The Method of D-Case Development Using HAZOP Analysis on UML Models, Knowledge-Based Software Engineering Communications in Computer and Information Science Volume 466, pp.617-629, 2014
[19] Yutaka Matsuno and Shuichiro Yamamoto. An evaluation of argument patterns to reduce pitfalls of applying assurance case. In Assurance Cases for Software-Intensive Systems (ASSURE), 2013 1st International Workshop on, pages12-17. IEEE, 2013
[20] Nobuhide Kobayashi and Shuichiro Yamamoto. The Effectiveness of D-Case Application Knowledge on a Safety Process. Procedia Computer Science, 2015.
[21] Shuichiro Yamamoto, Shuji Morisaki, and Noritoshi Atsumi, A unied approach on assurance case development method based on models . In SIG-KSN, 2015.
[22] Shuichiro Yamamoto, Shuji Morisaki, and Noritoshi Atsumi, An approach on assurance case review based on the conguration information. In SIG-KSN, 2015.
[23] Kato, Denso's Model-Driven Development and Software Product Line Engineering, NIKKEI ERECTRONICS, 2012
[24] Natsuko Noda, Tomoji Kishi, Verification in software product line development, Computer Software 30(3), 2013
