MISRA compliance 2016とは

はじめに

MISRA compliance 2016を読む機会があったので、勉強のためまとめる。
あまり解説してる人とかが居なくて参考にするものが無かったので間違ってる箇所があるかもしれない。
＃詳しい人居たら指摘もらえると助かります。
それにしてもこのコンプライアンス文書自体はpdf公開されてるけど、肝心の規約(MISRA-Cとか)自体は買わないと見れなかったりするし、MISRAは普及させようとしているのだろうか…。

概要

MISRAのコーディング規約を運用するためのガイドライン。
要は、単にMISRA対応してるよ！というだけだと、チェックはしてるけど直さなかったり、チェックしてないものもの実はあったりで対応がバラバラになるので、それを統一したやり方でやることで、第三者に説明できるようにするためのもの。
(と理解した。)

要求されるもの

GEP(Guideline Enforcement Plan)：ガイドライン施工計画

対象となる各規約(MISRA C 2012等)について、どのように準拠していくか(解析ツール、コンパイラ、マニュアルレビュー等)をまとめたもの。
ツールを利用する場合は下記の情報を記載する必要がある。

ツールのバージョン
コンフィグ
実行オプション
ツールが規約への違反を摘出可能なことを示すエビデンス(ツールが公表してる情報とかかな？)

また、マニュアルレビューが必要な項目については、レビューの手順も記載する必要がある。

GRP(Guideline Re-categorization Plan)：ガイドライン再分類計画書

対象となる各規約について、Mandatory(必須)/Required(必要)/Advisory(推奨)/Disapplied(非適用)の各カテゴリに再分類した結果をまとめたもの。
Advisoryに限ってはDisappliedに再分類可能だが、他は全て厳しくする方向にしか再分類できない。

再分類前カテゴリ	再分類後カテゴリ
Mandatory	Mandatory
Required	Mandatory/Required
Advisory	Mandatory/Required/Advisory/Disapplied

Investigating Messages

規約への準拠をチェックする(ツールの実行など)過程で得られた情報。
以下のカテゴリに分類される。

正しく違反を検知したもの(Correct diagnosis of a violation) →直すべきもの。逸脱するする場合は逸脱報告書に記載する必要あり。
違反の可能性があるもの(Diagnosis of a possible violation) →良く確認して違反であればそれなりに処置し、違反でないならそれを示す必要あり。
誤って違反と検知されたもの(False diagnosis of a violation) →何故それが誤りかを示す必要あり。可能であればツール等の開発元の同意を得ること。(それは無理じゃね…？)
違反ではない本当の問題(Diagnosis of a genuine issue that is not a violation) ※これどういう事だろう？ツールで摘出されるけど、コーディング規約的には実はOKで、でも本当にバグってるもの？

Deviation Permits：逸脱許可

プロジェクトとして、逸脱可能なユースケースを事前に定義したもの。
Deviation Permitsを作成することより、Deviation Records(逸脱報告書)の作成を簡素化できたり、
開発者が個別にDeviation Recordsを作成することによる、品質のばらつきを抑止できる。
以下を記載する。

識別ID Deviation Permitsを一意に識別するID。例えば{プロジェクト名}{規約名}{ユースケース番号}_{リビジョン}とか
ユースケース例えば"xxxな書き方はやっちゃだめ"と言う規約に対して、"XXXの場合に限り、使用して良い"とか
逸脱を許容する背景逸脱するメリット(例えばリソースの効率が良いとか、メンテナンスし易いとか)と、デメリット(規約で縛っているからにはリスクがあるはず)をまとめる
逸脱する場合の要求事項デメリットに対する処置(リスクを低減・解消する施策)をまとめる

Deviation Records：逸脱報告書

規約違反をそのままに(逸脱)するためのもの。
以下を記載する。

違反している規約名
違反が許容される状況の説明後述する理由で、コードを修正出来ないことの説明
逸脱する理由逸脱の正当化を参照
コンテキストと問題の説明規約違反の内容と、それが発生している前後関係の説明
リスク評価手順と、守るべき注意事項の要求逸脱することで発生するリスクをどう低減・解消するかの説明

逸脱の正当化

逸脱する場合は、以下のいずれかの理由に該当しなければならない。

Code quality ISO/IEC 250101に規定されている以下の製品品質特性に影響が出る場合
- Function suitability
- Performance efficiency
- Compatibility
- Usability
- Reliability
- Security
- Maintainability
- Portability
Access to hardware コンパイラ固有の拡張機能など、標準の言語機能では提供されないローレベルのハード制御に関わる場合
Adopted code integration Adopted code(プロジェクトとして受け入れを許容している、開発スコープ外のコード)とのインタフェースに関わる場合
Non-compliant adopted code そもそもMISRA compliance 2016非準拠のAdopted codeに対する指摘の場合

GCS(Guideline Compliance Summary)：ガイドライン準拠要約

規約への対応状況をまとめたもの。
各規約に対して、以下のいずれかを記載する。

準拠(違反も逸脱も無い)
逸脱あり
違反(Advisoryはこれも認められる)
非適用(再分類の結果やらないとしたもの)