（この記事は、開発元Parasoft社 Blog 「A practical guide to make your legacy codebase MISRA C 2012 compliant」2018年4月17日の翻訳記事です。）
実際問題として、レガシーコードが再利用されるのはよくあることですが、安全性が重要なソフトウェアプロジェクトでレガシーコードを再利用しながらMISRA C 2012に完全に準拠するのは難題です。
本来のMISRAの原則は、開発中のコードに対して適用することを意図して制定されました。MISRAの文書自体にも次のような警告があります：
「 …サイクルの後半でMISRA C準拠をチェックすると、再コーディング、再レビュー、再テストにかなりの時間がかかる可能性があります。したがって、ソフトウェア開発プロセスでは、MISRA Cの原則を早期に適用する必要があります。」
多くの組織では、ビジネス上の理由からレガシーコードを再利用する必要があるため、この課題に対応するMISRA Compliance: 2016ガイダンス文書が作成されました。このガイダンスでは、現在のプロジェクトで開発された新しいネイティブコードと、プロジェクトの外で開発され「受け入れられた」コードを明確に区別しています。この記事では、レガシーコードとMISRA C準拠の問題に対処するための実践的なアプローチについて説明します。
さまざまな段階のグレー
扱っているコードがネイティブか受け入れたものかは簡単に判断できるはずだと思われるかもしれませんが、多くの場合、状況は単純な白か黒かではありません。たとえば、MISRAのガイドラインに従わずに開発された初期のプロトタイプが製品化され、後にターゲットとなる市場ではコンプライアンスが必須だと経営陣が認識したとします。レガシーコードは、コーディングガイドラインをいっさい念頭に置かずに開発されているのが普通です。したがって、新しいプロジェクトで更新が必要になった場合、コードを自動的に「受け入れられたコード」に分類することはできません。これは複雑になる可能性があります。
非常によくある話ですが、静的解析ツールですべてのMISRA C 2012ルール（改正1を含む）を有効にして、大規模なコードをスキャンすると、初回で何千、何万もの違反が検出されることがあります。初めは呆然としますが、その後、チームは違反に対処する「建設的な」方法を見つけようとします。そこで開発チームが挫けないことが重要です――トンネルの終わりにはかならず光があります。
私はこれまでの経験から、進行中の開発を遅らせることなくコードをMISRAに準拠させるために開発チームがどのようなベストプラクティスとアプローチを採用したか、さまざまな例を収集し、パターンを見出しました。この記事では、既存のコードをMISRAに準拠させるための、実用的でバランスのとれたアプローチをいくつか紹介します。
MISRA Compliance:2016フレームワークを使用する
MISRA C 2012は、Cプログラミング言語向けコーディングガイドラインのセットです。この規格の焦点は、プログラマがC言語の既知の問題パターンを避けることによって、実行時の故障（およびそれに伴う潜在的な安全性の懸念）につながるようなコーディングミスを予防し、ソフトウェアの安全性を向上させることです。長年にわたって（そして現在も）、組み込みシステムの開発者の多くが、MISRA Cは規格としてあまりにも厳しく、完全に準拠したコードを書くコストを正当化するのが難しいと訴えてきました。現実的には、MISRA Cは安全性が重要なソフトウェアに適用されるという前提から考えると、プロジェクトに規格を適用することの価値は以下のような要因によって決まります。
- ソフトウェアの故障によるシステムの誤動作のリスク
- システムの故障がビジネスに与えるコスト
- 開発ツールとターゲットプラットフォーム
- 開発者の専門知識のレベル
したがってプログラマは、付加価値のない活動に労力を費やすことなく規格の根本的な要求を満たし、MISRAを順守していると主張できるような、実用的な中間地点を見つけなければなりません。
MISRAコンソーシアムはコミュニティの要望に応え、MISRA Compliance: 2016の中で、「MISRA準拠」という言葉が何を意味するかを合理的に整理して定義するフレームワークを提供しました。この文書は、以下の成果物を定義しており、組織が共通の言語を使用してコンプライアンス要件を明確にできるよう支援します。
- ガイドライン施行計画書 – 各MISRAガイドラインがどのように検証されているかを示します。
- ガイドラインの再分類計画書 – ベンダー/顧客関係の一環として、ガイドラインの各ルールの合意された重大度を伝達します。
- 逸脱報告書 – ガイドラインの違反を適切な根拠とともに文書化します。
- ガイドライン準拠サマリー – プロジェクトコンプライアンス全体の主要な記録です。
レガシーコードをどう扱うかに関して重要な文書はガイドラインの再分類計画書です。この文書はすべての指令とルールを挙げ、どのカテゴリが再分類されたのかを示します。たとえば、次の図は再分類計画書の一部を示しています。
まず、「受け入れられた」レガシーコードに関しては、 MISRA Compliance: 2016文書は、より緩い分類からより厳しい分類への再分類を避けるよう示唆しています。さらに、違反のタイプを検討した上で、推奨ルールをまとめて適用除外することも可能です。
逸脱を文書化するという要件は、必須ルールの場合にのみ要求されます。受け入れられたコードの違反はすべて見直されるべきであり、逸脱の文書化では、その違反が安全性とセキュリティを脅かさないことを明言する必要があります。再分類にかかわらず、システムの安全性やセキュリティを脅かす指摘事項がある場合は、その問題を修正する必要があります。また、レガシーコードを変更すると、開発者にはわかりにくい他の問題が入り込むおそれがあります。
終わりを見据えて開始する
安全上重要なソフトウェアの開発者が遭遇する大きな問題の1つは、プロジェクトの最後にどのようにコンプライアンスを実証して証明するかという点です。さまざまなステークホルダーの主観的意見に基づいてコンプライアンスが評価される場合、議論が紛糾し、時間と労力を無駄にする可能性があります。このような場合、 MISRA Compliance: 2016文書が解決に役立ちます。
コンプライアンスが完了したかどうかをよりスムーズに評価するための推奨アプローチは、最終的なコンプライアンスとツール認定レポートの両方に既存のテンプレートを使用することです。レポートに必要以上の情報が追加される傾向もありますが、規格で要求されていない情報をいたずらに追加するのは避けるべきです。余分な情報を追加することは時間の無駄であるばかりか、監査プロセスを遅らせる危険もあります。
最終報告書に含める必要がある情報は、 MISRA Compliance: 2016によって提示されています。
- ガイドライン施行計画書
- ガイドライン準拠サマリー
- 承認されたすべての逸脱許可の詳細
- 「必須」として再分類されたすべての違反をカバーする逸脱記録
下の例は、ParasoftツールのHTML形式レポートであり、適切なセクションへのリンクが付いています。
早期に最終目標を確立する
上記の推奨事項に加えて、ほかにも考慮すべき重要な点がいくつかあります。
- GRP（Guideline Re-Categorization Plan：ガイドライン再分類計画書）はプロジェクトの開始時に確定していますか？MISRA標準によれば、 アクワイアラーとの交渉が可能であるほか、プロジェクト期間中に変更されたコードであるネイティブコード用と、変更なしで使用される受け入れられたコード用に別個のGRPを作成することができます。
- インクリメンタルな変更のたびに、完全なコンプライアンスの達成までにあといくつの作業が残っているかを明確に把握できますか？これは、進捗に応じて作業を計画し、管理者に適切な期待を設定するのに役立ちます。
- プロジェクトの開始時にアクワイアラーと共同でGPS（Guidelines Compliance Summary:ガイドライン準拠サマリー）レポートのテンプレートをレビューし、その結果、テンプレートが妥当であり、漏れがないことを確認しましたか？
Parasoftを含む市販の静的解析ツールベンダーは、組織がMISRA Compliance: 2016フレームワークを満たすのを支援するためのテンプレートを提供しています。
段階的アプローチ：分割して統治せよ
初めて既存のコードを静的解析ツールでスキャンすると（特にデフォルトのルールセットを使用すると）、何千もの違反が発生することがありますが、これらの違反をすべて修正するのに力を注いで、新規開発作業を止めるのは現実的ではありません。実際、私は静的解析違反を修正するためにコードを大幅に変更し、手戻りが発生したというケースをいくつも見てきました。したがって、開発プロセスを中断させたり、ソフトウェアの品質を低下させることなく違反を修正するためのワークフローを確立することが重要です。
プロジェクトで静的解析ツールを初めて使用する場合の推奨事項を以下に示します。
- ベースライン化 －初回のコードスキャンの後、検出されたすべての違反を「後で対処する」とマークし、 ベースラインとして設定します。その時点から、既存のコードを更新したり、新しいコードを追加する際は、「新しい違反は許されない」というポリシーを維持してください。このポリシーは、コードレビュープロセスまたはJenkinsやBambooなどの継続的インテグレーション（CI）ツールによって強制できます。開発者に数時間または数日間の余裕があれば、ベースラインで検出された残りの違反を解決できるでしょう。組織は、現在開発中のコード、コードレビューの結果、またはメトリクス（例：複雑度）などに基づいて、アプローチに優先順位を付け、次に解決すべき違反を示すことができます。
- 境界線－ 「境界線」とする日付を設定します。この日以降に変更されたすべての翻訳単位（個々のソースファイル）は、すべての違反が対処されている必要があります。変更されていないすべての翻訳単位は自動的に、MISRAコンプライアンス文書が定義する、本当の意味での「受け入れられた」コードに分類されます。
- 重要度に基づく優先順位付け－開発者は、担当のモジュールのすべての必須指摘事項を修正します。長期的には、チームリーダーが選択した優先順位に基づいて、時間の許す限り、すべての必須ルール違反に対処します。
上記のいずれのアプローチの場合でも、テクニカルリードとマネージャーは、集中管理されたダッシュボードを使用して進捗状況とプロジェクト順守状況を常に監視することが重要です。たとえば、Parasoftのレポートハブには、以下の構成済みの順守状況ダッシュボードが用意されています。
ツール認定
MISRA準拠の比較的わかりにくい要素で、しばしばプロジェクトの終わりまで手つかずになるのが、製品で使用される開発ツールが意図された用途の認定（目的に合っていることの証明）を必要とするかの判断です。また、ツールの認定が必要な場合は、どのレベルの検証を実施する必要があるのでしょうか？
多くの場合、ツールの認定が必要ですが、認定の方法は、ツールの誤動作に関連するリスクやソフトウェアの重要度レベルによって異なります。Parasoftは、特定の安全規格とその要件に関する認定キットおよび認定を提供しています。このような効率的なキットがない場合、ユーザーは商用、無料、およびオープンソースのツールを評価する際に、ツールの認定コストを考慮する必要があります。
ISO 26262やDO-178B / Cのようないくつかの規格では、ツールの資格要件に関する合理的なガイダンスが提供されています。その方法にかかわらず、ツールの資格認定プロセスの目的は、「ツールは意図された用途に有効である」と明言し、チームがこの結論に至った証拠と理論的根拠を提供することです。
ツールの資格認定プロセスの推奨手順は次のとおりです。
- 使用目的に合わせてツールの要件を特定します。
- 製品のどの機能を使用するかを特定します。使用する機能だけに認定プロセスを適用します。
- 認定計画の概要を策定します。
- ツールが要件を満たしていることを検証する認定手順（チームが実施するテストを含む）の概要を決定します。
- 自動化できるテストケースを自動的に実行します。
- 手動テストステップの結果を入力するためのフレームワークを用意します。
- レポートテンプレートを使用して、開発者が入力する必要があるテキストの量を減らします。
- ステークホルダーと共同でレポートをレビューして終了します。
最初にツールの認定を見落とすと、サイクルの後半でプロジェクトに遅れが出ることがあります。
スタッフの能力とトレーニング
開発スタッフの専門知識とトレーニングは、見過ごされがちなもう1つの重要な要素であり、審査員が製品のコンプライアンスを評価する際に、第1の問題として指摘することがよくあります。
MISRAガイドラインによれば、 スタッフの能力はMISRA準拠の重要な部分です。ベストは、プロジェクトの初めにトレーニングを行い、トレーニングの日付とともに、トレーニングを受けたすべての開発者について、トレーニングを受けたというサインを記録しておくことです。そうすれば、プロジェクト終了時に、開発チームは次のことを証明できるでしょう。
- 逸脱を承認したスタッフは、違反に関連するリスクを理解しており、リスクを認識できるようトレーニングされている
- スタッフは、静的分析ツールおよび開発ツールを適切に設定して使用できるよう事前にトレーニングされている
実際には、経験豊富なチームであれば、トレーニングは比較的短期間で済みますが、プロジェクト開始時に数日を割いておけば、プロジェクトの締め切りが過ぎてから数週間もの手戻りが発生するのを防ぐことができます。
まとめ
安全性が重要なプロジェクトでレガシーコードのMISRA準拠を容易に達成することができるような特効薬はありません。しかし、 MISRA Compliance: 2016フレームワークを導入し、終着点を明確に思い描きながら着実に段階的なアプローチを採ることで、ソフトウェア開発チームは今の開発プロセスを大きく阻害することなく、コンプライアンスを達成できます。まとめれば、コンプライアンスを達成するためにはかなりの労力が必要ですが、インテリジェントな計画と適切なアプローチにより、バランスのとれた最小限のタスクのセットを確立し、レガシーコードと新規開発コードの両方について安心かつ安全を実現できます。
|
 MISRA Compliance:2016対応のレポートハブParasoft DTP |