ソフトのテストとハードの検証。（分科会編）議事録２

S2-4-2
「ソフトのテストとハードの検証。
　　　　　なにが違って、なにが一緒？（分科会編）」
B会場、30人程度
----
S:ソフトウェア編担当片山さん
H:ハードウェア編担当赤星さん

H「組み合わせを減らそうという考えはハード屋さんにはないと思う。直交でやるより自動でやるほうが安い。」
A「ソフトとハードでは複雑さの度合いが違う。ソフトで出来るものもあるが。」
B「SDCAみないにデバッグしたあとにそんなに損害がない場合でも検証をしっかりやるのか」
H「かなりソフト的に見えるのは事実。FPGAだと検証半分ぐらいでいいという人が多い。失敗を許す雰囲気があるが、それは良くないと思う。」
C「ハードではいろんな言語を作っているが、組込みシステムではCが使われているがバグが多い。バグをなくしたいから言語を作るというのはソフトにはないのか」
S「誤りを含むような文法を含む言語は良くない。しかし、Cがあまりにも普及している。Cでないと受け入れてもらえないところがある。」
H「ハード屋から見るとテスト環境までCでやる必要はないと思う」
A「テストファーストはクラス？」
S「テストファーストはクラスを作っている。テストファーストは開発のためのコーディングのための仕組みだと思う。」
D「シミュレーションでどんどんテストすればいいという話があるが、実機で完成した形で動かなければいけない。最終的にはシステムでやらなければ。」
H「OSの移植で何が怖いか。サンプルが動いたら良しではない！」
E「チップの中の仕様を組めなかったりする。ボードの検証をしないといけない。ハード屋さんがテストケースや結果などを全部ソフト屋さんに下さい。」
H「ハードでチェックしたことをボード上でソフト屋さんがもう1回チェックしてる。コミュニケーションがうまくいっていない。中身を全部見せるのはNGだが、大体どういうチェックをしたかを見せることはできるのでは。」
E「ハードの検証を済ませた人はソフト屋さん馬鹿なことやってると思うかもしれないが、ソフトはわからないからやらざるを得ない。」
H「ハード内でも同じ問題がある。ハード屋間でもテストケースを全て見せれない。」
A「個々のハードの検証の手法とソフトのテスト手法

H「ソフト/ハード、ハード/ハード間で隙間がある。」
A「検証に時間をかけるではなくて、設計に時間をかけようという話があったが、もうちょっと先にいくと、テスト容易性だけでなく、バグの入りにくい設計というのはあるか。コーディングルール以外で何か。」
S「一つはフォーマル。結局はそこに行き着いちゃう。」
A「実用的なレベルで。」
S「実用的なレベルであればこんなに苦しんでいない。そこを考えている。」
A「テスト容易なための
S「モジュール間結合度などのものはある。手順などはない。着目点は8つある。ガイドラインにもなっていない。」
A「ハードの方だとテストのためだけに無駄な回路を入れる。そういうものも特にないのか。」
S「そういったものもない。少なくとも私は知らない。プログラミング時の工夫はべたな方法はある。」
F「うちは自動化はしやすい。実装上の設計指針はいくつかある。ユーザインタフェース。プログラミング可能なもの。ループバックなど。」
H「通信機はうちもループバックもやる。割とやりやすい。」
A「ソフトでも自動化できる部分がある。ボードレベルでのファームウェアデバッグを考えた時に、ソフトでは書いていると思うが、LSI側でやると良いのでは。full ICEなどピンは全て出していた。セットレベルでテストしやすい仕組み。」
H「テストしやすいハードではあるが、検証しやすいハードではない。同じ機能でもアサーションの書きやすさが違ってくる。」
H「テスト用のパスは外に出す。検証用は出さない。検証用はバーチャルに出来る。検証しやすいかどうかがゴール。」
S「全部モデル化してるのは信用していない。機能用件があるから。ハード屋さんの意見は？」
H「例えば温度特性といった機能用件がある。Cで書いてもあんまり意味がない。すでに定義されたことがいっぱいあって、今回作ったチップではこうだ、こうだという感じに見える。」
H「ハードの場合は性能がないと絶対にダメ。ユーザインタフェースについてはソフト屋さんが頑張って。」
S「ソフトでは機能要求という言葉が先に出てきて、後で出てきたものをごそっと入れた感じ。ハードでは？」
G「チップ作った後外部と繋がるが、繋いで見たらインタフェースが期待通りじゃなかった場合、
H「規格書は厳密にある。規格がかなり抑えている。ハードは偉い人が決める。違う時計を持っている人たちが通信をする場合にバグが発生しやすい。マルチクロックを例えば静的ツールが定石に従って設計しているかチェックし、定石どおりでなければ直せというツールがある。」
S「ソフトウェア自体は定石というものが確立されていない。ようやく出てきたところだが。新しいことを勉強するより、
I「ソフトのツールも昔は高かった。それが崩壊してからは作りこみの部分は少なくなってきたのでは。オープンソースで自分たちで作っていくしか。ハード屋さんとは作る側のモチベーションが違う気がする。」
H「金取ってるからサポートする。金出さないからサポートしない。卵と鶏の関係のようになっている。」
S「値段が高いツールがあるにはあるが、値段が見合っていない
H「インタフェースの話に戻る。何でバグるかというとグローバル変数を使うから。ガイドラインがあるが遅くなるから守らない。」
J「インタフェースを作るのが面倒だからグローバル変数。詳細仕様がやってきてから新たに通信が必要になると、仕様を見直す時間もなくてグローバル変数でやってしまう。やらざるを得ないのでは。」
H「ハードだと後から一個ポートを増やしちゃえ、と出来る。最初の要求分析から全部導き出せない。」
A「ハードはバグが入ってしまうと仕様にしちゃう。システムとしてちゃんと動くのであれば割と問題はない。ソフトは複雑さが爆発している。ハードは人海戦術を取っていないがソフトは人海戦術をやっている。だから平均的なスキルは低下する。」
S「ハード屋さんで不具合が本とはあるけどソフトでカバーしたり、最後の最後でシステム全体のテストをしている。」
A「書こうとしてもエディタが書かせてくれないとか、その機能チェック規則を企業ごとに作りこめるエディタがあると良い。」
S「コードを書いている時にチェックするのがあるかは分からないが、コードを書いた後にチェックするのはある。ワーニングはいいよねっていうのもある。」
K「ワーニングをどれだけ信用するか、ワーニングで本当にバグがあるかなど、どのように考えているか。」
S「ワーニングが出た結果で見るのではなく、出る前にこのワーニングは無視する、このワーニングはなくす、という風に決めておくべきかも知れない。」
H「ソフトのワーニングは信頼性が低い。狼少年になっている。」
H「どのチェックに関してはOK、どのチェックに関してはNGというのは決める。」
A「全てのワーニング、全てのエラーについて、どれは無視してどれは無視しないかのルールを最初に決める。持ってきた部品も全部見て、必要なものは直す。直せないものは交渉して直してもらう。」

H「最後何をやるかと言うと結局KIAIだと言う。分かっているけど変えるのはむちゃくちゃ大変。そこで変えるかどうかはKIAIの問題。組織のKIAI、個人のKIAIがある。」
L「機能カバレッジを見てこれは大丈夫だとやってしまう。そうしないように教えていかなければ。」
H「書かなければ機能カバレッジは上がってくる。」
S「表を書いて全部チェックするのはソフト屋さんは面倒だからやってないと思う。そういうところにツールの力を借りましょう。状態遷移図などの規模が爆発してしまうところでは。」
A「頑張っただけ評価されて給料が上がればやる気も出る。初期コストをかけていって会社が持つかどうかも問題。」

--------------------------------------------------
赤星さんのスライド：

担当から見ると
・結局、技術者の評価は残業時間できまる。
・20回徹夜したからで評価するな！
悪循環になっている。

検証を改善したいというけれど・・・
・改善する気ないの？
・もしかして、どうしていいか分からない？
・新しい手票を入れたが、良くなったか分からない！

改善するからには！
・本当に、何が問題なのですか？
・改善指標がないと、改善できない！
・何を指標に持ってきますか？
　-指標になった項目は、計測可能→管理可能
　-計測可能になったら、短い時間でやるのがえらい！
---------------------------------------------------

S「これはハードに限った話？」
H「割と一般論だと思う。」
M「短期的に残業代で見ると使えないやつが給料が多い。長期的に見ると昇進していって確実に差が付く。頑張った分は褒めないといけないから残業代は仕方ない。モチベーションがある人はいいものを作る。扱っている規模は出来ない人に比べて大きいからバグは多い。」
H「いかに全体としてまとまりを持って出来るか。まだまだ検証は良くなる。設計に比べて自由度が残っている。全体をうまく回すような仕組みが必要なのでは。」
S「テストの終わりはソフト屋さんはあいまいなまま何とかやる。ハード屋さんはきちっと終わるのか。」
H「終わらない。本質的に抜けては許されない機能はものすごいチェックをする。32ビット通信が出来れば8ビットできなくても切っちゃう。」
H「機能が出来ても電気的な問題で動かなかったりする。コードカバレッジ、機能カバレッジも考えてやらなければいけない。」

S「第一に情報公開が重要。ソフト屋さんがハード屋さんのところにいってしつこく情報を要求してるのかというとしていない気がする。ハード・ソフトでお互い学ぶものもあれば共通するものもある。」