MasaoApril's Library.

Software Testingなネタを書いてみた。

ASDoQ大会2014(1):講演1「自動車分野・機能安全分野での文書要求と開発プロセスの対応」

2014/10/17(金)にASDoQ(※)大会2014に参加しました。
※ASDoQ(Association of System Documentation Quality):システム開発文書品質研究会

下記内容を聴講しましたので内容をまとめ次第、順次紹介する予定です。

講演1「自動車分野・機能安全分野での文書要求と開発プロセスの対応」

講演2「ここがダメ!日本人技術者の文書力」

講演3「アジャイル開発における ドキュメンテーションの考え方」

パネルディスカッション「開発文書はどのように進化すれば良いのか」

今回は、『講演1「自動車分野・機能安全分野での文書要求と開発プロセスの対応」』です。

講演1「自動車分野・機能安全分野での文書要求と開発プロセスの対応」安倍 秀二(パナソニック株式会社)

   

[1]車載開発における文章化要求

[1-1]プロセス遵守要求

[1-2]文章:正しい作業したという証拠

[2]Automotive SPICE PAM

[2-1]達成型

[2-2]達成すべきアウトカム:ゴール指向

[2-3]最低限書くこと

[2-4]能力レベルとプロセス属性

・作業成果物管理属性
  1. 管理されたプロセス(LV2)(※最低限やるべきこと)
  2. プロセスの能力指標
  3. プロセス作業成果物に対する要件(チェックリストやテンプレート)
  4. レビュー記録

[3]ISO26262

[3-1]機能安全規格

  • 電気電子部品は壊れることが前提
  • 壊れたときに不安全にならない
  • PL訴訟のリスク対応:説明できないと敗訴

[3-2]故障

  • ステマティック故障:設計要因
  • ランダムH/W故障
  • もらい故障:ランダムH/W故障によりS/W誤動作するなど

[3-3]要求

  • レビュー形式
  • 表記方法
  • 複文はだめとか

[3-4]安全機構:作るのはソフトウェア

[4]DIA(Development Interface Agreement)

[4-1]責任範囲を明確化している

[4-2]授受開示など

[5]品質保証の定義

[5-1]考えの違い

  • 日本の品質保証:すり合わせ→全員参加
  • 欧米:証拠主義

[6]文章化の目的

[6-1]機能安全

  • 説明責任
  • 要素(要求/論証/証拠)

[6-2]目的

  • 個人の活動の説明責任を果たす
  • 検証活動(レビュー)、一貫性と完全性
  • 検証活動(テスト)
  • 論理的なものを可視化。(※アーキテクチャは難しい)
  • 正しく作業を実施したか?

[7]トレーサビリティ

[7-1]変更時の影響分析

[7-2]トレースできる設計=良い設計

[8]文章化の問題

[8-1]全部読まないと分からない

[8-2]モノ先行の弊害:文章作成が多すぎる

[9]正しい認識:納期と文章化のジレンマ

[10]文章の活用

  • 開発時に使用
  • 開発終了後の資産

[11]インスペクション

  • ISO26262:レビュー要求

[12]文章化の留意点:詳細設計はよく書かれるが、アーキテクチャ設計はあまり書かれない

[13]有効な文章化

  • 抽象から詳細へ
  • 下書きやメモを有効に

[14]『良い設計できる人は、良い文章が書ける』

[15]文章化の強化活動

所感

 私の開発ドメインは自動車系ではありませんが、説明責任を果たすことが企業の社会的責任に繋がると考えると、テスト仕様書やテスト結果報告書が説明責任を果たしているかふりかえる必要があると思いました。いい加減なテストケースでは説明責任を果たせないため、「何のためにどのような手段でテストを行うのか?」「テスト結果の記録した内容は妥当か?」という点でテスト仕様書のレビュー方法を一考することにします。