ArchiMate を用いた品質基準の再利用性向上に関する提案
The proposal of improving reusability for quality criteria using ArchiMate
林 香織
1山田 ひかり
1小林 展英
1,2Kaori Hayashi
1, Hikari Yamada
1, and Nobuhide Kobayashi
1,21
株式会社デンソークリエイト
1DENSO CREATE Inc.
2
名古屋大学大学院情報科学研究科
2Graduate School of Information Science, Nagoya University
概要
本稿では，ArchiMate が提供する Motivation Extension を用いることで，品質確認時に熟練者が暗黙的に利用 している品質基準を再利用に適した形式で資産化する手法を提案する．また，開発現場の技術者が実際に作 成した品質基準の改善に本手法を適用し，記述内容の改善効果があることを確認した．
Abstract:
This paper proposes the method of visualizing implicit quality criteria and keep high reusability. Additionally, it also shows the effectiveness of our proposal based on the result of applying to improving quality criteria created by an actual automotive software engineer.
1. はじめに
車載システムの大規模，複雑化に伴い，開発者が知 っておくべき開発知識が膨大になってきている．ま た，開発期間の短縮も期待されており，開発チーム の要となる熟練者に時間的な余裕がなくなっている． こうした背景から，熟練者は暗黙的な知見を適切な 表現で形式化する方法を考えることが難しく，その 結果，熟練者の知見を開発チーム内の共通理解とし て継承することが困難となっている． 本稿では，熟練者が有する知見の中で，車載ソフト ウェアの品質判断に用いる品質基準を適切な形で可 視化する手法を提案する．さらに，本手法の有効性 を確認するために，車載ソフトウェア開発に携わっ ている技術者が作成した品質基準の見直しに適用し， 改善効果があることを確認した． 本章以降では，2 章で関連研究を述べ，3 章で提案 手法を説明する．4 章で本手法の有効性確認のため に行った実験内容を説明し，5 章でその結果を考察 する．最後に，6 章でまとめと今後の課題について 述べる．2. 関連研究
The Open Group が策定した ArchiMate[1]は，エンタ ープライズアーキテクチャを導入する際に必要とな る一連のビューを記述できるモデリング言語である． ビューとしては，ステークホルダが実現したいと考 えることを明文化する Motivation Extension，ビジネ ス レ ベ ル の ア ー キ テ ク チ ャ を 定 め た Business Architecture Layer などが用意されている．Motivation Extension は，表 2-1 に示す要素で構成されており， Stakeholder をレビューアとした場合，レビューアの 期待値に相当する品質基準は，Requirement，および Constraint に対応づけることができる． 表 2-1 Motivation Extension の要素 要素 内容 Stakeholder エンタープライズアーキテクチャの結果 に関心を持った個人，組織の役割 Driver 組織変革の動機となること Assessment Driver の分析結果 Goal Stakeholder が到達したい最終状態 Requirement システムによって実現されるべきこと Constraint システムを実現する上で制限されること
このため，品質基準の構造に Motivation Extension を 採用すれば，記述品質を改善できる可能性がある． しかしながら，従来の研究では，車載ソフトウェア の品質基準に Motivation Extension を適用した際の有 効性について議論していない． 一方，システムには，必ず何かしらの参照となるモ デルが存在しており，熟練者が有する知見を整理す る際に有効活用できることが分かっている．例えば， 文献[2]では，ソフトウェアレビューの観点を導出す るために参照モデルを活用する方法を提案している． 参照モデルの具体的な事例としては，組込み分野の システムをモデル化した組込みシステム参照モデル が提案されている[3]．また，車載ソフトウェアの参 照モデルとしては，AUTOSAR においてマイコン周 辺やミドルウェア層の標準化が進められている[4]． その他，ソフトウェアの欠陥に関する参照モデルと して IBM の ODC (Orthogonal Defect Classification)[5]， IPA のバグ区分[6]が提案されており，それらを踏ま えたインスペクション手法も提案されている[7]．し かしながら，Motivation Extension との関連について は議論されていない． また，自然言語を用いた自由記述の品質安定化には， EARS[8]や ISO29148 で定められた記述テンプレート が提案されている．しかしながら，品質基準の視点 での利用については議論されていない． 次 章 以 降 で ， ArchiMate が 提 供 す る Motivation Extension と上述した参照モデルを統合した品質基 準の作成法について説明する．
3. 提案手法
本章では，本稿が提案する品質基準の作成手法につ いて説明する．はじめに，本手法の前提を述べる． 次に品質基準の整理に用いる参照モデルを説明し， その上で品質基準そのものの構造と記述内容のテン プレートについて説明する．最後に，それらを用い た品質基準の作成手順を説明する．3.1. 本手法の前提
本節では本手法の前提となる事項を説明する3.1.1. 前提 1
本手法を適用した品質基準は，車載システムを構成 する一つの ECU (Electronic Control Unit) に搭載され た車載ソフトウェアを対象とする．3.1.2. 前提 2
品質確認時に期待される品質基準は，以下の特性を 有しているものとする． (1) 車載ソフトウェア開発者が達成すべき要求，ある いは開発時に遵守すべき制約が定義されている． (2) (1)が必要とされる前提（背景，目的）が明らかに なっている． (3) (1)が関連する確認対象の範囲が特定されている．3.2. 車載システム参照モデル
品質基準の分類を定義するためには，レビュー対象 に共通する基本構造を定めた参照モデルが必要とな る．本稿では，関連研究で紹介した組込みシステム 参照モデル[3]を車載システム向けに拡張した車載 システム参照モデルを採用する（図 3-1 参照）． 一般的な車載システムは，車載通信を介して ECU と呼ばれるコンピュータが複数連携して一つの巨大 なシステムを構成している．このため，本稿で採用 する車載システム参照モデルは，組込みシステム参 照モデルに対して，他の ECU に搭載された他システ ムとの関係を追加している（図中左下の赤枠の部分）． 図 3-1 車載システム参照モデル3.3. 車載ソフトウェア参照モデル
AUTOSAR では，車載ソフトウェアの制御対象とな るセンサ，アクチュエータ，ユーザ I/F との接続方 式として，ADC (Analogue Digital Converter), DIO (Digital Input Output), PWM (Pulse Width Modulation), SPI (Serial Peripheral Interface)を定義している[9]．ま た，他システムとの接続方式として， CAN, LIN, Ethernet, FlexRay, TTCAN, SAEJ1939 といった通信規 格を定義している[10]．また，車載システムにおけ る制御装置は様々なモードを有しており，その参照 モデルとして ECU Main States が定義されている[11]． 本稿では，品質基準の分類に用いる車載システム参 照モデルの構成要素，およびその関係の属性として， 上述した AUTOSAR の定義を採用する．3.4. 品質基準の構造
図 3-2 に Motivation view に基づいた品質基準の構 造を示す．図中の左側が Motivation view の構造，図 中の右側がそれに対応づけた品質基準の構造を示し ている．Driver にはレビューアの責務である「確認 対 象 が 正 し く 制 御 さ れ て い る こ と を 確 認 」， Assessment には確認対象の前提条件として「確認対 象では制御できないこと」を対応づけている．また， Goal には「前提条件を踏まえて確認対象が達成すべ きゴール」，Requirement には「ゴール達成のために すべきこと」，Constraint には「ゴール達成のために すべきではないこと」を対応づける． 図 3-2 Motivation view の利用方法3.5. 品質基準の記述テンプレート
本節では，品質基準を記述する際に用いるテンプレ ートを定義する．本手法においては，品質基準の要 求を記述する際には表 3-1，制約を記述する際には 表 3-2 の記述テンプレートを利用する． 表 3-1 要求記述テンプレート ID. 記述テンプレート R-1 確認対象は，＜イベント＞前に＜振る舞い＞し ている R-2 確認対象は，＜イベント＞時に＜振る舞い＞し ている R-3 確認対象は，＜イベント＞後に＜振る舞い＞し ている R-4 確認対象は，＜状態＞においてのみ＜振る舞い ＞している R-5 確認対象は，＜条件＞を満足できる＜対象＞を 確保している 表 3-2 制約記述テンプレート ID. 記述テンプレート C-1 確認対象は，＜対象＞に対して＜イベント＞前 の＜振る舞い＞を禁止している C-2 確認対象は，＜対象＞に対して＜イベント＞時 の＜振る舞い＞を禁止している C-3 確認対象は，＜対象＞に対して＜イベント＞後 の＜振る舞い＞を禁止している C-4 確認対象は，＜対象＞に対して＜状態＞中の＜ 振る舞い＞を禁止している3.6. 品質基準の作成手順
本手法を用いた品質基準の作成手順を以下に示す． ① 品質基準を紐付ける確認対象を特定する。 ② 確認対象が合致する車載システム参照モデルの 構成要素、あるいはその関係を特定する。 ③ 車載システム参照モデルで定めた属性に①で特 定した要素を当てはめる。 ④ ③で具体化した分類に対し、品質基準の構造、お よび記述テンプレートに従って品質基準を作成 する。 ⑤ ④の結果から Assessment を前提，Requirement を 要求，Constraint を制約として品質基準の記述内 容に採用する． 上記手順に従い、ADC に関する品質基準を作成し た際の事例を図 6-1 に示す． なお，作成した品質基準，参照モデル，および確認 対象の関係を図 3-3 に示す． 図 3-3 品質基準の位置付け4. 提案手法の有効性確認
4.1. 実験手順
5 年間の車載ソフトウェア開発経験を持つ技術者を被験者として，自分自身の経験に基づいて 10 件の 品質基準を作成してもらい，3.1.2 節で示した前提 2 を期待値として，記述内容を評価した． さらに，本手法を適用して上述の品質基準を再定義 し，前提 2 を期待値とした比較を行った．
4.2. 実験結果
被験者が作成した 10 件の品質基準を 3.1.2 節の前提 2 を期待値として評価した結果を表 6-1 に示す．前 提と要求をセットで記述できている品質基準は 10 件中 1 件のみであり，8 件が前提のみ，1 件が要求の み，という結果であった（図 4-1）．一方，被験者が 作成した品質基準に本手法を適用して見直した結果 では，表 6-2 に示す通り，全ての品質基準が期待値 通りの内容で記述できていた． 図 4-1 適用前の品質基準分類5. 考察
以下では、提案手法の有効性、十分性、品質ならび に限界について述べる。5.1. 有効性
被験者が作成した 10 件の品質基準のうち 8 件が前 提のみに分類される記述内容であった．この結果か ら，従来の品質基準を品質確認を用いた場合，記述 された前提を踏まえて，要求，あるいは制約の内容 を開発者自身の経験に基づいて類推する必要があっ た．前提と要求を明確に区分した形式とすることで， 熟練者が品質基準を定義する際にどちらかが欠落す ることがなくなり，品質確認における、要求の欠落 に起因して発生する前提と要求の対応付けについて の技術者の経験に依存する類推の低減が期待できる．5.2. 品質基準記述テンプレートの十分性
被験者が自由記述した品質基準を，3.5 節で定めた記 述テンプレートのみを用いて再定義できることが確 認できた．すなわち，提案した記述テンプレートに よって従来の品質基準をすべて記述できたことにな る。このことから、提案した記述テンプレートは、 品質基準を作成する上で十分であることが明らかに なった．5.3. 品質基準の品質
記述テンプレートでは自由に文章を記述する必要が ないことから、要求，制約の記述品質に対する文章 作成能力への依存度を低減することが期待できる． さらに，参照モデルと組み合わせたことで，被験者 が作成した品質基準の以下の点を改善できた． 前提の単位を適正化 ・ID.B3 が車載システム参照モデルの 2 つの要素 （システム間 I/F と記憶装置）を跨いでいたため， ID.A7, A8 に分割．これにより、確認対象が明確 になった。 品質基準の対象範囲を具体化 ・ID.B9 は、対象ソフトウェアの視点で何に影響 するかが不明確であったが、ID.A3 に修正するこ とで、特定の接続方式が対象であることを具体化。 以上の改善により，品質基準の対象が明確になるた め，品質基準を再利用しやすくなることが期待でき る．5.4. 提案手法の限界
本手法の有効性は，実験対象とした 10 件の品質基 準のみを対象として確認されている．本手法の実用 性を高めるためには，実験対象の件数を増やすとと もに，様々な経験を有した被験者に対して実験を行 い，その有効性を確認していく必要がある．6. まとめと今後の課題
開発チームで利用されている品質基準は，技術者の 経験，能力に依存して定義されており，品質基準と して記述すべき内容の漏れ、記述粒度の不均一など， 開発チーム内の共通理解を妨げる欠陥が少なからず 含まれている可能性がある．本稿では，ArchiMate の Motivation Extension を品質 基準の構造に採用し，品質基準として記述すべき要 素が漏れなく定義できる手法を提案した．また，車 載システム向けの参照モデルと組み合わせることで， 確認対象に関連する品質基準の特定を支援している． 前提のみ 8件 要求のみ 1件 前提と要求 1件
さらに，品質基準の記述テンプレートを用意するこ とで，技術者の文章作成力への依存の低減を図って いる．なお，本手法の有効性は，車載ソフトウェア 開発技術者が作成した 10 件の品質基準の記述品質 を，品質確認時に期待する記述内容に均一化できた ことで確認している． 今後の課題としては，本手法を適用して作成した品 質基準の実用性を確認するために，不具合の欠陥検 出能力に関して，従来の品質基準との比較実験を行 う予定である．
謝辞
本研究を進める上で，貴重な助言を賜った名古屋大 学 情報学研究科 山本修一郎教授，森崎准教授に感 謝いたします．参考文献
[1] A. Josey, ArchiMate® 2.1-A Pocket Guide. Van Haren, 2013. [2] 元山 厚, 中谷 多哉子, “ソフトウェアレビュー の観点を導出するための メタモデル構築,” ソ フトウェアエンジニアリングシンポジウム, 2011. [3] 山本 修一郎, “参照モデルに対する保証ケース,” BUSINESS COMMUNICATION 2013年4月号, 株 式会社ビジネスコミュニケーション社.
[4] The AUTOSAR development partnership, Layered Software Architecture Release 4.2.2. 2015. [5] R. Chillarege, I. S. Bhandari, and J. K. Chaar,
“Orthogonal defect classification-a concept for in-process measurements,” IEEE Trans. Software Eng., vol. 18, no. 11, pp. 943–956, 1992.
[6] 独立行政法人 情報処理推進機構, “組込みソフ トウェア開発における 品質向上の勧め [バグ 管理手法編],” pp. 1–87, Feb. 2013.
[7] Y. Chernak, “A statistical approach to the inspection checklist formal synthesis and improvement,” IEEE Trans. Software Eng., vol. 22, no. 12, pp. 866–874, 1996.
[8] A. Mavin and P. Wilkinson, “Big Ears (The Return of "Easy Approach to Requirements Engineering"),” 2010 IEEE 18th International Conference on Requirements Engineering (RE), 2016, pp. 277–282. [9] The AUTOSAR development partnership,
AUTOSAR Standards Classic Platform Release 4.3 Peripherals. 2016.
[10] The AUTOSAR development partnership, AUTOSAR Standards Classic Platform Release 4.3 Communication Stack. 2016.
[11] The AUTOSAR development partnership,
Specification of ECU State Manager with fixed state machine. 2016.
表 6-1 被験者が作成した品質基準 ID. 品質基準 B1. ポートの値が確定するまでの値を不定値として扱っているか B2. 意図しない悪影響が発生しないように，起動時に全てのポートに 対して機能を設定しているか B3. メッセージが受信できない場合を想定しているか B4. メッセージの化けを想定しているか B5. バス負荷が高くなるとメッセージが送信できないため，メッセー ジの送信タイミングをずらしたりする B6. マイコンのモード遷移には時間がかかる B7. RAM 化けする B8. シャットダウン前に全ての機能を停止しているか B9. スイッチはチャタリングする B10. センサ値の取得可能時間を考慮しているか 表 6-2 本手法を適用した結果（一部抜粋） ID. 確認 対象 属性 前提 種別 品質基準* 適用前 ID. A1. ポート ADC DIO 出力値の確定に時間を要 する 要求 確認対象は，出力値が確定した状態において 出力値を利用している(R-4) B1 A2. 機能未設定時の動作が保 証されない 要求 確認対象は，初期化完了時に全てのポートに 対して機能を設定している(R-2) B2 A3. 出力値がチャタリングす る 要求 確認対象は，出力値の確定前になまし処理を 実施している(R-1) B9 A4. ADC 設定レジスタの値が化け る可能性がある 要求 確認対象は，A/D 変換の開始直前に設定レジ スタの値をリフレッシュしている(R-1) B7 A5. 制約 確認対象は，A/D 変換実行中のリフレッシュ を禁止している(C-4) B7 A6. DIO 設定レジスタの値が化け る可能性がある 要求 確認対象は，初期化完了後に設定レジスタを 一定時間毎にリフレッシュしている(R-3) B7 A7. 通信 共通 メッセージの値が化ける 可能性がある 要求 確認対象は，メッセージ受信時に値の化けを 判定している(R-2) B4 A8. メッセージが届かない可 能性がある 要求 確認対象は，メッセージ受信監視のタイムア ウト発生時に未受信を判定している(R-2) B3 A9. メッセージが格納できな い可能性がある 要求 確認対象は，受信したメッセージを期待通り に格納できる領域を確保している(R-5) B3 A10. センサ 共通 センサ値の取得可能時間 が限られている 要求 確認対象は，取得可能時間終了前に値を取得 している(R-1) B10 *括弧内は記述テンプレートの ID に対応している．
