匿名 さんのコメント...※IEC61508-3: Functional safety of electrical/electronic/programmable electronic safety-related systems Part 3:Software requirements
IEC61508-3を調査するに当たり、貴兄のページに出会うことができました。
本当に助かります。
ちなみに、JasParさんが2013年5月下旬からテンプレート等を順次を配布することになったみたいです。
3月 06, 2013
JasParが公開する予定の文書とは下記のことだ。MONOist のこちらの記事『「現場で使える道具に仕上げた」、JasParがISO26262関連の成果を一般公開』に詳しく書いてある。
| 公開する文書 | 有償／無償 | 提供窓口 | 公開時期 |
| 解説書（ソフトウェア編） | 有償 | 日本規格協会 | 2013年6月以降 |
| 解説書（プロセス編） | 有償 | 日本規格協会 | 2013年6月以降 |
| 解説書（マイコン編） | 無償 | JasParのWebサイト | 2013年5月下旬 |
| チェックリスト（ソフトウェア編） | 解説書（ソフトウェア編）とセット | 日本規格協会 | 2013年6月以降 |
| チェックリスト（プロセス編） | 解説書（プロセス編）とセット | 日本規格協会 | 2013年6月以降 |
| 機能安全テンプレート | 無償 | JasParのWebサイト | 2013年5月下旬 |
| 記入ガイド | 無償 | JasParのWebサイト | 2013年5月下旬 |
【MONOist 記事より引用】
JasParは、2010～2012年度（2010年4月～2013年3月）の3年間、電動パワーステアリングなどの開発プロセスをたたき台にして、ISO 26262に準拠した車載システムを効率よく開発するための知見やノウハウを国内自動車業界で広く共有するための取り組みを進めてきた。これらの取り組みは、2011年度と2012年度の各年度で、異なる認証機関によるレビューも受けている。2012年度は、自動車メーカーやティア1サプライヤ、半導体メーカー、開発ツールベンダなど27社から94人のエンジニアが参加し、1850ページの文書を作成した。認証機関からは420項目もの指摘があったものの、これらの指摘は文書に全て反映されている。こう書いてあるので、日本の自動車業界総出で作り上げた ISO 26262 に適合するための解説、チェックシート、テンプレートのようだ。
規格認証機関からの指摘も反映させているということなので、規格認証機関もこのテンプレートに沿って作られたドキュメントをむげに却下することはできないだろう。
規格適合をテンプレートで乗りきる問題
規格適合を乗りきるのにテンプレートを使う方法は最も効果的だと思う。テンプレートといくつかの具体的な事例と解説、これらが揃っていると書類を作る側の理解が早い。
でも、『ISO 26262との向き合い方 (10) ISO 26262 をテンプレートで乗り切る功罪』で主張したことをもう一度説明したいと思う。
規格適合のためにテンプレートを作ったときの現場のエンジニアの反応は次の二つに分かれる。
- 素直に受け入れて要求を理解し穴埋めしようとする。
- 型にはめられることに反発し、本心では役に立たないと思いつつ穴を埋めたという事実だけ残す。
ほとんどの場合は1のタイプだが、2のタイプも一定の割合で必ず存在する。ソフトウェア開発でAgileプロセスを使っているプロジェクトもあると思うが、そういうプロジェクトは2になる確率が高い。そもそも、Agileとテンプレートはコンセプトが相反している。型にはめないで機敏にプロセスを回す（イテレーション）のがAgile のコンセプトだ。
ちなみに、自分は規格適合にテンプレートを使うにあたって、タイプ1 と タイプ2 のプロジェクトの両方に対応し、本質を理解しながら進めてもらうために次のような条件を付けている。
『このテンプレートはサンプルであり、要求を満たすことができるならば、様式は問わない。』
こうしておけば、タイプ2 のプロジェクトも型にはまらずに元の要求を満たせる自分達のスタイルを追求できる。
ところが、元の要求を満たせる自分達のスタイルを追求しようとしたプロジェクトが現れることはほとんどない。その理由は、その時間がないほど開発に余裕がないからだと予想している。
もとの要求をじっくり理解する時間もないし、自分達のスタイルを確立するのはたいへんだから、開発を横において、もしくは開発を進めながら自分達の様式を作る余裕がないのだ。
そうなると用意されたテンプレートを埋める方が圧倒的に早い。上記のタイプ1は要求を理解しようとしていて、タイプ2は形骸化しているように書いたが、実際には1と2の間が多いと思う。
ようするに、要求を理解して自分達のスタイルを追求したい気持ちは山々だが、十分な時間がないので穴を埋めることで規格適合をパスできるのならさっさと埋めて終わりにしたいと考えるのだ。
構造化プログラミングが教えたプラクティス
そのときに、思い浮かぶのが構造化プログラミングの教訓の話だ。この話はデバッグ工学研究所の松尾谷徹代表から伺った話である。
構造化プログラミングの提唱者（エドガー・ダイクストラ）は次のようなプロフィールを持っていた。
- セマフォ（semaphore)排他制御方式の提唱
- 最短経路問題の解放：ダイクストラ法
- 他にも、スタック、ベクトル。Algo60のコンパイラ設計など
- 1930年オランダのロッテルダムに生まれた
- ライデン大学に入学し物理学を専攻
- 1962年アインホーヘン工科大学の数学教授
- 1973年オランダ在住のまま米国バローズ社（現在のユニシス社）のフェロー
- 1984年テキサス州立大学でコンピュータ科学の教授
- 2002年8月6日 享年72歳
そいて、1970年代、80年代 ダイクストラの「構造化プログラミング」 は話題となった。
【構造化プログラミングの特徴】
【構造化プログラミングの特徴】
- goto レスプログラミング
- 制御構造の標準化/while, if then else, for ループ
- 図表示（フローチャート）の使用
自分が今でも記憶に残っているのは先輩から「関数は50行以下にしろ」とか「gotoは絶対使ってはいけない」といったことを言われ、なぜ、それがいいのか分からずにそれに従うのはイヤだと思ったものだ。
goto を使う使わないについてはいろいろな論議があったようだが、関数50行以下は、当時の標準的なディスプレイのテキスト表示が、例えばVT100で80桁×24行だったからせいぜい画面2ページぶん、印刷すれば1ページに入るくらいにしておけばレビューしやすいという意味だったのだ。
ソフトウェアに関するルールは形骸化しやすいという典型的な例だ。ルールの意味さえちゃんと伝わっていれば状況に応じてルールを最適化できるのに数字だけが一人歩きすると形骸化する。
かつて、構造化プログラミングの効果を計測する実験が行われたと聞く。
左記がその様子だ。同じ仕様の課題を二人のプログラマに渡し一人は「オレ流のプログラミング」一人は「構造化プログラミング」でプログラムを作らせる。
どちらのプログラムが優れていただろうか。（この実験ではバグの数でソフトウェアの品質が計測された。）
当然、構造化プログラミングの方がバグの数が少ないと思われたかもしれないが、結果は「オレ流プログラミング」も「構造化プログラミング」もバグの数にほとんど差異はなかったと言う。
なぜか？ その答えを説明する前に次の図を見てもらいたいと思う。
エドガー・ダイクストラは、米国バローズ社（現在のユニシス社）に在籍していたとき、あるソフトウェアプロジェクトが他のプロジェクトよりも格段にソフトウェアの生産効率が高く、品質もよいことに着目し、そのプロジェクトの設計の規範をベースに「構造化プログラミング」を考え、提唱した。
そのときの生産性が高く、高品質なソフトウェアを生み出していたプロジェクトの開発の進め方がこれだ。
プロジェクトリーダは、当初プロジェクトメンバが作ったソースコードをすべてコードレビューしていた。そのスタイルはバラバラであり、レビュー工数がかなりかかっていた。そこで、レビューワであり、プロジェクトリーダであった彼は、自分の過去の失敗を繰り返さないための設計の規範をルール化にし、これをプロジェクトメンバに説明し、その後はそのルールに基づいてプログラミングをするように指示をした。
これにより、プロジェクトメンバがアウトプットしたソースコードはレビューワであるプロジェクトリーダの設計の規範に基づいたスタイルに近づき、コードレビューのスピードが格段に上がった。
そして、このプロジェクトの生産性と品質は他のプロジェクトに比べて際立って高くなった。このエピソードから分かる構造化プログラミングが教えたプラクティスは次のようなことだ。
- 構造化プログラミングのルールはリーダの過去の経験を設計の規範にしたものだった。
- 設計の規範をメンバに説明し守らせることでレビュー効率が上がった。
- リーダの熱意、レビュー、指導がなければ生産性も品質も上がらない。
「オレ流プログラミング」と「構造化プログラミング」の比較実験で差異がでなかったのは、リーダーの指導とレビューがなかったからだ。構造化プログラミングは設計の規範とリーダーのリーダーシップの両方がないと効果がないのだ。
そのことが後生に伝わらず構造化プログラミングのルールだけが一人歩きしたのは不幸だった。
同じことが、ISO 26262 のテンプレートでも起こらないとは限らない。そうならないようにするために必要なのは、組織やプロジェクトの中にいる規格の要求の真意を伝える者の存在であり、規格要求を十分に理解したレビューワの存在である。
テンプレートは一度穴埋めした状態で承認されれば、そのプロジェクトはそれを成功体験として頭に刻み込む。仮に要求の理解が間違っていたとしても、全体として一度承認されていれば、次も同じように書く。だから、レビューワの責任は重い。レビューワは「絶対に見過ごしてはいけない」というレビューポイントとそこは譲れないという信念を持っていなければいけない。一度でもその方針を崩してしまうと「あのときは何も指摘しなかったじゃないですか」と反発をくらってしまう。
だから、テンプレートは本来、レビューワが考えた頭の中の構造になっていないと具合が悪い。そうでないとレビューのスピードが上がらないのだ。逆に、レビューワの設計の規範が反映されていれば、レビューのスピードは格段に高くなり、どこを押さえればよいか、どこに問題があるか素早く判断できる。
他人が作ったテンプレートが自分自身の設計の規範と異なる、もしくはテンプレートの真意が見えない状態でプロジェクトにテンプレートの使用を義務づけると、テンプレートは形骸化する。テンプレートの穴を埋めることが目的になり、エンジニアはテンプレートの向こうにある要求が何かを考えることを止めてしまう。
そうならないようにするにはレビューワがレビューの際に要求の意味を熱意を持って伝えなければならない。そうしないと「構造化プログラミング」の比較実験と同じように、規格に適合してもしなくても品質は変わらないという結果になるだろう。
テンプレートで規格適合を乗り来るアプローチは確かに有効だと思うが、プロジェクトに要求を理解させることと、レビューワのレビューと、リーダーのリーダシップが欠落するとテンプレートは形骸化し効果がなくなるということを肝に銘じて取り組みを進めて欲しいと思う。
この記事を読んで「本当にそうだ」と納得してもられるのは、あと1、2年先の話だろうなあ・・・
この記事を読んで「本当にそうだ」と納得してもられるのは、あと1、2年先の話だろうなあ・・・
0 件のコメント:
コメントを投稿