« 2013年4月 | トップページ | 2013年6月 »

2013年5月31日 (金)

ソフトウェアにおける「故障モード」

Facebookで知り合いの書き込みにコメントしたら、どうもソフトウェアにおける「故障モード」って整理されてない/一般的なものが存在しないようだと判明。探せば見つかるのかもしれないが、広まっているものがないように思えた。

ちなみに、CiNiiで「ソフトウェア FMEA」で検索すると19件、「ソフトウェア 故障モード」で検索すると7件ヒットした。未公開などの中に良い情報があるかもしれないが、読める論文だと、故障モードが詳細すぎる気がする。(今回ブログに書いたのは、それも理由。) またCiNiiで「FMEA」で検索すると249件、「ソフトウェア 故障モード」で検索すると119件ヒット。

と言うことで、自分の勉強も兼ねて、ソフトウェアにおける「故障モード」について考えてみた。本来は実機器や実システムでの故障モードを考えるべきとか考えるのが普通だけど、多少一般化できないかとの思いで記述。

ちなみに自分自身の「故障モード」やFMEAでの経験だけど、知識として知ってはいても実践はほとんど無い。実践と言っても、概算を机上で考えて重要そうなものを書き出す程度。装置やシステム全体のFMEAを全部記述して算出まで行うのは自分も経験無いし、ハード屋さんのそれも見たことがないように思う。(ハード屋さんは、MTBF算出の方が結構重要だったと思う。)


Fmea_pdf故障モードを具体的にイメージできそうに思ったものが左の二つ。


それぞれ、左の書籍での記載からである。

構成部品での故障を識別できる文言で記載し、上位構成要素(上位システムとか全体を含む)への影響を記載してある。他に発生頻度や重要度を記述し、その対応の必要性を検討する。例示したものは、分かりやすいと感じた。

ただし最初で述べたアクセスしやすい論文では、ソフトウェアのFMEAではトップダウンでのFTA手法と対比を意識するためか、細部の部品での故障に拘ることがあるようだ。ここで例示したような基板やある程度の機能の括りで考えた方が良い(と考える)。

また、記述する”故障モード”であるが、ソフトウェアの場合でのバグ分類のように分類する時/人がいる。仕様漏れで誤作動といった具合。それもおかしい。むしろユーザーとかサービスマン目線で考えるべきだ。(製造時のFMEAを検討する時があるけど、その件とは別で、あくまで一般的な故障モードでの話し。)

上記を敢えて書くのは、特にシステムの場合は、メカやエレキから構成される機器(サブシステム)や基板などが存在し、システムや機器の故障モードを考える場合は、メカやエレキによる故障モードと構成部品や故障の粒度を似たものにすべきであるためである。そうしないと”ちぐはぐ”になり、FMEAの結果を見るサービスマンなどが混乱してしまったり対応の検討も悪いものになる。

また、昨今ではクラウドを利用したソフトウェア開発が少なくない。その際にHDDやメモリーの故障は避けて通れないし、むしろそれを前提に設計する。それと同次元で、ソフトウェアの故障も考えて検討する意味でも、故障の粒度は似たものがよい。


さて、一般的な”故障モード”について。前述の「FMEA手法と実践事例」などでも記載されているが、「IEC 60812;FMEA」での”一般的な故障モード”は以下の4つ。

速めに動作
規定された時間に動作しない
規定された時間に停止しない
動作中の故障

ちなみにJIS Z 8115では以下のように表現している。

故障モード 故障状態の形式による分類。例えば,断線,短絡,折損,摩耗,特性の劣化など。

「FMEA手法と実践事例」では、IEC 60812;FMEAなどをもとに、それらを少し詳細化したり、電気系の機器ならこのような故障モード、電子部品ならこのような故障モードというのが参考として書かれている。例えば、電気系機器や電子部品での故障モードとしては、開放(断線)、短絡(出力が0)などである。


なお、従来のFMEAの考えは構成部品が上位へどう影響するの目線での検討であった。ところが、ソフトウェアの場合は、自分たちの構成部品でないものの影響で全体がダウンするなどがありえる。PCでの自分たちのソフト以外がメモリーやCPUリソースを喰ってしまい、PC全体がダウンするようなケースである。ある意味では、(自分たちの関与しない)他の構成部品からの”攻撃”で、自分たちの構成部品がダウンしてしまう。ウィルスが端的な例である。

ネットワークが絡むと更に”攻撃”への意識が必要な場合がある。具体的にはDoS攻撃などである。一般回線でない機器内のバス結合に近い状況でも、特定の構成部品の故障が結合路へ思わぬ負荷をかけたり、他の構成部品を故障や不正動作を誘発することがある。

CAN(車載ネットワーク)やフライバイワイヤー(航空機の操縦・飛行制御システム)のように、人命などに関わる機器での構成部品間のネットワーク経由での結合が普及している。特殊な通信経路や形態もあるが、汎用的なネットワークケーブルによるLANでのシステムも少なくない。また、機器内にそれらのネットワークを持つと同時に、サービスマン用やクラウドとの接続でWANと繋がる場合も多い。ネットワークに絡む故障モードは、大きな課題でもあり意識が必要とだろう。

他の構成部品や自分たちと関係しない部品やネットワーク経由の処理が、自システムや自システムに影響を及ぼす故障は、FTAでの検討も一つの方法かもしれない。FTAはトップダウン思考なのでマッチしやすいとの考えであり、FTAとFMEAとのハイブリッド的に考えた方が良いとの考えは組織体によるかと思われる。ただし個人的には、冒頭で述べたように、そう全体を整理することはないので、FMEAで”全体”(あるいは他からの影響)というものを構成部品に加えてボトムアップ的なFMEA前提で考える方がよいと思うのだが、、、。


さて、FMEAの検討の際によく利用されるのが、HAZOP(IEC HAZOP)であろう。以下で、HAZOPでのガイドワードをしめす。ちなみにこの一覧は、名古屋工業研究所の小川氏などによる表の、分類~外れの表現部分の抜粋である。


分類 誘導語外れの表現
存在 (existence)無 (no)質文は量が無い
方向 (direction)逆 (reverse)質文は量が反対方向
他 (other than) その他の方向
量 (quantity)大 (more)量的な増大
小 (less)量的な減少
質 (quality)類 (as well as)質的な増大
部 (part of)質的な減少
時間 (time)早 (early) 時間が早い
遅 (late)時間が遅い
順番 (order)前 (before)順番が前(事前)
後 (after) 順番が後(事後)


それらを踏まえて、ソフトウェアの故障モードの私案を示してみる。冒頭で述べたように本来は具体的な機器やシステムでのソフトウェア構成部品の故障モードで考えるべきだけど、ここでの故障モードはある程度汎用的と思われるものにしている。


故障モード 備考
ソフトウェアが存在しない(本来より少ない) 起動してない、起動後(他とのバージョン不整合などにより)自身でexit、killされた、、、
ソフトウェアが本来より多い (規定以上の)二重起動、終了せず
ソフトウェアが動いていない ハングアップ、(一定時間)応答無し、起動後自身でループなどで停止
リターン値が異なる 正しくない値をリターン
リターン値が異常 範囲外や型異常
リターン個数が異なる 多い、少ない
リターンデータが異なる 浮動小数点の微少部分、画像・音声データの微量部分、、
リターンデータが異常 リターンフォーマット異常
リターンタイミングが異なる 早い、遅い、順番が異なる、タイミングがブレル
アクセス異常 アクセスすべきでないものへアクセス。DBへのアクセス、フラグ/GUIなどデータ領域へのアクセス、他ソフトとの通信、他デバイスとの通信
アクセス方法が異常 物理的/論理的にアクセス方法がマッチしてない
アクセスしてない 物理的/論理的にアクセスしてない
アクセスデータ書き込みの値が正しくない値 間違った値のDBへの書き込み、データ領域への書き込み、他ソフトとの通信、他デバイスとの通信
アクセスデータ書き込みが異常値 異常値のDBへの書き込み、データ領域への書き込み、他ソフトとの通信、他デバイスとの通信
アクセスデータ読み込みの結果が異なる/異常 間違ったデータを取り込む。DBからの読み込み、データ領域からの読み込み、他ソフトとの通信、他デバイスとの通信
アクセスデータへのアクセスタイミングが異なる 早い、遅い、順番が異なる、タイミングがブレル

さほど多くない。逆に、もっと個数を絞っても良いかもしれない。(既に述べた、PCなりシステムがダウンするのは、これとは別に構成部品=全体として故障モードを考えればよい。そちらでの故障モードの個数は、多くても数個だろう。)

Facebookを契機にソフトウェアにおける「故障モード」を考えてみたけど、自分なりに気づきも出てきて勉強になったと言える。故障(モード)の検出を分かりやすくするには、どうしたらいいか。ここで示した故障モードでも、うまく区別しきれない状況もあり故障モードとして統合した方が良いのか、あるいは区別できる方法を考えるべきか、、、、。今回のをたたき台にして、ブラッシュアップすることも頭の隅に入れておきたい。

5月 31, 2013 ソフトウェア品質 | | コメント (1) | トラックバック (0)

2013年5月22日 (水)

「テストから見えてくるグーグルのソフトウェア開発」

今日、何気に本屋さんの本棚見たら、表題の「テストから見えてくるグーグルのソフトウェア開発」が1冊置いてあった。

平積みでなかったし、以前(今思えば予約注文だったか)にAmazonとかで見た気がしたので、結構前の出版かなと思った。

ところが巻末見たら、今年の5月23日の発行。パラパラと内容を読んだら結構面白そうで、則購入。

グーグルでの初期の頃のソフトウェア開発やテストの様子、そして現在のことが具体的に書かれてる。GmailやAndroid、インドなどいくつかのグループのテストのマネージャーとのインタビューがあり、話題も多岐に渡っている。

まだ全部読んでないけど、気になった事項をメモ。

・関連する職種として、SWE(ソフトウェアエンジニア)、SET(ソフトウェアエンジニアインテスト)、TE(テストエンジニア)。

TEが開発とは別の外部テストみたいに受け取った。ただし、ドッグフーダー(リリース前の社内利用者)や早期ユーザーとの協力関係もマネジメントするとのこと。

・テストを単体テスト/統合テスト/システムテストと分けずに、Sテスト、Mテスト、Lテストと表現。Sテストは(一般的な)単体テストというか自動テスト化。Lテストはユーザー視点でのシナリオテスト中心。システム全体のテストとして、Eテストなる呼び方のテストが最近出来た/言われるようになった。

・「プロトコルバッファ言語」なるものがある。公開されており、データ構造などの定義に使われる。JavaやPythonなど実際の言語での処理が、予め用意されてる(ひな形はある)感じなのだろう。 SETは、本コードの記述をレビューする。

・Buganizaerなるバグ管理システムがある。バグ票のフィールドで必須なものはごくわずかで、定義を曖昧にし、個々のチームがそれぞれのワークフローに応じて決めることができるようにしている。

・BITE(Browser Integrated Test Environment)と呼ぶ、ブラウザに統合されたテスト環境があり、テストの実践などをブラウザとクラウドで処理する。


インタビューなどの細部を含め、自分たちでも利用できそうな考えや手法などがちりばめられている感じがするので、じっくり読んでみるつもりだ。

5月 22, 2013 ソフトウェア品質ソフトウェアテスト | | コメント (0) | トラックバック (0)

2013年5月19日 (日)

GMarksと決別

今日GMarksでのブックマークを、Evernoteに移行を完了。本当は、1ブックマーク毎に1ノートにした方が良いんだけど、重要なものだけそうして、あまり利用しないものなどはタグでまとめたものを1ノートへ。

GMarksでのブックマークは、結構重宝してたもの。ソーシャルブックマークが一時期言われたときも、非公開のブックマークを前提としてるとか、コメントやタグなどが便利だった。また、Firefoxでのアドオンで右クリックでブックマーク登録できることや、それなりに安定してたのも良かった。

ところが最近、タグの変更がなかなかうまく行かない。WebでのGoogleブックマーク上での記述変更ならそれなりに動くんだけど、GMarksでのドラッグ&ドロップがうまく行かない。一度変更できたと思って、再度GMarksやWebでのGoogleブックマークで確認すると変更されてない。多少タイムラグかなと思って、翌日などに確認しても駄目。

色々試したし、他のソーシャルブックマークへの移行も検討。「はてな」が非公開登録が可能とのことで試したけど、結果的にはその都度非公開を選択する必要があるし表示がコンパクトに思えず、断念した。

ブックマークの件数が1000を越えていたり、何かの拍子に変な情報でWeb上のブックマークと差異が起きてるのかもしれないけど、それを調べる気力もない。さらっとGoogleのサイトを見たけど、掲載されてないし、Googleは多分本機能のメンテは優先度を下げているように感じた。

結局、Evernoteにすることにした。ほんとは、Evernoteで管理するのは例えばコメント上書きとかページタイトルの考え方などで使いにくい面のあるけど、仕方ない。また、1ブックマーク毎に1ノートにするのは、作業に時間かかるので重要とか使いそうなものだけにすることにした。

ネットサービスはサービス停止も多いし、ちょっとしたバグをなかなか直してくれないケースが多い。分かっちゃいるんだけど、実際作業する時はイライラしてしまう。まっ、これでイライラは一段落と言えば一段落。

5月 19, 2013 パソコン・インターネット | | コメント (0) | トラックバック (0)

2013年5月17日 (金)

「共通フレーム 2013」

とある所で「共通フレーム 2013」を見て、早速購入。ソフトウェアライフサイクルプロセスで、SLPC-JCF 2013。

ただし、この数日間で新宿の紀伊國屋と神田の三省堂に行っても、2013版は売ってなかった。2007の2版のみ。結局Amazon経由で、購入した。

理由は後述するけど、共通フレームに興味があれば、2007年の2版よりも2013版を入手すべきだ。

P5172547P5172548良い機会だったので、今までの共通フレームの本を並べて撮影。少し分厚くなった。

P5172549_22007年の2版から色々変更されているけど、自分が一番重要と思うのは左の写真。(スキャンでなくて、敢えてデジカメ撮影とした。)

上が2007年の2版で、下が2013年版。2007年でのピンク部分が、2013年版では大きく2つに分かれている。2013年版でのそのうちの上段がシステム開発での目線、下段がソフトウェア開発の目線(呼称的には「ソフトウェア実装プロセス」)である。

2007年の2版までは、ソフトウェアライフサイクルモデルをISO/IEC 12207に準じていた。ところが、”システム”ライフサイクルを定めたISO/IEC 15288が発行され、12207との整合性は当初から話題となっていた。 ちなみに2008年には整合性のために改訂されたが、整合性の第一ステップであり、共通フレームの改訂にまでには至っていなかった。(ISO/IEC 15288のJIS版で、整合性の件には触れていたはずだが、勘違いなら済みません。)

また、ISO/IEC/IEEE 29148があり、そちらは”要求工学”規格と書かれたりすることもあるが、原題は”Systems and Software Engineering – Life Cycle Processes – Requirements. Engineering”。つまりこちらも、システムまで含めた要求管理やライフサイクルの規格である。

今回の共通フレーム 2013では、ISO/IEC 12207と、ISO/IEC 15288やISO/IEC/IEEE 29148との整合性を図っている。ある意味では、”やっと”出版されたとの感想に近い。

ISO/IEC 12207が非常にまずかったのは、ソフトウェアが大きな1つの固まりのように捉えて、設計や実装、テストが進捗するように考えやすい点だ。少なくとも共通フレームなどの図をそのまま受け取って、そう思う人が少なくない。

今回は、上の写真が示すように、システム内のソフトウェアを実装するとの考えである。また、図ではシンプルに表せないので仕方ないが、ソフトウェアがいくつもあって、それらが並行して進捗するイメージである。ITシステムとか組込みでのシステムでの開発は実際はそうで、規格の方がそれらをうまく表現するようになったとも言える。(並行して進捗するイメージというかいくつかのサブシステムより形成されるという点は、規格での明示としてはISO/IEC 15288のJIS(JIS X 0170)での付属書が、参考になるだろう。)

その意味で、本屋さんに2007年の2版があったとしても、2013版を注文するとかネット経由で購入すべきだろう。特にソフトウェア開発を含めたプロセス構築やプロセス改善では、(2007年版ではなく)2013版を参考にしながら行った方が良い。


なおご存じと思うが、共通フレームワーク上のソフトウェア実装プロセスでのプロセスは(正式名称ではないが)以下であり、単体テスとか受け入れテストなどのプロセスはない。

・準備
・要件定義
・方式設計
・詳細設計
・構築
・結合
・適格性確認テスト
・導入
・受入れ支援

2007年版だと開発プロセスに該当するが、各プロセスは大きくは違わない。(2013版での構築プロセスが、2007版では”コード作成及びテスト”としているなどの違いはあり。)

つまり誰が考えても、開発プロセスに”受入れテスト”があるのはおかしい。受入れテストはユーザー側でのプロセスで、開発側ではユーザーへの出荷がOKかの判定とか、ソフトモジュールならリリース判定のようなものが該当するはずだ。ISO/IEC 12207や共通フレームワークでは、当初から”受入れ支援”とか”受入れテストの支援”という用語であり、あくまで”支援”という文言の付いたプロセスとしている。

”ISO/IEC 12207準拠”とか”12207でのプロセス”の文字の後に、(単体テストや統合テスト、)受入れテストが書いてあるのは、極論すると内容も眉唾と考えても良いことが少なくないのが個人感想だ。


「共通フレーム 2013」は、まださらっとしか読んでないが、随所に参考になりそうなネタも少なくない。じっくり読んだり、プロセス構築やプロセス改善の際には手元に置いて参照しながら作業したいと思う。

5月 17, 2013 ソフトウェア | | コメント (0) | トラックバック (0)

2013年5月 9日 (木)

「2013 Japan IT Week 春」見学

今日は東京ビッグサイトへ。「2013 Japan IT Week 春」の展示会見学。合計11の合同展示会で、今年から”通販ソリューション展 ”が加わった。

全体的には規模が大きくなったが逆に色々目移りして、帰ってから○○って見なかったかなとかで、反省する事項が2,3あった。個人的に「ソフトウェア開発環境展」と言うか開発環境の部分を気にしてたが、今までよりもさらに海外のオフショア系などを含む企業の展示などが多くて、少し期待はずれ。逆に後になって回った「組込みシステム開発技術展」の方の時間が無くなってしまって詳しく回れなかった。先に「組込みシステム開発技術展」を回った方が良かった。来年は、そうしようと思う。

以下断片的だが、記載する。何処の展示会だったかなどの記憶が不確かになっており、記載の順とブースとかは関連性は無いので、ご容赦。また、聞き違い勘違いも、ご容赦。

・インドのTATAのテストツールが出てた。横河のブース。自動テストまで行うとのこと。形式手法に置き換えてとのことで、TATAだったか他の会社のを昨年も目にした気がするが、横河のブースではなかったような、、、。少し意外だけど、(計測器や他のツールでの)顧客ニーズも絡んでいるのかもしれない。

・富士通は、世界初のトレーサビリティ技術搭載のPLEMIAなるトレーサビリデイツールを展示。これ以外でもISO 26262関連のツールは結構目にした。

・JDSはワンチツプAndroidを展示。Androidやアプリは固定を前提としているとのことだった。

・アマゾンウェブサービス(AWS)の展示があったが、アマゾン主体での展示と言うよりも、パートナー企業群による展示の様相を呈していた。

・オプテックスが製造し伊藤忠テクノソリューションズ(CTC)が販売する、3次元物体認識(距離計測)は、個人的には興味を覚えた。

・キヤノンソフトは、レクティファイ(Reqtify)を展示。Wordなどのドキュメントの関連を視覚化しトレーサビリテイを実現するための要件管理ツール。

 (あれっ、そう言えばと帰ってから調べたら、ダッソーシステムズの開発。ちなみにさらに元はGeensoftでの開発で、ダッソーがGeensoftを買収。)

・Sonitorは、超音波を用いたRTLS(リアルタイムロケーションシステム)を展示。部屋内の位置情報に適している。(電波ではないので、部屋の外に漏れにくい。)

・キングジムのミーティングレコーダーは少し興味がわいた。4面のWebカメラとして使え、TV会議での利用に良さそう。なお、元々は記録用の機械のため。少しずんぐりとした形状になっている。また、4面を余すところ無く撮影するために短焦点。なので書類などを写すと少しゆがみが大きく感じる。

・ルネサスでは、微弱な電波エネルギーの回収し昇圧する回路を開発し、マイコンを動作させる実験成功を展示していた。参考出品扱い。

・コンテックは、医療/看護/医事ICTシステム端末を展示。

・IBMはSPSSの隣にCognosを展示していた。2つの違いはと聞いたら、係の人はSPSSは未来の分析でCognosは現在の分析と言ってた。技術的に言ってもらえれば良かったんだけど、それだと分かったような分からないような、、、。

・来栖川電算の、1000sors/obj(オブジェクトセンサーズ)という物体認識エンジンも良かった。既にスマホで利用されているとのこと。

・NHKメデイアテクノロジーがWebベースの動画コンテンツ作成ステムを展示してて、NHKの展示が意外に思った程度で素通りしてしまった。少し内容とか画質などを見とけば良かったと反省。

・ネットエージェントでは、”トロイの木馬”を使ったPC乗っ取りの様子をデモしてた。目の前での実演だったし、Webカメラまで操作して見せてくれて、結構(相当)参考になった。


参考になる展示が少なくなかったが、冒頭に書いたように結構見学する時間が足りなかった。来年は回る順番や少し絞った見学をしたいと思う。

5月 9, 2013 技術 | | コメント (0) | トラックバック (0)