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 品質, 安心・安全 | | コメント (4) | トラックバック (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での返信でも書いたけど、そもそもテストの粒度の扱いをどうするかが悩ましく感じる人もいるかもしれない。また、いかに回帰テストを効率よくやるかも目標だろう。

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


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

http://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)

2010年12月27日 (月)

ビジネスロージャーナル「ITベンダ対ユーザ システム開発契約をめぐる紛争」

大掃除や年賀はがき作成をしながら、休みの時などに先週土曜日に買った本や雑誌をぱらぱら読んだ。

タイトルの雑誌は、先週の忘年会前に神田の書泉に行って、システム開発関連の判例とかを探した際に購入したもの。当初、ジュリスト別冊とかにありそうと思ってたけど、(事前にネットで調べても)ぴったりそうで安いものが無かった。店内を回ってたら、”ビジネスロージャーナル”という雑誌のバックナンバーがあり、その2010年5月号の表紙に、「ITベンダ対ユーザ システム開発契約をめぐる紛争」と書かれていた。少し立ち読みして購入。

ちなみに、”ビジネスロージャーナル”のバックナンバーページは以下。

http://www.businesslaw.jp/single/

判例もそこそこ書かれていて勉強になった。2ページだけど三菱電機インフォメーションシステムズの人の執筆もあり、基本契約と個別契約(ここでは、プロジェクトのフェーズ毎の契約のような意味)の両方がある場合の、矛盾を想定した記載方法とかは具体的で「そうだよな~」といった感じ。

ちなみに執筆者の一人は「中村好伸」氏。2009年のPMI日本フォーラムで講演され、情報交換会にも出席されて色々お聞きした。掲載記事での冒頭に、相手方のアドバイザーが「PMBOKであれば、○○書面があるはず」の一辺倒で交渉にならず、結局相手方としてのアドバイザーを降ろされたとの話も。個人的にも「そうりゃーそうだわな~」。教科書のべき論だけじゃ、交渉にならないし、落としどころを見つけられない。

知り合いとかには勧めたい一冊。


ついでに。本号に日本ハム(株)の”下請取引承認フロー”が図示されてる。承認が何処で行われて、メールが行くのかどうかまで書かれてる。

2010年12月号も参考になると思って買ったけど、そっちは付録が結構面白い。法律事務所のハンドブック。会社というか事務所の写真や事務所弁護士のプロフィールなどが掲載されている。で、面白いのは(写真掲載の事務所は)、どの事務所も立派で、しかもほとんどの事務所が”書架”の写真を掲載してる。模擬法廷のスペースのある事務所もある。こんなの見ると、就職先として憧れるのも分かる気がした。  (理科離れもだけど、理科系企業離れもありそうな気がしてきた。)

12月 27, 2010 プロジェクトマネジメント, プロジェクト管理, 品質, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2010年12月13日 (月)

フォーラム:NRIのシステム障害削減

今日は、PMI日本支部のフォーラムに参加。テーマ名は「システム障害の削減に向けた弊社の取り組み」、講師はNRI(野村総合研究所)の栗原氏。PMI日本フォーラムでの案内は以下で、”八割減”が印象的。

http://www.pmi-japan.org/event/open_seminar/monthly/2010_11_16_201012.php

ちなみに、参加して頂いたのが、「野村総合研究所のやる気を引き出すチーム改革 (アスキー新書) 」。セミナーでの内容が結構書かれている。セミナーで触れられた”エンハンスの卵”の図は、裏表紙やP49。

システム障害事例の情報共有とか草の根的な改善活動が述べられたが、ある意味大なり小なり行われていること。ただし実践していることに意義があるし、講演や本での細部で参考となるプラクティスが少なくない。特に、パートナー企業まで巻き込んだ活動には頭が下がる。そう簡単に構築できないだろうと思って、懇親会では質問させて貰った。

講演でも述べられたが、オフショアでのパートナー企業とは、品質改善以外に(証券とかの金融系)業務知識の教育なども行ったそうだ。根気の必要な活動。 (もしかしたら、海外で金融系の業務試験が行われていたが、それも関係するのかもしれない。)


野村総合研究所は、旧野村総合研究所と野村コンピュータシステム株式会社(NCC)が1988年に合併している。その辺りは知っていたが、今は売り上げ比率がITの方が高いし社長もIT系だと、その場で知った。その辺りも、品質改善活動を全社的にしたりパートナー企業を巻き込める原動力になったようだ。ちなみに数年前に情報系の大学の人と懇親会の場で人気のある企業はどこかと聞いたら、NTTデータとNRIの名前が出て印象的だった。

NCCの頃は、コンピュータシステムや業務ソフトの運用保守が主体のイメージが強かった。そのために、業務の把握やパートナー企業との息の長い連携が求められていたのだろう。それがかえって、今回の改善活動に結びつけやすかったのかもしれない。また、トラブル削減の次あるいは並行して、運用保守の改善や効率化にも取り組んでいるとのことだった。


ついでに:講演会で多少時間があったこともあり、Q&Aに時間が割かれた。印象的だったのは中国の人とのことだったが、その人らの質問。懇親会の場にも一人(?)いて、講演内容やPMI日本支部活動などを質問してた。聞いたら、NRIはオフショア開発がうまく行ってる企業とのイメージとのことで講演に参加したと。彼らの積極的/前向きな様子を見ると、頭が下がるくらい。

ついでにその2:結構昔に、旧野村総合研究所に出向いたことがあった(と思う)。暑い中に長い坂を登った記憶が、おぼろげながら。今回のを機にちょっと調べたら、旧野村総合研究所は鎌倉の坂の上にあったようで、記憶は正しそう。調べる際に写真などがネットにあり、少し懐かしい気になった。

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

2010年11月14日 (日)

テスト報告書を書ける人、そうでない人

週末に知り合いと話した件を、ふと思い出した。「ソフトウェアテスト報告書の作成能力って、レベル差ありすぎ~」

そもそも、”ソフトウェアテスト報告書”って、書く事が少ないかもしれない。まっ、判定書(やそのための資料)などに含まれてるケースを含むけど、テストしてバグレポート発行しても、報告書の類の話は余り聞かない。そのせいか、書ける人自体が少ないのかも。また、テストの依頼したり請け負ってもらっても、報告書を提出させたり、その吟味をできる人が、また少ないのかもしれない。

テスト戦略とかテスト計画は、規格があったり広く議論されてるので、力説する人はいる。でも、そんな力説する人たちって、報告書をどう考えているのか聞いてみるのも良いかもしれない。世の中には”認定機関”なるものがある。それと比較しちゃいけないのかもしれないけど、ソフトウェアのテスト結果レポーティングって、ちょっと気になった。

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

2010年10月27日 (水)

三菱重工業のGPM(グローバル調達マニュアル)

社外コミュニティのちょっとした勉強で、関連会社とかへの品質などのプロセス徹底などを気にしてる。

完全子会社とのそれよりも、連結対象会社・グループ企業とか、単なる取引関係のある会社との関係。自社のプロセスを、完全実施しろと言えないことも少なくない。というか、まず無理。それと、そもそも自分に関係の深いソフトウェア開発とかその品質保証プロセス以外にも、コンプライアンスを含め、いろんな分野の保証や監査が考えられる。

長く頭の隅にあったし、コミュニティで議論しやすい題材が無いかが悩みだった。分厚い本よりも、ちょっとネットに転がっているようなものを欲したが、なかなか良いのが見つからなかった。

で、今日見つけたのが、タイトルでの三菱重工業のGPM(グローバル調達マニュアル:Global Procurement Manual)のページ。

http://www.mhi.co.jp/company/procurement/gpm/index.html

2007年度に制定したみたいなのだが、”調達”関係だったので、検索などで気がつかなかったのかもしれない。逆に、改めて調達の重要性、当然だけど契約などの重要性を感じた次第。

なお、記載内容は基本的な事項なので、人によっては拍子抜けかもしれない。ただし、逆に、このような基本的なルールを明示的に示して、後はビジネスユニットで固有の事項を加えたり、より詳細の目標を定めるべきと思っていた。その意味で、個人的には丁度良さそうな表現。

ちょっと嬉しかった1日だった。

ついでに。以下は、東芝でのグループ会社を含めた品質保証体制。

http://www.toshiba.co.jp/csr/jp/customer/quality.htm

なお、(グループ会社との対応の記載は少ないが)半導体での品質保証体制については、結構細かい事項まで書いているページが置いてある。実はシェアとか利益率などとの対比で、サムスン電子などのそれがないか探そうとしたけど、日本語のページはすぐには見つからなかった。


ここで紹介したページよりも、もっと適したページがあるかもしれない。あくまで参考と言うことで、、、。

10月 27, 2010 出荷判定, 品質 | | コメント (0) | トラックバック (0)

2010年10月22日 (金)

制御プログラムの不具合でのリコール

ちょっと目についたので紹介。制御プログラムが良くなかったとのことで、自動車のリコール。スピードメータの不具合。

http://www.mlit.go.jp/common/000126290.pdf

メータの値や動作自体ではなく、メータの照明がうまく動かないというもの。個人的に、車のリコールで”制御プログラム”と明記したのは珍しいというか初めて目にしたかも。また、改修したら、リコール番号が判るステッカーを付けるらしい。(今まで目にしたのかもしれないけど、記憶になかった。)

10月 22, 2010 ソフトウェア, 品質, 自動車 | | コメント (0) | トラックバック (0)

2010年10月13日 (水)

ソフトウェアのADR(裁判外紛争解決手続) 寸劇

ここでのADRは、米国預託証券じゃなくて、裁判外紛争解決手続(Alternative Dispute Resolution)の方。

ふとソフトウェアでのADRのことを久しぶりに検索してたら、経産省のページにADRを劇仕立てにしたものを発見。

http://www.meti.go.jp/policy/it_policy/softseibi/#08

wmvファイル6つに別れてて、冒頭を見て思わず全部見ちゃった。6つで1つの物語だけど、冒頭は少しフランクにADRに関して説明する格好のもの。(そこでの弁護士さんが気さくなタイプで、個人的に嫌いな方じゃない。)

劇での紛争は、第1フェーズは上手くカットオーバーできたのに、追加的な第2フェーズのパフォーマンスが期待に添わなくて金を払わない/払ってくれというもの。第2フェーズでは、外のパッケージ利用もちょっと絡んでる。

ちなみに、以下でシナリオの方見られるけど、まずは冒頭のを見てみるのをお勧め。

http://www.softic.or.jp/seminar/2007-ADR/

個人的には、この寸劇では、ちょっとベンダー側に甘いかな~という印象。

蛇足だけど、結構劇としてもこなれているし、音もそれなりに高品質。それに似合う分、活用されてるのかな~とふと。もちろん、(少し前の日本の感覚だと)ADRを含め紛争や裁判を避けたいという感情があるだろうけど。また、2007年には情報があったようなので、何で前に気がつかなかったかは??

10月 13, 2010 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2010年10月 1日 (金)

保守(契約)とインシデント

今日は気になって、ソフトウェアの保守とインシデントを調査。インシデントって、障害とかの連絡もだけど、ちょっとした問い合わせなども含む事が多いかな。

で、以下はSalesforce関連の会計ソフトサービスのページで、下の方の料金の部分に”3インシデント含む”との記述がある。あくまでも例で、”保守 インシデント”とかで検索すると、結構出てくる。

http://www.sunbridge-sol.com/service/cloud/salesforce_relation/project/

以下の「アドビ デスクトップ製品向けサポートプログラム サポート規約」とかでも、インシデントのことが書かれている。

http://www.adobe.com/jp/support/programs/policies/terms_customer.html

”IT LEADER”2010年1月号での、ソフトウェア保守サポートの特集を読んだ時もちょっと調べたつもりだったけど、その時よりもインシデントのことを結構明記しているサイトが増えた気がする。勘違いなら、ご容赦。ちなみに、”IT LEADER”2010年1月号は、今は以下でも読める。

http://it.impressbm.co.jp/taxonomy/term/1189

会社やサービスによって料金が違ったり、件数カウントの方法を細部にわたって記載してあるサイトが増えたように思う。保守要員のコストなどを考えると、保守料金、そしてインシデント1件の料金の検討が必要な時代ということ。SLAも、お金が絡んでいる。

メカ系の製品の場合、MTBFなどを算出してサービスパーツの料金とかを計算するけど、ソフトウェアサービスもそのような考えが必要になってきている。また、逆に発注側としては、余りに信頼性の低いソフトやサービスのカットオーバーでの”受け入れ検査”のあり方や、その結果をどう扱うかなども吟味する必要がある。

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

2010年9月13日 (月)

「はやぶさ」 帰還のための電池試験

「はやぶさ」が地球に帰還して3ヶ月くらい経つ。カプセルの展示などの話題もあるけど、先週目にしたのが以下の記事。

小さな電池 好アシスト…探査機「はやぶさ」カプセル回収 (2010年8月23日 読売新聞)

帰還の予定が延びたので、回収のための電波発信装置(ビーコン)の電池がもつか試して欲しいとの依頼があったそうだ。何度もの実験とか12年持ちそうとの話もすごいけど、電池動作のために0度に温度を保とうとしたのもすごい。

そもそもメカニズム的に電池の周りにヒーターを用意したんだろうけど、その電源とか熱源をどうするかとか、暖めすぎるのを避ける必要もある。しかも、帰還のためにはいろんな装置を動かすので、その優先順位も考えないと行けない。(そもそも、帰還の少し前なら多少安心感あったけど、軌道を外れた頃は太陽パネルもまっとうには太陽に向いてなかったはず、、、。また、カプセルは回収が目的なので、はやぶさ本体と接合部分は少ないはず。なので、カプセル内にそれなりの保温メカニズム持たせたということだし、そもそもその保温のためなどに電気供給路を用意してたという事だろう。)

映画「アポロ13号」では、電気の消費を減らすために暖房を切り、飛行士がガタガタ震えるシーンがあった。それをちょっと思い出して、遠隔での対応に驚いた。

「はやぶさ」、そしてそれを支えたシステムや運用には、他にもまだまだ沢山エピソードがありそうだ。逆に、飛行が7年にもなるとどんなことが起きそうとか、その対応策を考えてみるのも面白そう。

9月 13, 2010 テクノロジー, 品質, 科学技術 | | コメント (0) | トラックバック (0)

2010年9月 8日 (水)

IPA「デジタル複合機の脆弱性に関する調査報告書」

今日、面白く読んだのが、タイトルの「デジタル複合機の脆弱性に関する調査報告書」。 (何故かこの所、IPAネタが多い。)

http://www.ipa.go.jp/security/fy21/reports/mfp/index.html

デジタル複合機(MFP)での脆弱性やその対策(案)を記載したもの。

耐タンパー性などに言及してるのは良いし当たり前かもしれないが、個人的にはバグの類じゃないのとか、この辺りだとユーザ責任でしょうと思えるところも少なくなかった。

ただ、保守の絡みなど、対策してた方が良いのかもしれないと考えさせられる部分もあった。IF種やネットワークサーバー種の記述も少なくなく結構網羅的に書かれているので、MFP以外でも参考になると考える。


ちなみに、「組込みシステムのセキュリティへの取組みガイド」は、改訂版が出ている。

http://www.ipa.go.jp/about/press/20100907.html

9月 8, 2010 ソフトウェア, 品質, 安心・安全 | | コメント (0) | トラックバック (0)

2010年8月24日 (火)

mixiの障害から学ぶもの

知り合いが、mixiの障害に関する細かい原因を記述してあるサイトをつぶやいてくれた。

mixi大規模障害について 解明編

そのサイトの左の方から、説明なども辿れる。”執筆者個人の環境と経験に基づく”とのことで、mixiの正式見解ではないけど、ミクシィ開発部の人なので貴重な記述。

このような(非公式)公表の仕方には意見あるかもしれないけど、個人的には好感。他の人の再発防止になるし、色んな思惑での公式な見解よりも純粋な技術的な話として参考になる。

で、個人的に実務的な実装を行ってないので細部は良くわかってないけど、分散キャッシュの”memcached”に関連した問題で、起動時のパラメータ変更で対応したとのこと。


高負荷状態のテストと同様に、接続限界数での確認を長く行えば事前に見つかったかもしれない。ただ、接続限界数を色々変えて、しかも日レベルでの動作テストすべきだろう。そうなった時に、確認環境をどうするか。一般的にクラウドのような範疇では、開発、テスト、本番の3システムを要することは言われているが、テストが1システムで良いか???

また今回は、”memcached”の問題とのことで、その点だけだとパラメータの組合せはそう多くない。が、システムには多くのソフトが使われている。各ソフトでの起動のパラメータの種類、そして複数のソフトのことを考えると、これらパラメータの組合せが膨大となる。

あと、今回は障害が長く続いた。”memcached”でのパラメータ変更の確認に時間がかかったとも言えるが、利用ユーザーからすると、もう少し早めに原因究明と確認が出来るべきだろう。

今回のトラブル、そしてその原因の記述が、開発とかテストでの課題を教えてくれた気がした。

8月 24, 2010 ソフトウェア, パソコン・インターネット, 品質 | | コメント (0) | トラックバック (0)

2010年8月16日 (月)

MSでの脆弱性”修正不能”

今日何気に目にしたのが、以下のSlashdotの記事。6月中旬の掲載だったようだ。

Office XPに含まれる脆弱性、「訂正不可能」なため放置

脆弱性は分かっているけど、Office XPについては対策を見送りますという宣言。マイクロソフトでの「MS10-036」のページでも、大きくは書いてないが下の方で読めば分かる。なお、本Slashdotのサイトが良いのは、皆さんのコメントで、他の例がいくつか書いてあること。

個人的には、MSなり巨大化したソフトではありがちなことで、「そうなんだ~」位の感想。用途によって、使うソフトなり仕組みは違って当然で、それを踏まえて設計するだろうと。

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

2010年7月24日 (土)

iPhone4のアンテナトラブル 事例研究

今回のiPhone4のアンテナトラブルとその対応って、事例として結構参考になる。携帯電話以外の分野でも、大なり小なり発生しそう。あるいは、想定として考えておくのは悪い事じゃない。

そもそも発端は、電波受信の感度が悪いようだとネット等で。

最初は、アップル側は問題ないと。そして、表示だけの問題だと。(後で述べるけど、ソフトウェアの立場じゃ、本件が引っかかった。)

そして、ジョブズからの発表があり、ケースを無償で配布すると。全般的には、以下辺りが参考になる。

http://www.itmedia.co.jp/news/articles/1007/17/news005.html

(ただし、その後ネット上じゃ、他メーカーでも起きそう発言が尾を引いている。)


個人的に気にしてるのは、表示上の問題(のみ)とした件。以下での反論もあるけど、ネット上では、表示の問題のみじゃないだろうとの発言は、(自分のよく目にするコミュでは)無かった。

http://wiredvision.jp/news/201007/2010070423.html

ちなみに、アップルは携帯電話の商品化のために、1億ドル以上の施設を用意。

http://www.itmedia.co.jp/news/articles/1007/20/news038.html

また、今回のアンテナ問題の対策コストとして1億7500万ドルと見込んでいるらしい。

http://www.itmedia.co.jp/news/articles/1007/21/news013.html


「iPhone4の感度がおかしい」との市場クレームをトラブルシートと考えると、以下みたいな動きかな。勝手な推測で書いてる。

「iPhone4の感度がおかしい」トラブルシート発行。
 ↓
電気屋(通信屋)は、そんなはずない。
 ↓
ソフト屋に。
 ↓
感度表示がおかしいと判明。対策してバージョンアップの方向へ。発表。

この後(並行して)、アップル内からか市場からか、表示だけの問題じゃないのではとの声が。
 ↓
再調査/再実験。
 ↓
ケース(Bumper)の関係が判明。
 ↓
ケースの無償配布とか、既存Bumper購入者への返金を発表。


iPhone4って、ハード的にiPadと共通化していることもあって、従来のiPhoneチームと若干違うんだろう。そのせいもあってか、最初の分析が(結果的に)甘かったし、表示のみの問題としたその直後の追試も(結果的に)甘くなってしまった。ハード屋、ソフト屋、メカ屋で情報共有なりたらい回し、その過程でそれぞれの問題発覚(今回は感度の計算)。それだけの対策と発表。そんなとこかな。

最初の分析=初動で結構耳にするのは、固有問題か傾向かの判断の難しさ。多少今回の件も関連するけど、ユーザーの使用条件が異なることで、さらに判断しにくいことが少なくない。

また、結構気になってるのは、ジョブズ自らの発表の件。感度表示だけだった件をジョブズが発表してたら、それはそれで収拾が困難になったかもしれない。品質問題系の発表者を誰にするかも悩ましい。

蛇足的に言えば、結構増えてきたのがハード設計の確認をソフト屋がやったり、ある程度の市場向けソフトで行ってる。今回ので言えば、アンテナの機能をソフトでの感度表示を利用するようなシーン。その関係で、問題の切り分けが難しかったり、根本原因の発見が難しい場面もある。あるいは、複合的な原因(ハードもソフトも)の場合もあるので、分析とか検証には念を入れる必要がある。 (ハード屋/メカ屋には、「またソフトか~」みたいな感覚が少なくなく、ソフト問題が発見されたりその対策が判るとシャンシャンとなり、ハード/メカの問題もある・あるかもと考えない。)

7月 24, 2010 ソフトウェア, 品質, 携帯・デジカメ | | コメント (0) | トラックバック (0)

2010年7月22日 (木)

バグが見つかったら、別バグも発見せよ 「1+n施策」

最近めっきり本を買うのが少なくなったり、読むスピードが遅くなってきた。「いかん、いかん」と思いながら、今日は「ソフトウェア品質会計」を超高速・断片的に読んだ。

誉田直美(ほんだなおみ)さんによる、NECでのソフトウェアの品質保証技術の本。全体で200ページ超と、余り厚めでもないので読みやすい。また数値データなどが具体的で、判りやすい。

ちなみに、”品質会計”との意図は、バグを負債として考えるためとのこと。(感想は後述。)


で、気になったのが、タイトルにもしている「1+n施策」。バグが発見されたら、真の原因などを探る意味で、同種バグをn件発見するというもの。これを1994年辺りから、バグ分析と共に検討したとのこと。

気にしたというのは、1980年代前半に本手法を実践しているのを耳にしているため。当時は、「1+n施策」という明確な用語化までには至ってなかったが。ちなみに、耳にした際のnは、1,2とかじゃないけど10とかまで多くはなかった。当時は、ポピュラーとまでは行かなくても、実践している会社は少なくないと思ってた。そのため、時期的な表記が気になった次第。

なお個人的には、バグ件数ゼロが本書での判定基準になっている等も気になった。バグを負債と考えるなら、資産というかバグ非ゼロでの出荷などにも言及してもらった方が有り難かった。コラム的な記載でも仕方ないだろうけど。


”丸投げ”について、いくつかの状況を丸投げ/丸投げでないと記載している部分は、参考になると考える。


Img036Amazonで、なかなか表紙が表示されないので、記載。下の方は帯。


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

2010年3月17日 (水)

バグカーブ近似 その2

昨日書いた「バグカーブ 対数曲線や二次曲線での近似のお勧め」で、少し補足。

対数曲線や二次曲線は増加関数なので、バグカーブの近似として不適切と感じる人がいるかもしれない。しかし個人的には、テストの終盤になってもバグが発見されるので、増加関数が適切と感じている。

その理由だが、ソフトウェアテストの場合には、操作やパラメータをテスターに一任する場合がある。これは「殺虫剤のパラドックス」の防止策の一つである。「殺虫剤のパラドックス」は、JSTQB(ISTQB)のFoundation Levelシラバス日本語版にも書かれているが、全く同じテストを繰り返すことで欠陥が見つかりにくくなることを指す。「殺虫剤のパラドックス」の防止策のためにパラメータや操作タイミングを変化させることで、新しいバグが見つかるケースがあるというわけだ。

シンプルで小さなソフトウェアなら、あるところからバグの発見がゼロになることもあろうが、大規模なソフトの場合や外部モジュールを利用する場合に、どうしても終盤でもバグの発見がゼロにならないことは実務的に少なくない。

★ただし、重大バグとなると若干話が違ってくる。つまり、バグ件数全体は増加関数でも仕方ないとしても、重大バグが終盤でも発生したら対策が必要である。具体的には、重大バグの解決まで市場リリースを延ばすなどである。そのためには、単なるバグ全体件数のカーブ以外に、重要度でレベル分けしたバグのカーブも情報としては必要となる。

なお、重要度のレベルは3つとか4つなどが普通と考える。また、最重要レベルのバグ曲線近似を少し考えてみたが、うまい曲線は見つからなかった。累積では成長曲線の類が良さそうだが、初期では昨日と同じような立ち上がりの不一致が発生すると思われる。累積ではなく発生件数をY軸とするカーブも考えられるが、うまく減衰する曲線が見つからない。(確率分布でのカイ自乗(χ2)分布みたいな曲線を思い浮かべたが、、、、、。)

ただし、最重要レベルのバグは、リリース直前では何日か発生ゼロでなくてはならないので、余り回帰分析などに拘る必要もないだろう。

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

バグカーブ 対数曲線や二次曲線での近似のお勧め

バグカーブ/バグ曲線とかソフトウェアの信頼度成長曲線って、ソフトウェア工学での大きなテーマである。ちょっとした会合や講演会の題材、あるいは学術論文でのネタになることも少なくない。

代表的な曲線は、ゴンペルツ曲線とかロジスティック曲線とかだろう。ただし、ソフトウェアテスト(具体的にはシステムテストであるケースが多い)の初期に無理に曲線を当てはめてみて想定と大きく違ったり、 測定値と予想との乖離が気になることがある。前者はある意味仕方ないが、後者はもっといい近似曲線がないだろうかと考えてしまう。(ちなみに、ここでは、バグ発生のモデルではなく、あくまで曲線近似の世界のことを扱う。そのことや、近似が成長曲線でないので、ここでは”バグカーブ”と呼ぶことにする。)

ここ1,2年前くらいから、少し”もやっと”したものがあったが、 Day2の本を読んで納得した。以下の左が、Day2の統合テストでのバグカーブ。

Day2_2Atz431_2

ちなみに、上の右の図は、  http://www.pmalignment.com/web/note/atz/atz43.html で紹介されているもので「ソフトウェア品質ガイドブック 森口繁一編 日本規格協会」に記載されている図とのこと。


1,2年前から少し”もやっと”していたのが、テスト開始初期段階のカーブ。上の2つのように、急に立ち上がるのが旧来と違っていて気になった次第である。自分の見聞きするケースにはそれが多く、ちょうど右での一般的な成長曲線のカーブを重ねた際に気になっていた。

もう○○年前の、ちょっと大きなプロジェクトでバグカーブを作成し、所謂S字カーブになり納得していた。理由付けとしては、テストメンバーが不慣れでバグの発生件数が少ない → 次第に増える → 終盤になるとバグ対策の効果でバグの発見自体が少なくなる。

それが昨今、初期段階に急な立ち上がりのカーブを目にする機会が増えた。最初、自分の見聞きするケースでは横軸を日数ではなくテスト件数にすることが多いからかとも思ったが、そればかりではなさそうと感じていた。ちなみに、昔に横軸を日数にしたのは、(紙ベースの時代でも)トラブルシートでのトラブル発生日を元に集計すれば求まったためである。しばらくしたら、BTS(バグトラッキングシステム)により、それらが自動的に集計できるようになった。しかし、昨今は、テストの進捗管理の実施も普及してきたので、その日のテストの実施件数を把握している事が多い。

Day2の本を読んでもバグ件数の立ち上がりが急だったので、一般的にもそうだろうと考え、ある考えに行き着いた。

つまり、テストチームは事前に仕様書を読んだりテストケースの準備をしている。場合によっては、プレリリース版を入手してバグの多そうなところも分かっているかもしれない。しかもテスト技術が発達したり、テストエンジニアやテストグループのリーダーにスキルや進捗管理能力の高い人を配置するようになっている。そうすると、テスト開始と同時に、多量のバグレポートが発行される。これは、ある意味では必然である。

そうなると、バグ曲線はS字カーブよりも、下のような対数曲線等の近似がぴったりである。あるいは思い切っての近似としては、あるところまでは直前で、あるところからなだらかとか水平になると考えてよい。例えば水平になるのは、市場投入予定の2週間前からと想定するなどである。

下はその前提で、仮想的なテスト件数とバグ件数を近似曲線で示したもの。対数曲線近似と二次多項式近似を示している。対数曲線近似や二次多項式近似のメリットは、近似曲線としてエクセルに標準でついていることだろう。具体的には、エクセルでの近似曲線のオプションで指定する。(OpenOfficeでは対数曲線近似は行えても、自動的に係数表示しない? Rだと、近似曲線を記述する格好になると思われる。)

__3__4


また下は、上記のデータをSPSS(ただし 15.0J)での回帰分析により、2つの曲線を描いたものである。

OutputtableOutput0


(ちなみにDay2でのバグカーブもX軸は件数。しかも2ヶ月程度で30万件強のテストを実施している。これはこれで驚きである。しかもバグ件数の想定が2619件で実績が2008件と、予測とのずれが少ないし、しかも絶対的にバグ率が小さい。)

企業によっては、公の資料としてゴンペルツ曲線などでの予想カーブを描かないと行けないなどがあるかもしれない。しかし、ソフトウェアテストの実務上は、対数曲線や二次多項式近似あるいは直線近似との乖離を監視するので良いと考える。特に、二次多項式近似あるいは直線近似の場合は、発見バグ数の予測によりカーブを求めることが容易である。工夫すれば、対数曲線での予測カーブを求めることも可能となり、実際の発見数との乖離を早期に見つけることが出来、差異に対する対応が行いやすくなる。

興味あれば、お試しあれ。

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

2010年3月 3日 (水)

津波と潜水艦の検収

日曜日の津波は、結構時間が長くて多少驚いた。理科系の立場としては、他の日本への津波もそうだったのか気になる。また、到達までに時間がかかったり、継続時間が長かったのなら、その理由も調査して欲しいものだ。結構水温とかが昔から変化したのかな~。地形とかが大きく変わったとは思えないし、、、。

さて、軍艦の類は、台風に突入して検収するような話を以前聞いた気がする。それを思い出し、潜水艦の検収では、水中で津波に向かうなんてのもあるのかな~と考えてみた。

気象庁 津波について

津波は海中をものすごい速さで伝わるそうですが、もしもその真っ只中に潜水艦がい... - Yahoo!知恵袋

少し考えたら分かったし、上のページなどにもあるように、潜水艦での津波自体の影響は少なそう。潜水艦は、急速潜行や急速浮上の確認や訓練が重要となる。

でも、急速潜行や急速浮上の訓練って、船舶での船酔いの類ではないだろう。なんかふと、船酔いの嫌な臭いが充満しそうに思えて来た。ただし、台風のような状態が長く続けば、船舶の方が苦しいかも。負荷テストなりちゃんとした検収って、そんな犠牲が伴う。身の回りの負荷テストなり検収が甘くないか、対比的に考えてみるのも良いかもしれない。

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

2010年2月11日 (木)

「ソフトウェア開発 データ白書」 2005 Vs. 2009

IPA/SECによる「ソフトウェア開発 データ白書」は、結構前に読んでて書いておこうと思いながらも、まとめるのが遅くなってしまった。勘違いなどがあるかも知れないけど、自分なりの分析や感想を書いてみる。

この本が良いのは、毎年発行されていること。それなりの品質データが記載されていることや、FP(ファンクションポイント)とSLOC(ソース行数)の両方によるメトリクスが掲載されていることだろう。

ということで、2005年版(最初の版)を探しだし、その対比も含めて書いてみる。ちなみにP***/P***は、前の方が2005年版でのページ、後が2009年版でのページ。特に断ってない場合は、2009年版でのページである。

1)2009年版では、改良開発でのメトリクスが追加されている

これは、非常に良いこと。新規開発との対比もそうだし、今後は改良開発自体の比較も可能になる。

2)計測データ数の伸びが鈍化

このデータ白書は、旧来のデータに新規な調査結果を追加するタイプ。(細部分析すれば、新規追加分での把握な事が少なくないが。)

P13にデータの年別内訳があり、2004年の942件に対して、2008年が271件。比率も2004年 40.5% → 20.5% → 15.3% → 12.2% → 11.6% と、順次減衰している。個人的には、不景気などよりも、計測に対する取り組み意識が少し変化してる気もする。計測意識の低いベンダーとか、ベンダー内グループが少しづつ増えてきたのかも知れない。まさかと思うけど。

計測のメリットなども明らかになっているで、今後の動向を気にかけておくつもり。

3)FP利用が少し衰退

規模尺度の対比がある。 P20/P43

2004年版のFPのみ 51.1% → 2009年版のFPあり36.4%。これは結構実感とも合っている。表現が良いか分からないが、FPブームはちょっと去ったとのイメージ。

ただし、FPの場合は、計画と実績の差が少ない。P264およびP265。その点はFPの有利な点。

4)品質は確実にアップ

稼働後のバグ件数の図。 P55/P79

平均値が2004年版の40.4件 → 2009年版15.4件。標準偏差も2009年が少なくなっているし、そもそもグラフを見れば明らか。バグ件数50件以上のデータも存在するが、2004年度などのデータも含まれるのも理由だろう。個人的には、せめてこのデータ部分は年の累積棒グラフにしてもらいたい位。つまり、最近での稼働後でバグの多いデータ件数は、非常に少ないと考える。

5)ばらつきが減少

ソース行数と工数の関係など。どれが端的か悩ましいが、P67/P160など。

6)改良開発の件

データ対比で、改良開発で端的なのは、P253での新規開発とP255の改良開発の対比。改良開発の方がテストケースが増るが、バグ件数は少ない。つまり、影響部分を確実にテストしていることが伺える。

ちなみに、このデータ白書での改良開発での作成行数は、改良で追加等を行った行数。参照元のシステム(母体)は含まない。P17。

なお、ちょっと気になったのが、言語別のSLOC生産性の対比。新規開発P178と、改良開発P188を対比すると、C言語の場合に改良開発の方が高い。VBも若干高い。

すぐ後のページで業種別のSLOC生産性を示しているが、改良開発での製造業と公務は生産性が対比的に高い。その辺りが、上記C言語での改良開発における生産性の高さに結びついているのかも知れない。つまり、製造業や公務は、C言語で書かれたものを大きく改良(含む部分ペーストなど)するのではないかと。このご時世、そもそもC言語の利用というのも再考が必要と思うんだけど。 まっ、外してたらごめん。


いずれにしろ、今回の改良開発の追加も含め、データ白書は対比などで活用していきたい。

2月 11, 2010 ソフトウェア, 品質, 派生開発、保守開発、改良開発 | | コメント (0) | トラックバック (0)

2010年2月 5日 (金)

TMMi Version2

TMMi(Testing Maturity Model integlation)の、Version2.0が発行されてた。TMMiは、ソフトウェアテストのプロセスに関する成熟度を表す。

http://www.tmmifoundation.org/html/tmmiorg.html

→ http://www.tmmifoundation.org/html/resources.html での「TMMi Reference Model」。

Version2では、成熟度でのレベル3が追加されてる。Version1でも、ちょっと触れてたと言えば触れてたけど。それにしても、この調子だと1,2年毎に記述されるレベルが上がるので、レベル5まで揃うのは、まだちょっと先ということかな。(まっ、それはそれで面白い。)

さらっとしか見てないし厳密に比較してないし、そもそも英語得意じゃないので、読み違えてたら悪いけど、Version1との主な違いは以下辺りかな。

・Test strategyは、どっちかというとレベル2からレベル3でへ

・Test automationは、レベル2でも必要に

Test strategyが重要なことは分かるけど、実際に構築できてるところが少ないということかもしれない。あるいは、TMMiではTest strategyに対して色んなプラクティスを書いており、レベルアップには時間かけても良いよとしているのかも知れない。個人的には、後者として納得したけど。

なお本Version2については、JaSST2009東海での電気通信大学西先生の講演資料に、少し記載されている。(参加したわけではなくて、今調べていて発見した次第。)


普通の組織体では、(成熟度は低いか高いかは別として)開発プロセスやソフトウェアのプロセスを持っている。あるいは、それが普通。 なので、悩ましいのは、ソフトウェアテストプロセス構築手法のどれを、あるいはどこを採用すべきかという点。プロセス構築手法を簡単に比較できるのがいい。お勧めは、ISTQB/JSTQBでのAL(Advanced Level)レベルかな。

http://www.jstqb.jp/syllabus.html

日本語版 Version 2007.J01だと、90ページ以降。

自分自身としても、どんなプロセス構築手法が良いか悩んでいることもあるので、今回のVersion2を契機にCTPなどもちょっと読んでみようと思う。

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

2010年1月30日 (土)

「ソース・コード静的検証によるソフトウェア品質評価の意義」

日経エレクトロニクス(NE)、1月25日号。先週届いたけど積ん読状態で、さっき読んだ。表紙は、マラソンのスタートっぽい写真。

http://www.nikkeibpm.co.jp/cs/mag/ele/ne/saishin.html ただし、最新号のページなので、時が経てば変わる。

その中での興味深かった記事の一つが、タイトルの「ソース・コード静的検証によるソフトウェア品質評価の意義」。論文だが、端的には、オージス総研での”Adqua”によるソフトウェア品質分析。ただし、もちろん、ISO/IEC 9126での品質モデルやGQM法との関連にも言及している。

静的解析ツールでの各種メトリクスを、段階的な対応付けで評価得点化する。手法的にはGQM法。評価得点種は、ISO/IEC 9126での機能性以外の5項目。

ここでの「信頼性評価得点」とバグ密度、そして「保守性(変更性)品質評価得点」とコーディング&テスト効率のそれぞれの相関が高いことを示しており、実務的にも役立ちそうなことも少なくない。


なお、このような得点なり点数にすると、良く判ってない人が満点目指すとかして、暴走する/プロジェクトが回らない話も聞く。現場に適用する時は、その辺りの回避もミソかな。 

#上で、9126って書いたけど、もちろん論文では、25000シリーズとの関連を簡単だけど脚注で触れている。ちなみに個人的には全部理解してないけど、25000ってなんであんなに大ボリュームにしたのか分からない。そのせいもあって、むしろ品質特性での議論で大事なのは、継続的改善の方かと思う。

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

2010年1月24日 (日)

HDリマスターに見る日本的品質

CS放送の「時代劇専門チャンネル」で、最近時々流れているのが”御家人斬九郎”の、ハイビジョンリマスター版制作の様子。

http://www.jidaigeki.com/special/1001_2/など。

斬九郎って、今まで時々見てたけど、実際は直近でもフィルム撮影だったそうだ。なので、ハイビジョンにしやすい。ただ、それだけだと驚かないけど、少し前はワイドでのフィルムじゃなかった。それをワイド化していく。単に上下のカットじゃなくて、当時のカメラマンと一緒に、構図的に上の方を残すとかやったとのこと。

また、デジタル処理で、従来だと目につきにくかった近代建築なども処理を行ったそうだ。従来のSDではほとんど目につかなかったが、ハイビジョンでは判ってしまうのでデジタル処理。(なんか韓国とかでは、時代劇つうか昔のドラマとかで、電線とか出ても余り気にしないみたい。ちょっと聞いただけで調べてないし、まっ国や人で考え方違う。)

時代劇のハイビジョンリマスターに向けたそんな作業の様子を目にすると、やはり日本の細かさというか品質に対する取り組みは、分野違っても同じなのかなと思えてくる。ふと、後は、そんなコンテンツを他の国に出せれば良いだけではないかと。


なお、”御家人斬九郎”の、ハイビジョンリマスター版は、明日25日からの放送。

1月 24, 2010 品質, 映画・テレビ | | コメント (0) | トラックバック (0)

2010年1月19日 (火)

「柱のきずは~ をととしの~」と唄いながら

今日は、何故が童謡”背くらべ”を口ずさんでしまった。

  柱のきずはをととしの
  五月五日の脊(せい)くらべ

先週だったかのソフトウェアのメトリクス関係の話から、思い浮かべたのかも知れない。(言葉のリズムのせいもあるけど)昨年とか去年でなくて、”一昨年”というのが良い。

なんか事例発表とかって、昨年との対比など、どうも短期的なのが多すぎ。せめて、2,3年続けるくらいの気持ちが必要と感じてしまった。

しかし、それよりも厄介なのが、全く計測に無頓着なケース。昨年との対比すら行われないケース。それで信頼性や品質が向上したかとか、適正値に近づいたかが分かるはずがない。

子供達だって、センチやメートルを知らなくても、マーキングすることでの対比が出来る。子供や自分がどれくらい大きくなったかを測ろうとするのが自然と思うけど、ソフト屋さんにはそんなこともせずに精神論ばかりという輩がいるみたい。困ったもんだ。

ちなみに、本童謡の作詞は、海野厚。著作権消滅曲。

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

2009年12月31日 (木)

トラブル・告知サイト

休みでの”積んToDo”対応その7。今年ちょっとウォッチすることにした、告知とかトラブルの紹介サイトの件。いくつかサイトがあるけど、自分でもまだ整理できて無くて断片的な情報だけど、書いておく。

製品安全ガイド

検索が可能で、重大製品事故にかかる公表を集めたもの。改正消費生活用製品安全法施行日の2007年5月14日以降のデータ。

NITE 独立行政法人 製品評価技術基盤機構

上との対比では、NITEは消費生活用製品安全法に基づく報告義務のない事故の掲載。

リコールプラス[家電]:家電に関するリコール/自主回収/お詫びの情報 (ソフトジャンル)

ソフトウェア屋の立場としてちょっと重宝している、家電業界のソフトウェア関係のリコールなどを集めたサイト。ただし、DVDのようなコンテンツ関係も含んでいるので注意。運営しているのは、一般の企業みたいである。


もちろん、これ以外に多数あって、自分でも整理できていない。逆に、一般消費者の立場では、どう検索して良いか悩むのでないかと思えてしまう。

製品安全ガイドとNITEが別々なのは、その最たるもの。消費者にとって、報告義務があるかどうかは余りたいしたことではない。○○が重大事故と聞いて、それとは直接関係しない自分の**は問題ないかを調べるのに、両方見る必要があるというのも変である。データベースの共通化までは無理としても、せめて公的機関間の情報やり取りが出来るようなインタフェースは考えるべきと思うんだが。


ソフトウェアのトラブル関係を、うまく一覧化しているサイトがないかは、ずっと宿題だ。上で書いたリコールプラスや失敗事例のサイトなどは参考にしているけど、不十分かなとの認識。と言いつつ、他力本願じゃなくて、自分とかコミュで整理しないと行けないのかな~とも。(一部そんな活動はしてるんだけど。)

12月 31, 2009 ソフトウェア, 品質, 安心・安全 | | コメント (0) | トラックバック (0)

2009年12月 1日 (火)

東工取のシステム障害での発表や対策

東京工業品取引所で先月27日にシステム障害が発生し、金の先物等の取引が出来なくなった。

東工取のシステム障害、原因はナスダックOMX子会社製ソフトのバグ

原因の記者会見が上記。開発はNTTデータで、問題部分は、OMXテクノロジーという会社のものだった。

で、このシステムの開発発端の記事を見つけた。以下。(他にもいくつかある)

東工取、次期システムの発注をNTTデータに(OMX社のソフトを採用)


言わば、発表をユーザ自らが行い、開発会社や利用しているモジュールやその作成会社が、(表現としては非常に変だけど)白日に曝された。また、東工取とNTTデータが原因究明まで行い、スウェーデンのOMXテクノロジーにソフト修正依頼をして、東工取とNTTデータで動作確認したんだろう。修正までの時間との勝負もあったろうし、動作確認といっても修正部分以外のテストもある。関係者は大変だったと想像できる。

逆に、ふとOMXテクノロジーの迅速な対処とかには感心してしまった。(人によってはバグ発生自体を大きく問題視する人もいるかもしれないが。)

ここでのソフトを、COTS( commercial off-the-shelf:商用オフザシェルフ、商用品)と呼んで良いか分からないが、増えつつある形態である。いわゆる外部モジュール。


その意味では、今回のトラブルは、対応も含めて非常に参考になるケースである。

重要なモジュールとかを公表しておくのは、トラブル発生時のリスク低減になる。逆に、そのためのメカニズムの用意や、テストなどを視野に入れておく必要がある。またCOTS開発側にしても、修正などを含めた迅速な対応を行えるかを十分検討した方が良い。ふと、そんなことを思った。

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

2009年10月 4日 (日)

「単体テスト」は、テストチームのメイン作業じゃないだろうに

結構、同意したブログ記事。

単体テストはQAのためのものか

時期的には書かれた頃にすぐに読んで、「そうだよな~」と思っていたもの。ついつい、こちらに書くのが遅くなっちゃった。

念のためだけど、ここでの単体テストって、ISTQB/JSTQBでの”コンポーネントテスト”のこと。

そんなテストは、本来設計がやるべきもの。そこまでテストチームがやるんなら、「設計って何やってるの?」って皆が言いそう。例えば、ソフトウェア技術者になりたい学生とかも、疑問になるだろう。

ペアプログラミングの担当だって、基本は設計者。それとコンポーネントテストとは、ちょっとしか違わない。ソースコードレビューに、テストチームを含めて効率が良いとは思えない。テストして問題あったら直すのが目的と考えれば、コンポーネントテストもペアプログラミングもソースコードレビューも手段としては同類。その中心は設計だろう。

もちろん、”コンポーネントテスト”という用語や手法は知っていた方が良いけど、それをQAなりテストチームがやるべき前提と考える点はおかしい。


そのブログに、「単体テストはQAのためのものではなくなっているのでは」って書いてあるけど、もしQAのためと今まで思っていたら、QAとしてちゃんとコンポーネントテストをするための工数とか、その網羅率とか測っているんだろうか、、、。今まで、そうしてきたんだろうか? (もちろん、結構成熟した組織で設計内のテストというかサポートとしてコンポーネントテストを実施するところがあるのは知ってるけど、それが一般的に所属としてのQAというケースは少ないだろう。)


ちなみに、海外の場合にQAチームが別組織で、そこが結構コンポーネントテストを実施するケースが少なくないのは知ってる。でもその件と、日本の実情なり今まではと違うと言える。

10月 4, 2009 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2009年10月 3日 (土)

「セーフウェア」の和訳本

「セーフウェア」の和訳本が出るとのこと。知り合いの書き込みで知った。

アマゾンで予約できる。

金額的には、日本語訳の方が安い。



ちなみに、以下が、今年のJAXA主催のイベント。2日目に彼女は講演している。その日に懇親会があって、英語の方の本を持って行ってサインもらおうかと思っていたけど、懇親会には彼女は都合とかで不参加。ちょっと残念だった。

http://stage.tksc.jaxa.jp/jxithp/seminar/0301.html

10月 3, 2009 品質, 安心・安全, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2009年9月16日 (水)

JSTQBのアドバンストレベルは、開発者も読んで欲しい

正確には、ISTQBのアドバンストレベルの日本語訳のこと。以下のJSTQBのサイトにある。(本来はトップからどうぞ)

JSTQBのシラバス(学習事項)・用語集

ご存じだろうけど、ISTQBは「International Software Testing Qualifications Board」で、JSTQBは日本での加盟組織。ソフトウェアテスト技術者資格認定の運営組織である。

日本語訳として既にファンデーションレベルはあったけど、今回アドバンストレベルの訳が公開された。

結構ソフトウェアテストでの管理関係が書かれていて、参考になる。なお、個人的に非常に良いと思ったのは「15.1 現場への適用のための推奨事項 」。テストの作業効率に悪影響をおよぼす事項を掲示している。30個近い。

例えば、、、。
・機能テストに偏ったテスト計画を策定する
・ドキュメントをテストしない

個人的には、本来ソフトウェアの品質は、そのプロジェクトの長や設計/開発者が保証すべきものと考える。少なくとも、テストチームとの”連携”という意識は必要。上記の例で言えば、開発者などはテスト計画を見て、非機能テスト(非機能要件のテスト)があるかの確認や、ドキュメントのテストをテストチームが行うようになっているかの確認が必要である。テストの工数として、それらも予定に入れておくべきである。

なお、「現場への適用のための推奨事項」の悪影響排除をテストチーム以外(特に設計/開発)の協力の下に行うことや、その製品やプロジェクトでは無視できるとの判断もあろう。しかし大事な点は、それらを計画時に検討したり、作業分担の検討やその合意を取ること。


以下のような項目もある。
・全てのテストを自動化しようとする

他にも類似する項目があるが、ちょっとしたソフトウェアテストの本や講演をかじって全部に適用しようとするケースが少なくないと思える。そのために失敗とか作業のやり直し。あるいは、プロジェクトそのものの再構築になることすら発生しているように聞く。テストチームからの提言が上辺だけのものになっていないかの確認としても、本「現場への適用のための推奨事項」の部分は役立つと思う。


なお、個人的に引っかかるのが「システム統合テスト」。P25で、ファンデーションレベルでの追加のテストレベルとして記載してある。しかし、ファンデーションレベルでのP21に「システム統合テスト」は明記してある。少し細かいかもしれないが、従来での”単体テスト”が、実際はISTQBで言うところの装置のシステムテストに該当したりするケースが多い。そのため、「システム統合テスト」という用語は浸透しておくべきと考える。つまり、「システム統合テスト」は、ファンデーションレベルでの必須用語としておくべきと考える。


ちなみに個人的には、本訳に掲載されているIEEE 1044をちゃんと押さえてないような気がする。持ってたか??? 時間見つけて確認するつもり。

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

品質と”かわいさ”と、どっちが大事?

先週でのちょっとしたニュースは、ビデオ機能付きのiPod nano。そして脇的になったニュースが、iPhone OSやiTunesの新しいバージョン。

iPod nanoとの対比を色々読んだりしたけど、ハードを比較する時代じゃないと思う。iTunes経由のダウンロードとか、App Storeを含めての比較をしないと。(さらに言えば、iPhonとiPod TouchはMacベース。普通の日本企業なら事業部とかが異なっているのに、ベースを共通にしている状況。他には、「アップル品質認定の整備済製品」なる制度もあるそうな。この辺りの風土も考えないと。)

あと目にしたのが、iPhone 新OSの不具合というか使いにくくなったなどの意見。実は、おいらも(ビデオ付きの方じゃないけど)iPod nano利用者。音楽聴きながらメモ見れるなど、並列的な処理を行える。ゲームも同時にできたような気もする。なので、結構ハングアップ。電源再Onで対応。(なのでは、変かもしれないけど。)


そんなこともあって、今日たまたま“軽~く一杯”でお店に行く途中で質問。もし我々が、アップルの品質部門だったら、「出荷OKにするかな~?」。

おいらも含めて、知り合いにiPodやiPhonユーザは少なくない。ハングアップは、まっ常識。そんな知り合いで、ソフトウェア品質とかソフトウェアプロセス、プロジェクトマネジメントに携わっている人も多い。そのため、ちょっと意地悪い質問が、先ほどのOKにするかとの問い。


道すがらだったから突っ込んだ議論にはならなかったけど、同じ認識だったのは「可愛いから、許せちゃうのかな~」。Macでの爆弾マークの可愛さにも通じるだろう。

でも、ある意味ではOKとするかの答えじゃない。答えにするには、「可愛さ」の尺度を考えたり、それと品質(バグやテスト網羅性)を比較しないといけない。あるいは、ユーザー自身が欲しているものや優先順位なども考える必要がある。


携帯じゃないけど、音楽プレーヤー等も海外製品(iPodやiPhon)が、非ガラパゴスなのかもしれない。「可愛さ」も含めて、品質って何だろうかとか、世界との競争でどうあるべきかを考える必要があるのかな~と思った次第。

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

2009年9月 4日 (金)

SPRINGAM関連の話を聞けるとは

今日は、某コミュニティでの勉強会。ソフトウェアでの重大事故の未然防止に関するもの。

で、説明の際に「SPRINGAM」がちらっと出た。実は、2,3ヶ月の間、ちょっと気にしていたもの。というのも、「SPRINGAM」は、ある日本企業での生産標準(開発方法論)で、ISOとかPMBOKも取り込んでいるイメージがあった。また、その会社では、CMMI レベル5達成を認められている部門もある。ISOやCMMI、そしてPMBOKを統合していると思え、気になる点がいくつかあった。また、SLCP(ソフトウェアライフサイクルプロセス)の扱いも気になっていた。

今回の講演でのQ&Aの際に、多少ぶっきらぼうな質問もあり、「えっ~、恐れ多くも、レベル5を認めてもらえるような所なんだから、頭下げて聞くくらいが良いのに~」とか思ったりした。説明の人が、まだまだ改善の余地があると丁寧な話し方だったからかもしれない。(この辺りが優秀な人の所以。レベル5取って高飛車な連中もいる。)

なお念のためだけど、今回のコミュニティにはCMMIのレベルを認めてもらった企業はいくつかあるし、今日もレベル5を認めてもらった会社のメンバーがいた。


今日の講演の題目とか説明者をちゃんと読んどけば、SPRINGAMと関連ありかもと思えたんだけど、ちゃんと読んでおかなかった。逆にそのために、今回の講演が非常にラッキーに思えた。懇親会でも色々話を聞けて良かった。SPRINGAMそのものの話は聞けなかったけど、雰囲気としてはSPRINGAMを統合したプロセスとして構築したというよりも、ISOなどを取り込む格好にしたとの理解が良さそう。意地悪い言い方だけど、部分部分の改良。(逆に、そうできると言うことは、骨幹は結構シンプルなんだと思う。)

レベル5取っても予防活動するところがすごい。もちろん、レベル取得って全部門じゃないから、横展開なども必要なんだけど、、、、。信頼性向上のためには、常に問題意識と改善活動が重要と思った一日だった。

9月 4, 2009 ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2009年4月30日 (木)

日立冷蔵庫の“エコ”不当表示とコンプライアンス

今日の日経新聞。日立のエコ冷蔵庫の、不当表示に関する謝罪広告。一面の広告で、日立アプライアンスと日立製作所の連名。

「えっ、ここまで問題になったか~」というのが、偽らざる気持ち。また、電機メーカーを中心とした公的資金の注入もニュースになっているので、余りにタイミング悪すぎ。

開発のデータが企画に正確に届かなかったとのこと。ただし、開発⇔企画とか営業の対立って、どこでもあるような構図。なので、ちょっとした手違いで、どこの会社でも発端に関しては起きる可能性はある。ただし、今回は、その後が芳しくない。賞受賞のヒヤリングでも明らかになってないし、その後場合によっては自主的に返上とかすれば良かったのに、それができなかった。

個人的な日立系の知り合いって優秀。超が付くくらい。なので、ついつい、何で起きたんだろうと気になった。一番気になったのは、コンプライアンスの通報制度。表面的だけど、ネットでの情報を探してみた。

まず、日立製作所のコンプライアンス通報制度って、「取締役会の窓」というのがあり、2004年5月からは匿名でも通報可だそうだ。

http://www.hitachi.co.jp/csr/csr_images/csr2008_016-031.pdf

グループ会社に目を向けると、日立電線商事は一般の人の通報もできるようにしてある。

http://www.densyou.co.jp/compliance/index.html

他にもグループ会社のコンプライアンス体制も、結構検索で引っかかる。ソフトウェア関係では馴染みにある「日立ソフトウェアエンジニアリング」なども。

が、日立アプライアンス株式会社でのそれが、なかなか見つからない。上の方に表示されない。社長の方針めいた資料に出てはいたけど。(見つけ方が悪かったのかな~。) ちなみに、日立アプライアンス株式会社のトップページは、本件のお詫びのページになっている。

#それにしても、コンプライアンスとアプライアンス。言葉として似すぎ。


で、今日の新聞読んで思ったけど、コンプライアンスの体制って、単独ではなくてグループ会社を巻き込んでやらないと駄目な時代なんだな~。しかも、体制を作る次元ではなく、それを回してったり、監査的な事を実施しないと駄目。またできれば、一般ユーザからの声を取り込める形態にしておくのが良いということかも。


なお、最近のニュースでは社内告発が不利となったとのニュースもあった。(詳細は不明なので、視点が偏ってるかもしれないけど。)

http://www.shikoku-np.co.jp/national/social/article.aspx?id=20090227000217

もしそんなニュースのために、今回のエコ冷蔵庫の社内告発が埋もれてしまったとしたら、残念としか言いようがない。

#いずれのリンク先も、更新等で辿れなくなってたらごめんなさい。

4月 30, 2009 ニュース, 品質, 新聞 | | コメント (2) | トラックバック (0)

2009年2月20日 (金)

半導体から学べなかったのか、日本の「電機」

実は結構以前からソフトウェア品質の向上のために、半導体のアプローチが参考になるかと思い、少し勉強している。(細部は後日。) また、明日、とあるコミュニティで「組込みソフトウェア開発プロジェクト」に言及することになり、組込み業界を再俯瞰している。

こちらは、今週月曜日に発売となった週刊ダイヤモンド。タイトルが、すごい。”「電機」全滅!”。すごいと言うよりも、実感がストレートに表現されていると言った方が適切か。

電機業界の損益とか人員整理に言及したもの。

組込みソフトウェアで括るけど、電機業界のそれと、自動車や機械のそれとは、アプローチが違うと考えた方が良さそうに思えてならなくなった。アプローチと言うよりも体質的な事なのかも。


また、週刊ダイヤモンドの表紙にもある、”半導体”の文字が気になっていた。半導体も、昨今はCでの記述など高速にソフトウェア的な面が出てきた。一般論としての、組込みやIT業界のソフトウェアの品質と、半導体のそれとは比較にならない。ソフトウェア開発の立場では、高品質半導体ソフトが非常に参考になると思いながら、何かが頭に引っかかっていた。それが何か、、、、。結局、収益なんだと、今週気がついた次第。

そこで、なんで日本の半導体の収益が悪化したのか、わかりやすい資料を探してた。今のところ一番わかりやすかったのが以下。

「技術力から見た日本半導体産業の国際競争力の研究」

要は、過剰技術、過剰品質で、利益確保するチャンスを失ってしまったというもの。サムソンなどの製品化のための流れなど、非常に参考になった。携帯の”ガラパゴス化”とも通じる面があるだろう。そう考えると、過剰技術、過剰品質は、電機に共通な”性格”なんだろうと思えてきている。

ちなみに似たような内容で、同名レポートがある。ただし、個人的にわかりやすかったのは上。また、本レポート作成の(元エンジニアの)同志社大学 湯之上 隆氏の記事が、ネットにはいくつか転がっている。

QCDというのは容易いけど、C(コスト→利益)の事も考えないと、ソフト”全滅”になっちゃう。今年とかは、その辺りを意識しないと大変なことになるということ。

2月 20, 2009 テクノロジー, プロジェクトマネジメント, 品質, 経済・政治・国際 | | コメント (0) | トラックバック (0)

2009年2月18日 (水)

F-15C 空中崩壊

ネットで品質関係調べていて、引っかかったのがタイトルの「F-15C 空中崩壊」

保守の不備で訴訟起こしたみたい。写真見る限り、胴体で真っ二つ。(写真が本物かよく知らないし)専門家じゃないけど、こんな部分が崩壊するのって珍しいのでは?

本件の原因は、金属疲労とのこと。しかし、米軍での、F-15の直近1年間の墜落が、5機にも上るそうだ。それを聞くと、ちょっと多すぎと思えてしまう。


F-15って、試作から30数年らしい。我々が若い頃、当時の次期戦闘機の絡みもあって、F-14 Vs. F-15のことを酒の肴にしたこともあったと思う。もちろん、我々が次期戦闘機を選別する訳じゃなかったけど、結構いろんな国の機種が雑誌などを賑わしていた。

ちなみに、次期戦闘機(次々期戦闘機というべき?)として、F-22とか国産ステルス機「心神」なども話題もあるようだけど、F-14 Vs. F-15のような盛り上がりはないように感じる。機密性が高くなったためなのか? あるいは、政治系の記者の注目が、そんなことよりもゴシップ系とか上辺だけを扱うのを良しとするようになったのか??

2月 18, 2009 テクノロジー, 品質, 安心・安全 | | コメント (0) | トラックバック (0)

2009年1月 1日 (木)

読売新聞 元旦のスクープ 「生体認証」突破して入国

今日元旦の新聞。特集的な記事が多い中で、読売新聞は異彩。入国審査時の指紋照合で偽装して、不法に再入国していたことが判明したというもの。

テープの利用ということで、本人確認の生体認証(バイオ)の、もろい一面が出たことにもなった。

なんか、今年の情報関連での大きなテーマを与えられた気がしてならない。性悪説とかを前提とした設計とか、いくつかのゲートを用意する必要があるということ。ふ~~。

元旦で、のんびりTV見てて、紙面一覧のようなコーナーだったかで紹介された。気になったので、その後コンビニまで行って新聞購入。他の新聞も買って、改めて元旦の新聞は分厚いなーとも感じた。

1月 1, 2009 ソフトウェア, テクノロジー, 品質, 安心・安全, 新聞, 科学技術 | | コメント (0) | トラックバック (0)

2008年11月25日 (火)

日本のカメラが低品質だった頃

なかなか面白い論文を発見。

日本カメラの品質向上と輸出検査 日本大学経済学部 竹内さんという人の論文。

戦後初期は、日本のカメラは低品質だった。その品質向上の取り組みを論文化したもの。特に目を引いたのが、”輸出検査”。その検査での不合格率のグラフがあるけど、悪いときはスチルカメラで35%。レンズで40%。とても、今では信じられないような数字。(といっても、今輸出検査がある訳じゃないと思うので、市場品質みたいなものとの比較だけど。)

羨ましいというか、さすがだな~と思ったのは、業界として取り組んだことや、それらのデータ取得を行ったこと。掛け声ばかりじゃ、品質は上がらない。データ取得したり、問題点を潰してかないと。

その点、ソフトウェアは、まだまだ対応が遅れてるとしか思えない。(海外よりは高品質とのデータがあるだろうけど、以前より品質落ちてるし、ソフト規模の拡大などで楽観できない。)

11月 25, 2008 品質, 科学技術 | | コメント (0) | トラックバック (0)

2008年8月22日 (金)

北京オリンピック 「ソフト、ソフト、、、」

朝、TVtvのニュース見てたら、北京オリンピックで日本のソフトボールチームが金メダルを取ったとか。そして、表彰式後?のシーンがあって、複数のチームがボールで”2016”の文字を作り、オリンピックでの種目復活へのアピール。

チャンネル回しながら見たシーンだったので、最初は何のことかわからなかった。メンバーのユニフォームの色が幾つかあるし、単にボールをいくつか並べるシーンだったので。ズームアウトして、”2016”の文字と解って、なるほど。事前打ち合わせなんてするわけないだろうから、表彰後の皆の気持ちが体現されたんだろう。

「良いシーンだな~」と思って、急いでEPGで放送見たら、NHK BSでやりそう。予約しておいた。で、さっき見たけど、その表彰後のシーンなし。うーん残念think

ネットニュースとか読むと、日本/アメリカ/オーストラリアのメダルチームでやったそうだ。朝のニュースでは、オーストラリアのユニフォームの色は目立っていたけど、この類ってアメリカのメンバーは参加するのかな~と思っていた程度。でも、皆でやったみたい。

で、「バック・ソフトボール、バック・ソフトボール、バック・ソフトボール、、、」と叫んでたそうだ。ニュースの時は、”ソフト”は聞き取れたけど、その他は曖昧。なので、「ソフト、ソフト、ソフト、、」と叫んでいたように聞き取れてしまった。

(ふと思いだしたのが、カード会社のCMで、国連のような国際会議で各国の通貨を叫ぶシーン。面白いのが、ユーロ。皆で肩を組んで「ユーロ、ユーロ、、」。)


「ソフト、ソフト、ソフト、、」と叫んでいたように聞き取れた事もあって、今日一日”ソフト!”って、何人かで鼓舞する事あるのかな~と思った。というのも、組込みソフトの場合、ハードのしわ寄せがソフトに来ることが少なくない。

例えば、以下のSECでの「プロジェクト責任者向け調査 報告書」のP169で、「ハードウェアの仕様変更によりソフトウェアを修正した」ことがあるとか「ハードウェアの不具合をソフトウェアで回避した」ことがあるのが、50%前後を占めている。(0.5って、50%のことだと思う。)

http://sec.ipa.go.jp/reports/20080715.html

中には軽微なものもあるかもしれないが、少なくないのは事実。で、講演などを聞くと、スケジュールでの月レベルに影響することが少なくないから困った問題。さらには、そもそも、企画とか基本スケジュールがハード設計の都合で決まってしまい、ソフトの実装とかその周辺のこと、そもそも実装実現性が無視されて決められることが多いみたい。

今や人数的には、ソフトの設計やテストの人員の方が多いはず。その割には、イニシアチブをとっていない。イニシアチブなんていうよりも、なんか意見すら無視されているてな感じかな~。もっとアピールすべきじゃないの~。そうしないと、日本のお家芸の組み込みソフトはすたれるばかりだと思う。品質関係もそうだし、若い情報系の学生から見向きされなくなる。

「もっと、アピールしたら~~」。 なんか、今日のシーン見ててそう思った。

ちなみに、個人的には、SECでの本設問に追加して、ソフトへの影響度を測ってもらえればと思う次第。「ハードウェアに起因したソフト実装での影響 人月」みたいな設問。人月とするのに、抵抗ある人がいるかもしれないけど。

8月 22, 2008 スポーツ, ソフトウェア, 品質 | | コメント (0) | トラックバック (0)

2008年8月19日 (火)

宇宙線で鉄筋の透視

今日受けた科学関連のメルマガで面白かったのが、「手抜き工事もお見通し 宇宙線で鉄筋の透視成功」。

http://www.asahi.com/science/update/0813/TKY200808130230.html

題で分かるように、鉄筋のレントゲン写真みたいなのを宇宙線で作成できるというもの。17時間もかかるようなので、その辺りは今後の課題だろう。で、個人的に気になったのは、横方向の透視はどうするんだろうってこと。宇宙線って、簡単に曲げられたり反射できる? 宇宙線は文字通り、天から降り注ぐので、垂直に立った鉄筋を透視できないんじゃないの~。

でも、うらやましいのは、そんなことが記事になるなり、注目を浴びること。

効率的なソフトウェアバグ発見とか開発プロセスとかを考えたら、このように取り上げたり注目浴びると、少し状況違うのかな~。なんか、バグだらけでデスマーチ突き進む輩の方が、社内などでは評価高いんじゃないのかなとも思える。(というか、そんな会社が少なくない??) 

8月 19, 2008 テクノロジー, 品質 | | コメント (0) | トラックバック (0)

2008年6月28日 (土)

「食品企業の信頼性向上への対策」講演会

今日は、技術士会の講演で、東京海洋大学へ。

昔、東京水産大学の頃に1回行ったことある気がするけど、全然回りが変わった。結局少し道を間違えて数分遅刻。構内の掲示に潜水実習科目の件があったり標本の建物があったりと、畑違いなせいか新鮮。

会場は、なんか、懐かしい昔の国立大学の部屋coldsweats01そのもの。冷房が入っているのが、我々の頃との大きな違い。

そこへ、びっしりと人が埋まってたから、さらに驚き。3人掛けの真ん中の席が空いてはいたが、今から割り込むのも気が引けて、後ろでパイプ椅子を取り出して聞いた。(途中で知り合いの窓口の人が席代わってくれたけど。)


「食品企業の信頼性向上への対策」講演会  イメージ貼っておこう→taurusfishpig

場 所: 東京海洋大学・品川キャンバス

主 催: 社団法人 日本技術士会
(農業部会、水産部会、生物工学部会等食品関連部会およびプロジェクトチーム「食品技術士センター」、「食品産業関連技術懇話会」)

募集定員:120名

1)食品企業のコンプライアンスの徹底について

農林水産省食品産業振興課の人

2)雪印乳業に於けるコンプライアンス・CSR経営

雪印乳業株式会社の人


1)の話は、冒頭は、海外の日本食ブームの件。美しさとか最初に全部がそろうことが多いので豪華に感じるとか、、。また、中国とかでは、お菓子のパッケージに日本語の表示を付けるのが流行っている話が出た。MADE IN JAPANは書かないんだけど、日本語だと日本製をイメージするためとか。(つまり、食品も日本の高品質は浸透しているとのこと。で、じゃソフトはとか、昨今の偽装問題はとかに思いをはせた。)

で、そこまではプラス要因。逆に国内は、零細企業が多いとか低利益率のマイナス要因の話が。そして信頼性向上のための取り組みが紹介された。結構わかりやすい資料も作成しているが、それをどう広めるかが課題とか。業界団体へまずは説明しているようだけど。

2)の話は、雪印の数年以上前の食中毒事件と牛肉偽装事件、そしてその後の信用回復のための取り組みの話。企業存亡の瀬戸際までいった話なので、非常に参考になった。こんな講演の場でしか聞けないような話もあり、ソフトウェアの信頼性向上活動とかでも流用できそうなこととか、チェックが必要な事項も少なくなかった。

説明の際に(自分だけかもしれないけど)、水を打ったようようにシーンとなる時が何度かあった。聴講していたのは技術士の人や大学の人もいたと思うけど、企業内に努めている人も少なくなかっただろうから、いつわが身に振りかかるかといった思いがあったり、身の周りの取り組みとの対比を行っていたんだろう。

話も実例が多かったり、構内の掲示を見て、以前事件後に雪印内で講演してもらった人を思い出し、その人とのエピソードなどもあって資料の説明に終始しなかったのも良かった(と個人的には)思う。

行動基準とかCSR取り組みの冊子をもらう。行動基準が30ページ、CSR取り組み(活動報告書)が44ページ。ページが多ければいいという代物でもないだろうけど、個人的には具体的で好感持てた。逆に、ソフトウェアの信頼性向上活動との対比をついついして、そんなことやってる企業少ないよな~と考え込んでしまった。

事件以降の体制見直しで、ちょっとした(出荷前の)回収騒ぎが事例として話が出た。結論的にいえば、用具管理という基本的なことが守られていなかったため。基本的なことをやっていれば、早期に未然防止できたはずというもの。やはり、”慣れ”てしまう恐ろしさを述べていらした。 恒常的にどうするかは、どの分野でも課題だな~。恒常的にと、そのチェックをどうするか、、、。

畑違いだったけど、有意義な一日だった。

6月 28, 2008 品質, 安心・安全, 技術, 技術士 | | コメント (0) | トラックバック (0)

2008年4月26日 (土)

「ソフトウェアの規模決定,見積り,リスク管理」

少し酔っ払いながら、本屋(有隣堂)へ。今頃と思われるかもしれないけど、J-SOX法関連の本とか、知り合いの人が出版したそうなのでその本の確認とか、、、。他にも携帯電話に記憶させてた気になる本を調査。結局、気になってて見つけられなかった本が1冊。他は見つけられたり購入へ。

で、いろいろ回って目に付いたのが、「ソフトウェアの規模決定,見積り,リスク管理」。富野さんの監訳。酔ってたこともあって、「買ってないはずだよな~」と思いながらも自信なし。中身をパラパラ見て、買ってなさそうと思い購入へ。

アーンドバリューなどプロジェクト管理志向、リスク関係、オブジェクト指向に関するメトリクスなどが書かれていて、整理されていると感じた。(今までの富野さんの本と比べて、紙質が良くなったというかつるつる感が増えたように思う。あっ、そんなことはどうでもいいか。wink



なお、本屋をぶらぶらしてたら、Google Androidの(新しい?)本を発見。結構気にいった表紙。少し買おうか悩んだけど、数冊買い求めたこともあって今回は断念。次回にでもゆっくり見て、買おうか決めようと思う。

4月 26, 2008 ソフトウェア, プロジェクト管理, 品質 | | コメント (1) | トラックバック (0)

2008年4月24日 (木)

ISO 25000(SQuaRE)シリーズ 14冊

CMAP21さんも書かれているけど、ポツリポツリとISO 25000(SQuaRE)シリーズの話が出始めてる。ISO 9126などを発展させたもの。

http://blogs.dion.ne.jp/cmap21/archives/7075562.html

そこのこと自体は良いけど、ISO 25000(SQuaRE)シリーズって全部で14冊なんだそうな。14冊。4冊じゃなくて。

JISの9126を何冊か持ってるけど、個人だと1冊買うのも大変。ISO 25000(SQuaRE)シリーズのJIS版の値段がいくらになるか知らないけど、値段は考えてほしい。そうしないと、敬遠されることだってあるだろう。また、メトリクスのどれが重要だとかも書かれないと、闇雲に測定する連中が出てくるような気がする。そうもせずにやたらと規則だらけに運用すると、形骸化したISO9000の二の舞になりそう。

4月 24, 2008 ソフトウェア, テクノロジー, 品質 | | コメント (0) | トラックバック (0)

2008年3月19日 (水)

ソフトウェアテスト カバレッジ

「ソフトウェアテストの勉強室」での、コードカバレッジの記事。↓

http://softest.cocolog-nifty.com/blog/2008/03/post_7864.html

モディファイドコンディション/デシジョンカバレッジとかは良く知らなかったので、ちょっと勉強になった。「原因結果グラフやデシジョンテーブルなどを利用したテスト設計は、このカバレッジ基準と同等といえる。」って、網羅度として同値ということにもなるのかもしれないけど、良く考えてみたい。

具体的な例で100%の網羅度の例を示したり、強み/弱みが対比されてて面白い。


実は、月曜日の宴会で、”網羅度”が少し話題となった。こっちは、「網羅度って割合で、分子/分母」とか「コードカバレッジ、要件に対するカバレッジ、組合せテストでのカバレッジは、それぞれ意味が違うよ」っと途中まで言ったけど、何か聞く耳持たない人が多かった。うーん、大事な事なんだけどね。

3月 19, 2008 ソフトウェア, 品質, 組み合わせテスト | | コメント (1) | トラックバック (0)

2008年3月10日 (月)

「組込みプレス」形式手法、「プロセス改善ナビゲーションガイド ベストプラクティス編」

今日は朝早かったので早めに切り上げて、ちょっと本屋さんへ。

組込みプレスはVol.10。”祝”のマーク。形式手法の車載シスエムへの応用が目に留まったため購入。なお、帰ってから読んだら、Promelaという構文を利用しているみたい。ちょっと良く調べてみないといけない、、。

巻末にはスキル判定シートなるものがあり、結構面白そう。また、ロボット技術なども。


SEC BOOKSとして、「プロセス改善ナビゲーションガイド ベストプラクティス編」が出ていた。いくつかの事例集と考えた方が良い本。結構具体的で、参考になりそうなメトリクスなども少なくない。

JAXAとか日本電気(CMMIレベル5)もあり。住友電気のJAVAでのu管理図は、以前から気にしていたテーマなので参考になった。(でも、時系列での視点の言及が、少ないような気がするけど、、、。)


どちらも、細かい部分を読むと結構身近なプロジェクトでのヒントとなったり、URLにアクセスして深く調べた方がいいのがある。今週、他の資料も含めて詳しく調べようと思う。

3月 10, 2008 ソフトウェア, 出荷判定, 品質, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2008年3月 7日 (金)

「やわ物の品質管理の考え方」森口繁一さん

ソフトウェアの品質関係をネットサーフィンしてたら、故森口繁一さんのPDFを発見。

http://www.juse.or.jp/software/pdf/tresurebox02.pdf

「やわ物の品質管理の考え方」と題した、7ページの記事(シンポジウム講演)。”やわ物”とか”HIPO”とか、結構懐かしい用語を目にする。当時、ソフトウェア関係の英語表記を日本語で表記する動きがあり、当時が偲ばれた。ただし、”算譜”は結構記憶がはっきりしてるけど、”やわ物”と呼んだかは???

バグを見つけるよりも発生の防止が重要とか、統計(今ならメトリクス)を改善のために活用しなさいとか、基本的なことが書かれている。1981年の記事、20数年前。

森口先生は、当時個人的には数学系との思いがあり、ソフトウェア工学とかソフトウェア品質に関するこの記事は新鮮だった。(ある意味では、当時が不勉強だったのかな。)


当時(その少し前?)だと、コンピュータは花形産業。(多少失礼かもしれないが)キーパンチャーですら、憧れの職業だった。それが今や3Kとか5K?とか。会社や部署、業界によるらしいけど、20数年前よりもひどいと思わせるような非科学的なプロセスがあるように聞く。進歩してないのか、情報系の連中が不勉強なのか、誰でもソフトを作れると思うような組織の問題なのか、、、。勉強テーマになりそう。

ちなみに森口さんの記事は、以下の日科技連のページから辿れる。他にも参考になるのが少なくないので、興味あればどうぞ、。

http://www.juse.or.jp/software/tresurebox.html

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

2008年2月18日 (月)

「情報処理」 ”ソフトウェアテストの最新動向”

情報処理学会の会誌「情報処理」2月号の特集は、”ソフトウェアテストの最新動向”。

http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-JS8020-JS-Z

以下が最新号のはずなんだけど、今は1月号。
http://www.bookpark.ne.jp/ipsj/index.asp

以下は購入ページだけど、詳しい目次が分かる。
http://fw8.bookpark.ne.jp/cm/ipsj/search.asp?from=Magazine&flag=-1&keyword=Magazine,YM200802

学会誌なので、少し固めの内容。特に並列プログラムのテストとTDDは、そう感じるかもしれない。ただし、具体的なので、分かりやすいと思うんだけど。

なお、テスト/デバッグ技法の効果と効率は、テスト技法の包括的な話。もう少し突っ込んだ話は、松尾谷さん自身の講演なんかで聞くのが良さそうに感じた。

情報処理って、ソフトウェア開発者でも読んでない人が多いんだよな~。まっ、学会誌だから仕方ないというか、それが日本の実力。会社で話題になればラッキーな方だろう。特にお偉いさんが読んで気が付けば、ちょっとソフトウェア品質上がるというか、ソフトウェアテストの体制や技法の見直しなどに結びつくかもしれない。

2月 18, 2008 ソフトウェア, 品質, 直交表, 組み合わせテスト | | コメント (1) | トラックバック (0)

2008年2月 9日 (土)

「新派生売買システム」、OpenPNE運用実験、Googleカレンダー、、

今日は、結構バタバタ。

朝、「新派生売買システム」の障害の件を、ほんのちょっとしたレポートへ。とある所で、障害事例を調べているため。(でも、数段詳しく調べる人がいくれて脱帽。)

昨日のトラブルは、前引け後に派生売買システムに障害が発生して、TOPIX先物2008年3月限(JTIH8)の売買を後場から終日停止したというもの。 復旧の見込みが立たず、三日連休返上だそうだ。

http://itpro.nikkeibp.co.jp/article/NEWS/20080208/293321/

http://itpro.nikkeibp.co.jp/article/NEWS/20080208/293371/

で、本システムは以前から危なさそうと言われていたもの。

http://itpro.nikkeibp.co.jp/article/NEWS/20080123/291892/

の、中段などを参考の事。ToSTNeT(立会外取引)システムとの統合なので、接続でのテストや負荷、異常データなど多数の注意すべき事項があったんだと思う。基本的に色んな所に、バグが潜んでいる/いたんだろう。規模でかいし、大変。


その後というか、平行しながら別コミュニティのOpenPNE(SNS)の運用実験。昨日テストしつつあると聞いて、早速テスト。やっぱ個人的には、メールベースでの連絡よりも、SNSなんかの方がいいな。日記の下に自分のブログサイトも記載できる。つまり、そのSNSでの日記とブログの日記の表題が両方出る。mixiだと、mixiの日記→各ブログへのジャンプなので、そのワンクッションが面倒。

テスト運用のための、コミュやトピを作成したりした。若干登録の手順でおかしいところがあったので、蓋してもらった。作業が早くてありがたかった。

早急なテストだったので、全体的な見直しは必要そう。でも、何となく基本的なところは形が見えてきたかな。後は、皆をどう勧誘するかとか、本格運用のお墨付きを貰うにはどうするかなどが課題。

さすがに、頭使いっぱなしだったので、一時期スーパー銭湯へ。

その後は、OpenPNE(SNS)の運用実験とGoogleカレンダーのオフライン操作へのチャレンジを、平行しながら作業。運用実験は、他の人とのネット上の意見交換もあるので、やっぱ時間かかる。

で、Googleカレンダーのオフライン操作だけど、数日前から悪戦苦闘。Googleカレンダーのサーバーが駄目になった時に、どうオフラインデータを表示させるかの検討。同期よりも、オフライン表示を優先させようとしたもの。

そもそもGoogleカレンダーのエクスポート→インポートが、とある場所では、どうもブロックされている。最初それに気がつかず、ソフトそのものが動かないと思って再ダウンロードなどの作業が発生。自宅で実験したとしても、うまく行かないケースが、、。

・Calgooはネットワークをはずして起動すると、ハングアップなのか処理に時間かかっている。結局断念。これはきつかった。どっかに勘違いや設定があるのかもしれないが。

・Google Gearsを組み込む方法は、何となくインストールできるが、肝心のオフライン用の緑のアイコンが表示されない。うーん何故なのか?? 結局こっちも断念。

・ソーシャルカレンダー「c2talk」は、オフライン機能というよりサービス志向で、ユーザー登録などもやるので止める。

で、Lightningなどを使ったThunderbirdでの表示は、同期が主体の様子。

ほとんど八方塞りかなと思ったけど、再度Sunbirdでのインポートにチャレンジ。GoogleカレンダーでiCal(メニュー上はICAL)のファイルを一旦保存。Sunbirdで取り込むようにした。で、どうにか取り込めた。

ポイントは、非公開のICALを一旦選択→ポップアップでリンク先を保存→Sunbirdで取り込み。

非公開のICALじゃないとうまく行かなかった。また、思えば当たり前だけど、リンク先の保存が味噌かな。

ただし、インポートすると上書きしない。例えば、basic.icsでエクスポートしたものをインポート、次の日に再度インポートしたとすると、Sunbird上で2つのbasicのスケジュールが表示されてしまう。まっ、仕方ない。古いのを消してインポートするか、icsファイルの名前をユニークにする方法をとるか。後者の方が安全かな。

Palmのデータ(ToDo)を、順次Googleカレンダーへ移行している。上のオフラインでの表示も出来るようになったので、PalmでのToDoデータは不要になってきた。他のメモ帳データなども順次移行する予定。なんか、結構な作業だけど、ToDoが目処たったので少し安心。

2月 9, 2008 ソフトウェア, パソコン・インターネット, 品質, 技術 | | コメント (0) | トラックバック (0)

2008年2月 8日 (金)

ISO/IEC 9126-2と4購入

今日は、ISO/IEC 9126-2と4を購入(購入申し込み)。邦訳冊子を個人で。金額考えると、ふ~。

"-1"と"-3"は以前から持ってたけど、出荷判定の寸劇というかメトリクスの勉強のために2と4も購入。イヤー何年もソフトウェア関係に携わっているけど、自腹で買う羽目になるとは思わなかった。いろんな意味で、考える/考えさせられる事ある。

次の改訂版が出る前に、今回買った分の成果が出るか。というか、成果出さないといけないな。

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

2008年2月 3日 (日)

食品メーカー役員会での全商品試食

今日のTBS TV番組「がっちりマンデー!」は、駄菓子関係。で結構新鮮だったのが、役員会での試食の様子。毎日役員が持ち回りで、全商品を試食するとか。源氏パイやチョコバットなどが代表的な商品の三立製菓。

TBSのページで様子が見れる。(時が経って無くなったら御免)

http://www.tbs.co.jp/gacchiri/oa20080203-mo4.html

駄菓子メーカーだから出来るんだと言ってしまうのは簡単だが、昨今の食品偽装問題。考えてみれば、役員会で試食するようなシステムがあれば、ほとんどは防げたのではないかと思う。

トレーサビリティシステムの導入など、技術的にはいろんなことが議論されている。導入も進んでいる。そちらはそちらで大事だが、本質的なことを忘れつつあるような気もした。食品業界だけでなく、いろんな業界でも、上の試食制度は真摯に受け止めて良さそう。

2月 3, 2008 品質, 安心・安全, 映画・テレビ, 科学技術 | | コメント (0) | トラックバック (0)

2008年1月30日 (水)

JaSST'08 東京 出荷判定寸劇など

JaSST'08 東京へ参加。ソフトウェアテストのイベント。

http://www.jasst.jp/archives/jasst08e.html

我々は、出荷判定寸劇を演じる。SQiPを含めると2回目。もちろん劇そのものは内容なども大きく違うので別物なんだけど、発想として観客にも判断をしてもらうというコンセプトは同じ。

P1300023P1300024会場の目黒雅叙園の様子。初めてだったので、日本風の所々に驚く。数年前は、プロジェクトの関係で結構近くで作業していたが、入った事はなかった。朝、駅からの下り道では足痛くなった。結構急勾配。しかも人が多くて、「えっ~、こんなに集まるの?」と思っていたが、近くにできたオフィスビルへの人たちだった。数年前は無かったんじゃないかな。

基調講演は、ケーパージョーンズ。

以下が参考になるかな。

http://itpro.nikkeibp.co.jp/article/NEWS/20080130/292517/

品質の高い組織と低い組織の比較など面白かったし参考になった。いくつかの数値は、実際チェックしてみたい。特にBackfiringと呼ぶ各言語とFPとの変換の話をしていた。以前から変換の一覧はあったけど、Backfiringと呼んでいたか??

実は、昨日もとある所で彼の話を聞いた。昨日とは資料は別。両方ともすごいページで、感服というか頭が下がる。あっ、日本では京都、奈良、下田に言ってといっていた。また宮本武蔵や平家物語を読んだとも。

なお、彼も情報交換会(懇親会)に出席していた。実は昨日も講演後彼にサイン貰う人に付き合った。どちらでも、サイン貰うチャンスあったのに、本持っていかなかった。懇談会に参加するとか、しゃべる時間があるとは明記無かったので、、。(しかも、両方とも結構重いものの持ち運びがあったので、彼の本をしのばせるという発想にならなかった。)

P1300026左は、出荷判定講演直前の会場リハーサルの様子。

リハーサルなどを含めると時間が無かったので、メンバーがおにぎりなどを買ってきて、控え室で食べる。事務局への意見で、昼休みを長くというのも頷けはする。駅周辺に店はあるけど、集中すると食事しにくい。駅方向へは上り坂。でも、休憩時間をずらすなどのほうが良い。時間を長くしてもあの近辺で食事しにくいのは同じだし、休みが長いとテンション緩むし、、。

メンバーのうちの一人のブログ。
http://softwaretest.blog87.fc2.com/blog-entry-37.html

出荷OK/NGのどちらになりそうかを、微妙な状態にしたのも以前と同様。残バグがあるのが、特にポイント。

で、観客の判断は、若干NGが多目。会場の質疑応答でNGと判断した人に理由を聞いたら、回避策の提示が不十分との事。言われて気がついたけど、PPTでも口頭でも、その辺りに触れていなかった。SQiPの時には、ちゃんと触れてたんだけど、、、。

OKにしようとの考えでセリフなどを考えていたので、ミスといえばミス。でも、その分皆さんが注意して聞いてたということで、ありがたい。ただし、出荷判定会議の経験者が3割いたか? これは、ちょっとまずいかも。Web開発とかでもイベント化すべきだ。(あるいは、携わっている製品やプロジェクトに、出荷判定会議とかそれに近いイベントがあるかと聞いたほうが良かったかもしれない。)

またIEC 61508の部分は、そもそも目標基準を明確にしてないとかの会場の指摘があった。そちらは補足説明で乗り切る。(ただし、安全評価の表はあくまで仮想で、フィクションとしても非常に甘い記載。間違いと言われても仕方ない部分ではあるが、これは一般製品への適用という意味ではちょっと課題かな。)

反省すべき事項が少なくなかった。劇を演じるメンバーの数や時間の関係もあるので、更に難しい。特に今回は、リハーサルなどで寸劇自体の時間を短くする必要があり、皆の頭がそちらに行ってしまったのも大きな反省点。前段の説明などを短くするなど工夫すればよかったというのも、劇の後の意見。

また、もっと”出荷判定とは”の原点に立ち戻って、ドキュメント化するなどの提示方法もあるなとの意見も。寸劇メンバーで、ネット上のマインドマップツールを利用して、多少リストアップしてるけど充実していく予定。


午後の講演で、まずはWebの性能チェックツールの話を聞く。実務じゃないし、1つのツールの説明だったので、自分にはさほど有益となならなかった。

その後が、「モデル検査ブートキャンプ」。VDM++ VICEなどだと良かったんだけど、関西電力での説明は別の手法。逆に、ちゃんと色んな手法の長所などを知らないといけないと痛感。富士ゼロックスでの説明で質問あったけど、時間の関係でカット。オーエスエー・リミテッドの説明は、ループのモデル検査には有益。ただし、こっちの思っているモデル検証の範疇とはちょっと違う。C0/C1の延長がいいかな。

なお、富士ゼロックスの人には、セッションが終わってから質問。xUMLとModel検証用言語との関係(テストクラスなの?)とか並列処理のモデル検証方法。後者は色々工夫しているとか、まだ不十分? 引き止めるのも悪いと思い、他のモデル検証も含めてウォッチかな。なお、関西電力でのツールのCDを配っていたけど、質問の関係もあってもらえず。ダウンロードして試すか、、。

とにかく、実はJaSSTへの直接参加は初めて。色々有意義だった。次回は2日とも参加しようかなと思う次第。


情報交換会や会場で見知った人たちと会う。顔を合わすのは半年振りの人もいて懐かしかった。交換会や会場で、懇談できなくてすみません。また、酔ったせいとか講演を聞いてなかったせいもあって、失礼な対応となってしまった人もいて超反省。メール来たら謝らないと、、。


なお、寸劇メンバーや知った人等とカラオケカラオケへ。結構メンバー増えて、終盤に来た人を含めると14名。たまたま雅叙園の出口で、別の人の知り合いだった関西からの人も合流。

結局3時間も皆で唄う。

実は、カラオケへは目黒雅叙園の出口で予約して行った。ビックエコー。同じ会社の若い人がたまたまいたので、予約してもらう。昨日の朝に調べた場所に行ったら、予約を受けてないとの事。100メートルくらい駅寄りの別の支店だった。

予約の時は、携帯の情報サービス経由。目黒駅周辺は携帯のサービス上は一店だったみたい。カラオケ屋さんがどんどん増えていくのに、情報が追いついてなかったのか、、、。繁華街の場合は、カラオケ屋さんに予約するとかメンバーと合流する時の連絡の時は、場所を的確に言うなど気を付けないとつい思ってしまった。

1月 30, 2008 ソフトウェア, 品質, 科学技術 | | コメント (3) | トラックバック (1)

2008年1月25日 (金)

デザインウェーブ 2006年12月号

今日、会社の本屋さんでTVガイド誌を買おうとしたら、「ほんださん、本届いていますよ」と店員さん。あれっ、何か頼んでたっけ?と言ったり、店員さんとのやり取りで判明。雑誌のバックナンバーを頼んでいた。デザインウェーブマガジンの2006年12月号。電話も無かったし、最初”本”と言われたり、ちょっと考え事してたこともあって、すぐに思い出さなかった。

受け取って、早速席で読む。

特集1が、”組み込みシステムの信頼性と安全性を高める”。そして特集2が、”冗長設計で事故・故障を防ぐ”。

特集2の方は、ハードウェアの話なのでソフトウェア設計の人にはあまり関係ないかもしれないけど、ハード屋さんと話する時に役立つことがあるかも。事例が15も記載されている。例えば事例4は、”使わない端子や機能も定義しておく”。自分の経験では、まっ優秀でトラブル少ないハード屋さんはやってること。再現性が乏しい現象が発生してて、ハードとソフトのどっちかと揉めて原因探ったらプルアップ/プルダウンしてない端子のため。そんなことは2,3回はある。

で、特集1が面白い。IEC 61508の話はもちろんだけど、アーキテクチャ記述言語の話やMISRA-SAの話なども。分野も、鉄道や宇宙機器、人工呼吸器の話など様々。文も平易。

もう1年以上前の雑誌で、最初バックナンバーがあるか不安だったけど、ラッキーなことに手に入った。

安心・安全のソフトウェアについて考えるのなら、電気電子やメカの雑誌とか本も参考にしたほうが良さそうに感じる次第。


1月 25, 2008 ソフトウェア, 品質, 安心・安全, 技術 | | コメント (0) | トラックバック (0)

2008年1月18日 (金)

ソフトウェア品質向上を祈願して、、

P11800081ソフトウェア品質向上を祈願して、某所での会議準備の合間に撮影。

写真撮ったからだけで向上するとは限らないけど、自分自身の意思表示ということで、、。

1月 18, 2008 品質, 日記・コラム・つぶやき | | コメント (0) | トラックバック (0)

2007年12月 3日 (月)

NHKスペシャル 機能五輪

今日のNHKスペシャルは、日本で開催された技能オリンピックについて。「若き技能エリートたちの戦い ~巧みを競うオリンピック~」。

番組の冒頭は、海外チームの鼓舞するというか叫ぶシーン。結構印象的。技能オリンピックは、基本は世界大会だしメダルをかけた戦いなんだと、改めて思った。それは当たり前なんだけど、改めて感じさせる映像的なインパクトが大きかった。

やはり、NHK。番組は丁寧な作り。韓国での国を挙げての施策や、巨大企業サムソンでの採用も伝えていた。日本での工業高校の垂れ幕に、輩出した生徒のメダル数を書いていた。選抜の人は、放課後6時間の実習だと。

競技の様子や指導する人の感想、そして企業トップ(セイコーエプソン会長)の見学の様子なども伝えていた。日本の企業、デンソーやセイコーエプソンでの教育の様子も出た。技能オリンピックのためだけの養成コース。逆に、日本企業での海外からのメンバーとの議論の様子も。海外メンバーの鋭い指摘。追い上げを印象付ける。


実は恥ずかしながら、技能オリンピックへの出場は、22歳以下だと明確には知らなかった。イメージ的には、工業高校などを卒業して企業などで特訓受けて、やっとメダルを獲得できるという縮図。ある意味、学士サン達とは一線を画する世界。それで、何となくここ何年か軽視されてきたような気がする。

今回は日本開催ということもあったろうけど、”もの作り日本”の復活が力説されだしていることもあって、技能者育成にとって参考となる番組だった。新聞でも見かけたりしたので、いい動きと思う。

なお、メカとかは、そんな活動で教育体制やキャリアが整っているような気がしてきている。ソフトウェア関係者という意味では、少しうらやましく感じるこの頃。

12月 3, 2007 テクノロジー, 品質, 映画・テレビ, 科学技術 | | コメント (0) | トラックバック (0)

2007年8月 3日 (金)

本「ソフトウェアテスト HAYST法 入門」感想

「ソフトウェアテスト HAYST法 入門」を読んだ。ちょっと時間出来たので、急いで感想を書いとかないと、、、。

この本、ずばり HAYST法の本。このブログ読んでる人は、JaSSTなどでのHAYST法の資料や論文を読んでる人が多いと思うけど、それを詳しく書いたもの。HAYST法以外に、ソフトウェアの肥大化などにも触れているので、ソフトウェアテスト担当の人もそうだけど設計や開発の人にも参考になる。(というか、組み合わせテストって、設計の人も理解しておくべきというのが持論。)

帯=推薦のことばがいい。冒頭が”画期的な本である。”。ソフトウェアテストでは著名な、電気通信大学の西さんによる。推薦のことばでは、”曽呂利新左衛門の褒美のように”なんて書いてあって微笑ましい部分もあるけど、最後は”日本の産業競争力の向上”なんていう少し重いテーマで結んである。

結構丁寧に書かれている。直交表もいくつか記載されているし、用語集とか、脚注も丁寧。まとめや宿題(理由はあるけど解答は記載なし)で、理解度を自己採点できる。コラムがいくつかあり、別視点での見方などが書かれていて、参考になるものが少なくない。

HAYST法では、FV表とかFL表などを使うようだけど、詳しく書かれている。また”連結法”とか”水準集約法”という、直交表のサイズを変更する技法も紹介されている。ほんとは、”連結法”そのものでサイズは変化しないけど。

網羅度そのものの説明(具体的な計算方法)は詳しくないけど、網羅度と品質の目安が書かれていて、個人的には興味深かった。

またペアワイズ法やPICTにも少し触れているので、HAYST法以外に興味ある人も参考になると思う。k-wayテストにも触れている。(もちろん、ペアワイズ法などの方がいいとの考えの人には、多少不満のある記述かな。)

ちなみに、この本、発売日の25日に入手しようとして神奈川の有隣堂に行ったけど、なし。検索サービスで探してもらったけど、引っかからなかった。翌日26日が外出だったので、電車の中で読もうと、横浜のダイヤモンド地下街店で検索してもらったけど、その日もだめ。結局、28日の隅田川の花火大会に行く際にイヤモンド地下街店で買って、電車の中で急いで読んだ。日曜である程度読み終えたんだけど、感想を書く時間が無い。というか、すぐに文章にしたり、キーボードで打ち込めない。こんなのも、老化現象なのかな~。なんてね。

さて、ちょっと不満の部分も書いておかないと、、、。^.^;;

・用語集のFL表とFV表の記述(正確には用語での見出し語)が逆
FL表とFV表って、結構重要なキーワードなので残念。

・FV表の説明がよく分からない
というか、機能分析って、もっと別のやり方がいいというのが個人的な意見。

・どこまでがHAYST法での規定部分なのか、自組織で考えてもいい部分か分かりにくい
上のFV表もそうだけど、HAYST法のHAYST法なる部分がよく分からない、。HAYST法を体系と思えば、全部と言えるけど、全部を実践するのは多分酷。どの部分を自組織の既存のプロセスなり手法を流用できるか考えにくい。つまり、それが無いと、HAYST法をどう自組織に適用するか作戦が描けない。

・”テストファースト”
V字モデルからWモデル(を意識?)で、HAYST法を使うことを”テストファースト”と読んでるけど、XP系の人には違和感あると思う。また、もう少し設計系での利用方法の具体例があるといいなと思った。

・話が発散する部分が所々にある
FV表とFMEAの関連とかバランススコアカードとの連携とか、、、。コラムでの「お客様視点での因子」とか「機能だけを因子にすればいいか」というのも、ちょっと飛躍してると思える。まっ、各自の受け取り方だろうけど。

・実践するには??
直交表とか技法はある程度分かったとして、じゃ実践するにはどうするかが頭をよぎってしまう。そのあたりも書いてあればよかったんだけど。続編につづくなのかな。


と、後の方は個人視点が強い意見も書いてみた。ただし、冒頭で述べたように、組み合わせテストに関係する人には非常に参考になるので、一読してみてはいかがですか?

8月 3, 2007 ソフトウェア, 品質, 書籍・雑誌, 直交表, 組み合わせテスト | | コメント (2) | トラックバック (0)

2007年6月12日 (火)

「AssistAllpair」がPICT生成も対応

表題のように、「AssistAllpair」が「PICT」による生成へも対応した。今日、偶然にも知り合いの人が教えてくれて、早速ダウンロード。既にPICTは動かしていたし、旧版の「AssistAllpair」も動かしていた。そのために、あまり手間もなく動いた。また、こうなって欲しいな~と思うとおりの操作性。結構感激した

「AssistAllpair」のダウンロードは以下。07.05.29公開。

「AssistAllpair」は、そこに書いてあるように、エクセルのアドインで、All-pair法の組み合わせを生成する。今回は、その延長で、PICTの組み合わせケースも生成する。PICTは、マイクロソフトの提供する組み合わせテストケース生成ツール。禁則を構文で記述できるなどが特徴。

操作は、因子と水準の表を作成、その部分を選択状態にして生成を指示する。生成指示の際に、All-pairとPICTのどちらで生成するか指示できる。指示すると、別シートに結果が生成される。

ちなみに、PICT生成では、2つ目の選択セルに禁則構文などを記述しておく。

いや~、ここまで出来ていたら、以前本ブログで書いた「PICTの可視化」は、ちょっとお恥ずかしいくらい。特に禁則までサポートしてもらったので、感激。

明日とかに、AssistAllpairを使って、禁則とかSub-Modelsを含めたちょっと本格的なテストケースを生成してみようと思う。

後は網羅度の計算とか、他の組み合わせテスト生成の構文化などが自分自身の課題かな。後者は、あるコミュニティで話題となっているので、ちょっと何らかの成果が出るといいな~と思っている。

6月 12, 2007 ソフトウェア, 品質, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年6月 6日 (水)

組み合わせテスト 料理に例えるといい?

今日、雑談してて、組み合わせテストでの、直交表とAll-pair法の違いについて妙案を思いついた。

端的には、「カレーとハヤシの違いくらいかな」。牛肉とかタマネギ、、、、は、それぞれ因子と水準に相当。まったく同じ因子と水準(食材)でも、最終的な料理が違う。まっ、実世界での食材の細部は違うけど。また、カレーとハナシが嫌なら、甘辛カレーとピリ辛カレーの違いにしてもいい。

なお、大体の定説として、2因子の網羅度ならAll-pair法が、より多い因子の網羅度だと直交表が優れている。表生成以外に、長所・短所がそれぞれある。

で、最終的な料理をイメージしないと、いくら食材を組み合わせても意味が無い。組み合わせテストツールを使っていると、面白いから因子と水準を色々組み合わせてみることがある。全然アンバランスな因子と水準でも、ツールの上では気にせずに作業する事が考えられる。それじゃ、あかん。何をテストするのかが最初に無いと、因子・水準の検討は、無意味/効率悪い。

最終的な料理がイメージできれば、他の料理とかその場の会食もイメージしてみればいい。どこを組合せテストとするか、単機能でのテストとするかなどが見えてくる。

特に女性のテスト設計者には、判りやすい例えに利用できるかな。

6月 6, 2007 ソフトウェア, 品質, 直交表, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年5月26日 (土)

Google Spreadsheetsで簡易バグ曲線生成 更新

以前記載した、Google Spreadsheetsでの簡易バグ曲線生成を更新した。

新しいURLは以下。

http://spreadsheets.google.com/pub?key=p8G5_VJ836HAp2al0ekShLQ&output=html

改めて、生成方法などを記述しておく。

あるコミュニティで、仮想的なソフトウェアテストの事例研究を行っている。研究と言うよりも、意見交換に近いかな。で、その過程で個人的に、Google Spreadsheetsでバグ管理やバグ曲線生成が出来ないかと、ふと思った。そこで、作ったもの。

日々の発生、対策済みのトラブルを入力することで、累計とグラフを生成、自動的に更新される。対策済みは、トラブルに対して対策日を入力する方法。

ただ、Spreadsheetsは選択した列でのグラフ化が出来ない様なので、結局続いた列の4種類全部のグラフ表示にした。まっ、処理スピードや機能などは表計算ソフトには及ばないけど、複数人でバグ発見や対策済みを入力するには便利かな。もちろん、小さな規模の時とか、簡単なシュミレーションの時。大規模になったら、それなりのツールやシステムが必要。

あっ、もちろんバグ累積曲線の分析は、Google Spreadsheetsをエクスポートして統計ソフトで分析を想定。こっちは、後日別の検討関連で書く予定。当たり前だけど、バグ累積曲線の分析をやるのは、統計ソフトだよ。エクセルじゃないからね。


累計とグラフの生成・更新のポイントは、累積を計算で求めることと、計算関数を利用してバグ一覧から自動生成している点。ちなみに、Spreadsheetsって、公開できて何人かで編集できるけど、”誰でも編集”の設定が出来ない。なので、上のURL経由で見ても、実際の”計算関数”の記述はわからない。

余りここで説明せずに、「誰でも編集」で見て貰えばいいやと思ってた。でも、よく調べたら「誰でも編集」が不可なので、ここで説明しておく。

例えば、「バグ時系列_グラフ化」シートのB3(5月2日のバグ発生件数) のセルには、”=COUNTIF('バグ一覧'!D$2:D$30;A3)"と入力されている。つまり、「バグ時系列_グラフ化」シートでのA列での日付と、別の「バグ一覧」シートでの日付が一致する個数をカウントして、「バグ時系列_グラフ化」シートのB列にストアする。

セルのB3には”=COUNTIF('バグ一覧'!D$2:D$30;A3)"と入力されているので、B3~(例えば)B45までをクリックして、Cntl-Dを操作。すると、エクセルと同様に関数がコピーされ、しかも自動的に関数式内の行番号(日付に相当)が更新される。

累計や日付も、計算式を埋め込んでいる。

まっ、ずっと先までグラフ化しておいても気にならないなら関数式上の日付を長めに設定出来るけど、そうでないと時々Cntl-Dで処理する範囲や日付部分の行番号を更新したほうが良い。この辺りはお好みかな。

意見等あったら、コメントください。(なおコメントは承認制なので、反映まで時間かかります。)

5月 26, 2007 ソフトウェア, パソコン・インターネット, 品質, 科学技術 | | コメント (0) | トラックバック (0)

2007年4月28日 (土)

Google Spreadsheetsで簡易バグ曲線生成

あるコミュニティで、仮想的なソフトウェアテストの事例研究を行っている。研究と言うよりも、意見交換に近いかな。それなりの成果が出来たら、ここで書く予定。

で、その過程で個人的に、Google Spreadsheetsでバグ管理やバグ曲線生成が出来ないかと、ふと思った。作ってみたのが以下。

http://spreadsheets.google.com/pub?key=pdNXeKvRXfJKDqhyGoN3_Bw

日々の発生、対策済み件数を入力することで、累計は計算してくれる。グラフも自動的に更新される。

ただ、選択した列でのグラフ化が出来ない様なので、結局続いた列での4種類全部の表示にした。まっ、処理スピードや機能などは表計算ソフトには及ばないけど、複数人でバグ発見や対策済みを入力するには便利かな。もちろん、小さな規模の時とか、簡単なシュミレーションの時。大規模になったら、それなりのツールやシステムが必要。

なお、今回のは日々の集計からのグラフ化。別シートにバグ発見や対策済みの入力シートを作ったので、そちらからの主計自動化をこれから考えないといけない。

あっ、もちろんバグ累積曲線の分析は、Google Spreadsheetsをエクスポートして統計ソフトで分析を想定。こっちは、更に先の話。


★★作ってみたSpreadsheetsは現在メンテナンス中です。しばらくお待ちください。

4月 28, 2007 ソフトウェア, パソコン・インターネット, 品質, 科学技術 | | コメント (1) | トラックバック (0)

2007年4月20日 (金)

NE「たたいてつくるソフトウェア」

日経エレクトロニクス最新号の、特集「たたいてつくるソフトウェア」を読む。副題が「検証しやすい設計へ」。

NEの最新号のページに少し紹介記事が出ている。なお、このページは最新号のページなので、しばらくたったら更新されるので、注意してね。

ソフトウェア、特に組み込み系のテストを含めた記事。ソフトウェア規模の急激な拡大とかマイクロソフトでの「デイリービルド」(や開発者と同数のテスト技術者)なども紹介されている。記者が、どちらかというとテスター側の意見を記載しているので、ちょっと小気味いい。

なお、個人的には「デイリービルド」の組み込みへの適用は、目標設定をちゃんとしないとやるべきじゃないと考えている。場合によっては、ビルドしている事で仕事している気になり、無限ループのもぐらたたき状態にならないとも限らないためだ。

素朴な疑問のコーナーでは、XPは”本来厳格なルールがあるんだよ”とかもちゃんと書いてある。後ろの方では、少し学術的なアサーションなどにも触れているが、「お好みで」みたいな感じかな。「お好みで」って書いたのは、今回の記事は基本的な事項の記述が多く、まずはそちらを押さえてからでしょうという意味。

来週月曜からが楽しみ。知り合いも含めて、どんな会社や部署で今回のが話題になるか聞いてみるつもり。部署の会合などで話題になる所は、まだ少し望みがあるかな。アサーションも含めて、単語だけを記憶してきたリーダーとか管理者層だけなら希望無し。話題にならないのなら、こっそり勉強してるか、限りなく無知。どっちにしろ、組み込みでソフトウェア規模の大きな所で全く話題にならないとしたら、チームビルディング時点で問題かも。

日経エレクトロニクスは、ハードウェア技術者向けの雑誌。これで、ハード屋さんがソフトウェアテストに”覚醒”してくれるといいが、、。

4月 20, 2007 ソフトウェア, テクノロジー, 品質, 技術, 書籍・雑誌 | | コメント (0) | トラックバック (0)

2007年3月10日 (土)

All-pair法は直交表を利用している?

ここ1,2週間で悩んでいたのが、「All-pair法って直交表を利用しているの?」ってこと。細かい事考えてたら、どうもそうじゃないのではないかなと思うようになった。しかもAll-pair=pairwiseと固定的に考えるのにも疑問が湧いてきた。

多分分類としては一緒でいいけど、All-pair法でのロジックにはラテン方格などの性質を使ってるか疑問になってきた。

ということで、自分の頭の仲がすっきりしてないので、昔の記事も少し変更。マイリストのドキュメントも少し変更する。ただし、後者は少し時間かかりそう。

ついでに、HAYST法とAll-pair法が直交表利用として同類に扱ってた様なので、そこも修正。

やっぱ色々難しい。

3月 10, 2007 スポーツ, 品質, 直交表, 科学, 科学・技術, 科学技術, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年3月 3日 (土)

食品添加物の組み合わせテスト

今、フジテレビでやってる番組の「日本全国 そんなんあり?!」というコーナーの話題は、商品添加物。ph調整剤とか、、、。で、それぞれの添加物の是非は分かることが多いが、組み合わせとなるとまだ分からない事が多いとの事。番組では、厚生労働省の見解と紹介していた。

ある意味では、食べ合わせ。→組み合わせテスト。 (へと、ついつい考えが行くのが、少し悲しい。^.^;; テスト専門家じゃないけど、職業病?)

日本で認められている添加物は、800種類ぐらいあるようだ。これを因子・水準でテーブル化できそうなら、組み合わせテスター(組み合わせテスト設計屋さん)の出番になる。種類が多いことや因子という考えが希薄なので、色々工夫はいりそうだが。関連する分野としては、薬品とか、食品メーカーでも活躍の場になるかもしれない。

実験計画法の起こりは、R.A.フィッシャーの農事試験によるのだから、少し回帰する事になるとも言える。ソフトウェアテストでの組み合わせ手法は、ちょっと進化したかなと言えなくも無いので、色々交流すると面白いアイデアが出るかもしれない。

3月 3, 2007 ソフトウェア, テクノロジー, 品質, 映画・テレビ, 直交表, 科学, 科学・技術, 科学技術, 組み合わせテスト | | コメント (0) | トラックバック (1)

2007年2月27日 (火)

組み合わせテストの縮小化

ここ1週間、組み合わせテストでのテスト件数を(強制的に)小さくする事を考えていた。以下のように考えたけど、どうなんだろう? 

ほんとは図とかを付けた方がいいが、少し先にする。また、アイデアの一部は、とあるコミュニティでのまったく別件に関するやり取りも参考にした。感謝。


因子(M個)と水準(M個毎に個数は違う)をノミネートして、All-pair法などでテストケースを生成すると、行方向にN件、横方向はM個の表になる。

「テストケースを小さくする」ということは、MやNを小さくするということ。ただし、基本的に因子M個は減らせない。

となるとNを減らす事になる。なるべく均一に減らす。→N行を並べて、最終的に収めたい行数nへすればよい。

となると、1からNでのn個の乱数を発生させて、その行を該当行とすればよい。

1からNの乱数を発生させて、同一番号が発生したら?? 1つは、そんなに多くないのでそのまま該当行としてよい。大抵は、同一番号の発生によりテストを複数回行う必要は無い。つまり、同一番号の発生をそのまま利用する方法なら、n個ではなくて、n-1個等のテストケースとなる。

同一番号の発生をそのまま利用したくなければ、乱数を余計に発生させる方法がある。他にエクセルなどを利用する場合は、乱数関数とRANK関数を利用すればいい。(RANK関数も、OpenOfficeのCalcで使える。) この場合は、個数nを一定に出来るメリットはある。

この際、テストケースでの表で因子と水準は均一になっておくべきなので、先頭の因子を優先順位1、次の因子を優先順位2などとしてソートした上で、乱数での該当行を有効にするのが必須。またALLPAIRSを使った場合、Don't Care(テストケースでの”~”記号)の部分は、”~”記号を省いた並び替えとなるし、本強制的な縮小後はDon't Careの意味は薄れることになる。

もし、強制的に水準を少なくしたいときで水準に重み付けがある場合は、重みを軽くする方法がある。All-pairなどでは重みを”(5)”などと表記する事があるようだか、それを”(3)”などと記述して生成すればいい。また、重み付け表記でなくて水準をそのまま列挙している場合で同一水準が複数ある場合は、同一かの判断を元に水準値の間引きが可能だ。

更には、因子そのものを削除してしまう方法がある。

水準や因子の削除は、操作系を中心としたテストで利用している場合は抵抗あるだろうけど、自動テストで利用したり操作で何度も同じようにテストしていたら利用できる。自動テストで、ずっと同じ水準値のままでUnitテストする必要は無い。(操作系を中心としたテストでも、この類はやるべきというのが持論だが。)

当然だけど、修正影響を調べるための重要な回帰テストでは、前のテスト件数の行数や因子や水準で調べるのが普通。また水準での重み付けを軽くする部分は自動的な処理が可能だが、水準そのものや因子そのものの削除自動化は難しい。

組み合わせテストでのテスト件数を、テストフェーズやソフトウェアの品質に応じてダイナミックに変更してテストすべきと思っているんだけど、どうなんだろう。その場合は、本方法などでの縮小化は有用だ。また、直交表によるテストケースとAll-pair法によるテストケースに本方式を適用した場合どうなるかも調べたいけど、ちょっと先だろうな。

2月 27, 2007 ソフトウェア, テクノロジー, 品質, 技術, 直交表, 科学・技術, 科学技術, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年2月18日 (日)

マイリストに「ソフトウェア組み合わせ生成ツール「PICT」の可視化」をアップ

マイリストに、表題のドキュメントをアップした。

All-pair(Pairwise)法によるソフトウェアテストの組み合わせ生成ツールの中での、 Microsoft社による”PICT”と呼ぶツールの可視化。具体的には、表計算ソフトのExcelで因子・水準の設定→結果表示を行なうようにした。ただし、PICTでの基本的な設定への対応のみで、重みづけとか禁則の指定へは対応していない。

Excelのマクロで実装したのには、理由がある。All-Pair法に基づくテストケース生成ツール"ALLPAIRS"利用を支援するExcelアドイン「AssistAllpair」があり、それとの因子・水準の共用を考えたため。矩形領域を指定して実行する操作方法も似せた。

ちなみに「AssistAllpair」は、moonlightさんの作でフリーソフト。"ALLPAIRS"はJames Bachさんの作。ただし、本Excelファイルにはそれらのアドインは含んでいない。

#個人的にはMac使いなので、”PICT”はMacでの画像ファイル形式の代表的な形式名と同一のため組み合わせツールの名称を別にして欲しかった。

PICTと"ALLPAIRS"(/AssistAllpair)をさらっと勉強した事になる。後、組み合わせテスト生成ツールで勉強すべきと思っているのに「 Intelligent Test Case Handler」がありダウンロードまではやったけど、使ってみるのは先になりそう(他が忙しい)。個人的には、「 Intelligent Test Case Handler」のように開発ツールに組み込む方法は、上流設計への利用や自動化と結びつける際のメリットとなると思っている。

2月 18, 2007 ソフトウェア, テクノロジー, 品質, 技術, 科学・技術, 科学技術, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年2月 7日 (水)

ITproのVista開発史に見る品質

ITproのVista開発史が、ちょっと面白い。

個人的には、Vistaは余り興味ない。ただ、この記事での品質関係の話題は、参考になる。

Gartnerのアナリストにバグ検出システムを視察してもらうくだり

第三者機関にテスト依頼してから急激に品質が上がったとするくだり

上のページでは分かりにくいが、直前のページでの、この部分の見出しは「2006年8月:品質が突如高まる」


前者は、MSなりGartnerが検証システムを企業の核心と見ているということだ。日本の証券会社なりM&A系の会社でそんな認識のあるところは多いのだろうか? ましてや、企業でそんな検証システムを見せようと考える企業はあるのか????

後者は、第三者機関で全部の検証を行ったのか疑問だが、書き方の行間を読むと第三者機関による検証のメリットがありそうに思えてしまう。ただし、どこを任せたのか良く分からないし、期間が短すぎる事、RC1で解決したバグ数が少ないように思えるので、100%信用できかねる。

でも方向としては、ソフトウェア開発をアウトソーシングする動きと絡めて、ソフトウェアテストのアウトソーシングは広がりつつある。それなりの専門分野なので仕方ない。そうなると、ソフトウェアでのものづくりって何なんだろうと思えるこの頃。特に開発・検証の丸投げやろうとする輩を見るとなおさらだ。

2月 7, 2007 ソフトウェア, テクノロジー, パソコン・インターネット, 品質, 技術, 科学・技術, 科学技術 | | コメント (0) | トラックバック (0)

2007年1月29日 (月)

「ヨードン」さんのサインをもらう

今日は、ある会合で”デスマーチ”で有名なヨードンさんの話を聞く機会があった。詳細は言えないが、日本wikiの件数をも把握していて、やはりすごい人と思った。

で、表題のように、サインをもらった。デスマーチの1版の方を持っていたのでサインしてもらった。実は、昨日その本を読み直したが、今でも示唆に富む内容が多かった。逆にヨードンさんばかりでなくソフトウェア工学の人が大抵しゃべるけど、20年とか30年してもソフトウェア工学の利用がなかなか進んでない。ほんと、考えないといけない。

なお、懇親会の会場で、急に話せといわれた。デマルコさん論文集の訳本(共訳)をやった関係。まっ、ヨードンさん自身がデマルコさんと仲良しだと、講演で何回かしゃべった事も関係したのかも知れない。

共訳の本は以下。

ほんと、いいチャンスに恵まれたといってもいい一日だった。

1月 29, 2007 ソフトウェア, テクノロジー, プロジェクト管理, 品質, 技術, 科学技術 | | コメント (0) | トラックバック (0)

2007年1月20日 (土)

富士通の資格認定制度

少し古いネットニュース見てたらの続編。富士通の、「ものづくり」技術者向けの資格認定制度の件が出ていた。日経ITproだけど、多分細部は、日経コンピュータの雑誌の方に掲載されると思われる。


http://itpro.nikkeibp.co.jp/article/NEWS/20070119/259134/

新設するのは「プロフェッショナル・プロダクト・エンジニア(PPE)認定制度」。とのこと。企画やソフト開発、品質保証技術などのカテゴリがあるそうだ。

あまり杓子定規に資格を振り回すのは好きじゃないけど、冷静な技術レベル把握は必要。特にオフショアが絡むと。合理的な制度を持っていないと、どこの地域を使うかとか教育そのものの評価やカリキュラム検討が出来ない。バグの多さの分析に、スキルを入れないと”次”の対応が無理。

実は、ここ1週間調べているのにトヨタのGPC(グローバル生産推進センター)がある。TVとかでチラッと見たため。トヨタの職能制度は、結構はっきりしている。ソフトウェア開発や品質もそんな職能制度を参考とした方がいいと思う。で、トヨタのGPCの場合は、技能訓練でのトレーナーが日本人とは限らない。つまり技能(より正確にはカイゼン精神)を伝播させる必要がある。そのためには、各国にトレーナーなどを育てる必要がある。

やっぱ、いつの間にか技能とか教育という意味では、ソフト関係(組み込み、IT含め)は遅れや企業間格差が大きくなってきた。ただしその遅れは、ソフトウェア技術者のせいじゃないよな~。ソフト技術の軽視。

1月 20, 2007 ソフトウェア, テクノロジー, ニュース, 品質, 技術, 科学技術 | | コメント (0) | トラックバック (0)

2007年1月18日 (木)

マイリストの「ソフトウェアテストにおける直交表やAll-pair法の利用」を更新

マイリストの、「ソフトウェアテストにおける直交表やAll-pair法の利用」を更新しました。

大きな変更は以下です。
・自明と書いた部分を補足
・図でHAYST法をタグチメソッドからの派生としていたが、実験計画法からの派生へ
・L18の水準組み合わせを訂正
・直交表の例でのLauncharを紙サイズへ。またその表での間違いを訂正。
・その他。誤字脱字も。

コメントやトラックバック大歓迎です。承認制ですが、勧誘の類でなければ反映します。また、普段のハンドルネーム外を含む匿名でも構いません(気にしません)。

1月 18, 2007 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 品質, 技術, 直交表, 科学, 科学・技術, 科学技術 | | コメント (0) | トラックバック (0)

2006年12月30日 (土)

ブログフィードを整理 「知識ゼロから学ぶ ソフトウェアテスト」が更新されてた

今日は、”Bloglines”ヘ、気になっているブログをノミネートした。少し操作にも慣れた。この類のツールは、本当に便利。特定分野のブログを、一まとめにして見ることが出来るからだ。しかも、以前から更新されたブログのみ列挙できる。(逆に、ある特定時間前から列挙させることも可能。) しかも保存も出来る。

そのため、今日は学会やフォーラム系、ニュース系、そして知り合いのブログを登録した。特に最後は、ブログの更新状態がわかり、今年の締めくくりという意味でも役立った。

その中で、更新されていて少し驚いたのが、「知識ゼロから学ぶ ソフトウェアテスト」のブログ。まっ、ソフトウェアのプロセスとかテストとかは狭い業界。著者には、時々お世話になっている。(ソフトウェア自体が狭い業界だけど。)

なおブログ名は「知識ゼロから学ぶ ソフトウェアテスト」だが、個人的には「現場の仕事がバリバリ進む ソフトウェアテスト手法」の方が好きだ。

そのブログでの12月18日の日記で触れているのが、Windows Vistaの行数。Vistaのソースコードが5000万行。4000人の開発者、と同数のQA(テスター)。まっ、開発とテスターが1:1ということで、一般論と合致。また、一人1万行も、他と似ていると思う。

なお、一人1万行って期間を加味しないといけないけど、私の経験ではそれくらいが人間の集中力の限界。大抵は、1年とか長くても2,3年。つまり、一人当たりのプロジェクトでの生産量は多少変わるけど、2,3万超えるのは(超えるのを前提とした計画は)どっかがおかしいくらいに思った方がいいというのが個人的意見。あくまで生産という立場での平均的な数値だけど。(Vistaのような場合、期間は長いとの認識かもしれないけど、実質的な生産部分の期間は、2,3年じゃないのかな~。それ以前の研究的な期間は多少長いだろうけど。間違っていたらごめん。)

で、気になったので、SECでのほかの機器での行数の資料も、もう一度探しもとめた。IPS(SEC)での発表資料。東洋大学の野中先生による。

そこでのP5に書いてあるように、DVDレコーダーで100万行。ちなみに、P19には、日本のソフトウェア品質は高いんだぞというのもあるので、興味あれば見て欲しい。

ただし当時よりも、製品でのプログラム行数は増加、日本のソフトウェア品質は低下というのが、まっ飲み会レベルでの常識かな。(行数の件は、対数軸上で外挿した値で認識すれば外れてはいないはず。)


年末でのブログの整理のおかげで、ちょっとソフトウェア工学のおさらいをする羽目になった。来年の課題がいくつか出来た感じでもある。

12月 30, 2006 ソフトウェア, テクノロジー, パソコン・インターネット, 品質, 科学・技術, 科学技術 | | コメント (0) | トラックバック (0)

2006年12月19日 (火)

日経 人間発見 畑村さん

日経新聞の夕刊の「人間発見」のコラムだが、昨日から失敗学の畑村さん。今日は日立時代のパワーシャベルの話など、畑村さんの若い頃の話しが出て面白かった。

おととし、技術士会関連で、畑村さんの講演を聞いた。結構面白かった。

http://www.kogakuin.ac.jp/events/200501/2201.html

その時、初めて工学院大学に入った。普段、新宿の高層ビルに向かったりする時に何度も脇を通るんだが、学内(といっても巨大なビル)に入ったのは最初。

残念ながら、失敗学がこれだけ脚光を帯びているのに、”失敗”が急に減ったように思えない。高度化が進み過ぎるのか、失敗やリスクが広がっているのか、昔ならベテランなどで歯止めがかかったのに歯止めが少なくなったのか、、、。

12月 19, 2006 テクノロジー, 品質, 技術士, 科学技術 | | コメント (0) | トラックバック (0)

2006年12月18日 (月)

もうGHSは施行

今日は暮れということで、一部のメモ帳を整理した。後で調べようとしていた事項をメモしていた帳面。中には、半年くらい前のメモもあった。我ながら先送りが多くて、ちょっと情けない。

で、ちゃんと調べなおしてなかったもので気になったのが、”GHS"(Globally Harmonized System of Classification and Labelling of Chemicals)。化学物質等に係る表示及び文書交付制度の改善を図ることを目的したもので、世界調和システムと略される。

国連の勧告があり、日本では労働安全衛生法の一部改正での対応。法律管轄という意味では、厚生労働省だけど、経産省など色んな省庁のページにGHSは登場する。(逆に労働安全衛生法一部改正の解説ページでは、小さな扱いかな。)

調べなおしたら、今年の12月1日からの施行。つまり、もう施行されていることになる。メモしていながら、気がつかなかった。いかん。

GHSの細部の資料が、結構すごいボリューム。内容まではちんぷんかんぷんだけど。個人的には、”世界遺産”とかに一生懸命のみと映ってしまう国連だけど、結構技術的なこともやってるんだと、改めて関心した。

化学は専門外だけど、目に見えにくいという意味ではソフトウェアと似てはいる。でも分析機器があったりして、最近”隣の芝生”の視点かもしれないけど羨ましい時がある。しかも今回のGHSの発想は、中に何が入っているか分かりやすくしようとの考え。その視点は、ソフトウェアでも参考にしても良さそうだ。(少し関連するけど、アニメ映画やゲームソフトの場合は、タイトルクレジットにセル作成とかソフトを含めた作成者名が流れる時代なんだけどね。)

12月 18, 2006 品質, 技術, 環境, 科学技術, 経済・政治・国際 | | コメント (0) | トラックバック (0)

2006年12月16日 (土)

au端末 ソニーエリクソン製でバグ(パラメータテーブルミス)、wiiのストラップ交換

ニュース聞いてたら、ソニーエリクソン製のau端末でバグが見つかったとの事。ワンセグでの課金のテーブルが間違っていたそうだ。

http://www.au.kddi.com/news/au_top/information/au_info_20061215173006.html

詳しく分からないけど、料金請求金額は間違ってないが、請求のジャンルが違うということかもしれない。

プログラムばかりじゃなくて、テーブルもチェックしたりダウンロード変更出来ないといけないという例かな。

朝は、ニンテンドーのwiiのストラップ交換もニュースになってた。wiiは、娘が発売日に入手。普段は、ゲーム全くやらないけど、アナログ・デバイセズ社製の三次元加速度センサーには興味あった。使わせてくれと言っても、使わせてくれない。

見せてはくれた。その時ストラップが何であるか、すぐに分からなかった。形状などから、静電気防止かと最初思ってしまった。緩めに装着する決まりなのかもしれない。圧迫の関係かな。でも緩めだと外れやすいし、悩ましいところだ。(まっ、ゲームだと何時間もやるだろうし。逆に肉体動かす運動は、それほどの時間やらない時代なんだろうな。)

なお自腹で買ったwiiスポーツも、まだ一度もやらせてもらえてない。シュン。

12月 16, 2006 ニュース, 品質, 技術, 携帯・デジカメ, 科学技術 | | コメント (0) | トラックバック (0)

公認会計士に通報義務へ

今朝の日経新聞だと、公認会計士に不正通報義務を課す方向との事。2008年年度の導入を目指し、証券取引法などの改正。

自分の資格関係では、証券取引法細部の法律改正をおさえておく必要は無い。商法改正が一段落したのに、また改正があるので、会計士さんなども大変だと思う。でも、逆にその分メリットある資格ではある。(会計事務所自体の騒動に巻き込まれなければ。)

技術士の倫理関係で、通報に関する法律化などが話題となった。通報そのものの秘匿性などは法律化されたはず。(うっ、法律名をちゃんと覚えて無い。いかん。) それを義務化して法律改正しようとすることが、会計士なり金融監督局のすごいところ。

ちょっと愚痴っぽく/いちゃもんっぽくなるけど、教育での理工離れと同様、社会の重要度認識も理工離れなのかもしれない。

12月 16, 2006 ニュース, 品質, 技術士, 経済・政治・国際 | | コメント (0) | トラックバック (0)

2006年12月13日 (水)

Rubyでのソフトウェアテストツール

明日、知り合いのRubyで作ったソフトウェアテストのちょっとしたツールを見せてもらう。

その知り合いとは、妙なつながりで、ある勉強会であった人。いくつか共通の人脈があって、2回ほど一緒に飲んだ。で、2回目の帰りの電車の中で、同じ出身大学と判明。やはり世の中狭い。向こうは、ソフトウェア専攻じゃなかったけど。

で、飲み会の時に、そのRubyでのツールの話が出た。その話を聞いたとたん「何でまた」と思った。口頭でも言ったけど。

でも、2、3分して、ちょっと別な事考えてたら、「案外面白いかも」と思えてきた。ネットでの共同作業とか考えると、効率のいい使い方になるかもしれない。そう思うのに時間かかったのは、会話をしながら半分は、直交表の事考えてたからだろう。

若い人達が、ちょっとしたアイデアで作ってみる所がすばらしいと言うか、どんどん発展させればいい。

明日が楽しみ。(多分どんなのかは、本人の意図でこれ以上話しちゃ駄目だろう。)

それにしても、ほんとは専門じゃないのにソフトウェアテスト関連の作業が多い。ここ2月ほどは直交表の資料作成とか、上のような人との繋がりとかのためだ。そろそろ本来の勉強しとかないと、いけないんだけど、、、。

12月 13, 2006 ソフトウェア, 品質, 技術, 科学技術 | | コメント (0) | トラックバック (0)

2006年12月 9日 (土)

「功名が辻」でアフレコ修正

今朝、何気なくTVでのスポーツ新聞のコーナーを聞いていたら、NHK大河ドラマ「功名が辻」で時代考証が間違っていて今日の再放送でアフレコで修正して放送するとの事。スポーツ紙の見出しは「功名なつじつま合わせ」だったようだけど、不正確。

ネットで、どの新聞か調べようとしたが、ヒットはしなかった。なお、NHKの「功名が辻」ページでは、”*訂正*”クリックで、間違った旨がポップアップする。

間違いは、高台院(ねね 浅野ゆう子さん)が、秀吉が死んでからの年数を言うシーン。10年と言ったけど、本当は5年だということ。NHKには、問い合わせ等で6件(?)あったそうだ。

で、その後のNHKがすごい(と思う)。浅野ゆう子さんの言葉で、”5年”の部分を探して、差し替えたとの事。ほんとはアフレコって後で音を入れる手法なんで、今回の修正をアフレコと呼ぶのは少し不正確だけど、、、。

結構色々考えさせられた。数人が指摘するというのは、結構細かいこと知ってる人たちがいるんだなーと関心。

更にはその対処方法。一番考えつくのは、訂正テロップ。他には、浅野さんに吹き替えを願いする方法。後者は、契約とかお金の関係で止めんだろうな。個人的な感覚だと、後日修正が多いのか、そんなやり方でもいいような気がするけど。(自分の場合、規模や先覚性でちょっとした修正は少ない訳じゃない。)

それを役者さんの既存の声の差し替えでやるからすごい。ちなみに、全編を調べる方法じゃなくて、文字放送でのセリフ(テキスト)の検索で”5年”を探したんだと思う。映像と文字とを組み合わせるのをメタデータって言うけど、それが”功”を奏した感じかな。

それにしても、この類はこれからも出てくるんだろうなと思う。特に放送の二次利用とかが絡んでくるから尚更。メタデータ化とか、音声認識、音声合成なども技術として結構利用されていくと思われる。


ちなみに、再放送は地上波のみ。ちょっと録画して、修正程度を調べてみるつもり。

12月 9, 2006 ソフトウェア, ニュース, 品質, 技術, 映画・テレビ, 科学技術 | | コメント (2) | トラックバック (0)

2006年12月 3日 (日)

マイリストに「ソフトウェアテストにおける直交表やAll-pair法の利用」をアップ

やっと、「ソフトウェアテストにおける直交表やAll-pair法の利用」について、まとめることが出来たので、マイリストにアップしました。

何年か前からタグチメソッドのソフトウェアへの応用への感心が無くはなかったので、まとめてみました。ソフトウェアにおける直交表の利用での問題点を書くとともに、提言も書いてみました。

問題点の記述では、直交表に携わっている人達(色んな会合で私がお世話になっている人達を含みます)には、ちょっと挑発的な記載もあるかもしれません。これから、ソフトウェアテストが良い方向になればとの思いからですので、了解ください。

なお、ソフトウェアテストの専門家と言うほどでもないので勘違い等があるかもしれません。

意見や指摘等は、トラックバックなりコメントでください。許可制にしているので、反映までにちょっと時間かかるかもしれませんが、反論とかでも掲示する予定です。(さすがに、勧誘目的のトラックバック等は勘弁してくださいネ。)

順次コメント追記したり、マイリストのドキュメントそのものを更新して対応して行きます。(でも他にいろいろ宿題があるので、どれくらい対応できるか多少不安ですが。)

よろしくお願いします。

12月 3, 2006 ソフトウェア, プロジェクトマネジメント, 品質, 技術, 直交表, 科学技術 | | コメント (2) | トラックバック (1)

2006年11月28日 (火)

地球儀製造でのこだわり

ついさっきTV東京のワールドビジネスサテライトを見ていたら、地球儀作成の現場が出た。

球状のベースに、一枚一枚紙を貼っていく作業。集中力が必要とのことで、午前中のみ作業するそうだ。空調などに気を使うのは分かるとして、驚いたのは、手で貼る際に赤道に近いほうに力が入るために紙上の長さをそれを見越して設定しているそうだ。つまり(多分)、赤道に近い方が緯度上の長さを短くしているということ。うーん、そこまでやるのか~。

多分衛星写真かと思うが、そちらからの地球儀を作るような話もしていた。ふと、実際の地球は球形でないことの影響は出るのかなと色々考えたけど、北半球と南半球の長さを同じにするだけなので、気にすることなさそう。

やっぱ、それぞれの業界なり専門としている会社には、細かいノウハウがあるんだな~。


11月 28, 2006 品質, 技術, 科学, 科学技術 | | コメント (0) | トラックバック (0)

2006年11月14日 (火)

日経ビジネス 「品質の復讐」

日経ビジネス11月13日号を読んだ。特集の表題は「品質の復讐」。ソニー510億円、日立製作所300億円など、膨れ上がる品質トラブルの対策費が表紙や記事の表を飾る。

”複合品質汚染”とか”海外勢に独占されるデミング賞”という用語や見出し。言い得て妙だとついつい感じてしまう。

目新しかったと思ったのは、日科技連の「品質管理セミナーベーシックコース」の受講者数の推移のグラフ。最近はバブル期の1/5の人数。まっ、高価なコースだし日数もかかるので、今でもそんなに参加しているのが個人的には驚きだし、日本の品質もまだ捨てたもんじゃないと感じはしたが。

トヨタやコマツの取り組みとかも紹介されていて、参考になった。

11月 14, 2006 品質, 技術, 書籍・雑誌, 科学技術 | | コメント (0) | トラックバック (0)

2006年10月12日 (木)

直交表によるソフトウェアテストに関する教育や実践での問題

最近、直交表をソフトウェアテストに応用する事に少し関心がある。ただし個人的には昔から、それに関係する品質工学などをある程度知っていたし、社外の知り合いとの会合などでも話題となっていた。そのため、少しさらに身近になった程度の意識しか無い。自分自身が使う訳ではないが、、、。

ここでは、そんな経緯から、直交表によるソフトウェアテストに関する教育や実践での問題を考えてみたい。


まず直交表で代表的なHAYST法に関して、以下のJaSST(ジャスト)での論文などが参考になる。

http://www.jasst.jp/jasst05w/jasst05w.html
http://www.jasst.jp/jasst04/jasst04.html
での以下のドキュメント。

http://www.jasst.jp/jasst05w/pdf/S4-1.pdf
http://www.jasst.jp/jasst04/pdf/B1ap.pdf
http://www.jasst.jp/jasst04/pdf/B1ah.pdf


他に、雑誌「ソフトウェア・テスト PRESS Vol.2」でも取り上げられている。
http://www.amazon.co.jp/%30bd%30d5%30c8%30a6%30a7%30a2%30fb%30c6%30b9%30c8-PRESS-Vol-2/dp/4774125733/sr=8-1/qid=1158284230/ref=sr_1_1?ie=UTF8&s=gateway&tag2=blogamebaj01c-22

ちなみに、こんなブログもある。
http://fnya.cocolog-nifty.com/blog/2006/09/__54af.html

また、直交表のテスト項目生成のバックグラウンドを知る為には、品質工学とか”タグチメソッド”を知っていた方がよい。ちなみに品質工学会のページは以下。ただし後述するように、品質工学とかの勉強が、直交表のテスト項目生成の理解の”諸刃の剣”になりかねないので注意。
http://www.qes.gr.jp/top.html


では、本題の教育や実践での問題。

1)田口先生の話が分かりにくい。
今まで、田口先生自らが講演される会合に2回ほど参加した事がある。どちらもソフトウェア関連の会議とかフォーラム。タグチメソッドに関する話なのだが、色んな事例に話が飛び理解に苦しんでしまう。また、ソフトウェアテストの応用となると、(自分の例では)田口先生から直接聞いた事がない。

田口先生の話し方は、タグチメッソッド自体、(特に日本では)理解してもらえなかった事への反論がある為かもしれない。そのせいもあって、今すぐにでもソフトウェアテストへ利用したい立場で話を聞こうとすると、拍子抜けになると思われる。(話自体は、結構面白い。念のため。)


2)タグチメソッドでのSNや機能ばらつきとのギャップ。
品質工学とかの勉強が”諸刃の剣”となる、代表の一つがSN。そして、機能ばらつき。田口先生も言うように、タグチメソッドでの基本的な考えは、機能の悪さは気にせずにばらつきを最小化すること。そして入力等を信号と考え、分散などによりSN比を算出する。

タグチメソッドの考えを知れば知るほど、ソフトウェアへの応用=直交表のテスト項目生成がすんなりと頭に入らない。そもそも出力が数値化できないと行けないのではとか、ソフトウェアでのばらつきって何だろうかと悩んでしまう。

直交表のテスト項目生成の推進派は、タグチメソッドでのSN比なりノイズを外乱要因とするようだが、数値化との関係で少し理解に苦しむ時がある。

また、それと関連して、直交表のテスト項目生成で因子にOn/Offのような状態を選ぶ事があるが、そこが少し理解しにくい。特にOn/Offのような因子が複数出てくると、タグチメソッドでの数値化とどんどん乖離して行くような気がしてしまう。


3)直交表のテスト項目生成推進派から時々話の出る品質用語。
直交表のテスト項目生成の推進派には、タグチメソッドでのSN比等の理解もそうであるが、そもそも品質に関する理解度が深い。分散とかσの理解は、当然である。

逆に、ソフトウェアテスト系の人には、品質での分散とかσに馴染みが無い人が多い。

時として悲劇が発生するのは、直交表のテスト項目生成推進派が(専門家ぶりをひけびらかす為に)分散とかσなどを意味も無く使うとき。ソフトウェアテスト系の人に統計的などの基礎が無いと、話がかみ合わない。(ほんとは、ソフトウェアのテストの設計者にはそんな素養が必要だと管理職が分かり、必要なら教育課程を用意するなどが必要なのだが。)


4)直交表のテスト項目生成推進派の大きなサイズの直交表。
直交表のテスト項目生成の推進者からは、L64とかL128の話がすぐ出る。ツールが自動的に生成するので、生成時間を気にしなければ、サイズはあまり気にならない。

逆に、タグチメソッドを多少かじった人にとっては、普段利用するよりもサイズが格段に大きいので、結構抵抗が出てしまう。

また、直交表のテスト項目生成の推進者の作成を見ていると、因子(水準)をどんどん列挙し、一挙に直交表にまとめるように思える時がある。タグチメソッドでは、各因子を結構吟味する様に思えるので、そのギャップに驚いてしまう。

直交表のテスト項目生成の推進者からは、更に数の多い因子への対応法の話が出る。つまり、そのままだとより大きなサイズの直交表を小さなサイズの表にする手法の話。頭では理解できるものの、上記の抵抗感と同様にふと疑問が湧いてしまう。

抵抗感は何かと以前から考えていたが、”直交性”が保てるかとの疑問かもと思うようになった。”直交性”は相関の逆数で、大きければ大きいほど直交表としてはいいと言える。ただし、具体的な算出方法が思いつかない。2つの因子で、各因子の水準が数値なら出来なくはない。が、因子が増えると計算が面倒。まして、水準が離散的とかOn/Offのようなケースをどう考えたらいいのか???


5)ソフトウェアテストの設計者のスキル。
既述の3)での品質の話にも関連するが、ソフトウェアテストの設計者が品質やソフトウェア設計の経験が無いという事が少なくない。そのため直交表のテスト項目生成の勉強を実際のテストに生かす時に、テスト全体の中での位置づけが分かっていない。

ソフトウエア開発のVモデルはもちろん、スパイラルとかアジャイルモデルも理解しておくべきと考える。念のためだが、アジャイルモデル自体はモデルではなく、雰囲気とか、高レベルの人は各アジャイルでの手法の違いの理解と考えてほしい。その辺りの知識が無い事が多い。

直交表のテスト項目生成の学習者はテスターであることも少なくなく、ソフトウェア開発のどのフェースでのソフトウェアテストに利用するかの方針めいた事に無頓着な事が少なくない。その場合、直交表のテスト項目生成の学習で終わったり、有効的な活用にならない事がある。

直交表のテスト項目生成の推進者からは、各テストフェーズでの利用の話は出る。が、製品のソフトウェアテストでトータル的に直交表のテスト項目生成を利用したケースは、事例としてあまり発表されているように思えない。本件は、事例発表を含め今後の課題かもしれない。


6)直交表のテスト項目生成を救世主・絶対視する人達の存在。
直交表のテスト項目生成の推進者がそうだとは思わないが、直交表でテスト件数が相当減るとか品質が上がると思っている人達がいる。従来のテストを行う事自体を否定する事すらある。

MBAでの新経営手法の一つとでも勘違いしている人もいるように思える。少なくとも、MBAでの新経営手法と同様な扱いと思える時があるようである。

そうなったら、従来のテストとの併用とかテストのどのフェーズで利用するかなどの細部検討がなおざりになってしまう。

個人的には、最近になって騒ぐ管理職は上記の類かもしれないので、要注意といった所に思えてならない。


直交表によるテスト項目生成が、ソフトウェアテストの関係者に浸透しつつある。直交表がテスト設計者やテスターの生産性に寄与する為にはどうすべきが考える事が必要な時期かと思う。

10月 12, 2006 ソフトウェア, 品質, 直交表, 科学, 科学・技術, 科学技術, 組み合わせテスト | | コメント (2) | トラックバック (1)

2006年10月 8日 (日)

ソニー製バッテリー交換 やっと終わる

水曜日に、申し込んでいたiBookのソニー製バッテリー交換での、新バッテリーが届いていた。旧バッテリーの返品の事は聞いていたし、箱にその説明もあったので、昨日交換しようとした。

で、すぐ交換しようとしたら、旧バッテリーは放電してくれの旨の記載。がーん。いろいろ用事あるし、充電しっぱなしで家を空けるのも不安だぞ、、、。家にいる時に放電したけど、パワーセーブ解除しても、なかなか残量減らない。普段充電の時は、もどかしいんだけど。

しかも、最初説明書を読んだら”店頭”の文字。えっ、どっかのショップに来いという事? 前後関係で、”点灯”のことと判明するのに、30秒くらいかかった。誤字。以前の申し込みでの氏名例での”林檎”といい、普段さほど気にならないのが、どうも気分的に良くない。

やっと放電し終わり、取りにきてほしい旨を電話。土曜日の夕方でお願い。外出した。

昨日帰ってみたら、不在の紙が。午前に来たみたい。再度電話して、夕方と言ったのにと言うと、集配は午前中のみとの事。それなら、受付の時に言ってくれ〜(それくらい出来るように教育しててくれ〜)。

Pa070018ちょっと悔しい気分になったので、交換の箱を写真に撮った。


結局、今日に旧バッテリーを受け取ってもらったので、1ヶ月くらいかかった事になる。何か、日本の色んな所での品質の”荒”をかいま見た気がした。これから、どんどんひどくなるのかな。

10月 8, 2006 パソコン・インターネット, 品質, 日記・コラム・つぶやき, 科学技術 | | コメント (0) | トラックバック (0)

2006年9月29日 (金)

ラジカセの修理

今日修理依頼していたラジカセが、戻ってきた。タイマーでの録音が3とおり出来るので、重宝していた機種。電源ONが、出来なくなってしまった。

電話して、サービスセンターの場所を聞いたら、通勤途中の駅だが、結構歩く場所。バッグに入る大きさでもないので、結局スーパー経由で修理依頼した。

一度再現せずとの事だったが、もう一度調べてみてくれと言ったら、再現したのか見積もり金額の連絡が入った。その金額でOKと連絡して、今日直り、家族が受け取ってくれた。ちょっと驚いたのは、以前の部品(ユニットとかベルト)が添付されていた事。ボードの丸ごと交換ではなかったみたいだ。(まっ、ベルトは今回の現象には関係しないが、メンテナンスの一環だろう。)

結構小さな箱に入っていて、驚き。最近数年くらいで、元の部品が戻ってくるケースは無かったように思う。

ここ1月くらいの間に、バッテリーとかコピーとか、そしてこのラジカセとか、リコール/修理に多少振り回された。iBookのバッテリーはまだ届いていないせいもあって、このラジカセの修理が満足度の高いものに思えてきた。

タイマーでの録音が複数とおり設定できる事自体、ラジカセでは本メーカーくらいしか無い。オンラインサイトでラジオ番組のダウンロードが出来る日が来るまで、使う事になりそう。

9月 29, 2006 品質, 技術, 日記・コラム・つぶやき | | コメント (1) | トラックバック (0)

2006年9月17日 (日)

キヤノン小型コピーのリコール 自宅のは非対象

ソニー製のバッテリー交換に対する気分落ち込みが一段落したと思ったら、今度はキヤノンの小型コピーのリコール報道。「PC7」「PC80」「PC100」が対象との事。

小型コピーと聞いて気になっていたので、念のために今日調べた。自宅のは「FC230」で非対象。とりあえず一安心。まっ、最近はほとんど使ってないので、むしろ捨てるかどうするかも検討しないといけない。

それにしても、こうもリコール騒動で自宅の機器を調べる事になるとは。機能アップが余りに早いのか、品質に関して日本が無頓着になったのか、、、。でも、昔よりも情報伝達が早くなったり、品質データを含めた情報自体の細分化が進んでいるのみ一因かもしれない。

9月 17, 2006 ニュース, 品質 | | コメント (0) | トラックバック (1)

2006年9月 3日 (日)

ソニー製バッテリー交換への申し込み

ソニー製のリチウムイオンバッテリー騒動。自分のアップルノート型は、3年近く前の発売なので対象でないだろうと思っていた。念のため調べたら、該当品。もーショック。Webで申し込んで、受け取って、以前のを返却するそうだ。

今日申し込んだが、憂鬱。電気とか製造の品質関係者じゃないけど、他の色んな意味でも少し気分落ち込んでいる。

申し込みのアップルのページは、全世界共通のせいか何かそっけなくて、多少不満がつのった。バージョン確認のページは英語のままだし、、、。普段は、愛嬌があって面白い情報も、今回は少しカチンと来るところも。だって、例文の姓のところ”林檎”だし。^.^;;;;;

9月 3, 2006 ニュース, パソコン・インターネット, 品質 | | コメント (0) | トラックバック (0)

2006年6月17日 (土)

NHK「週刊こどもニュース」で”バグ”

夕方、何気なくTVを見てたら、NHK「週刊こどもニュース」で、ソフトウェア”バグ”を取り上げた。

携帯電話で仮名漢字したら、電源切れる現象を再現してくれた。バグでうまく動作しない例を、子供がプログラミングして誤動作する様子を見せていた。

後者は、多分UMLロボットコンテストを利用していたので、内情は少し先覚的だし、子供たちにバグのイメージが理解できたかは個人的には少し疑問。でも、普通のプログラム言語でバグを説明すること自体、既に古臭いのかもしれない。特に子供たちが仕事する頃に、今のようなプログラミング言語を利用する人はほとんどいないだろう。

その後、自動販売機でのテストの様子が出た。実際の工場での、恒温槽や紙幣読み取りのテストの様子が出た。

締め括りとしては、ソフトウェアの”再利用”。同じ会社で製品間での再利用が進んでいる話や、それが企業間に広がっているとの話。やはり、「週刊こどもニュース」、少し先覚的。

「週刊こどもニュース」を見るくらいの子供たちは、ソフトウェアの再利用の必要性を知っていると思ったほうがいい。ソフトウェアの再利用の進んでいない企業は、子供から鼻で笑われる時代ということかも。我々は、それ位の気持ちでいたほうがいい。

6月 17, 2006 ソフトウェア, 品質, 映画・テレビ, 科学技術 | | コメント (0) | トラックバック (0)

2006年6月16日 (金)

ソフトウェアのバージョンアップで最初からテストするかよ~

今日は、プロジェクトでのソフトウェアテストの計画を打ち合わせ。

その際に、「今までテストでのバグ対策版がリリースされたら、どこからテストするの?」と聞くから、「対策項目と、回帰テストをやって、次のテスト項目から」と答えると、「先頭からやらないの?」と。役職的には、テストチームの束ね役の二人ともがそう言う。

例えば、200件のテスト項目があって、100番までテスト済み。そこで、バグ対策版のリリース。対策項目と、回帰テストをやって、101番からテストするか、1番からテストするかという議論。

心の中で「アホか」と言ってしまった。機能アップのバージョンならいざ知らず、バグ対策版で先頭からテストしたら、テスト項目の最後の方は、いつまでたってもテストできない。しかもテスト項目の最後のほうに記載している事項は、大抵の場合、エラーとか複雑なテストやシナリオ的なテスト。それを言っても、二人とも「先頭からやりなよ」。

昨日/一昨日は別の人との打ち合わせでもソフトウェアテストに関する手法での基本部分で気落ちする事があって、今日でほとんど奈落の底状態。実験計画法の手法を取り入れるが、ソフトウェアテストでの基本的な事項はしっかりしてないと感じた次第。

来週は、そんな議論からは、ちょっと逃避しようと思う。疲れる。逆にオフショアメンバーと、「○日友好カラオケ大会」にエネルギーを集中したい。^.^; 彼らのスキルは、それなりのもの。初めてVBマクロを使ってテストに関連するツールを作ってくれたり、SQL文でDB操作を記述してみてくれたりした。テスト方法は教育したり実際OJTでカバーできそうなので、彼らの残る課題は、日本語コミュニケーション位。で、解決策として選んだのが、”カラオケ大会”。がんばるぞ~。

6月 16, 2006 ソフトウェア, 品質, 科学技術 | | コメント (0) | トラックバック (0)

2006年5月28日 (日)

防衛庁 機密流出で最大8割の違約金へ

今日の日経新聞で、防衛庁が発注の際に防衛機密が流出した場合の違約金として、契約金額の最大8割とすることにする方針を決めたそうだ。

ウィニーによる事件が続いていることもあって、啓蒙の役目も果たすと思われる。今後、情報流出を契約条項とする自治体や企業が増えるだろう。

それにしても、万一お役人が機密を漏洩した場合はどうするんだろう。国民に税金戻すとか、せめて担当者やその官庁の賃金カットなどで望まないとダメでは? 今一番啓蒙すべきはお上のほうと思えるんだが、、、。

5月 28, 2006 ニュース, パソコン・インターネット, 品質, 科学技術, 経済・政治・国際 | | コメント (0) | トラックバック (0)

2006年5月14日 (日)

「マインドマップ」でCE図(特性要因図)作成

個人的に、CE図(特性要因図)に多少のこだわりがある。

以前、VISIOでの作成をマイリストに登録した。今回は、”マインドマップ”のソフトを利用して、CE図を作った情報をそれなりにまとめて、マイリスト経由でたどれるようにした。

興味があれば、参考にして欲しい。

実は、画像などは3月に生成していた。文書等にするのに、2ヶ月かかった事になる。色々忙しかったからだが、我ながらスピーディーに出来ないかと少し反省。

5月 14, 2006 品質, 技術, 科学技術 | | コメント (0) | トラックバック (0)