PPTVIEW

目次 日産自動車におけるソフトウェア品質向上活動ー SWEEP ー 日産自動車 ( 株 ) ソフトウェア品質グループ菊池光彦 2006 年 1 月 30 日 1. 歴史 2. SWEEP 3. ソフトウェアレビュー 4. SQAツールレビュー 5. まとめ 2 1. 歴史クルマは常に進化し続ける 1. 歴史 1 台の車には数十個の ECU がある 環境 省エネ CO2 魅力品質 安全性 電子開発部サプライヤ C IT 開発部サプライヤ A エンジン開発部サプライヤ B 3 電子開発部サプライヤ D 4 1. 歴史ソフトウェアサイズは膨大 @2000 1. 歴史ソフトウェアサイズは膨大 @2000 [ 行 ] 10M 1M 100K 世界初の電子制御 @1971 10K '71 車両全体 1M@2000 パワートレイン部 0.25M@2000 '95 '00 '05 [ 西暦 ] 5 [Lines] 10M 1M 100K 10K 1M @2000 0.5M @1990 1M @2000 6

1. 歴史開発中のソフトウェア不具合の分析 @2000 1. 歴史 2001 年 4 月に SWEEP 活動を開始 誰が? 日産仕様 (4%) 日産 サプライヤ間の連携 (9%) サプライヤ (87%) どこに? 単純ミス (33%) 仕様 (33%) プログラム構造 (33%) SoftWare Engineering Evolution Program 7 8 目次 1. 歴史 2. SWEEP 3. ソフトウェアレビュー 4. SQAツールレビュー 5. まとめ 2.SWEEP SWEEP 活動の開始 ソフトウェア品質グループの設立 ソフトウェア開発プロセスの構築 ソフトウェア開発のルールの確立 9 10 2.SWEEP ソフトウェア品質グループの役割 2.SWEEP ソフトウェア品質グループの役割 IT 開発部エンジン開発部 開発部 範囲 : 車載されるすべての ECU のソフトウェア 独立した組織 ソフトウェア品質グループレビュー サプライヤ A 仕様書 ハード ソフト サプライヤ B 仕様書 ハード ソフト サプライヤ n 11 役割 : 日産標準の開発 社内適用 サプライヤ適用のフォロー サプライヤのソフト開発プロセスのレビュー プロセスどおりに進んでいることの第 3 者レビュー ハイリスク部品に対する特別活動 日産役員への定期報告 よりよいツールや手法の調査と開発 12

2.SWEEP 標準プロセス ルールの構築 個人の経験 ノウハウ 過去の成功体験 組み込みエンジニアの常識 過去の失敗体験 2.SWEEP 実践的アプローチを採用した プロセス ルール構築のポイント 確立した技術 再利用可能な仕組みとしての 標準 技術とプロセスの整合 重大不具合の再発防止 13 成功体験の展開 14 2.SWEEP ソフトウェア開発のプロセス 2.SWEEP ソフトウェア開発のルール 4 カテゴリの標準ルールを規定 Software Quality Management プロセスレビュー 仕様設計 構造設計 詳細設計 結合テスト 単体テスト 実車テスト ソフトウェア開発計画 ソフトウェア開発プロセス ソフトウェアテスト仕様 ソフトウェア不具合管理 コーディング コードレビュー 仕様レビュー構造レビュー テスト仕様レビュー SQA ツールレビュー 15 ANPQP 16 目次 3. ソフトウェアレビュー日産 / サプライヤの開発分担 1. 歴史 2. SWEEP 3. ソフトウェアレビュー 4. SQAツールレビュー 5. 依頼事項 17 日産 ヌケモレや矛盾の無い仕様を作成する 実車を用いて システム間機能評価や車両性能評価を実施する 仕様設計 構造設計 詳細設計 結合テスト 単体テスト コーディングコードレビューサプライヤ 要求仕様を分析し 整理する ソフトウェアを設計/ 開発し テストする ソフト品質向上のため 節目毎にレビューを行う 実車テスト 18

3. ソフトウェアレビュー日産 / サプライヤの開発分担 日産 日産で不具合を発見したとしても 日産ではソフトの詳細を直接解析できない! 実車不具合は再現困難! サプライヤ 仕様設計 構造設計 詳細設計 コーディング 単体テスト コードレビュー ソフト開発はサプライヤの分担ソフトはサプライヤの資産 実車テスト 結合テスト 19 3. ソフトウェアレビュー日産 / サプライヤによるソフト品質レビュー 仕様設計 仕様レビュー構造レビュー 構造設計 詳細設計 コーディング プロセスレビュー 結合テスト 単体テスト コードレビュー 実車テスト テスト仕様レビュー SQA ツールレビュー 20 3. ソフトウェアレビューレビューの内容 全体設計工程テスト工程プロセスレビュー サプライヤ評価: 弱点を分析し 今後のレビュー方針を決める プロセスアセスメント: 各プロセスが標準プロセスどおりに実施されていることを確認する仕様レビュー 設計部署とサプライヤ間で実施し 仕様のヌケモレ 矛盾を無くす構造レビュー シンプルな構造になっていること テスト容易な構造になっていることを確認するテスト仕様レビュー ソフトウェアが仕様書通りにできている事を確認する ゼロ割りなどの純粋なソフトバグの観点でテストされている事を確認するソースコードレビュー (SQAツール解析) 設計基準やコーディングルールが守られていることを確認する 21 3. ソフトウェアレビュー日産のすべきこと 22 3. ソフトウェアレビュー必要理由 23 3. ソフトウェアレビュープロセスレビューは必要! 作ろうとしているソフトにあった設計技術 手法の確立 個人に依存せず 組織として作業 工程が標準化されていることを確認 強み / 弱みを把握し 補強 24

3. ソフトウェアレビューたとえ話 設計技術 手法の確立 = おいしいラーメンのレシピを持っていること 個人に依存せず 組織として作業 工程が標準化されていることを確認 = 毎回おいしいラーメンを繰り返し作れること 強み / 弱みを把握し 補強 3. ソフトウェアレビュー必要理由 =レシピはわかりやすく書くこと 25 26 3. ソフトウェアレビューハインリッヒの法則 (1:29:300) 3. ソフトウェアレビュー 見える不具合 は氷山の一角 労働災害の事例から導き出された統計値 H. W. Heinrich ( 米 ), 出典 : フリー百科事典 ウィキペディア 1 件の重大災害の影には 29 件の軽微災害があり 300 件のヒヤリハットが隠れている ソフト規模 ルールからの逸脱 1 件の重大不具合の影には 29 件の軽微不具合があり 300 件のルール違反が隠れている 27 28 3. ソフトウェアレビュー氷山が小さければ不具合は少ない 3. ソフトウェアレビュールールを守れば氷山は小さくなる ソフト規模 不具合の総数 =3 角形の面積 不具合を減らすには 底辺 高さを小さくする ソフト規模 底辺を小さくするには 標準プロセス ガイドラインやコーディングルールを守る! ルールからの逸脱 ルールを守る! 29 30

3. ソフトウェアレビューシンプルに作れば氷山は小さくなる 3. ソフトウェアレビュー氷山を小さくすることは可能 シンプルな構造! ルールを守る! 高さを小さくするには シンプルな構造を設計する! 無管理のソフト プロセス ルール構造レビュー 高品質なソフト 31 32 3. ソフトウェアレビュー必要理由 3. ソフトウェアレビュー仕様バグには仕様レビューが必要 単純ミス (33%) どこに? プログラム構造 (33%) 仕様 (33%) 日産 / サプライヤ間の仕様の誤理解 誤伝達 33 要求仕様分析と要求仕様レビュー 34 3. ソフトウェアレビュー必要理由 3. ソフトウェアレビュー単純ミスにはテスト仕様レビューが必要 単純ミス (33%) どこに? プログラム構造 (33%) 仕様 (33%) テスト不足 35 テスト項目の規定テスト仕様レビュー 36

3. ソフトウェアレビュー必要理由 3. ソフトウェアレビュー構造バグにはソフト構造レビューが必要 単純ミス (33%) プログラム構造 (33%) どこに? 仕様 (33%) 複雑な構造による想定外タイミングの動き シンプルな構造とソフト構造レビュー 37 38 3. ソフトウェアレビュー必要理由 3. ソフトウェアレビュー効率向上 & 正確化には SQA ツールが必要 多彩で詳細なルールや手順による非効率化 完全にゼロにはできないヒューマンエラー SQA ツールによる効率向上と正確化 39 40 3. ソフトウェアレビューサプライヤのすべきこと 依頼事項 標準の開発プロセスの構築 要求分析の実施 トレーサビリティの確保 アーキテクチャ設計の実施 3. ソフトウェアレビュー観点を整理してからレビューに臨む 観点工程 システムテスト 結合テスト 単体テスト 仕様 ( 設計部署の観点 ) 仕様は正しく作られているか? ソフトは仕様通りに作られているか? ソフトは仕様通りに作られているか? 例外処理は考えられているか? ロバスト性 ( ソフト品質部署の観点 ) システムダウンしないか? ( 想定外の使われ方 ) タイミング BUG やタスク間 I/ F に問題はないか? ( 想定外のタイミング ) ゼロ割やオーバーフローなどはないか? ( 想定外の入力 ) ガイドラインやコーディングルール 41 42

目次 4.SQA ツールレビュー解析フェーズとレビューフェーズ 1. 歴史 2. SWEEP 3. ソフトウェアレビュー 4. SQAツールレビュー 5. まとめ Cソース SQAツール解析レポート 解析フェーズ レビューフェーズ 解析レポートをサプライヤでレビュー 43 44 4.SQA ツールレビューサプライヤと日産とで協調して実施 4.SQA ツールレビューソースコードは保護される 設計 ソフト品質部署 日産実施依頼 事前質問集 サプライヤ 記入回答 ノート PC 持参でサプライヤを訪問 & 解析 半日 ~3 日間 解析結果を納入 レビュー方法を指示 ソース返却 刈り取り 受諾 再レビュー 45 SQA ツール解析はサプライヤ 日産の合意が前提 サプライヤサイトで実施することで ソースコード流出を防止 日産所有の PC へのコピーと削除は サプライヤ担当者の同席が前提 SQA ツール解析中はサプライヤ担当者の同席が前提 46 4.SQA ツールレビュー SQA ツールでコードレビューを支援 4.SQA ツールレビューテストしやすいコードであること コーディングルール仕様設計実車テスト構造設計結合テスト詳細設計単体テストコーディングコードレビュー スパゲティコードはデバッグ困難 コードのスパゲティ度合いを数値化 SQA ツールでメトリックス測定 絡まっている箇所を特定 テストしやすいコードであること SQA ツールで支援 ル - ル通りのコードであること SQA ツールで支援 仕様どおりのコードであること 47 単純な構造に作り変える 48

4.SQA ツールレビューメトリックスで複雑箇所を特定 4.SQA ツールレビュール - ル通りのコードであること プログラム構造の複雑さ モジュール間 I/F 関数の複雑さ 静的パスカウント 実行行数 実車テスト結合テスト単体テストコードレビュー 構造検査 : モジュール間 I/F 論理的な誤りの検査 コーディングルール違反のチェック 49 50 4.SQA ツールレビューコーディングル - ル違反 4.SQA ツールレビュー論理的な誤り たとえば MISRA-C コンパイルエラーとならない記述 MISRA-C 安全な記述 http://www.misra.org.uk ( 社 ) 自動車技術会より日本語版が発行 振る舞いを確定できない記述 SQA ツールで排除 C ソースの集合 コンパイルエラーとなる記述 コンパイラで排除 51 オーバーフロー アンダーフロー ゼロ除算 配列の範囲外アクセス 不正なポインタアクセス 実行されないコード 過去の不具合経験から代表的な 6 個を重視 52 4.SQA ツールレビュー構造的な誤り : モジュール間 I/F 4.SQA ツールレビュー要レビュー! 多重書き込み変数 多重書き込み変数 リエントラント関数 再帰関数 書き込まれない変数 / 読まれない変数 Z 変数 意味のない演算 タスク間共有変数 割り込み許可 / 禁止のペア DFD のループ 過去の不具合経験から タスクや割り込みルーチンから変数の値を上書きする箇所 優先順位 : 高 起動タスクA タスク B S 待機再開. タスク A タスクAが変数 V1の値を読み込む時 V1の値は タスクAが自分で書き込んだ値? タスクBが途中で上書きした値? 振る舞いを確定できない! 代表的な9 個を重視 53 54 S 起動 V1 終了 R 終了 t

4.SQA ツールレビュー要レビュー! 多重書き込み変数 4.SQA ツールレビュー要レビュー! 書き込まれない変数 フローチャートで書くと taska() V1 a 演算 割り込み発生タスク切り替え b V1 (bの値はa? それともc?) 値を確定できない! ret taskb() V1 c ret 55 関数 A 書込み 関数 B 書込み 変数 1 読出しがない変数の存在意義は? 読出し 変数 2 書き込みがない変数の存在意義は? 読出し 関数 D 関数 E データフロー図を作成すると すべての要素が線で結ばれているはず! 56 4.SQA ツールレビュー要レビュー!Z 変数 4.SQA ツールレビュー要レビュー!Z 変数 Z 変数とは? 1 周期前の値を保持する変数 フローチャートで書くと foo() 新鮮ではない値を保持する変数 Read してから Set となる変数 a V1 Read V1 foo Z V1 ブロック線図 (Zは1 周期遅れの意味 ) 変数 V1 は Z 変数 関数 foo は周期的に実行される 関数 foo は変数 V1 に値を書き込む 関数 foo は 1 周期前の変数 V1 の値を参照する 57 ここで V1は静的なメモリ領域を割り当てられた変数とする 演算 V1 b ret Set 58 4.SQA ツールレビュー要レビュー!Z 変数 4.SQA ツールレビュー要レビュー!Z 変数 1 つの関数の中での Z 変数だけではなく タスク全体を見ると 実は V2 は Z 変数 タスク内の関数について Z 変数を検出する taska() V2 foo V1 poo Z V2 foo () poo () foo() a V2 ret poo() V2 a ret ret Read Set 59 60

4.SQA ツールレビュー要レビュー!Z 変数 組み込みソフトでの使われ方 内部状態を保持する状態変数 / フラグ 状態遷移で設計されたモジュールの状態変数 入力信号の変化を見るための前回値 SW の ON OFF/OFF ON のエッジ検出 アナログ入力の変化の度合いの測定 4.SQA ツールレビュー要レビュー!Z 変数のリスク 想定するリスク プログラマの単純ミスではないか? ( 本当は Z 変数ではないのでは?) Z 変数の場合 初期値は正しいか? ( 電源 ON 時の初回実行時の動作は検討されているか?) 新鮮でない値を使って制御することに問題はないのか? 61 62 4.SQA ツールレビュー要レビュー!Z 変数 レビューポイントの抽出 タスク内の一連の処理の中で Set する前に一度も Read されない変数 4.SQA ツールレビュー要レビュー!Z 変数のレビューの観点 Z 変数なのは意図どおりか? 正しい初期値で初期化しているか? ( ゼロなどの固定値で初期化するのではなく 電源 ON 直後の初期化ルーチンで入力値を読み込んだ上で その値を Z 変数の初期値としているか?) 初期値や初回の動作は設計されレビューされているか? 63 64 4.SQA ツールレビュー要レビュー!Z 変数 注意すべきパターン 4.SQA ツールレビュー要レビュー!Z 変数 疑問に思う? V3 V2 foo V1 poo V2 車速 ギヤ位置 (Z) foo V1 関数 foo() は 前回値と今回値を参照している つまり 値の新鮮さが異なる Z 現在の車速が 30km/h で ギヤ位置がリバース 本当? 65 66

4.SQA ツールレビュー 3 つの SQA ツールを活用 目次 タスク間共有変数 データフロー解析 実行時エラー メトリックス計測未初期化変数 PolySpace MISRA-C 1. 歴史 2. SWEEP 3. ソフトウェアレビュー 4. SQAツールレビュー 5. まとめ IMAGIX QAC 67 68 5. まとめソフトウェアはさらに膨大に! @2005 5. まとめソフトウェアはさらに膨大に! @2005 [Lines] 10M 1M 100K 10K 5M @2005 0.5M @1990 1M @2000 69 [ 行 ] 10M 1M 100K 世界初の電子制御 @1971 10K '71 車両全体 1M@2000 パワートレイン部 0.25M@2000 5M@2005 0.8M@2005 '95 '00 '05 [ 西暦 ] 70 5. まとめソフトウェア不具合は 1/20 に! @2005 5. まとめ構造バグはゼロ! @2005 開発期間中の不具合数 1 0.8 0.6 0.4 0.2 0 不具合 1/20! 単純ミス (20%) プログラム構造 (0%) 2000 2005 仕様 (80%) 単純ミス (20%) プログラム構造 (0%) どこに? 仕様 (80%) 71 72

プロセス技術ツール5. まとめ SQA ツールで万に 1 つも徹底撲滅! 5. まとめ成功要因 結合テスト 単体テスト コードレビュー 実車テスト 不具合発見率 = 約 10~20 個所 /KLOC 不具合発見率 0.06% 約 200 個所 /KLOC 不具合発見率 1.3% 約 100 個所 /KLOC 不具合発見率 0.3% 真の不具合数 ツール検出数 ( 値は日産ソフト品質グループの経験値 ) 73 個人ノウハウから共有ルールへ 1 つの成功事例をどのプロジェクトでも再現できた 実践的アプローチ : 新規技術ではなく既存技術中心の活動 特別な導入教育なく すぐに 全員に 浸透できた 74 5. まとめ成功要因 ソフト品質部署の立場から サプライヤの生資料を使ってレビューすることで 真の問題点を共有できた 5. まとめ成功要因 やってあたりまえ の内容 全員参加できた 日産設計部 日産ソフト品質グループ すべてのサプライヤ サプライヤの立場から 自分の文書 コードを他人に示すことで 自分のやるべきこ 継続的な活動 体質 基礎体力として定着できた とがよく見えるようになった 例 ) 社内監査体制 75 76 5. まとめソフトウェア品質を支える 4 本柱 5. まとめ 4 本柱 : 技術 ソフトウェア品質組織 経験を積むだけでは再利用できない 技術的視点での問題意識 デザインルール や チェックリスト へ昇華させる 77 78

5. まとめ 4 本柱 : ツール 多彩で詳細なルールや手順による非効率化 完全にゼロにはできないヒューマンエラー SQA ツールによる効率向上と正確化 5. まとめ 4 本柱 : プロセス なすべきことをせよ プロセス通りに実施していることのチェック = メタプロセス 担当者 / マネージャの業務処理基準 開発プロセスの定義 79 80 5. まとめ 4 本柱 : 組織 製品開発を担当するグループ プロセスやインフラ定義を担当するグループ プロセス通りであることを監査するグループ SHIFT_the future 主体的な行動者の定義 権限の明確化 チェック体制 それは私がやるんだ 81 82