memorandumsスマートフォン用の表示で見るmemorandums日々の作業ログです。今日も博多〜小倉の移動でした。今日の講演で面白かった(失礼!興味深かった)のはデンソーの佐藤様のご講演「車載システム開発における品質向上のための取り組みと技術」。カーエレクトロニクスに関わる組み込みソフトウェア開発の現状を垣間みることができました。組み込みソフトウェアの大規模化・複雑化に対応するためのAUTOSARという取り組みがあること。Bus)と呼ばれる共通バスでECUを接続することによりECUをプラグインと見なせるようになるとか>Androidと同じ思想。ADLやその一種であるEAST-ADL2による品質向上の取り組み。次はHAYST法の開発者であるゼロックスの秋山さんによる講演と演習。ExcelVBAで直交表作成ツールを作ろうという演習がありました。作ってみると考え方を理解できました。ちなみに、HAYST法や直交表に関係するリンク集を公開してくれている方がいましたのでご紹介(Link)。メインページは現在閉鎖されているようですがリンク集はアクセスできるようです。資料の多くはJaSSTのページにあるようです。年に田口玄一氏により「実験計画法」[1]が出版されたことを契機とし、広く使われるようになった。ブラックボックステストの一種です。入力因子が増えると爆発的に増える組み合わせを少なくするための方法のようです。以下、メモをまとめようと書き始めたのですが基本的なことがわかっていないことに気づきました。前職では直交表は特に使われていませんでした。日本の他の企業でも同様のところがあるのでは?と思います。直交表が使われていない理由を少し考えてみました。ちなみに辞めて6年経ちます。前職では、単体試験では主要な値、境界値を主体的に検査していました。UnitTestなどツールなどを利用するのではなく、昔ながらの手動(開発者がテスト仕様書を書いてテストする)でやっていました。場合によってはチームやメンタとレビューすることがあったと思います。あとは経験的に技術者が認識しているレベルでのフールプルーフテスト?をやっていたように思います。後は機能テスト(前職では総合テストと呼ばれていましたが)では、正常/異常ケースでシナリオベースで試験していました。テストケースの作り込みには(品質を確保するためには)確かに経験が必要ですが、これで何とかなる業界のように感じます。事実これで数十年やってきているわけですから。直交表を採用することでテスト工数を減らせるのであれば検討が必要なはずです。直交表に真面目に取り組んでいる業界はやはりそれなりの必然性があるのだと考えます。必然性のある業界といえばやはり組み込み機器。)もありますし、そうでない業界でも機器回収という事態が考えられます。製品リリース前に最大限、品質を確保することに務めなければなりません。組み合わせを試しておきたいところでしょう。前職のシステムでは画面入力の因子数はそれほど多くありませんでしたから、極端な話、全数検査してもそれほど時間がかかりません。外部入力(シーケンサやDCSとのI/F)についても、プロトコルが決まっているのでかなりの異常ケースが取り除かれます。直交表を利用できないことはないけど。その効果が薄い、というのが結論のようです。同じソフトウェア産業でもいろいろあるよな。(長々書いたわりに情報がない。来週末(20〜22日)は試験監督で岡山出張。休みがあるようでない不思議な職業。»プロフィールid:ke_takahashiソフトウェア開発、工作、面白ガジェットに興味があります。(1)はてなブログをはじめよう!ke_takahashiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。