商品詳細
内容紹介 | |
---|---|
販売会社/発売会社 | 日本規格協会 |
発売年月日 | 2008/09/08 |
JAN | 9784542504530 |
- 書籍
- 書籍
トラブル未然防止のための知識の構造化
商品が入荷した店舗:店
店頭で購入可能な商品の入荷情報となります
ご来店の際には売り切れの場合もございます
お客様宅への発送や電話でのお取り置き・お取り寄せは行っておりません
トラブル未然防止のための知識の構造化
¥1,650
在庫あり
商品レビュー
4
1件のお客様レビュー
本書のサブタイトルは、「SSMによる設計・計画の質を高める知識マネジメント」です。つまり、SSMについて書かれている本です。 SSMとは、「Stress-Strength Model:ストレス-ストレングスモデル」の略で不具合の発生メカニズムの知識を構造的に表現するモデルのこ...
本書のサブタイトルは、「SSMによる設計・計画の質を高める知識マネジメント」です。つまり、SSMについて書かれている本です。 SSMとは、「Stress-Strength Model:ストレス-ストレングスモデル」の略で不具合の発生メカニズムの知識を構造的に表現するモデルのことです。 ★★★ 筆者は、「トラブル情報データベースはなかなかうまく活用されていないことが多い」と言います。そして、その問題点を解決するためには、 トラブル情報自体の設計への再利用性を高め、設計者に必要な内容を提供できるように情報自体のもち方を工夫しなければならない。では、その工夫とは何であろうか──それは、知識の構造化である。 と言います。 また、再利用性についてFTAと比較して、こう書いています。 トラブル情報の整理に役立つ構造化知識表現モデルとしては、FT図が挙げられる。FT図は、FTAの結果として表現されるツリー図であり、トップ事象として取り上げられる望ましくない事象の原因系を把握するうえではわかりやすい。 しかし、FT図は、因果を分節で切り出すという考え方がない。つまり、トラブル発生メカニズムの一部を再利用可能な知識として切り出して活用するという知識の機動的な動きは難しい。また様々な危機に再利用可能な一般的なトラブルメカニズムの知識を整理したいと考えても、展開という性質上、事象の対象を明確に定義する方法がないため、知識の一般性を明確に表現することは困難である。 なるほど、トラブル情報データベースから、再利用可能な知識データベースを構築するためには、「トラブル発生メカニズム(因果関係)を分節として整理する」必要があるのですね。 ★★★ それでは、SSMの構造化知識表現モデルは、【定義属性】、【制御属性】、【ストレングス】、【ストレス】、【不具合モード】の5つの要素から成り立っています。 【定義属性】とは、不具合モードの発生メカニズムの知識を適用する対象・アイテムの範囲を定義する属性のことです。 「どこで(定義属性で)、何が起きるか(不具合モードが起きる)」ということです。この定義属性を細かく定義してしまうと、「トラブル発生メカニズム」の適用範囲が狭くなります。したがって、定義属性はどこまで一般化できるかについて考え、広く定義する必要があります。 【制御属性】には、【定義属性】に対してどんなパラメータを選択(制御)することができるのかについて書きます。【不具合モード】が起ったポイント、逆に言うと起こらなくするために制御できるもののことです。 【ストレングス】は、【不具合モード】発生防止のために本来設計上確保すべき総合的な耐性や狙いの不足・不備のことです。簡単に言うと強度です。 【ストレス】は、【不具合モード】の発生要因となる制約条件・異常入力・制御できない条件のことです。簡単に言うと負荷です。 【不具合モード】は、説明するまでもなく不具合の内容です。 つまり、トラブル情報データベースのデータを、【定義属性】、【制御属性】、【ストレングス】、【ストレス】、【不具合モード】の5つのアイテムで構造化することで再利用可能な知識になるわけです。 文章で書くと、 【定義属性(トラブル知識を再利用する対象)】によって示される対象において、【制御属性(設計パラメータ要因)】の【ストレングス(耐性・狙いのまずさ)】の大きさが、【ストレス(運転条件・異常入力等)】に負けたため【不具合モード(望ましくない事象発生)】となった。 というようにまとめることができます(これを「相対的因果メカニズム」と呼び、他にも「絶対的因果メカニズム」と「断片的因果メカニズム」があります)。 ★★★ さて、ここまで読んでソフトウェアテスト関係のみなさんは、バグ情報データベースから、SSMの考え方をもちいて、ソフトウェアにおけるバグ知識データベースが構築できるのかどうかが気になったのではないかと思います。 【定義属性】と【不具合モード】の考え方(因果関係を再利用しやすい単位で切り出すこと)はそのまま使えると思います。 しかし、不具合モードの発生要因である【制御属性】、【ストレングス】、【ストレス】については、あてはまりません。 細川さんがバグ手帳にバグを記録していると言っていたそうですが、きっと散文的ではなく記録のポイントがあると思うんですよね。そういったものを持ち寄って不具合モードの発生要因の整理の仕方を考えたいと思っています。
Posted by