MISRA-C

質問

勤め先で、組み込みプログラムを作っています。
コーディング規約として、MISRA-Cを適用しようとしていますが、発行されたのが1998年と2004年で少し古く実情にあっているか、本当に品質向上に定量的な効果があるのか疑問があります。
一方で、自動プログラム生成なる技術が出てきており、その適用やMISRA-Cとの共存（文法上問題ないが、MISRA-Cにそぐわないプログラムが出る)などの課題があります。
みなさんは、これらについてどのように解決しているか、ご意見ください？
例：MISRA-Cは意味ない/手製プログラムには適用、自動プログラムには適用しない

http://8612.teacup.com/sprintergt/bbs?BD=5&CH=5

回答No.5

iriyak · ベストアンサー

背景情報の共有ありがとうございました。

(1)について

> もとになった状態遷移図等とCコードの振る舞いが一致するかをみる開発ツールもありますが、ACG自体に懐疑的でそこまで導入できず、製品開発には使えない状態です。顧客も含め懐疑的な人を説得するいい方法が無いか調べているところです。

確かにそのツールに依存してよいか議論は分かれるところです。

回答者は、こうしたツールは、製造工程において生産性を向上させるツールと捉えています。後続のソースコードレビュー、単体、結合、総合試験では、ツールがもとになっているソースコードかどうかを区別せず試験を実施し、品質を確保するアプローチをとりたいです。

つまり、生産性の向上と品質の確保は、独立した別の話として捉えています。もちろん、ツールが生成するものの品質水準の上に全体の品質確保のための戦略を練ることができますが。このようにツールの位置づけをとらえれば、懐疑的な人への一つのメッセージになるかもしれません。

(2)(3)について
> 実はMISRA-Cは少しずつ浸透していますが、自分がMISRA-Cによる改善効果を定量的な資料が欲しいと思って質問しました。
自動生成ソースコードも、MISRA-C準拠させることで品質保証になるのか、せっかく自動で作られたものに対して人が書きなおしてよいものなのか（個人的にはACGを使うのは人的ミスを排除する意味があると思っています）が、知りたいです。

回答者は、コーディング規約を違反する危ないコードが存在しないことの立証は、品質水準の一要素と考えています。

ですので、質問者の『MISRA-C準拠させることで品質保証になる』という表現が、もし『コーディング規約違反の除去によって品質が保証される』という意味ならば、ちょっと違和感を感じます。

というのは、ウォーターフォールの開発プロセスでは、製造工程において、規約違反していないコードをスタート地点に、ソースコードレビュー、単体試験、結合試験、総合試験と試験工程を進めながら最終的な品質水準に達するよう品質を作りこんでいくからです。

回答者は、原則として、ツールで生成されたソースコードの品質をコーディング規約違反が発見されなければ品質が保証されるはずだという仮定を置かない立場です。(1) のアプローチで全体として品質を作りこむべきだと考えています。

※ もちろん、例外はあります。どう生成されるかその生成手続きを回答者が完全に掌握しており、生成されるソースコードの正しさを推定できる場合のみです。

ところで、コーディング規約違反を除去しないで試験工程に渡ったものと除去されたもので試験工程に渡ったものとでは、後続の試験工程で発覚した不具合やバグなどの原因解析、対処、類似調査（同様の構造をした別の潜在バグの存在の調査）の進行に雲泥の差となる場合があったことを実際に経験しています。MISRA-C 導入による改善効果の具体例として定量的ではありませんがご紹介します。

お礼

ありがとうございます。

>コーディング規約を違反する危ないコードが存在しないことの立証
>は、品質水準の一要素と考えています。
まずは、従来どおりの品質確保手段をとってみようと思います。

回答No.4

iriyak

こんにちは。

質問者のお話をうかがっていて、三つの課題が見えてきました。

(1) 自動生成ツールを質問者の職場に普及させたいが、懐疑的とする意見がある
(2) MISRA-C を普及させいが、敬遠する意見がある
(3) 自動生成ツールを利用して作成したソースコードの品質保証をしたいが、どうアプローチすればよいのかが分らない

差し支えなければ、この三つの課題の背景をもう少しストーリ立ててこの場で共有していただくことは可能でしょうか。

背景内容によっては、もう少し具体的な処方箋を提供できる可能性があります。

というのは、(1) や (2) については説得したい相手がいてのことだと推察します。自動生成ツールも設計成果物からテンプレートを生成するものから、仕様（状態遷移図/表など）から手続きを生成するような類のものまであります。何を生成するのか？も示してくれれば、それに依存した品質の作りこみのアプローチが取れるかどうかも議論できるかもしれないと思ったからです。

補足

ありがとうございます。
(1)について
状態遷移図、ブロック線図、真理値表(ULMライク）から、Cコードを生成してくれます（ツールはACGともいう）。自動生成されたCコードを人手を加えずに取り込んで組み込みマイコンで動作できたのですが、初期の不効率なACGの印象が強い人は、小さな組み込みマイコンで実行＆実装可能か、ACGを使うことに起因するバグは出ないか、の意見があります。もとになった状態遷移図等とCコードの振る舞いが一致するかをみる開発ツールもありますが、ACG自体に懐疑的でそこまで導入できず、製品開発には使えない状態です。顧客も含め懐疑的な人を説得するいい方法が無いか調べているところです。
(2)(3)について
実はMISRA-Cは少しずつ浸透していますが、自分がMISRA-Cによる改善効果を定量的な資料が欲しいと思って質問しました。
自動生成ソースコードも、MISRA-C準拠させることで品質保証になるのか、せっかく自動で作られたものに対して人が書きなおしてよいものなのか（個人的にはACGを使うのは人的ミスを排除する意味があると思っています）が、知りたいです。
おそらく、組み込み開発の企業にとって、各社のノウハウになるのだと思いますが、よろしくお願いします。

回答No.3

R32C

自動生成ツールとMISRA-Cって、遠い関係のもののように思えてしまいます。
ずいぶん昔、UMLからCのソースがでるツールについてセミナー等受けたことが
ありましたが、それなりに効果があるのは分かるのですが、ある程度のソースの
手直しが必要で、さらにコード効率は２の次という感じでした。

>動作検証はするので、いいと思うのですが

組込みと一口に言っても幅が広いので、品質について、顧客や業界に明示する
必要がある場合に、どう説明するかという問題があったりします。
いわゆる品質ポリシーです。
そういった場合MISRA-Cの適用は説明のひとつの要素になり、その他テストカバレジや
あと、コードレビューの実施ルールがどうであるとか、バグ曲線がどうとか、あるかと思います。

品質ポリシーの説明が求められた場合に
「自動生成ツールででたものは動作検証をしているので大丈夫です。」
というと、それはそれでポリシーなのですが、受け入れられない場合もあるように
思います。

本来、自動生成ツールが出すソースが、MISRA-C対応であれば問題ない話だと思います。
あくまで、ソースを書き起こすためのひとつの手段であれば問題ないと思います。
MISRA－C対応したツールを使うか、対応されるまで待つか、対応するようメーカーに
要望するとかどうでしょうか。

>MISRA-Cを適用しようとしていますが、発行されたのが1998年と2004年で少し古く
>実情にあっているか、

それは問題ないです。　ルネサスコンパイラは、そんなに新しい仕様じゃないので
一度、Cのどの規格になっているか確認すれば分かると思います。

お礼

自動生成ツールから出てきたプログラムをどのように品質保証をするのか、というところでも悩んでいます。MISRA-Cでいくのか、そのほかのコーディングルールを適用するのか。
MISRA-C対応の自動生成ツールを使ったとして、それを何かの理由で人手で直してしまうと、その部分を保障しなければならないので、自動生成ツールを使うのに2度手間になってしまいます。
昔は、関数コールでぐちゃぐちゃだったプログラムも、今のとある自動生成ツールは入力したフローチャートと1対1で追えるぐらいになっていました。16bitマイコンでも走らせることができると確認もできました。
残りは、品質保証をどうするかです。確かに「動作確認しました」は最終手段だと思っています。やはりそうすると、現状ではMISRA-C（またはMISRA-C対応のツールを探す）しかないような気がしてきました。

※添付の掲示板にもお越しください。

回答No.2

iriyak

こんにちは。

回答者は、コンシューマ向けのあるサービス基盤の構築に C を採用したプロジェクトに携わったことがあります。開発機能はデータ加工やネットワーク通信を行うオープン系ではオーソドックスなものです。そこで、プロジェクトの開発チームは、品質を確保するために MISRA-C 規約に基づいてソースコードの検査を行うソフトウェアツールを採用しました。

開発チームの採用した規約は MISRA-C のサブセットでした。規約のほとんどは言われてみればその通りのものが多かった印象が回答者にはあります。ですが、製造工程で規約違反したコードが検出されました。規約の導入が危ないコードの除去に寄与してくれました。さらに、深堀調査で開発チーム特定メンバのコードに危ないコードが集中している傾向も確認できました。結果、潜在する不具合の除去に寄与してくれました。

MISRA-C の導入は有効だったか、と言えば有効だったケースだったと考えます。

お礼

ありがとうございます。
潜在する不具合を除去するのも効果だと思うのですが、なかなか納得してくれず、困っております。
静的ツールで客観的に判断するのはいいと思いました。

回答No.1

R32C

与えられた環境について、疑うことも悪いことではないと思います。
ちなみに自動生成ツールを使われているのですか？

補足

勤め先では、手元にあるので使っています。HEWと組み合わせたりとか。
自動でプログラムを生成しても、動作検証はするので、いいと思うのですが、まあ、懐疑的な人もいましてなかなか普及しません。
MISRA-Cも、昔のプログラムも修正すると、返って手間が増えるので敬遠されているというところです。
それなりの効果を定量的に示せればいいと思ったのですが・・・。