presentation title (on one or two lines)...title presentation title (on one or two lines) author...

不具合リスク発想のための観点の抽出方法とその効果

ソフトウェア品質シンポジウム2016

2016年9月15日（木）

（株）東芝余宮尚志東芝ソフトウェア・コンサルティング（株）小島昌一

© 2016 Toshiba Corporation



目次

• ソフトウェアFMEAの概要

• 観点リストとは

• リサーチ・クエスチョン

• 製品分野を考慮した観点リストの開発手順

• 観点リストの抽象度と開発事例

• ソフトウェアFMEAの評価方法

• ソフトウェアFMEAの評価結果

• まとめと今後の研究



ソフトウェアFMEAによって期待している効果

• 不具合の再発防止と未然防止の実現

• 開発効率の向上

– 後戻りの削減

• 分散開発管理の改善

– 思考過程の可視化

• 機能安全の国際標準規格への準拠

– IEC 61508, ISO 26262等


ソフトウェアにFMEAを適用するときの課題

ハードに比べて設計の自由度が高いため、考えるべき範囲や組み合わせが多い（限られた開発工数の中でやりきれない）

1. 故障モード（故障）の抽出が難しい

2. 実施工数がかかる

機能故障モード

データを送信するデータが送信できない

×発想が広がらない×壊れ方のパターンが定まらない（影響の評価や対策の検討も十分にできない）

ハードウェアソフトウェア

経年劣化あり経年劣化なし

物理特性の変化条件の組み合わせ

【故障の捉え方（例）】

部品の果たす機能の裏返しになってしまう

匠が最適な設計解を与えて解決してきた



ソフトウェアFMEAの概要

観点リスト

部品定義故障モード発想影響解析対策要求仕様

「ソフトウェア故障モード」の枠組み

技術要素・環境失敗メカニズム機能不全

何がどうしてどうなる

故障モードの発想容易化故障モードを抽象的に定義したリスト（ドメインごとに用意）

内部処理

論理演算処理

通信・データ伝送処理

数値演算処理

能力

スピード不足

容量不足

不安定

機能が欠落する

性能不足

異常終了

「何が」「どうして」「どうなる」

ソフトウェアにおける故障モードﾞとは？それを漏れなく洗い出すには？

観点リストを利用して発想（4つの発想手順を用意）

技術要素・環境起点（観点リスト）機能不全起点（観点リスト）シナリオベース事例起点



観点リストとは

• 故障モードを発想しやすくするための、技術的な観点（起点）を記述した目録

• ソフトウェアFMEAでは、以下の3つの属性を持たせている

– 何が（部品の特性）

– どうして（故障発現のメカニズム）

– どうなる（症状）



組込み一般向け観点リスト（一部抜粋）ソフトウェア品質シンポジウム2016


製品分野を考慮した観点リストの期待効果

• 組込み一般向け観点リストを使わず、製品分野を考慮した観点リストを使うことで、

– 製品の特性によって起こりやすい不具合の再発・未然防止につながる

– 開発組織やエンジニアの特性によって起こりやすい不具合の再発・未然防止につながる



リサーチ・クエスチョン

• 製品分野を考慮した観点リストを開発するための方法とは？

• その観点リストを用いてソフトウェアFMEAを実施した製品は、（本当に）品質の改善効果があるのか？

？



製品分野を考慮した観点リストの開発手順

（0） “組込みソフトウェア一般向け観点リスト”を用意する

（1）過去の不具合を真因解析し、その結果を3つの属性で表現する

（2）手順（1）に対する応用例・類推を考える

（3）手順（1）と手順（2）の結果を抽象化する

（4） “製品分野を考慮した観点リスト”に反映すべき結果を選択する

（5）手順（0）における組込み一般向け観点リストを更新する

• 経験や実績等をより活かすために、以下の内容も手順（1）に含める

– 過去のソフトウェアFMEAの結果

– 設計やソースコード等のレビュー記録

– エキスパートの経験や知見

– 関連製品の観点リスト（入手可能な場合）



適切な抽象度が必要

手順（3）における抽象度

観点は具体的過ぎると未然防止への効果が限られてしまう抽象化し過ぎると発想が難しくなる



（製品分野を考慮した）観点リストの開発事例（1）







不具合事例：あるシステムの入力値には文字コード体系Aを想定していたが、出力値が文字化けしてしまった。原因は、文字コード体系Bが入力値に混在されていたためだった。


観点リストにおけるグルーピング（例）

先述の事例では「表現」の階層化に「文字コード」「数値」「言語」等が表記できる

“なにが（部品の特性）”以外に“どうして（故障発現のメカニズム）”“どうなる（症状）”も同様にグルーピングできる



評価方法（その1）エンジニアの予測に基づいた評価

• エンジニアによるアンケート

– 故障モードの発現密度（ソースコードのステップ数あたりの個数）

– 新たに認識された故障モードの割合

– 市場流出が予想される故障モードの割合

– 実施工数

– 所感（自由回答）


評価方法（その2）市場における評価

A）同じ製品での比較（異なる部品での比較）

B）同じ開発対象での比較（過去製品との比較）

開発規模（ソースコードのステップ数）に対する不具合の発現密度で評価



評価対象製品

• 製品P

– ソフトウェア部品19

– 製品向け観点リストによるソフトウェアFMEAは4部品で実施

• 製品Q

– 製品Pと同じシリーズ製品で過去機種

– 製品向け観点リストによるソフトウェアFMEAは2部品で実施



• 新たに発見された不具合リスク： 0.45個／1人時• 組込み一般向け観点リストによる場合の実績値（平均）

： 0.39個／1人時

評価結果（その1）エンジニアの予測に基づいた評価

15％高い


エンジニアによる自由回答（抜粋）

• 従来まで想定していなかった故障モード（不具合リスク）を発想できたことを体感できた

• （再度仕様を検討し）仕様を厳密にできた

• 開発途中の（修正による）部品の差し替え回数が減少した

• 仕様上の不備をマニュアルやカタログの関連個所に早めにフィードバックできた

• 他の自社開発部品に展開していれば品質向上が見込めると感じた

• 開発初期の段階で課題が抽出できたことが早期対策につながった

• 既製品にも展開したい



• ソフトウェアFMEA実施部品：不具合無し• ソフトウェアFMEA不実施部品： 48ー123PPM

評価結果（その2）市場における評価

PPM: ソースコード100万行あたりの不具合個数を表す割合

再発防止及び未然防止に効果



品質改善プロセスへの適用

観点リストの更新によって、将来的な不具合の再発根絶と未然防止効果の向上



まとめ

• “製品分野を考慮した観点リスト”を用意する方法を開発した

• 実製品開発に適用し、不具合の再発防止と未然防止に効果があることが推察できた

– エンジニアの予測：新たに認識された1人時当たりの不具合リスク数が15％高くなり、開発中に市場流出の不具合リスクが抽出できた

– 市場における評価：ソフトウェアFMEA実施部品では、不具合が発生していない



今後の研究

• 観点リストを用いたFMEA以外のリスクアセスメント手法（FTA、HAZOP等）のソフトウェア開発への適用

• 観点リストの抽象度に関する基準の指針作成

• 観点リスト更新を伴うリスクアセスメント実施のソフトウェア開発プロセスへの適用推進


presentation title (on one or two lines)...title presentation title (on one or two lines) author...

Documents