2015年1月20日 (火)

第12回クリティカルソフトウェアワークショップ GSNやIV&Vケースなど

今日は「第12回クリティカルソフトウェアワークショップ (12thWOCS2)」へ。ソフトウェアシステムでの信頼性・安全性の確保に関するもの。3日間のうちの1日のみ参加。

http://www.ipa.go.jp/sec/events/20150120.html


・アシュアランスケース入門

アシュアランスケースは、テスト結果や検証結果を利用者に保証したり確信させるためのドキュメント。具体的には、GSN(D-Case)という表記があるが、説明は主としてそれで行われた。その前段として、トゥールミンの三角ロジックが紹介された。自分としてはディベートでの反駁(はんばく)などがすっきり図示化できる~と、ちょっと感心してしまった。また、アシュアランスケースの標準化作業や認証関係も話が出た。


・セーフティとセキュリティ規格の同時認証方法論について

認証にお金がかかる話も行われ、似かよった2つを同時認証した具体例、またその課題が説明された。以前からセーフティとセキュリティに限らず興味のあった範疇なんだけど、一挙に実践へ向えない色んな事情も感じた。


・ソフトウェアIV&Vの基礎

IV&V自体の説明と、GSNをベースとした「IV&Vケース」の説明があった。


・第1回IV&Vコンテスト(電子レンジ仕様編)審査評・表彰

午前中に行われたコンテストの審査評・表彰。電子レンジの要求に対する検証結果などを確信させるコンテスト。うーん分かりにくいかな...。電子レンジの検証をGNS(IV&Vケース)で書いて、それを審査するコンテスト。チーム対抗で、出場したのは5チーム(だったと思う)。なお、コンテストへの参加はチームで応募するもので、コンテスト参加者のみが午前中に受講と作業。

IV&Vケースの実践的な場と思って、個人的に期待してたもの。ただし、電子レンジの検証全てにわたるわけではなくて、2つくらいの課題に対するIV&Vケースで、自分としてはなんで微細的な視点で考えるんだろうと、少し頭の中がもやもや。

後で、IV&Vケースの説明者に聞いたけど、IV&Vケースの使い方にも色々意見はあるそうだ。俯瞰的な利用の方を好む人もいるようで、自分もそのほうが良さそうに思った。(俯瞰的に眺めた上で、今回のコンテストの2つの課題を掘り下げて記述するのは構わないだろうが。)

ちなみに、本コンテストの優勝チームの1人は少し知った人だった。さすが。


GSNは、(複数の)モデリングツールで利用できるようになっているので、徐々に広まっていくと考えられる。呼称がそのまま広まるかは分からないが、IV&Vケースを実践していく事例も出てくるかもしれない。少し頭の隅においておくつもり。


Amazonでの書籍「ソフトウェア 信頼性 安全」


1月 20, 2015 ソフトウェア品質安心・安全ソフトウェアテスト | | コメント (0) | トラックバック (0)

2015年1月 6日 (火)

自己免疫疾患と品証暴走

今日ちらっと見たテレビ「家庭の医学」で登場したのは、SAPHO症候群。症状的には手足の関節痛なんだけど、リウマチ症などと少し違って皮膚系の症状も現れる。SAPHO症候群が”自己免疫疾患”であることが何度か番組で言われた。(ちなみに関節リウマチも自己免疫疾患かと思う。SAPHO症候群は、NHKの「ドクターG」に登場したようだ。)

医療系の番組で時々出てくる”自己免疫疾患”。外部からの異物への反応が過剰になって、症状を引き起こすというもの。しかも厄介な事に、ある病気と思って対処療法的に治療しても良くならずに色々調べたら自己免疫疾患のほうだったというケースが少なくないような気がする。あくまでTV番組などを見ての感想だけど。なお、ふと自律神経失調症なども含まれるのかと思って調べたら、基本的には含まないが、自律神経失調症の中のいくつかを自己免疫疾患に含めるという書き方のサイトもあった。


ソフトウェアに関しては、このような病気との関係では「ソフトウェア病理学」がピンと来る。ただし、この本では”過大な文書化作業”なる項目はあるが、ソフトウェア開発での自己免疫疾患のような事項は書かれていないようだ。

ソフトウェア開発での自己免疫疾患的な現象は、バグゼロを目指す余りにいつまでたってもテスト終了を出せないとか、静的解析でのワーニングゼロを目指すなどが考えられる。市場トラブルなどでバグが見つかってその対応は必要だが、ソフトウェアでのバグゼロが可能かは議論あるところ。むしろソフトウェア工学的には、「バグがないことは証明できない」が通説だ。

単純な論理構造の場合にバグがないことは言えても、どのシステムでもそうだとは言えない。昨今のように他モジュールや他サービスの利用が進むと、全体的なバグのコントロールはもちろん、(意図した時期のリリースのような)管理さえ難しくなる。

ソフトウェア開発以外でも製品企画や製品出荷、製品製造でも似たような事は発生して、いわゆる”過剰品質”。主体が品証とは限らないけど、声高に高品質が叫ばれ、商品化などがなかなか進まない。品証や品証気取り連中の、言わば暴走。

生物が生きてくために免疫は必要だけど、過剰になると弊害が大きくなる。しかも、その弊害が大きくなると直しにくい。(過度の)過剰品質は、その組織体での問題であり、積極的に対処すべきと考える必要があろう。過剰品質の問題は以前から言われてはいるけど、小さな場合(軽い症状)ならまだ良いが、大きい場合(重篤なら)は根本的な治療が必要だし最悪その組織体がなくなることも考えた方が良い。自己免疫疾がそうであるように、外見では自己免疫疾とは気づかない事もあるから要注意。

TVで「自己免疫疾患」が出て、つい考えてしまった。

Amazonでの過剰品質

1月 6, 2015 ソフトウェア品質ソフトウェアテスト | | コメント (0) | トラックバック (0)

2014年11月28日 (金)

サービスQC7つ道具って、無いんだろうか

今回の帰省での飛行機で少し驚いたのが、搭乗者の誘導を窓際の人から先にやったこと。窓際の人が先に搭乗して、通路側の人は後で搭乗するように、どこの列の人が搭乗して欲しい旨のアナウンスがあった。今までは番号の若い方(機首側)から搭乗させていた。

今回の窓際の人からの方が、着席した後で席に着く人のために立ち上がったりする必要がないので、当然メリットが大きい。なお、それを考えると、以前でも番号の大きい人(尾翼側)から着席するやり方を試行しても良かったかな~とか、さらに組み合わせて番号の大きい窓側からを先にした方が良いのだろうにとか思いついた。

いずれにしろ、定時運行のために工夫してたり試行錯誤したりしてるんだというのを実感した。逆に自分達は、そんな試行錯誤を目に前にしたら色々考えを述べることができるけど、普段はもっと良い方法があるだろうにと考えたり、それを航空会社に提案する所までにはなかなか行き着かないんだと感じた。

昔、工場とかでQC活動と称した改善活動が広く行われていた。今も実施してる所が少なくないかもしれない。サービス産業でもそんな活動が必要だし、増えてきたという感じ。ただ、ふと思うに、QC活動ではQC7つ道具とか新QC7つ道具があるけど、サービス産業でそれらをそのまま使うには適切ともいえない。

そんなツールを思い浮かべたら、検討などが効率よくなるだろう。サービス産業でのQC7つ道具(改善ツールと呼ぶべきかも)ってあるのか調べたけど、直ぐには引っかからなかった。じゃ、自分で考えてみるか~と思い立ったけど、直ぐにまとまらない。そもそも、いくつかをノミネートする段階にすらならない。7つに拘る必要は無いだろうけど、7つくらいが良さそうとは思う。

ちょっと長い宿題になるかもしれないけど、考えてみるつもり。

11月 28, 2014 品質 | | コメント (0) | トラックバック (0)

2014年7月 7日 (月)

「原産国表示」と「品質保証」 

自分の別ブログで「金針菜、湘南ポモロン、空芯菜」というのを書いた。

実は金針菜(きんしんさい)を買う直前に、中国産だったらどうしようと悩んだ。個人的な気持ちとしては、今回のに関しては珍しそうなので買おうと思っただけど、中国産ならわざわざ買う必要は無いと考えた。その時ふと浮かんだのは、台湾産ならどうしようということ。というか、台湾産って表記するんだっけ?  (ちなみに、実際はマレーシア産だった。)

ソフトウェアでの画面表示で、「国」として、その列に台湾があろうものなら、某国は大目玉。そのため、多少神経使ったり、実際に発生したら修正したりする。具体的には、「国」→「国もしくは地域」にするなど。

台湾での生産でも中国産ってするのかな~とか、できれば台湾産ってはっきりするのが良いよな~とか思った。そこで念のために確認したら、そもそも”原産国表示”のつもりで覚えていたけど、本当は”原産地表示”。つまり国ベースでの表記じゃない。

商標法での記述は、あくまで”産地”。また、以下の消費者庁の食品表示・原料原産地表示に関する情報でも原産地。
http://www.caa.go.jp/foods/index3.html

それからすると、商品パッケージで原産国としているのは、本来は間違いに近いと言える。


実は似たような話があって、良く”品質保証”と言ってるけど、ISOなどでは”品質管理”。ISO 9001は「品質マネジメントシステム」の規格だ。

ISOやJISの規格で、”品質保証”がタイトルになっているものに「JIS Z 9900:1994 品質管理及び品質保証の規格-選択及び使用の指針」や「JIS Z 9903:1998 品質システム-最終検査・試験における品質保証モデル」 などが存在していたが、今は廃止である。

ISO 9001の(JISでの)正式名称は、「JIS Q 9001:2008 品質マネジメントシステム―要求事項」である。(ISO9001:1994/JIS Z 9901:1998の時のタイトルは”品質システム”であった。)

今や部署名も、品質保証から品質管理となっている所が少なくない。あるいは、上位概念のコンプライアンスやユーザーといった用語を冠した名前にしているところもある。

部署名は品質保証のままでも良いのかもしれないが、”保証”するとのスタンスのままの所は少し問題。というか、それまでも保証できてたのか。あるいは、今まで保証していた製品やサービスと今の形態は同じなのかを自問すべきかと思う。あるいは、品質問題などユーザーへの対応への体制が十分か考えた方がよい。不良が見つかったら工場に文句言って直させるという感覚の時代から、発生率をウォッチしたり発表をどうするかなどを視野に入れた対応が必要な時代になってる。


原産国や品質保証のように、つい慣れ親しんだ用語で考えてしまうことがあるだろう。ただし、本質的な考えや世の中の方向は頭の隅に入れておくべきだといえる。ふとそんなことを思った。

7月 7, 2014 技術品質 | | コメント (0) | トラックバック (0)

2013年9月13日 (金)

いよいよ明日は イプシロンロケット再発射

8月27日に発射しようとして発射中止になったイプシロンロケットは、トラブル対策して、いよいよ明日に再発射の予定だ。

それにしてもイプシロンロケットは、昨年11月に職員の端末1台がコンピュータウイルスに感染し、外部に情報が漏洩した可能性があった。そして本来22日に発射予定だったけど、回路の配線ミスが発覚して27日に発射延期となった。新ロケットなので、その分トラブルが多いだろうけど、多少不運続きだ。(こうのとり4号機の大気圏突入での撮影装置機能せずも、ちょっとネガティブなニュースだ。) 金曜日にせずに土曜日にしたのは、対策確認作業や見学への配慮もあろうが、13日・金曜日は避けたかったというのもあるかもしれない。

ちなみに27日の発射中止は大きなニュースになり、ネットでの記事では「大丈夫か日本の技術」みたいなのまであって、流石にそのようなタイトルにはうんざりした。ちょっとした中止を元に、これ幸いと他の技術系の失敗例などで記事を膨らませている。自分たちのことを棚に上げたり、日本を萎縮させようとしているように思えてならなかった。


さて、27日の発射中止で色々原因を考えたけど、最初に目に着いたのは以下。

http://togetter.com/li/555075

最後の方の「ロールがプラスマイナス1度の範囲で閾値設定をしていたが、もう1度くらい回ってしまったような値が来てしまった」を、359などが返ってきたのだと考えた。-1なのに359みたいなこと。後々、ここでの”1度くらい回って”は、1度くらい傾いてみたいな意味と判明した。ほんとは傾いてるんじゃなくて、回転なので”回って”。それを1周りの360度と、つい考えてしまった。ある意味、ありそうなバグなので。

その後、遅延が理由と発表された。ただ、ここでも、しきい値±1度みたいな言い方がされた。2度に対してしきい値±1度と言う表現。多少、その表現で混乱した。本来は、許容範囲±1度として、しきい値は1度~3度と言うべきだ。JAXAの発表でも、2度に対してしきい値±1度みたいに書かれてて、それがネット記事などになったように思う。

ちなみに、なぜ0度から2度に変更したかがはっきりせず、個人的には色々思いをめぐらせた。最初は、追跡用アンテナが違ったのかもと思ったけど、2度は微々たるもの。ありえるのは、内之浦内のアンテナで変更したかなくらいだった。あるいは、イプシロンロケットは固定燃料だけど垂直発射なので、何か計算間違いが判明したのかもと考えた。ただ、今は、ランチャーの回転が180度であるべきなのに、182度あるいは178度しか回ってないのかもしれない。1度レベルの精度出せないのかもしれない。素人考えだけど、そう高い精度が必要な箇所でもないだろうから、それ自体は構わないように思える。

また、そもそも起動した後に起動して、タイマー(時刻)が0.07秒違ったままというのも少し違和感があるが、そこの部分の対策は難しいというか手を入れられないのだろう。そのためもあって、監視側のロケットからのタイマー(時刻)監視をずらす対策とのこと。

ちなみに、直近で対策方法が参考になると思ったのは以下。ロケットの搭載計算機(OBC)からの情報が、タイマーも含めて分かるように図示してある。

http://news.mynavi.jp/articles/2013/09/13/epsilon_measure/index.html


再発射、うまく行くと良いな。

9月 13, 2013 品質テクノロジー | | コメント (0) | トラックバック (0)

2013年8月22日 (木)

ソフトウェアのお掃除タイミング

しばらく前から気にしてた事項に、ソフトウェアのメンテナンス時期があった。OSSなどを使っていたらセキュリティパッチの情報により、更新したりが必要である。プロダクトラインでの管理をしていたりそうでない場合でも、他機種での変更情報が自分担当の機種に関係するかが気になったりする。

開発中や直近で出荷したものならまだ開発メンバーもいるが、出荷後に期間を経た場合はメンバーが別部署に異動しているケースもある。あるいは退社したり、委託先の会社が消滅していることもありえる。

組込み機器の開発でない場合でもセキュリティパッチへの意識は同様だし、ITシステムの場合は利用側からの変更要望が発生したりする。

セキュリティパッチの場合は、パッチ発生の度に対応していたら効率が悪いことがある。再テストもそうだし、多少厄介なのがパッチリリース自体にバグが潜んでいるケース。かといって対応を延び延びにしていては、忘れてしまったりして重要なトラブルになってしまうことがある。次機種や次のITシステム開発の場合でも、従来のソースコードを見直さないと潜在的なバグが次機種などで発生することがあったり、リファクタリングのための工数が見極めにくい。

つまり、問題発生時や新機種/新システムの開発に向けてのソースコード見直し以外に、ソースコードを綺麗にしたり問題点を見つけておくことが必要だ。ソフトウェアのメンテナンスをコンスタントに行っておく意識が必要。また、集中的なソースコードレビューは行われるだろうが、どうしても重要な部分に限定されたり、時が経つと修正などが入ることがある。自分の経験則では、リーダーのような直接タッチしてない人が何気にソースコードを眺めた時にバグやコーディングルール逸脱が見つかることがある。そう考えたら、ふと家事の特にお掃除のスケジューリングってどうしてるんだろうとか、どう教えてるのか気になった。


で、自分の卒業した高校には、当時”家政科”なるものがあって、同窓会のちょっとしたイベントの時に聞いてみた。「授業で、家事のスケジューリング方法とか教えた?」と。返事としては、習わなかったし実際の主婦でもスケジューリングまでやってる人は少ないかもとのことだった。ある意味、予想どおり。

そこで、ネットで調べると授業の格好でまとまっているのは見かけなかったけど、個人ブログで各自の工夫として掲載しているのはいくつか見つかった。もっと良いのがあるかもしれないが、見かけたのは以下。

http://kajirakuraku.com/cleaning001.html
月と週でスケジュール表を作ってみようというもの。

http://ameblo.jp/kajino-chie2525/entry-11442422842.html
どちらかというと、年/月レベル主体でのスケジューリング。

http://ameblo.jp/logica/entry-10460566887.html
ファストフード店などの掃除の仕方を参考にして、表に掃除する日をマークして、実施したら名前を書くようにしようとの提案。

皆さん、それぞれ工夫している。


そうこうしているうちに気になったのが、事業所での掃除や害虫駆除。法律での背景があるように聞いたので確認してみることにした。(法律が根拠と思ったけど、実際は法律に直接書かれているわけではなくて、基準での運用だった。)

http://www.sharosisikaku.com/backnumber/anneihou/20060318.html
掃除や害虫駆除に関してフランクにまとめてあった。

http://www.mhlw.go.jp/bunya/kenkou/seikatsu-eisei10/
厚労省の「建築物環境衛生管理基準について」のページ。

半年に1度は大掃除をして、害虫がいないかの調査をしなさいとある。


他を参考にする限りでは、曜日や月を決めてソフトウェアのメンテナンスをするのが良さそうだ。また、それらはソースコードをいじっている人以外も巻き込んでスケジュール案を検討するのがよいと言える。暗黙なり明確に、その組織体でルールを決めて実施したかの確認まで行と良い。

(掃除をしたかしないかが一目瞭然なように)ソースコード上のどこを見直したかが視覚的に分かるように工夫したり、出荷後に期間を経た場合でも定常的な業務項目としてノミネートしておくなどすれば完璧だろう。

追記:2013/12/18のNHK「あさイチ」で、掃除術を放送していた。

http://datazoo.jp/tv/%E3%81%82%E3%81%95%E3%82%A4%E3%83%81%28%E6%B0%B4%E6%9B%9C%E6%97%A5%29/689108

その中で登場したのが”予定掃除表”。冷蔵庫や換気扇の掃除予定に○をつけておき、実施したら塗りつぶすというもの。予定の横軸は、曜日だったように思う。

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

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年3月13日 (水)

軽めの品質のために

先だってのセミナーも含めて、以前からソフトウェアに対して、軽めの品質管理やテストをどう考えたらいいか思いをめぐらしてた。技術的な考えは後日にでも記載するけど、今日は、アナロジーとして的確と思えるのを見つけた/考えついたので紹介する。

自分自身が少し体育会系なので、以下の「陸上競技ルールブック2012」。(年度でタイトル変わってるかもしれない。)

http://www.jaaf.or.jp/athlete/rule/

ここに”第3部 トラック競技”と”第9部 クロスカントリー競走”があり、さらっと対比してみると良い。そもそもページ数が、38ページと4ページ。トラック競技だとmm単位の記述。クロスカントリーはシーズンだって”冬期期間に行われるべき”とか、”魅力的な”や”おおよそ”なんていう非常に曖昧な表現などが目に付く。

自分でも正確に知らなかったけど、トラック競技での風速測定は定められてて、100m競技だとスタートから10秒間。スタート前の計測でもないし、全員ゴールまでの時間でもない。当然だけど、スタートの記載は”スターターの信号器の発射(閃光/煙)”。

クロスカントリー競走は大抵芝生の所で開催されているけど、ルールブック上は”可能な限り草で覆われた”との表現。自分が事前に想定してたよりも、遙かに記載がアバウトだった。


でソフトウェアの世界では、ここでの例の、クロスカントリーの競技のくせにトラック競技のルールブックで話す愚行を行ってるケースがあまりに多い気がする。

そもそも、競技種目に相当するユーザや必要とされる使われ方が異なるのに、つい同じ土壌(例だと陸上競技)で括ってしまう。それなりの素地(元々のメンバーの能力とか今までの信頼性)があった上で厳密な手法などを話すのならいざ知らず、より高度な技法の説明に終始することもある。せっかくクロスカントリー競技で競う/楽しもうとしてるのに、妙にトラック競技のmmの話を持ち出されて興ざめするようなシーンに近いだろうか。

背景としていろんな手法や技法を知っておくのは良い(悪くない)が、組織体内の議論やセミナーでのグループ討議のための情報では、その組織体やグループに応じた手法や技法を元に議論すべきと考える。

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

2013年1月22日 (火)

パッチリリースでのバグ(予防保全とバスタブ曲線)

以前「再考 バスタブ曲線」「ソフトウェアバグとバスタブ曲線」で、バスタブ曲線のことを取り上げたけど、今日興味あるサイトを見つけたので紹介。

http://blog.goo.ne.jp/plant-alpha/e/9b248baf1e47d90f75872f0ae03f0c32

プラントのライフサイクルに関する技術コンサルティングの会社の人のブログ。

7e4d0758e4854e0955d2172a7203d37c特に、その中での左の図。

偶発故障期間に、予防保全を行ったことでトラブルが発生していることを示している。また、その先の方の記述で、むやみに予防保全をすることが、逆にトラブルの頻発を招くことが示されている。


で、この現象は、市場トラブルで対策パッチを出したのに、それが更にバグを引き起こす現象に似ている。よく回帰テストが不十分だったために起こることがあるが、パッチ部分での修正にも一定確率でバグが入っているとの統計的な側面で考えても納得できる話である。

最近一定期間ごとにバージョンリリースするソフトウェアが、ポツリポツリと出てきている。本カーブを考えると、本当に市場投入した方が良いかとか、その期間が適切か再考すべきだろう。

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

2012年12月16日 (日)

ドキュメント作成やレビューでのイライラ

最近、自分の資料作成や他人の文書レビューに参加して、ちょっとイライラ。自分や相手そのものへのイライラではなくて、文書がうまくまとまっていないとか、ロジックがおかしいと感じてのもの。「そういえば」と、とあるプロジェクトでの様子を思い出した。他のプロジェクトでも大なり小なり発生。むしろ、設計書作成や設計ドキュメントではイライラするくらいが正常と思うようになった。

どういう事かというと、ドキュメント作成時には、そもそもどうまとめるかで議論沸騰。章立てを決める前後は、どこに何を書いた方が良いか悩みが発生する。章立て(見出し)の階層レベルをどうするかも、キーポイントになる。しかも章立てしながら、新しい要望や実装に関する制限が頭に浮かんだりする。

実は、要求工学とか要求開発で、その辺りが知識体系(BOK)として明快な答えが得られるかと思ったけど、無理そうだ。要求開発とかでの妥当性確認(validation)とは、整理された要求項目がユーザ要求と合致しているかとか、ソリューションがユーザ要求と合致しているかの確認である。後者では、元々のユーザ要求というよりも、合意されたなり設計上のユーザ要求と考えて良いだろう。

ちなみに、一般的に「実現性確認」という言葉もあり、ユーザ要求に対するシステム設計が実現できるかの確認を行う。通常は、実現するためのコストなども加味した確認を行う。

当初書いたイライラや悩みは、製品開発の初期にどうのような製品にするかも漠然としている状況で、言わば実現性も検討しながら製品仕様をまとめ上げる過程での悩みである。(ITシステムだと、むしろRFP(提案依頼書)をうまくまとめ上げる作業での悩みに近い。)

小説や映画(文書としては台本というべきか)での生原稿で、いくつも朱書きがある状況がイメージしやすいかも知れない。その後、いく度も推敲を重ね、編集や校正の人の手を経る事になる。

上記で章立てと書いたが、設計とか提案依頼書の作成は複数人で行う事も少なくないので、その作業分担も関することも悩むところである。複数人での作業では、記述の詳細化レベルや表現もばらばらなこともあり、読む側にとってはそれらも気になる。(かと言って、それらの整合性のために余り多くの時間を割くわけにも行かないというのが実情だ。)

逆に、ドキュメントを小さなボリュームの文書に分割して、各々を一人程度で作成することが行われる。それぞれの文書を、それぞれレビューする事が多い。個人的な見聞きでは、大枠が決まってない状態でこれをやると、作業は進んでいるように見えても、ほとんど後々うまく行かなくなる。

設計書や提案依頼書のまとめ上げ方は、案外その組織体での大きなプロセス資産だと思うのだが、どうだろう。


蛇足1:後付でドキュメントを書くことがある。特に多いと感じるのは、システムのちょっとした変更だが実装による制限発生とか使い方での注意点の追記記述。良い例か分からないけどタイムリーなのは、2013年3月のIC乗車券の全国相互利用だろう。システム的には微細な変更だろうが、利用者に分かりやすく説明したり制限を正確に記述するには大変な作業と思われる。設計サイドで書くよりも、ライターとか品質部署の目線での記述が良いかもしれない。あるいは、設計含めたそれら複数グループの協業。

蛇足2:仕様の抜けや漏れが無いようにと言うけど、新製品の適用市場や対象ユーザの想定における抜けや漏れへの意識/(ちょっとした)対策も、結構役立つことがある。

12月 16, 2012 ソフトウェア品質 | | コメント (0) | トラックバック (0)

2012年12月 7日 (金)

ソフトウェアバグとバスタブ曲線

昨日「再考 バスタブ曲線」を書いたけど、そこで少し触れた、ソフトウェアのトラブルとバスタブ曲線に関して、、、。

ソフトウェアの出荷後/リリース後のトラブル(バグ発覚)は、ソフトウェアの経年変化がないので、終盤の故障率アップは無い。出荷直後やリリース直後は、テストが不十分だったりしてバグが発覚する。そしてバグ対策されて、トラブル件数は減ってくる。

その意味では、初期辺りは、バスタブ曲線に合致する。その後は安定して利用され、故障率ゼロに推移する。それがその商品やシステムの寿命まで続く。それが、一般的と言えるかも知れない。あるいは理想。

ただし、現実は、そうならない。

1)偶発期間でも一定の故障率

某OSを含めてセキュリティパッチのことを考えると、一定の故障率が続くと考えた方がすっきりするように思える。

ただし、ひどいのは、バグが継続するケース。そもそもテスト不十分等のままでリリース。修正バージョンを出すけど、修正ミスがチラホラ、デグレード、、、、。(製品回収やサービス停止も視野に入れた)抜本的な対策が必要なケースだ。

2)スポット的な故障発生

安定して使われても、時々トラブルが発生してしまう。(当時の開発メンバーが移籍したりしていることもあり、対応が厄介なケースになることもある。)

良くあるケースとして思い付くのは、システムでのデータ量の増大、外部記憶装置の容量不足、ログの増大などがある。

バスタブ曲線に関連したものとして、部品や機器の故障へのソフトウェアの対応が不十分で、それがトラブルの引き金になる時がある。結構対応やテストをした場合でも、複合的な故障の発生への対応が不十分だったり、想定される故障順番と異なった場合の対応ができていないことがある。後者では、故障率や部品耐用年数のデータでは、Aが故障してBが故障するという想定だったのに、いきなりBが故障するケースなど。

現用/予備の切り替えでのトラブルも、この範疇かも知れない。ただし、この類のトラブルはニュースレベルで目にすることが多いので、世間一般としては設計やテストが不十分と思われかねないジャンルである。

また、運用部門が(組織変更等で)結果的に不慣れとなり、思わぬ操作をして潜在的なバグが発覚することもある。一時的な対応として操作等で回避していたものが恒常的な対策を行わなかった&回避操作をうまく伝達できていなかった事でのトラブル発生もある。


基本的な確認を行わなかったなどは論外としても、見つけにくい/見つかりにくいケースもある。ある程度のレベルの組織体でも、時々発生する。ソフトウェアやシステムの設計やテスト、そして運用では、ソフトウェアの外部が(長いスパンをかけて)経年的に変化する事への対応を検討しておくべきだ。


追記:「日経 SYSTEMS」の2011年2月号(P52)に関連しそうな図が出ていたので紹介。”ノコゴリ曲線”。

2011___systemsp108_場当たり的な改修でトラブルが継続するし、終盤で保守が困難となることを図示している。

本ブログで述べたことは、ここでのノコギリ状態で、トゲのようなスパイクとして発生すると考えればいいかもしれない。多少地震のように、小さなトラブルが兆候として発生することもあるだろうが。なお、通常ならここでの保守困難期でのトラブルは少なく、システムとしての終焉を迎えるし、それを想定するだろう。

逆に、安定期でトラブルが頻発したり、周期的であれば、改修や元々の設計がまずいかも知れないと考えるべきだろう。また保守困難期が発生するかも知れないとして、新システムへの移行などを含め、その対応を検討すべきだろう。


追記:「ソフトウェアの経年変化がないので、終盤の故障率アップは無い」って書いたけど、そのソフトウェア(あるいはシステムと言うべきか)が使用できなくなる状況は発生する。具体的には利用しているOSのサポート切れ。組み込んだオープンソースを含むモジュールが利用できなくなるケースなども該当するだろう。また特にシステムの場合、一般的にメンテナンス契約があり、ソフトウェアはその期間まで動作することになる。

それらを考えると、ソフトウェアのバスタブ曲線は、稼働率のカーブと言えなくもない。あるポイントを0%としてX軸を稼働率100%とすると、従来のバスタブ曲線のように下に凸のカーブとなる。提起メンテナンスなどがあるのなら、想定時間に対する稼働率とすれば、トラブル無しなら100%稼働を意味することになる。

12月 7, 2012 ソフトウェア品質ソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年12月 6日 (木)

再考 バスタブ曲線

2、3ヶ月前から、バスタブ曲線ってなんだろうと考えるようになった。バスタブ曲線は、最初は故障が多くて、その後安定、そして終盤に再度故障が増えるというあの曲線。

ウィキペディアでの解説は以下。
http://ja.wikipedia.org/wiki/%E6%95%85%E9%9A%9C%E7%8E%87%E6%9B%B2%E7%B7%9A

ウィキでの図が左だけど、一般的には右の方の図(http://www.eonet.ne.jp/~hidarite/ce/anzen05.html より)に馴染みがあるだろう。

400pxbathtub_curveBathtab01

ちなみに調べてみたら、初期とか終わりの方を直線で近似している図やその傾きを元に議論しているページもあった。


バスタブ曲線自体は何となく理解できるけど、最近バスタブ曲線の元々の”意図”や特に終盤(摩耗故障の発生する期間)での実計測したデータがあるんだろうかとか考えたりして、いくつか素朴な疑問が湧いてきた。(他にソフトウェアとの関係にも思いを馳せたが、そちらはまた別途。)

1)この図は、製造者側への図? 消費者側への図?

2)この図は、1つの装置や製品での故障を示している? あるいはいくつかのロットでの故障を示してる?

3)故障ではなくて、部品交換の必要性を言いたい?

製造者側にとって、装置や製品が終盤で故障が増大してしまうことへ対応することは考えにくい。右の図で言えば、耐用寿命を偶発故障期間内にしようとするだろう。

消費者にしてみれば、購入した商品/製品が最初故障だらけで、使用していても故障が起きるとなると使い続けるだろうか。保証期間内なら無償修理だが、消費者自身にとって許容できる故障率は低いはずである。そもそも初期不良なら交換だろう。初期に何度か(例えば2、3回)故障したら、交換とかキャンセルになる可能性がある。終盤でも同様かもしれないが、むしろ終盤では製造中止になってるであろうから、(部品保存期間内で修理してもらうとしても)使い続ける事が現実的には皆無である。

さらに言えば、消費者の手元で実際に使う商品が、初期に使っていて故障率が下がることは考えにくい。昔であれば真空管とかが安定して画像や音質が良くなるとかはあったかもしれないが、それらを故障の低減と呼べるか疑問である。また、昨今での電気製品等ではデジタル化が進んだこともあって、使用して性能がアップすること自体が考えにくい。そう考えると、バスタブ曲線は、消費者の購入した各商品/製品の故障頻度を示しているとは考えにくい。

例えば、自分の購入した時計、テレビ、自家用車などの故障が、バスタブ曲線に当てはまるか考えてみると良い。多少購入直後に故障に遭遇するだろうけど、1,2回と離散的なのが普通だ。しばらくしての偶発故障期間の時での偶発故障に遭遇することがあるか、、、。自動車でのブレーキの利きが悪くなったなどはあるだろうが、それを故障というべきなのだろうか。調整の範疇とも言えなくはない。個人購入の商品の範疇で、その商品がバスタブ曲線に沿って故障するようなものを思い付かないのが実情だろう。(あったら教えて欲しいくらい。)

製造者から見た生産でのロットも同様で、同一ロットで部品交換による故障率低減が現実的か疑問に思えた。故障が多いと、そのロット全体の出荷停止などが行われる。管理上も、同一ロット内で細部の故障率低減を図るより、次ロットで部品を変更して故障率の低減を図るだろう。

つまり、バスタブ曲線は、その製品のライフサイクルでの故障率と考えるべきだろう。多少最初の頃は各ロットでの故障率があるが、いくつかロット生産するに従い故障率が低くなる。

製品のライフサイクルの他には、ビジネスユースの機械等で保守契約の形態のものは、バスタブ曲線の前半部分は当てはまるかも知れない。特に新規開発だと部品が安定しないので、メンテナンスでカバーする。偶発故障期間内は、各部品のMTBFなどを元にして交換して駆動させる。


そうなると、バスタブ曲線での終盤(摩耗故障の発生する期間)での、市場での故障率を上げない(偶発故障期間内程度に抑える)にはどうすればいいか? 故障率が上がることを部品交換で対応することが考えられるが、現実的だろうか? 特に部品コストとかそのための人件費、さらには技術革新で当時の部品そのものが入手できない事態は充分に考えられる。

その対応として、”モデルチェンジ”が行われていると考えるが、どうであろう。いくつかのロットを経て故障率を下げたとしても、初期のロットは経年により故障率が増えてくる。いくつかのロットで生産しても、傍目にはその商品の故障が増えてくる。傍目でも違いを分かるようにするにはモデルチェンジが一番妥当と思われる。ビジネスユースの機械等では、商品(システム)の寿命を見越しての計画を考えるし、想定とずれた場合には次期商品(システム)への移行の交渉も一つの手段と言える。

そんなことを考えたら、バスタブ曲線は、現象の説明と言うよりも、初期や終盤の故障率への対応を検討する材料に思えてきた。計画時の想定もそうだし、想定と実際の故障率の乖離の計測やそれへのリスク対応の検討などだ。

ちなみに、市場故障率の測定や判断のためには”ワイブル試験紙”が使用されることが多い。実際に品質部門で利用しているところも多いだろう。偶発故障期間内に該当するかの判断に利用していると考える。ちなみに個人的に、ワイブル試験紙とバスタブ曲線とを関連づけたりバスタブ曲線の曲線関数が無いのか気になったけど、まだ見つかってない。


さて、以前から社会インフラでのバスタブ曲線も頭の隅にあったが、ここ2,3日では笹子トンネルの事故が発生して、多少確信めいたことに気が付いた。ビルやトンネルの建築物も、故障という点ではバスタブ曲線に絡めても良いかもしれない。当初では基本部分での故障の類はないとしても、細部での使いにくさで手直しすることは考えられる。それを故障率と呼ぶかは別として。

しかし、問題は終盤。後になると、基本部分すら故障が発生する。バスタブ曲線での偶発故障期間内で点検と補修は行うだろうし対応できるだろうが、終盤をどう考えるか、、、。部品交換で対応できない時期が来ることを念頭に置くべきだろう。その時期での対応方法は、やはり立て替え。立て替えといっても、大きなビルや大型トンネル(さらには海底トンネル)の場合、ビルの破壊や旧トンネルをどう塞ぐかも大きな課題になる。また、想定しているインフラ寿命との差異の検出やその対応検討も重要だ。

ちなみに社会インフラの減価償却での耐用年数を調べたら、鉄筋コンクリートのトンネルは75年だった。 (線路設備としてのは60年。蛇足だろうが飛行機は、主金属製150t超で10年。) 減価償却として決められた耐用年数だろうが、実際耐用できるかの確認は必要だろう。そんな点の見直しも絡めないと、インフラ建て直しは難しいかもしれない。

さらっとしか読まなかったが、この類の点検は、当初は2年毎だが、その後は5年毎になるようだ。それでは終盤の故障率の変化を識別できないだろう。当初のインフラ寿命と環境等で異なることだってある。例えば、地震の多発は、何らかの影響を及ぼすと思われる。今回のトンネル事故に関連して調べて、終盤に関する点検や対応の記載が余りに少なくて(見つからないレベル)、昔これらを検討するときに品質系の人もいただろうしバスタブ曲線のことは知っていただろうにと思えてしまった。

思うに、バスタブ曲線は人の一生のようなものかも知れない。故障率は、病気や怪我。最初の頃は小児科、偶発故障期間内の後半辺りは生活習慣病みたいな用語が該当するだろうか。年をとれば人間ドックの周期は短くなるし、うまく自己治癒力でカバーできない事も増えてくる。社会インフラや製品寿命の長い商品の場合は、そんなことも意識する必要があるだろうと考えた。

12月 6, 2012 品質安心・安全 | | コメント (1) | トラックバック (0)

2012年11月 1日 (木)

「僕がアップルで学んだこと」

数年前から、時々品質関連の人と話題としたのが、アップル製品(当時だと代表的なのはiPod)の品質に対する感覚と自社製品を含む日本製品に対する感覚の違いは何?というもの。つまり、iPodを使っていると、(時々)音飛びが起きたりする。ところが日本製品だと、多分出荷NG。この違いはなんだろうかとか、判断基準をどう考えるべきかといった話題。実際アップルの製品を使っている人が少なくなくて、どう考えるか聞いたりした。

なかなか結論は見出せなかったが、アップルでの品質保証/品質判定の方法や基準は、その後も気になっていた。

左は、数日前に購入した本。著者の松井氏は、元・米アップル社品質保証部のシニアマネージャ。

実は、2,3ヶ月前とかに、本屋で手に取って見たことはある本。当時はパラパラ捲った程度だった。ところがiOS6でのアップル地図のゴタゴタをネットニュース等で目にして、色々検索。アップルの品質などの検索で、本著者の松井氏が引っかかってきた。そして、この本に品質保証部在籍当時のことが書かれていそうだったので購入した。内情暴露ではないだろうけど、ヒントになることが分かれば良いな~位の思い。

書評などでは、社内政治への対応やアップル回復のことが書かれている。それらの記載ページが多くて、品質保証絡みは所々。ただし、キーとなりそうなことが書かれていて参考になった。

品質保証部の役割は、品質を保証することではなくて、開発プロジェクトの状態を定点観測を行うということ。[P82] テストを行ってバグ分析をし、その製品がどの程度出荷可能レベルに近づいているかを測る。

バグ修正は重要度の高いものから行い、優先順の議論に時間が費やされることもある。[P79] また意見として、過剰品質を求めていないとの記載もある。[P84]

個人的には納得だし、優先順位の議論とかは知り合いなどの自分の回りで良く聞く話で、理解しやすい/当然と考える。

なお他に、マニュアルを少なくしたり無くしたこと[P69]や収益に対する研究開発費が2.3%と低いこと[P77]、デザインでブレが無いことと細部での変更とが書かれている[P64、P78]。

ちなみに、品質保証部門を担当した時の、メンバーの惨状の様子[P109]や整理整頓に心がけたエピソード[P112]に触れている。


先頭の方で記載したiOS6でのアップル地図問題は、iOSの開発統括のスコット・フォーストール上級副社長が来年退任するとのニュースで落ち着いた感じだ。代償が大きくなった。

実情は分からないが、松井氏が退社したことで、P109に述べてあるような惨状に戻ったのかも知れないとふと思った。また松井氏自身、今回のアップル地図問題をどう考えるか、彼のブログなどを注意しているつもりだけど書かれていない。(今は)書きにくいとか、書くべきではないとの判断かも知れない。 個人的には、アップル地図を出さざる終えない事情があるように思えて、申し送り事項(例えばαバージョン扱いにするとか)として明言などで対応する方法もあったように考えるのだが、、、、。

いずれにしろ、アップルを知る上で、個人的には読んで良かったと感じた本だ。


追記:以下の松井氏とのインタビューで、アップルも出荷判定会議をやってるとか、そのリハーサルの準備をした逸話が書かれている。

http://www.cyzo.com/i/2012/07/post_11040_3.html

11月 1, 2012 書籍・雑誌ソフトウェア品質出荷判定ソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年4月24日 (火)

建設での品質管理

建築での品質管理に関しては、断片的には知ってた。資材の確認とかメンテナンスでの検査、、、、。ただし、断片的な情報で、どこかにまとまってないかな~というのは気になっていた。建設会社のホームページなどにも掲載されているが、より細部が分かると良いなと思っていた。今朝、何気にいくつかの検索で調べたら、結構良いページ/資料を発見。

「建設事業の品質管理体系に関する技術開発」報告書

http://www.kenken.go.jp/japanese/research/prd/list/topics/hinshitsu2/Q00.htm

国交省のプロジェクトで、建築部分が上記”建築研究所”に置いてあった。平成13年の発行なので多少古いかもしれないけど、自分の場合は十分。逆に結構なボリュームで、(建築外の自分では)必要な時に読む程度かもしれない。

第3章が自分には参考になりそう。また2章の木造建築は、中小の会社への品質管理普及も意図しているようで、その観点で参考になるかもしれない。(中小ということよりも、品質管理の意識が乏しいところへの普及との意味で。)

各フェーズで主体が違うことへの対応や個別の性能要求に対する管理方法など、今まででも余り意識しなかったことが書かれているようで、ちょっと読んでみる。あるいは、読んで芋づる的に参考になりそうなことが出てくるかもしれない。

建築での品質管理の良い資料がないかは頭の隅に長くあったので、今朝は結構すっきり。

4月 24, 2012 品質プロジェクトマネジメントプロジェクト管理 | | コメント (0) | トラックバック (0)

2012年3月17日 (土)

画面変更と仕様変更

早朝のテレビ東京「モーニングサテライト」は、結構見ている番組。そこでの表示方法が、今年になって若干変わった。

20120316_左は昨日(16日の放送)での、ニューヨーク株式の値動きの画面など。

http://www.tv-tokyo.co.jp/mv/nms/market/post_17307/での画像だけど、画像圧縮を高めてる。

青っぽい画面で”ダウ 1日”と書いてあるが、昨年までは日付だった。つまり、以前だと前日のダウなので”ダウ 15日”と表示された。日本株式とか為替なども同様。

今年になって表示を見て、システムのトラブルかと思ってしまった。つまり表示に関する日付更新がされてないと。多少日を置いてからだったけど、Twitterに書いたりモーニングサテライトでの問い合わせから投稿したりしても反応無くて、なおさら不可解に思えた。

2月になっても変わらないので、おかしいな~と思いつつ。どうも日付ではなく、期間(1日分)を示すように変えたのかもしれないと思うようになった。そうだと悪くはないんだけど、日本が祝日で向こうの市場が開いてる時にどちらの日か分かりにくいことはある。それよりも日付/期間の表示部分を固定的に出来るので、手間が少なくて済む方を採用したのかもしれない。(1月放送の冒頭で、表示変更のアナウンスがあったのかもしれない。ただそれでも、投稿等での反応で教えてくれても良いのにとは思ったが。)

これが良い例か分からないけど、システムのテストなどで、画面変更が仕様変更なのかトラブルなのかと悩む事は少なくない。リリース前に、変更部分をアナウンスしないなんていう考えられない事もあるようだし。その度に、再試験とかバグ表の発行とか、仕様確認とか無駄な作業が発生するのに懲りないみたい。

また昨今のWebサービスでの画面変更は珍しくないし、新旧画面の切替をユーザーが行えるようになってるケースも多い。操作性が悪くなることは少なくないし、トラブルかと悩むことも時々発生する。

画面変更に対するアナウンスは、多少手間でも行うべきと再認識した次第。

3月 17, 2012 ソフトウェア品質 | | コメント (0) | トラックバック (0)

2011年12月16日 (金)

バグカーブの理想曲線

今朝のブログに引き続き、バグカーブ関連。具体的な(理想的な)バグの累積曲線を考えてみた。

前提は、今朝と同じく以下。

・バグは均一
・ソフトの生産性(修正スピード)は一定
・テスト件数のスピードは一定

以下の数値を設定するものとする。
・全体行数(初期のソースコード行数)
・テスト密度(行辺りのテスト件数)
・単位時間(1日の最大)テスト件数
・テストに対するバグ率

ちなみに、1バグに対する修正行は、テスト相当行数*バグ件数とする。
(テスト相当行数=テスト1件に相当する行数=テスト密度の逆数) 多少乱暴な仮定かも知れないが、修正とか修正確認などを考えると、それほどかけ離れているとも思えない。

1それをエクセルにしたのが左。(次の写真を含め、ダブルクリック等で拡大できる。)

a2: =F1
b2: =IF(A2>(1/$F$2)*$F$3,$F$3,ROUNDUP(A2*$F$2,0))
c2: =ROUND($F$4*B2,0)
a3: =A2-(B2-C2)*ROUNDUP(1/$F$2,0)

a15は、3960行のテストすべき行が残っており、1日10件のテストをしたので、100行分はテスト完了。ただし、バグが2件発生したので、その対策として20行テストすべき行として追加された事を意味する。(結果的に次の日=a16では、3880行のテストすべき行が残っていることを示す。)

2終盤が左。テストすべき行数が減って、テスト件数も減る。(テスト出来る件数分テストしても良いけど)テストで見つかるバグ件数も減って、追加される修正行数も減ることになる。

横軸をテスト件数、縦軸を累積のバグ件数とすると、当初からほとんどが直線(1次曲線)となり、終盤が減衰する曲線となる。それを理想カーブとして良いかと思われる。(行数前提への意見とか色々あるかもしれないけど、行→FPなどの場合でも考え方は同じになると思う。)

なお当然だけど、回帰分析などでカーブを求める場合、何らかの数式になっている方がよい。しかも、原点から連続したものが操作も楽である。今回示したカーブが、回帰分析で使えるような関数の格好になっていればいいのだが、すぐには見つかりそうにない。(もし判明したら、連絡もらえれば幸い。) 


捕捉:カーブが求まらないか、少し考えてみた。

3こちらは、終盤でのテスト件数やバグ件数を、整数化しなかったもの。

4こちらも、テスト件数やバグ件数を整数化しなかったもの。ただし、初期の行数を調整して、終盤で一旦(テストと行数の関係で切りの良い)100行にしたもの。

2つの終盤で、整数化しないことではっきりするけど、テスト件数がバグ率による等比数列になっていく。バグ件数も、バグ率による等比数列になっていく。

なので、バグ件数は、 k*a^x の指数関数となる。kは、終盤(最大テスト件数を処理する必要のない段階)での初期の値で終盤の行数に依存する。今回のグラフの例だと1から9かな。aはバグ率。 (表の意味するxはテスト件数により離散的だけど、テスト件数をlimで1件などに考えて行けば、指数関数と考えてOKそう。)

で、指数関数とすると、バグ件数の累積=積分も指数関数のカーブになる。(積分することで係数は違ってくる。特にバグ率は少数以下なので、係数がマイナスになることで上下反転する。) 

終盤のバグ累積件数を指数関数で近似するのは悪くないだろうが、テスト開始からを指数関数で近似するのは多少無理があるかもしれない。なっ、この辺りになると、実際のデータでの近似曲線間の決定係数の比較になるだろう。

結構自分なりには、すっきりしたかな。

12月 16, 2011 品質ソフトウェアテスト | | コメント (0) | トラックバック (0)

"コーダーとテスターのパラドックス"

昨日Twitterのつぶやきで、信頼度成長曲線の話しにちょっと反応。こちらは、むしろテスト件数などの理想カーブに注目すべきと思って書いたけど、元々品質を測る信頼度成長曲線に注目してたようだ。って、元々そう書いてあったと言えば、そうなんだけど、、、。

で、ふと思ってこっちに補足的なことも含めて書いとく。

まずタイトルは、「アキレスと亀」をもじったもの。”コーダー”とせずにソフト開発者としても良いかもしれないけど、語韻と開発よりも製造に近いイメージがあるので、”コーダー”。ここでの”テスター”は、第三者検証のようなコーダーや設計/開発とは別チームでの検証の人。

「アキレスと亀」って、”ゼノンのパラドックス”とか”ゼノンの逆説”の中の一つで、ウィキなどにも書かれてる。 

http://ja.wikipedia.org/wiki/%E3%82%BC%E3%83%8E%E3%83%B3%E3%81%AE%E3%83%91%E3%83%A9%E3%83%89%E3%83%83%E3%82%AF%E3%82%B9

あるところにアキレスと亀がいて、2人は徒競走をすることとなった。しかしアキレスの方が足が速いのは明らかなので亀がハンディキャップをもらって、いくらか進んだ地点(地点Aとする)からスタートすることとなった。

スタート後、アキレスが地点Aに達した時には、亀はアキレスがそこに達するまでの時間分だけ先に進んでいる(地点B)。アキレスが今度は地点Bに達したときには、亀はまたその時間分だけ先へ進む(地点C)。同様にアキレスが地点Cの時には、亀はさらにその先にいることになる。この考えはいくらでも続けることができ、結果、いつまでたってもアキレスは亀に追いつけない。

この話は、高校の数学で取り上げられるケースが多い。無限級数とか収束。ネットで検索すると分かりやすい解説もあるので、興味あればそちらを。


で、ソフトウェアテストとの関係。アリストテレスをコーダー、亀をテスターと置き換える。そして、スタート地点でのことをテスターに最初に渡すバージョンでの何行かのソフトウェア、スタート後もバグ対策で何行かソフトウェアを作成すると考える。すると、追い越せるかは、テストが完了=バグ修正の行数がゼロになるかと考えればよい。無限に続きそうに思える点が、ゼノンの逆説とも似てくる。(テストでは、スピードを一定と考えるべきじゃない点は後述。)

ちなみに、ソフトウェアでの理想的なこの類を考える時の前提としてはいくつか考えられる。

1)バグはゼロ

理想という点では分からなくもないが、非現実的。

2)バグは均一

3)ソフトの生産性(修正スピード)は一定

4)テスト件数のスピードは一定

従来の信頼度成長曲線って、3)とか4)はあまり議論せずに、バグ残件がどのカーブにフィットするかの議論が多い。残件は終盤でゼロに近いので、成長曲線の類になるのは当然だが。それはそれで価値があるが、それを理想モデルと言うべきかは疑問のあるところ。また、検証サイドとしては、4)のテスト処理がスムーズに行われない原因を探るべきなのに、(論文や記事が信頼度成長曲線に関するものがほとんどなので)残件バグのカーブの方に目が行ってしまう。そんな気がする。

ゼノンの逆説の解法で分かりやすいのは、横軸が時間で縦が距離のグラフ。ただし、ソフトウェアテストのコーダー側の場合は、縦を行数として、追加行数を考える必要がある。コーダーの生産行数(スピード)はテスト結果の反映を考えて、テスト開始(t0)から追加行数自体は次第に減衰する。t1には、t0からt1直前までに発見されたバグ対策に相当する行数を生産していることになるため。これは(理想モデルでは)等比級数でOK。ゼノンの逆説でのイメージでは、アリストテレスは疲れてきて段々スピードが遅くなるイメージ。

ソフトウェアテストのテスター側は、横軸が時間で、縦軸が件数。これは直線で良いだろう。(回帰テストのことがあるけど、処理件数という点ではスピードは一定が理想。) 等比級数(等比数列の項の総和)は求まるので、バグ率によりトータル行数も算出できる。もちろん、テストが追い抜く時期も判明する。

ここでのテスター側は、回帰テストも含めてテストスピードが一定であることを前提としているが、ある意味目標かもしれない。Twitterでの返信でも書いたけど、そもそもテストの粒度の扱いをどうするかが悩ましく感じる人もいるかもしれない。また、いかに回帰テストを効率よくやるかも目標だろう。

なお、冒頭でバグゼロが非現実的と書いたけど、(第三者検証に対しては)バグゼロに近づける事を目指していることや、実際近づきつつあるのは事実。テストツールでの事前確認もそうだし、イテレーション毎に出荷できるリリースを目指す開発手法なども普及しつつある。なので、ここで述べた追いつくまでの期間や修正行数が、ゼロに近づきつつあるとは言える。


いわゆる信頼度成長曲線で(開発の)状況を分析するのは良いことだと思う。自分自身はアンチ信頼度成長曲線派でもなく、使うべきとの考え。また、対数曲線や二次曲線での近似も悪くないことを、このブログでも書いた。 

https://blog-honda.cocolog-nifty.com/gijyutuya_nikki/2010/03/post-4fef.html

ただ、信頼度成長曲線は信頼度を示すけど、ソフトウェアテスト自体の状況を示している訳じゃない。ソフトウェアテストの状況を知って改善するには、別の指標での監視が必要だし、理想での指標を頭にイメージしておくべきと言える。

12月 16, 2011 品質ソフトウェアテスト | | コメント (0) | トラックバック (0)

2011年11月22日 (火)

ハードウェア受け入れテスト

以前”初期「受け入れテスト」”って書いたけど、ハードウェアの受け入れテストも重要である。以前「受け入れテスト」を書いた時も頭の隅にはあったけど、明記しなかったようで、補足的に今日記載。

ハードウェアの受け入れテストも、開発の初期段階に行われるのは同様。ここでのハードウェアって、社内の新規基板の場合もあるけど、他部署での(先々内販/外販予定の)半導体とか、他社の半導体なども含む。

で結構厄介なのが、ソフトウェアにバグがあるように、ハードウェアも完璧なものが最初からある訳じゃない点。しかも量産を意識している場合、修正ハードウェアを入手できるのに期間を要することが多い。(逆にFPGAのように、変更が容易なケースもある。その場合は、修正確認に付き合わされる頻度が多くなる。)

基板のような場合は、ジャンパー線で修正ということも少なくない。試作機が何台もある場合は、修正済みとそうでないものが混在。ハード屋さんは、出来れば修正台数を少なくしたいと言うし、、、。


ハードウェア受け入れテストを、誰が実施するかも懸念点だろう。ソフトウェア開発メンバーになることが多いが、テストの頻度やボリュームが大きいと、委託などの方法も検討する必要がある。ハードウェアの一般的な知識や組込みの知識があった方が良いので、人捜しが難しくなる。

結局、この辺りを含めた開発初期の作業項目列挙や人員の手配などの立案や実施が重要だ。開発のその後を、大きく左右すると言っても過言ではない。

11月 22, 2011 ソフトウェア品質 | | コメント (0) | トラックバック (0)