【題目】ソフトのテストとハードの検証。なにが違って、なにが一緒？(分科会編)
【日時】7月14日(金) 15:20-16:50
------------------------------------------------------------------------------------------
--------------------+-------------------------+--------------------
SW | | HW
| |
--------------------+-------------------------+--------------------
ちまたで言われる | 検証意識の高まり | 検証期間の増大
(テスト不足) | | 失敗によるリスク増大
--------------------+-------------------------+--------------------
直交法 | | ツール
ツール | 効率化の取り組み | 言語
自動化 | | 手法
| |
--------------------+-------------------------+--------------------
スペック⇔実装の確認| 検証とは？ |スペック⇔実装の確認
非機能要件の扱い | |
--------------------+-------------------------+--------------------
テストファースト | 最近のキーワードは |(制約付)ランダム生成
TDD | | アサーション
モデル検証 | | フォーマル検証
--------------------+-------------------------+--------------------
ガバレッジ | 検証の終わり | テープアウトの日
メトリクス | | バレッジ
--------------------+-------------------------+--------------------
・HW設計では自動化が進んでいる。
人手が入るとミスも入る。人件費もかかる。自動化が必要。
SWとHWでは複雑性が異なる。
SWは、人手で扱えるような複雑性に抑えている。
Q：HW設計や検証のために言語を作って対応している。
しかし、SWでは言語を変えようという動きがないのはなぜか？
A:プログラム言語としては、進化している(変わっている)。
JAVAが出てきた時に、なくなった文法がある。←いろいろと検討された結果。
Cが普及しすぎているため、開発言語の変更は難しくなっている。
普及させるためには、Ｃ類似の言語になる。
Q：Ｃ++でテスト環境に対して、オブジェクト指向を適応させる動きはないのか？
A:テストファーストはＣ++で作られている。
ＪＡＶＡだと、Ｊ−unit
テストファーストは、テストのためというよりは、コーディングのためという認識
・シミュレーションをドンドンやって検証すればいいじゃないかと言うが、
部品・ボードの状態で動かないといけない。
ノイズ、電源をくみ上げた状態での検証が必須。
最終形での検証が必須。
ボードから離れれられないのは、当然。
バーチャルでしかできない検証もある。
ソフト屋もそういう点を考慮している。
・HW屋は、チップの検証結果やボードの検証結果をオープンにしてほしい。
HWのシミュレーターやその結果も欲しい。
HWとSWのコミュニケーションが不足している。
HW屋が検証したことを、SW屋も検証している。無駄な作業である。
中身を見せる(結果を出す)のは重要と思う。(全部は出せないけど)
HW屋も、部品を買ってくると、たいてい動かない！！
HW屋でも同様のことが起こっている。（HW−HWのコミュニケーション不足も同じ！！！）
HW/SWお互いに検証結果のオープンを望む。そうすれば面白いことができるはず。
Ｑ：テストに時間をかけるのではなく、設計に時間をかけるべきという意見。
バグを入りにくいという方向での検証方法とはどういうのがあるのか？
たとえば、コーディングルールみたいなものはあるのか。
A:実用的なレベルではない。
Q:HWでテストを容易にするために、無駄だけどテストのための回路を入れ込むということがあるが、
SWにはそのようなものはないのか？
A：現在はそのようなものはないと思う。
・通信分野はデバッグがしやすいようになっている。
これは他の分野にも参考になるのではないか。
・LSIを製造する時には、テストしやすい設計をしているが
ボードレベルでデバッグしやすいようにできないのか？
・ソフトウェアのテスト費用を下げることが重要。
Q:検証用の回路は出荷時にはどうしているのか？
A:いろいろな対応がある。
・HWはステップで大体検証ができる。感触がつかめる(見当がつく。)
SWはステップで正しいからと言って、プログラム全体が正しいかは分からない。
・HWの場合は、
温度特性 30-80度
消費電力 xxmW
のように機能用件は決まっていると思う。
SWの場合は、さまざまな機能用件、性能-パーフォーマンス、
ユーザービリティーが求められる
Q:HWチップを製造後、外部とつなぐと予想と違うと動作をすることがある。
A:バスの規格は結構しっかり作られてる。
HWの規格はメーカが決める。
それに従わないといけない。
例えば、複数クロックを持つときの通信ではバグがよく出やすいところ。
・SWでは”定跡”が確立されていないが、
最近はデザインパターンと言う概念が出てきている。
しかし、プログラムが動けばいいという思考が支配的。現実的。
・SWのツールは昔高かった。今は価格は崩壊的。
オープンソースでツールを自分で作っていくことに期待するしかない。
HWさんのツールは高い。
そして機能的。サポートもある。使用する側のモチベーションも違う。
・グローバル変数を使っているのが問題の本質？
グローバル変数を使う理由は、
下請けの問題
インターフェイスの必要が生じた時に、仕様を見直す時間がない
納期の問題。
当然理解してないで、使用する人もいる
・HWのバグを仕様化する傾向にある。
システムが動くなら、この傾向は完全には悪いものではない。
・システムの複雑性と技術の低下を全てをテストでカバーしてほしい！
・テストが最後の辻褄合わせになっている感じがする。
Q:技術の低下をツールでカバーできないのか？
悪いコーディングができないエディターとか。
A:言語仕様のチェックはできるが、機能仕様チェックはできない。
コードを書いている最中にチェックできるツールは分からないが
終わったところでチェックをするツールはある。
↑
それではやはりダメで、設計している段階で警告が欲しい。
Q:ワーニングをどれだけ信用するのか？
ワーニングを見逃した場合はどうなる？
A： SW：ワーニングを無視する傾向がある。
HW：どうしてワーニングなのか？を追求する。
自分の開発品については、ワーニングは全部つぶすようにしている。
ただし保守のためのもの(他社製品)は、ワーニングをつぶさない場合がある。
SW：ワーニングは信頼性が低いと思う。
HW：ワーニングの取り扱いについては、お互いに説明している。今後もめるのを防ぐため。
・ワーニングについて
どれが無視してOK、どれが無視できないというリストを作成。
買った部品についても、全部チェックしてリストを作成する。
HWはいちから作るので、いきなり一万個のワーニングが出ることはない。
(ワーニングは少ない。)
・こういう環境を変更する気があるのか？
気合いがあるのか？
問題がないなら、変更をいやがる
組織としての気合、個人の時の気合が必要！
気合が問題なる時は、大規模開発の時。
給料があがれば気合がでるか？
改善する場合、初期コストがかかる。この兼ね合いが難しい。
初期コストに会社の財政が耐えられるのか。
・検証を改善したいというけれど・・・
改善する気があるのか？
もしかして、どうしてよいのか解からない？
新しい手法を入れたが、よくなったか分からない！
本当になにが問題なのですか？
改善指標がないと、改善できない！
何を指標にもってきますか？
指標項目が、計測可能⇒管理可能
計測可能になったら、、短い時間でやるのがえらい！
・残業時間で評価されている現状がある。
短期的に見れば確かに効率の悪いやつは給料が高い(残業代で)。
長期的に見た時には、できるやつはちゃんと出世して実力に応じた差がついているような気がする。
・上司としては、できなくても頑張っている人に対して「頑張っている。」と言うしかない。
戦力がなくなるよりは良い。
・気合がある人が集ると、検証の改善は進むと思うし面白いことができるはず。
・検証の立場も低いような気がする。
テストの人で有名な人はいない、。キャリアパスの問題（テスト部門の位置づけ）
Q:テストの終わりは？
A:SWのテストの終わり：バグを取って動きを確認して、不安がのこりつつ。。。終わりの実感はない。
HWのテストの終わり：検証項目の優先度の問題。機能毎に優先度をつけて、検証の力の入れ具合を変える。いつも安心はできない。
＜まとめ＞
SW−HW間の情報公開が必要！
いいものをつくるという気持ちは一緒。
SW-HW間の議論が必要！