Mais conteúdo relacionado
Semelhante a 高信頼性を確保するソフトウェア開発手法と実践-組込み製品の潜在的価値を今以上に高めるために- (20)
高信頼性を確保するソフトウェア開発手法と実践-組込み製品の潜在的価値を今以上に高めるために-
- 6. ©Yoshio Sakai
組込みソフトが原因になった不具合の例
公表日 製品種別 不具合の内容
2004.08.16 DVDレコーダ
DVDレコーダで電源がオン状態の時に録画予約メールを受
信できない
2004.10.04 デジタルカメラ
連続撮影中や、オートパワーオフ状態でレンズを着脱後、デ
ジタル・カメラが操作不能になる
2004.10.21 携帯電話
電話を発信するとほぼ同時に着信があった場合、電話帳の
内容が消失する
公表日 社名/製品名 不具合の内容
2004.03.18 英ジャガー「XJ8」など12車種
6速自動変速機で、勝手にギヤが3速に固定されたり後退に
入る
2004.08.31 仏プジョー「206」など10車種
電源制御装置の不具合により、リモコン・キーでドアロック時
にホーンが鳴り続ける
2004.09.14 独BMW「525i」など7車種
着座センサーの情報が感知できず、事故時に助手席エア
バッグが作動しない
携帯電話やAV機器などの故障を引き起こした事例
自動車のリコールにつながった事例
日経コンピュータ 2004.12.27 号 『組み込みソフトの巨大化に立ち向かう』 p119 より
- 9. ©Yoshio Sakai
組込み製品の価値とは
顕在的価値
ユーザーの本質的な要求
何をしたい? 何を解決したい? どうなるとうれしい?
要求を満たすためのサービスや機能
そこから導き出される製品の本質的特長
使いやすさ、わかりやすさ
潜在的価値
製品の品質(安全・信頼できる・壊れにくい)
保守性(故障しても直してくれる、直しやすい)
使い方の分からないところはすぐに教えてくれる
組込み製品が売れるためには “顕在的な価値” と “潜在的な価値” の両
方が高くなければいけません
作り上げた製品で顧客満足を高めることができなければ、何の意味もありません
顕在的価値
潜在的価値
- 22. ©Yoshio Sakai
リスク分析表を使った信頼性の向上
番
号
障害 原因 重要度
発生の可能
性/故障率
対策 実施確認の方法 チェック
No. Hazard Cause
Level of
Concern
Likelihood/
Failure Rate
Method of Control Trace Check
A-1 ヒータの異常加
熱により火災が
起こる
・サーミスタの故障
・ヒータの故障
High 1/10000
(故障率)
・ハードウェアによる対策
温度ヒューズによるヒータ
への回路切断
・ソフトウェアによる対策
ブザーによる注意喚起とエ
ラー表示(30秒)を行う.
設計書番号 #001
テスト計画 #001
□
□
・水の量が少ない
に加熱した
High たまにあり
(Moderate)
・ソフトウェアによる対策
第1水位センサがオフ状態なら
ば,ヒータや沸騰ボタンは動作
しない.
設計書番号 #002
テスト計画 #002
□
□
ヒータ制御ソフト
ウェアの安全対策
不備
High まれ
(Low)
・ソフトウェアによる対策
ヒーター制御値のマイナス値は
受け付けない
連続ヒーターONの時間に上限を
設ける
設計書番号 #003
テスト計画 #003
□
□
フィールドで起こった不具合の対策をコア資産に追加し、より強固なものにします
出典:Guidance for FDA Reviewers - Premarkrt Notification Submissions for Automated Testing Instruments Used in
Blood Establishments
例示
- 27. ©Yoshio Sakai
信頼性向上の Activity Map
機能設計
詳細設計 単体テスト
結合テスト
システムテスト
プログラ ミ ング
Verification
不良
入り込み分布
不良
摘出分布
Software
Life Cycle
Process
設計努力
摘出努力
User Requirements
Software
ProductSoftware Validation
Design Validation
Verification
Verification
要求分析
UML
構造化分析
レビュー,インスペクション
ユーザー要求の分析
品質機能展開
プロダクトリスク分析
コーディングルール
コードインスペクション
静的コードテスト、メトリクス分析
テスト
レビュー,インスペクション
統計分析
不具合データベース
不具合発生・対策曲線
各種テスト
内部設計
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
- 33. ©Yoshio Sakai
コーディングルールを定めているか?
障害票データベースを持っているか?
ソース管理システムを持っているか?
開発の節目節目でレビューを実施しているか?
スケジュール表を常に更新しているか?
仕様書を作ってからプログラムを書き始めているか?
プログラムを変更した後の回帰テストは実施しているか?
買える範囲で一番良い開発ツールを使っているか?
OJT以外に技術者教育のカリキュラムを持っているか?
テスト担当者はいるか?
1~4(レベル1)、 5~7(レベル2)、8~10(レベル3)
参考:ジョエル・テスト(The Joel Test: 12 Steps to Better Code) http://www.joelonsoftware.com/
まずはプロジェクトの成熟度を評価しましょう
- 36. ©Yoshio Sakai
CMMIと本プレゼンテーションの視点の違い
- 比較項目 - CMMI 本プレゼンテーション
アーキテクチャ 組み合わせ開発が前提 摺り合わせ開発を考慮
規模 組織全体に適用させる
(大規模プロジェクト)
チーム・個人にフォーカスをあてる
(小・中規模プロジェクト)
設計手法 設計手法には踏み込んでいない 体系的再利用の設計手法を取り入れ
ている
商品価値の視点 組織の成熟度向上が目的であり商
品価値には直接は結びつかない
商品の潜在的価値向上が目的
責任と権限 責任と権限が厳格である 責任と権限の曖昧さを許容する
What/How あるべき姿を提示
(What)
具体的なActivityを提示
(How)
- 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日以上ある
評価点が4以下の場合は、Validation 実施グループを再編成する必要が
あります
- 41. ©Yoshio Sakai
Validation & Verification 計画の簡易評価指標
すべてのソースコードを一定の基準でスクリーニングするようになって
いるか(レガシーコードを除外する場合はその理由が明確であるか)
正常使用における機能テスト計画はあるか
Validation 実施グループに製品が使われる場面をよく知っている開発
メンバーが含まれているか
リスク対策の実施を確認する計画になっているか
システムの入力に対する網羅性は分析されているか
システムの入力に対する境界値テスト計画はあるか
Validation 実施グループ、テスターの要件は満たされているか
- 44. ©Yoshio Sakai
日本のもの造り哲学(藤本隆宏著)から学ぶこと
東京大学COE ものづくり経営研究センター センター長 藤本 隆宏氏
日本経済新聞社 1,600-
日本の製造業について長年技術管理論や生産管理論を専門に研究された
藤本先生がさまざまな企業の開発部門や工場を実地調査した経験にもとづ
き、日本、アメリカ、ヨーロッパ、中国のもの造りの違いについて分析していま
す
ソフトウェアに特化した内容ではありませんが、欧米発のソフトウェア開発手
法をそのまま日本の組込みソフトウェア開発に取り入れることが必ずしもベス
トではないことがわかります
日本のもの造りの強みについて理解し、欧米発のさまざまなソフトウェア開発
に関する手法を日本向けにテーラリングすることが重要です
- 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)
- 61. ©Yoshio Sakai
Filter A と Filter B の効果を試してみる
カットオフ 4.3Hz のハイカットフィルタカットオフ 8.4Hz のハイカットフィルタ
10Hzのノイズが十分に除去されていない 10Hzのノイズが十分に除去された
- 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 パターン
ファイルから
取り込み
A/D変換器 デモ入力波形
実システムと仮想システム
を共存させるクラス構成
- 68. ©Yoshio Sakai
信頼性向上の Activity Map
機能設計
詳細設計 単体テスト
結合テスト
システムテスト
プログラ ミ ング
Verification
不良
入り込み分布
不良
摘出分布
Software
Life Cycle
Process
設計努力
摘出努力
User Requirements
Software
ProductSoftware Validation
Design Validation
Verification
Verification
要求分析
UML
構造化分析
レビュー,インスペクション
ユーザー要求の分析
品質機能展開
プロダクトリスク分析
コーディングルール
コードインスペクション
静的コードテスト、メトリクス分析
テスト
レビュー,インスペクション
統計分析
不具合データベース
不具合発生・対策曲線
各種テスト
内部設計
Verification
不具合を
作り込まない努力
プロセスで抑える
不具合を
摘出する努力
再掲
- 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, CQ出版社 (2003).