高信頼性を確保するソフトウェア開発手法と実践 －組込み製品の潜在的価値を今以上に高めるために－
•Download as PPTX, PDF•
0 likes•717 views
第8回 組込みシステム開発技術展（ESEC） 2005年6月29日～7月1日 専門セミナー の講演資料
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 高信頼性を確保するソフトウェア開発手法と実践 －組込み製品の潜在的価値を今以上に高めるために－
Similar to 高信頼性を確保するソフトウェア開発手法と実践 －組込み製品の潜在的価値を今以上に高めるために－ (20)
高信頼性を確保するソフトウェア開発手法と実践 －組込み製品の潜在的価値を今以上に高めるために－
- 1. ©Yoshio Sakai 高信頼性を確保するソフトウェア開発手法と実践 －組込み製品の潜在的価値を今以上に高めるために－ 組込みソフトウェア管理者・技術者育成研究会 酒井 由夫 EEBOF (Embedded Engineer's Birds Of a Feather) 第8回 組込みシステム開発技術展（ESEC） 2005年6月29日～7月1日 専門セミナー 講演資料
- 3. ©Yoshio Sakai １. 高信頼性ソフトウェアの定義と必要性 ２. 高信頼性ソフトウェア実現のフレームワーク ３. 日本のもの造りについて分析する ４．体系的な再利用によるソフトウェア信頼性向上の実践
- 5. ©Yoshio Sakai 組込み製品の信頼性とソフトウェア 組込み製品の信頼性＝潜在的価値 品質は宣伝にもなります Quality is its own advertisement. （品質それ自体が広告である） 顧客満足を高めるには組込み製品の安全性・信頼性を高めることが重 要です それは日本の得意分野であるはず 組込みソフトウェアの安全性や信頼性を高めるには、技術も必要ですし、 もちろんコストもがかかります 製品の安全性や信頼性を効率よく高めるソフトウェアの開発手法が必要 です
- 6. ©Yoshio Sakai 組込みソフトが原因になった不具合の例 公表日 製品種別 不具合の内容 2004.08.16 ＤＶＤレコーダ DVDレコーダで電源がオン状態の時に録画予約メールを受 信できない 2004.10.04 デジタルカメラ 連続撮影中や、オートパワーオフ状態でレンズを着脱後、デ ジタル・カメラが操作不能になる 2004.10.21 携帯電話 電話を発信するとほぼ同時に着信があった場合、電話帳の 内容が消失する 公表日 社名／製品名 不具合の内容 2004.03.18 英ジャガー「XJ8」など12車種 6速自動変速機で、勝手にギヤが3速に固定されたり後退に 入る 2004.08.31 仏プジョー「206」など10車種 電源制御装置の不具合により、リモコン・キーでドアロック時 にホーンが鳴り続ける 2004.09.14 独BMW「525i」など７車種 着座センサーの情報が感知できず、事故時に助手席エア バッグが作動しない 携帯電話やＡＶ機器などの故障を引き起こした事例 自動車のリコールにつながった事例 日経コンピュータ 2004.12.27 号 『組み込みソフトの巨大化に立ち向かう』 p119 より
- 8. ©Yoshio Sakai 0 2 4 6 8 10 壊れにくい 手入れしやすい 故障判断が的確 ２４時間連絡体制相談電話のつながり易さ 修理代が安い 修理が早い 組込み製品の品質がユーザーに評価される日は近い 0 2 4 6 8 10 価格 デザイン 操作性 画質 手ぶれ補正 バッテリ 携帯性 拡張性 たとえば家電製品の評価サイトでビデオカメラの機能・性能のみならず、品質もあ わせて評価されるようになるとどうなるでしょうか？ 商品の性能（顕在的価値）評価 商品の品質（潜在的価値）評価 左レーダーチャート：価格．com ビデオカメラ人気アイテムランキング１位の商品の評価バランスより
- 9. ©Yoshio Sakai 組込み製品の価値とは 顕在的価値 ユーザーの本質的な要求 何をしたい？ 何を解決したい？ どうなるとうれしい？ 要求を満たすためのサービスや機能 そこから導き出される製品の本質的特長 使いやすさ、わかりやすさ 潜在的価値 製品の品質（安全・信頼できる・壊れにくい） 保守性（故障しても直してくれる、直しやすい） 使い方の分からないところはすぐに教えてくれる 組込み製品が売れるためには “顕在的な価値” と “潜在的な価値” の両 方が高くなければいけません 作り上げた製品で顧客満足を高めることができなければ、何の意味もありません 顕在的価値 潜在的価値
- 12. ©Yoshio Sakai
- 15. ©Yoshio Sakai コア資産を切り出し、結合度を弱めます 高凝集 (high cohesion) 疎結合 (low coupling) コア資産 を目指す
- 20. ©Yoshio Sakai 電子ポットのリスク分析・妥当性確認 Ｒ＆Ｄセンターの省電力研究室から、電子ポットの温度テーブルを最適化するこ とで、ポットの消費電力を１０％削減できるという調査報告が回ってきました この調査報告を受けて、ポットの消費電力を削減すべく設計変更をいました E0: （℃） ＜-3 ≧-3 ＝0 ≦3 ＞3 ΔT0 （℃） ＜-3 0 100 100 100 100 ≧-3 0 70 70 70 100 ＝0 0 30 30 50 100 ≦3 0 0 0 30 100 ＞3 0 0 0 0 100 E０：目標の水温－現在の水温 ΔT０：前回の制御周期時の水温－今回の制御周期時の水温 例示 参考： SESSAME WEBサイト 話題沸騰ポット GOMA-1015型 要求仕様書
- 21. ©Yoshio Sakai ポットから煙がでた！ ユーザー先で使用中の電子ポットで煙がでたという報告がありました ポットを分解したところヒータの異常加熱により、周りの部品が焼けこげていました 品質保証部門の解析チームがプログラムを解析したところ、省電力のために変更した温度 テーブルの組込みでミスがあり、テーブルのヒータ制御量の中に誤って負の値が定義された 部分がありました 負の値がヒータ制御のソフトウェアに渡るとヒータを最大出力で熱してしまうプログラムに なっていたことが判明しました エラー監視のプログラムでヒータ連続オンの時間の上限を監視していませんでした 例示 E0: （℃） ＜-3 ≧-3 ＝0 ≦3 ＞3 ΔT0（℃） ＜-3 -1 100 100 100 100 ≧-3 0 70 70 70 100
- 22. ©Yoshio Sakai リスク分析表を使った信頼性の向上 番 号 障害 原因 重要度 発生の可能 性／故障率 対策 実施確認の方法 チェック No. Hazard Cause Level of Concern Likelihood/ Failure Rate Method of Control Trace Check A-1 ヒータの異常加 熱により火災が 起こる ・サーミスタの故障 ・ヒータの故障 High 1/10000 （故障率） ・ハードウェアによる対策 温度ヒューズによるヒータ への回路切断 ・ソフトウェアによる対策 ブザーによる注意喚起とエ ラー表示（３０秒）を行う． 設計書番号 #001 テスト計画 #001 □ □ ・水の量が少ない に加熱した High たまにあり (Moderate) ・ソフトウェアによる対策 第１水位センサがオフ状態なら ば，ヒータや沸騰ボタンは動作 しない． 設計書番号 #002 テスト計画 #002 □ □ ヒータ制御ソフト ウェアの安全対策 不備 High まれ (Low) ・ソフトウェアによる対策 ヒーター制御値のマイナス値は 受け付けない 連続ヒーターＯＮの時間に上限を 設ける 設計書番号 #003 テスト計画 #003 □ □ フィールドで起こった不具合の対策をコア資産に追加し、より強固なものにします 出典：Guidance for FDA Reviewers - Premarkrt Notification Submissions for Automated Testing Instruments Used in Blood Establishments 例示
- 25. ©Yoshio Sakai １. 高信頼性ソフトウェアの定義と必要性 ２. 高信頼性ソフトウェア実現のフレームワーク ３. 日本のもの造りについて分析する ４．体系的な再利用によるソフトウェア信頼性向上の実践
- 26. ©Yoshio Sakai 過ちを犯しやすい人間の活動をコントロールする ソフトウェアの不具合を作り込 む原因は後にも先にも人間で す 高信頼性ソフトウェアを目指す には過ちを犯しやすい人間の活 動をコントロールする必要があ ります ソフトウェアの品質向上を目的 とした Activity を“過ちを犯しや すい人間の活動をコントロール するという視点”で分類すると右 のようになります 人間の過ちを軽減する Activity (取り組み) 人間の介在を少なくする Activity (取り組み) プロセスの定義 MDD(モデル駆動開発） リスク分析 ソフトウェア資産の再利用 コーディングルールの定義 優れたアーキテクチャ フレームワークの採用 静的コードテスト メトリクス分析による指導 テスト・レビュー・インスペクション ソフトウェア資産の再利用 不具合・仕様変更データベースの整備 UMLによるシステム構造の階層化 不具合発生・対策曲線の分析
- 27. ©Yoshio Sakai 信頼性向上の Activity Map 機能設計 詳細設計 単体テスト 結合テスト システムテスト プログラ ミ ング Verification 不良 入り込み分布 不良 摘出分布 Software Life Cycle Process 設計努力 摘出努力 User Requirements Software ProductSoftware Validation Design Validation Verification Verification 要求分析 ＵＭＬ 構造化分析 レビュー，インスペクション ユーザー要求の分析 品質機能展開 プロダクトリスク分析 コーディングルール コードインスペクション 静的コードテスト、メトリクス分析 テスト レビュー，インスペクション 統計分析 不具合データベース 不具合発生・対策曲線 各種テスト 内部設計 Verification 不具合を 作り込まない努力 プロセスで抑える 不具合を 摘出する努力 参考：保田 勝通 『ソフトウェア品質保証の考え方と実際』 p36 図 1.10 「不具合低減のための方針」 重要
- 28. ©Yoshio Sakai Drivers Real Time OS Middle Ware 1 Middle Ware 2 Product User Requirements Design Validation Software Validation ApplicationSoftware ApplicationSoftware ApplicationSoftware Software Subsystem の結合 システムはサブシステム の集合体です 個々のサブシステムの信 頼性が高くなければ、シス テムに爆弾を埋め込むの と同じです システム全体の信頼性を 高めるには、個々のサブ システムの Verification(検証)とユー ザー要求に基づいた Validation（妥当性確認） を行うことが重要です サブシステムが高凝集、 疎結合の関係になってい る必要もあります Framework for high quality embedded software system
- 29. ©Yoshio Sakai Drivers Real Time OS Middle Ware 2 Product User Requirements ApplicationSoftware ApplicationSoftware ApplicationSoftware COTSに爆弾が含まれていたら？ COTS: Commercial Off-The-Shelf （商用で即利用可能なソフトウェア部品） Middle Ware 1 COTS (Black Box) Design Validation Software Validation COTS 製品に使うために購入した“商用で即利 用可能なソフトウェア部品”=COTSには、 爆弾が含まれていないとは限りません ブラックボックスのCOTSに含まれる爆 弾は、Software Validation や Design Validation によって取り除きます 具体的にはCOTSに対してブラックボッ クスで機能テストをしたり、サブシステム 同士の結合テストや製品の機能テストに よって爆弾を見つけます 見つけた爆弾はCOTSの供給者に取り 除いてもらうしかありません 社内で過去に作成した中身の分からな いサブシステムでも同じです 検証が十分に行われ市場で長い時間使 用されたサブシステムは再利用できます
- 30. ©Yoshio Sakai Product A User Requirements SoftwareValidation Product B User Requirements SoftwareValidation Product C User Requirements Design Validation SoftwareValidation Support Process Product Line Education Core Asset Core Asset Core Asset Architecture Software Engineer Software Product Line と Engineer 製品群におけるコア 資産は製品群の価値 が凝縮された重要な サブシステムです コア資産の信頼性を 高めることが商品群 全体の信頼性を向上 させることにつながり ます 不具合を作り込むの は人間です エンジニアの教育は 不具合の元を断つこ とに直結しています Framework for high quality embedded software system
- 31. ©Yoshio Sakai
- 32. ©Yoshio Sakai 組織成熟度・視点別QA向上のためのActivity Map ※「要」は必要性を表す ※A,B,Cは要求レベルを表す ※◎○△は優先度を表す 開発プロセスの定義、Validation（妥当性確認）の 実施、エンジニアの教育はどのような組織、どの ようなプロジェクトにとっても必要です 組織成熟度レベルの低い組織は、不具合を摘出 する Activity を強化します 組織成熟度レベルが高くなってきたら、不具合を 作り込まない Activity（要求仕様の分析技術の向 上） や支援プロセス（構成管理や不具合管理ＤＢ など）を整備します アーキテクチャの適用や体系的な再利用の推進 はパイロットプロジェクトを編成しノウハウをフィー ドバックするとよいでしょう Q A向上に必要な施策 さまざまな視点 開発プロセスの定義 Validationの実施 エンジニアの教育 不具合を作り込まないためのActivity 不具合を摘出するActivity 支援プロセスの整備 アーキテクチャの適用 再利用の推進 組織成熟度レベル１ 要 要 要 C B C C C 組織成熟度レベル２ 要 要 要 B B B B B 組織成熟度レベル３ 要 要 要 A A A A A 組織から見た重要度 ◎ ◎ ◎ ○ ○ ◎ ○ ◎ プロジェクトから見た重要度 ○ ◎ ◎ ◎ ◎ ○ ◎ ◎ エンジニア個人から見た重要度 ○ ○ ◎ ◎ ◎ △ ○ ○
- 33. ©Yoshio Sakai コーディングルールを定めているか？ 障害票データベースを持っているか？ ソース管理システムを持っているか？ 開発の節目節目でレビューを実施しているか？ スケジュール表を常に更新しているか？ 仕様書を作ってからプログラムを書き始めているか？ プログラムを変更した後の回帰テストは実施しているか？ 買える範囲で一番良い開発ツールを使っているか？ OJT以外に技術者教育のカリキュラムを持っているか？ テスト担当者はいるか？ １～４（レベル１）、 ５～７（レベル２）、８～１０（レベル３） 参考：ジョエル・テスト(The Joel Test: 12 Steps to Better Code) http://www.joelonsoftware.com/ まずはプロジェクトの成熟度を評価しましょう
- 36. ©Yoshio Sakai CMMIと本プレゼンテーションの視点の違い - 比較項目 - CMMI 本プレゼンテーション アーキテクチャ 組み合わせ開発が前提 摺り合わせ開発を考慮 規模 組織全体に適用させる （大規模プロジェクト） チーム・個人にフォーカスをあてる （小・中規模プロジェクト） 設計手法 設計手法には踏み込んでいない 体系的再利用の設計手法を取り入れ ている 商品価値の視点 組織の成熟度向上が目的であり商 品価値には直接は結びつかない 商品の潜在的価値向上が目的 責任と権限 責任と権限が厳格である 責任と権限の曖昧さを許容する What/How あるべき姿を提示 (What) 具体的なActivityを提示 (How)
- 37. ©Yoshio Sakai
- 38. ©Yoshio Sakai 高信頼性ソフトウェア実現のアプローチの例 トップダウンアプローチ（Validation & Verification） ユーザーニーズに適合しているかどうかを確認するために、 Validation チームのレベルを上げる 商品に要求される機能のうち重要度の高い基本要件に対しては網 羅性の高いテストを行う 過去に起こった不具合の対策が実施されていることを確認する TopDownBottomup Reuse ボトムアップアプローチ（コードスクリーニング） コーディングルールの策定 客観的にソースコードをスクリーニングして、引っかかったものをコード レビューする ソースコードはルールに従って作るという習慣づける 体系的再利用アプローチ（プロダクトライン） ソフトウェアをモジュール単位／サブシステム単位で再利用を推進し、 再利用資産をマネージメントする 再利用資産をブラックボックスにしないことがポイント コア資産のシミュレーション環境も再利用の対象とする DEMO
- 39. ©Yoshio Sakai Software Validation の実施 Software Validation（妥当性確認） Validation は製品を開発するプロセスの中で、見落とされた真のユーザー ニーズや、安全性や信頼性に関わる危険性を摘出し対策するために役立ち ます Validation 実施グループ 組織成熟度の問題や開発期間が短いなどの理由で、信頼性向上の Activity を十分に実施できない場合は、Validation 実施グループを組織し、 Validation グループよるテストで不具合を摘出します これは、おそらくどんなプロジェクトでも経験的に実施していることですが、こ の方法が有効な理由は熟練したテスターがユーザービリティだけでなく、設 計者が想定しにくいユーザーの使用方法や誤用をシミュレーションすること ができるからです
- 40. ©Yoshio Sakai Validation 実施グループの簡易評価指標 Validationメンバーにユーザーが含まれている Validationメンバーに複数人のユーザーが含まれている Validationメンバーに製品が使われる場面をよく知っている開発メンバー が含まれている テスターがソフトウェア技術者である テスター経験5年以上のソフトウェア技術者である テスター経験10年以上のソフトウェア技術者である 製品のすべての機能を網羅した取り扱い説明書や機能仕様書がある テスターが製品を使ったランダムテストを実施した経験が3回以上ある 製品の入力に対して境界値を発生させる手段がある Software Validationを実施する期間が5日以上ある 評価点が４以下の場合は、Validation 実施グループを再編成する必要が あります
- 41. ©Yoshio Sakai Validation & Verification 計画の簡易評価指標 すべてのソースコードを一定の基準でスクリーニングするようになって いるか（レガシーコードを除外する場合はその理由が明確であるか） 正常使用における機能テスト計画はあるか Validation 実施グループに製品が使われる場面をよく知っている開発 メンバーが含まれているか リスク対策の実施を確認する計画になっているか システムの入力に対する網羅性は分析されているか システムの入力に対する境界値テスト計画はあるか Validation 実施グループ、テスターの要件は満たされているか
- 43. ©Yoshio Sakai １. 高信頼性ソフトウェアの定義と必要性 ２. 高信頼性ソフトウェア実現のフレームワーク ３. 日本のもの造りについて分析する ４．体系的な再利用によるソフトウェア信頼性向上の実践
- 44. ©Yoshio Sakai 日本のもの造り哲学（藤本隆宏著）から学ぶこと 東京大学COE ものづくり経営研究センター センター長 藤本 隆宏氏 日本経済新聞社 1,600- 日本の製造業について長年技術管理論や生産管理論を専門に研究された 藤本先生がさまざまな企業の開発部門や工場を実地調査した経験にもとづ き、日本、アメリカ、ヨーロッパ、中国のもの造りの違いについて分析していま す ソフトウェアに特化した内容ではありませんが、欧米発のソフトウェア開発手 法をそのまま日本の組込みソフトウェア開発に取り入れることが必ずしもベス トではないことがわかります 日本のもの造りの強みについて理解し、欧米発のさまざまなソフトウェア開発 に関する手法を日本向けにテーラリングすることが重要です
- 45. ©Yoshio Sakai 機能と構造の関係 モジュラー型（例：パソコン・システム） パソコン プロジェクター プリンター 演算 映写 印刷 インテグラル型（例：自動車） 走行安定性 乗り心地 燃費 サスペンション ボディ エンジン モジュラー型は機能とサブシステム が一対一になっている インテグラル型は機能とサブシステ ムの関係が一対多で、機能とサブ システムが複雑に絡み合っている 参照 日本もの造り哲学（藤本隆宏著） p125 図10 アーキテクチャとは何か
- 46. ©Yoshio Sakai アーキテクチャの基本タイプ クローズド・インテグラル型 自動車 オートバイ 薄型超小型家電 ゲームソフト 他 クローズド・モジュラー型 メインフレーム 工作機械 レゴ 他 オープン・モジュラー型 パソコン・システム パソコン本体 インターネット製品 自転車 他 モジュラー（組合せ）インテグラル（摺り合わせ） ク ロ ー ズ ド （囲 い 込 み ） オ ー プ ン （業 界 標 準 ） ※ 国 別 分 類 は あ く ま で も 参 考 で す 参考 日本もの造り哲学（藤本隆宏著） p132 図11 アーキテクチャの基本タイプ
- 50. ©Yoshio Sakai オープン・モジュールは日本の強みにならない Software Software (Closed Module) Hardware Hard ware Hard ware Hardware Software (Open Module) Software (Open Module) Software (Open Module) Software (Open Module) Hard ware Software (Integral) オープンモジュール のソフトウェアとそ の組合せ部分は商 品のオリジナルの 強みにはならない ノウハウとして外部に 流出させてはいけない 部分(Closed Integral の部分はもともと流失 しにくい) コア資産の組み合わせ 部は開発効率のために モジュール化すべきだ が、あくまでも Closed にしておく コア資産： コア資産は摺り合わせ 部と組み合わせ部両方 含まれるのが日本の強 い形
- 52. ©Yoshio Sakai コアアセットをどこにするかが大事 Software Software (Closed Module) Hardware Hard ware Hard ware Hardware Software (Open Module) Software (Open Module) Software (Open Module) Software (Open Module) Hard ware Software (Integral) 摺り合わせ部 コア資産： コア資産は摺り合わせ 部と組み合わせ部両方 含まれるのが日本の強 みを消さない 組み合わせ部
- 53. ©Yoshio Sakai Software SoftwareSoftware Software Software Software Software プログラムの汚さはユーザーには直接見えません 制約条件 CPUパフォーマンス ROM/RAMの容量 リアルタイム性 開発期間 コスト スパゲッティプログラム きれいに機能分割された プログラム コア資産を抽出した プログラム どんなにきれいなプログラムでも制約条件をクリアできなければ商品としての価値はないのです 不具合がある確 率は高いが・・・ Software Software (Closed Module) Hardware Hard ware Hard ware Hardware Software (Open Module) Software (Open Module) Software (Open Module) Software (Open Module) Hard ware Software (Integral)
- 54. ©Yoshio Sakai １. 高信頼性ソフトウェアの定義と必要性 ２. 高信頼性ソフトウェア実現のフレームワーク ３. 日本のもの造りについて分析する ４．体系的な再利用によるソフトウェア信頼性向上の実践
- 55. ©Yoshio Sakai
- 57. ©Yoshio Sakai １ｃｈ信号ノイズ除去装置のドメイン構造図 dd ドメイン構造図 1ch Noise Rejecter System RealTimeOS USBインターフェース ノイズフィルタ 信号入力 信号計測アプリケーション 波形表示 信号計測のコン トローラ ハードウェアに 依存するドメイン ハードウェアに 依存しないコア資産
- 59. ©Yoshio Sakai 仮想システムでフィルタの効果を確認する 要素技術としてフィルタを確認し、確認されたフィルタドメインをそのまま実システムに 使用する 要素技術の検討に使った仮想システムは、コア資産の検証環境として使用できる バーチャルシステム ハイカットフィルタA ファイルから 取り込み パソコンのディスプレイ ハイカットフィルタB 1Hz Sin Wave + 10Hz Sin Wave DEMO
- 61. ©Yoshio Sakai Filter A と Filter B の効果を試してみる カットオフ 4.3Hz のハイカットフィルタカットオフ 8.4Hz のハイカットフィルタ 10Hzのノイズが十分に除去されていない 10Hzのノイズが十分に除去された
- 62. ©Yoshio Sakai １ｃｈ信号ノイズ除去装置のドメイン構造図 dd ドメイン構造図 1ch Noise Rejecter System RealTimeOS USBインターフェース ノイズフィルタ 信号入力 信号計測アプリケーション 波形表示 信号計測のコン トローラ ハードウェアに 依存するドメイン ハードウェアに 依存しないコア資産
- 63. ©Yoshio Sakai cd 実システムと仮想システムを共存させた例 信号計測アプリケーション::MeasureSignal + MeasureSignal() + measureSignal() : void + activateHighCutFilter() : void + stopHighCutFilter() : void + stopMeasurement() : void + giveDataFileInformation() : void + getDelayTime() : unsigned short + getFastDataSet() : void + getSlowDataSet() : void + initializeMeasureSignal() : void + setBehaviorOnSystem() : void 信号入力::SignalProcessorOnSystem + <<pure>> getSignalData() : signed short + <<pure>> setDataInfomation() : void + <<pure>> initializeSystem() : void 信号入力:: SignalProcessorOnRealSystem + getSignalData() : signed short + setDataInfomation() : void + initializeSystem() : void 信号入力:: SignalProcessorOnVirtualSystem + BehaviorOnVirtualSystem() + getSignalData() : signed short + setDataInfomation() : void + initializeSystem() : void 信号入力:: SignalProcessorOnVirtualDemo + BehaviorOnVirtualDemo() + getSignalData() : signed short + setDataInfomation() : void + initializeSystem() : void ノイズフィルタ::HighCutFilter + <<pure>> doHighCutFilter() : signed short + <<pure>> getDelayTimeOfHighCutFilter() : unsigned short + <<pure>> initializeHighCutFilter() : void ノイズフィルタ::HighCutFilterTypeA + HighCutFilterTypeA() + doHighCutFilter() : signed short + getDelayTimeOfHighCutFilter() : unsigned short + initializeHighCutFilter() : void ノイズフィルタ::HighCutFilterTypeB + HighCutFilterTypeB() + doHighCutFilter() : signed short + getDelayTimeOfHighCutFilter() : unsigned short + initializeHighCutFilter() : void 1..*1 1..* 1 Template Method パターン Strategy パターン ファイルから 取り込み Ａ／Ｄ変換器 デモ入力波形 実システムと仮想システム を共存させるクラス構成
- 64. ©Yoshio Sakai １ｃｈ信号ノイズ除去装置の摺り合わせ部と組み合わせ部 Software (Closed Module) Hardware Hard ware Hard ware Hardware Software (Open Module) Software (Open Module) Software (Open Module) Software (Open Module) Hard ware Software (Integral) 摺り合わせ部 ・信号入力部 組み合わせ部 ・ノイズフィルタ ・信号制御アプリ USB インターフェース A/D変換器 Real Time OS
- 68. ©Yoshio Sakai 信頼性向上の Activity Map 機能設計 詳細設計 単体テスト 結合テスト システムテスト プログラ ミ ング Verification 不良 入り込み分布 不良 摘出分布 Software Life Cycle Process 設計努力 摘出努力 User Requirements Software ProductSoftware Validation Design Validation Verification Verification 要求分析 ＵＭＬ 構造化分析 レビュー，インスペクション ユーザー要求の分析 品質機能展開 プロダクトリスク分析 コーディングルール コードインスペクション 静的コードテスト、メトリクス分析 テスト レビュー，インスペクション 統計分析 不具合データベース 不具合発生・対策曲線 各種テスト 内部設計 Verification 不具合を 作り込まない努力 プロセスで抑える 不具合を 摘出する努力 再掲
- 70. ©Yoshio Sakai Appendix A 参考書籍 ソフトウェアプロダクトライン Pail Clements, Linda Northrop(著), 前田卓雄(訳) 日刊工業新聞社 藤本 隆宏:日本のもの造り哲学，日本経済新聞社 (2004). 組み込みUML 渡辺 博之 (著), 堀松 和人 (著), 渡辺 政彦 (著), 渡守部 和記 (著) 翔泳社
- 71. ©Yoshio Sakai Appendix B 酒井 由夫:人間の考え方，コンピュータの考え方, Software People，vol.4，pp.112-120，技術評論社 (2004). 酒井 由夫:組込みソフトウェア品質向上のためのActivity Mapping JaSST’05: Japan Symposium on Software Testing 2005 (2005). 保田 勝通:ソフトウェア品質保証の考え方と実際，日科技連 (1995) CMMI モデル-公式日本語翻訳版 http://www.sei.cmu.edu/cmmi/translations/japanese/models/index.html (2004). SESSAME:組込みソフトウェア管理者・技術者育成研究会(SESSAME) http://www.sessame.jp/ General Principles of Software Validation, Final Guidance for Industry and FDA Staff 3.1.2 Verification and Validation http://www.fda.gov/cdrh/comp/guidance/938.html 酒井 由夫:組み込み商品群におけるソフトウェアの妥当性確認 JaSST’04: Japan Symposium on Software Testing 2004 (2004). 酒井 由夫, 今関 剛他:具体例で学ぶ組み込みソフトの再利用技術 Interface，2003年12月号，pp. 67-137, ＣＱ出版社 (2003).