SSブログ

ドコモ、NEC製携帯電話機を発売初日に販売停止

ひさびさに大きそうな不具合。まあこういうのがたくさんあるとメシの種になるので、おこってもらうとうれしかったりする。

NECの携帯は事故多いのかな?
http://k-tai.impress.co.jp/cda/article/news_toppage/43542.html

まあ誰に聞いても、携帯の開発現場は地獄だというので、それは開発体制も厳しいものがあるのだろう。別段どこの会社の携帯の品質がいいということはない。Nokiaはあまり知らないが、少なくともサムソンも同じように悲惨である。

携帯のソースは確実に300万行を越えていそうなので、Windows 95とかいうレベルなのかな?Windows 95だってハングしまくりだったのだから、携帯もハングするのは当然である。そのうちリセットスイッチが見えるところにつくようになるのでしょう。

コードを書く

ここ一ヶ月ぐらいずっとコードを書いていた。GWはトータルで100時間ぐらいは書いていたと思う。残念ながらもう仕事でコードを書くことがなくなってひさしい、でも論文を理解&展開するのにどうしてもコードを書かねばならなくなり書き始めたのだが、軽くできると思っていたのがなんだかんだで、数千行にもなるコードになってしまった。
アカデミックな実証のコードはいつもいいかげんでglobal変数バリバリ、コメントなし、クラスは絶対使わない、スピード命なので、かなりいいかげんだ。常日頃からコード品質についてうるさく言う私も、自分には甘い。

ただ2000行を超えたあたりでいいかげんなコードはなにがなんだかわからなくなってきた、その時点でクラスを作成して、global変数をなくしてprivateメンバーにするといった作業をしだした。かなり不毛なつまらない作業だった。

若い頃にはわからなかったが、としを取ってわかたことだが、コードを書くのは頭脳労働ではない。floatだのintだのを間違えると動かないし、==と=をタイプミスをするし。いわゆる作業の70%ぐらいはどうでもいい、誰でもできるコーディング作業だったような気がする。昨今オフショアが盛んだが、コーディング作業なんて全部オフショアに出すべきだなと思う今日この頃。

逆にテストケースを書く作業というのは「すごーく知的」と思うのは間違いであろうか。

想定されないバグ

私はよく日本信号のトラブルの例を出して話すことが多い
http://juichi.blog.so-net.ne.jp/2007-12-22

あるときその説明に対して質問が出た。「たしかにあの件はバグだが、日本信号のある人に聞いたら想定されないユースケースだったと言っていた。そういう場合はどうやってテストで未然に防ぐのですか」

この業界に長くいると、だいたいの質問に対して水が流れるように答えることができる。ただこの質問はちょっと困った。想定されないユースケースは無限にある、それをすべて要求仕様として定義するのは非常に困難である。また全ての異常系のテストをするのもまた困難である。

そのときなんと答えたかというと、基本的には日本信号のケースはテストしていないswitch文に入ったバグなので、default処理なり特別な例外処理に関してはすみやかなシャットダウンや、なんらかのフェールセーフルーチン処理をするべきだと答えた。

すべてのコードはテストできないはもう現代のソフトウェアでは常識なので、制御できない状態に陥った場合に、システム全体に影響を与えないエラー処理ルーチンはとっても必要だと思う。

品質に交渉の余地はあるか?

なんかぐぐっていあら「品質に交渉の余地はあるか? 」
http://www.infoq.com/jp/news/2007/12/4

なる記事をみつけて。変な学説より、とっても正直な意見である。
もしも顧客が、「完璧なコード」は求めておらず、要求したことを行ってくれる限り品質の低いコードで満足だ、と言ったら、あなたはどうしますか?顧客の要求に応えることが我々の役目ですよね?では、品質については手抜きをしますか?私はそうはしないでしょう。私は顧客が考えていることを理解したいと思うでしょうし、もしそれが、短期的な思惑(「最も費用のかからないソリューションにしたいから品質は気にしない」)あるいは無知や単なる愚かさによるものだということがわかったら、私はほうっておくでしょう。私の良心は、自分の仕事の品質を妥協することを許しません。

ほんとそうだよねー、今の不景気な時代、品質なんてどうでもいいんだ赤字さえ減らせばという風潮である。でもそういう企業って景気が上向いた場合厳しい状態にさらされるんじゃないかなー

私は、少し前にA社を訪ねたのですが、A社のソフトウェアは競合のB社のものよりもよく売れていて、B社を倒産に追い込むことができるくらいです。私が話した人はこういっていました。B社の製品は多機能で速く、そしてA社のものよりバグが少ないのですが、B社は、A社のような現場の専門家がサポートする組織を作らなかったのです。 彼らの顧客から見たら、A社の製品はB社のものに比べ、「より高い品質」を備えていたのです。 単にバグを減らし保守性の高いコードを書くだけでは「品質」は実現できません。それでも誰かが買わなければなりません。それを買うと決めることは、「何を品質とみなすか」という尺度です。 「品質」には数えきれない側面があり、それをどの順で評価するのかを十分に話し合わなければなりませんし、そのほぼ全てが必要なのです。倒産したら、「バグがなくて保守性が高い」ことには価値がないのです。

はげしく同意。品質とは話し合いによって決まるもので、バグの数ではないのである。ましてやバグ曲線で品質を語るものではまったくもってない。

A Practitioner's Guide to Software Test Design

まあソフトウェアテスト関連の本は一応買っておいて、本棚でこやしになっていくが、ちょっと時間があったので多量の読んでいない本を見始めた。
A Practitioner's Guide to Software Test Designという本がほとんど読んでなく中を見始めた。タイトルは素晴しい、この本はテスト設計について教えてくれるのである。私を含めテストの専門家はテスト設計が重要と言っているが内実は、テスト設計のスタンダードはないに等しい。まあIEEE 829 test designのテンプレートがあるが、それを使っている人はみたことがない。ソフトウェア設計のようにUMLなるものはテスト設計には存在しないのだ。
話は本に戻るが、中身を見ると設計というよりは手法なのかなー、あまり設計のことは書かれていない。と思ったら、日本語訳が出ていた「はじめて学ぶソフトウェアのテスト技法」。うーん、こっちのほうが正しいタイトルかもしれない。

MSの中の人”がホンネで語る

http://www.itmedia.co.jp/enterprise/articles/0903/23/news011.html

でQFE(Quick Fix Engineer)の話がでてきて、ああなつあしいなーと思った次第だ。リリースした後のサポート体制は、本当に外資系はうまくやっている。MSもそうだし、SAPも同様の強固なシステムを採用している。たぶん予想ではIBMもちゃんとやっているのだろうなー

日本の会社はこの辺をうまくシステマティックにできないので、メインテナンスコストの正確な算出ができない。さらに専門のメンテナンスチームをもってなかったりするので、メインの開発チームのスケジュールにもインパクトを与える。

日科技連ニュース

2009年3月号

「品質中心の組織文化:ソフトウェア品質の基盤」

野中先生の記事、累積欠陥摘出率の推移が失敗プロジェクト&成功プロジェクトの間では典型的な差異が認められないといったもの。まあそれがいい悪いという話ではなく、多面的アプローチが必要だということ。

たぶん組織や、製品ドメイン、製品開発の時間やコスト等々とってもたくさんの多面的な要素をいれなければならないのかなー

こういった調査を会社の中で、きっちりちゃんとやっていけば、同様な製品ラインナップ、同様な組織形態なので結構高い予測(失敗プロジェクトなのか、成功プロジェクトなのか)ができるのかなー

IEEE Trans. Soft. 9月号

やっと暇になったので机の上の整理をはじめる。IEEE Trans. Softの9月号をやっと読む。

regulaer paperの4つのうち3つが品質関連だった、すごい。10年前では考えられないことだ、昔は数ヶ月に一個ぐらい品質に関するペーパーがあったが、最近は月に一つは平均であるんじゃないかと思う。
code cloneに関して2つの論文があったので、code clone好きなひとは読むのもいいであろう。


ASTA

ASTAという活動をしている
http://aster.or.jp/activities.html

Asiaのテストの地場力を上げていこうという活動である。韓国人のWonilとISTQBのミーティングに出ているときに、このままだとアジアのテスト業界はヨーロッパやアメリカの従になってしまい、アジアはテストの世界でもだめになってしまうというのがモチベーションだ。

ヨーロッパは今元気である、たぶんテスト関連のいろんなことはヨーロッパ主導で決まっていくであろう。その中にあって、極東はただの英語とスキルのない、そして安いものを売ったり勝ったりする2流国の集まりである。実際どこの国際会議にいってもアジアの意見は通らない。人口がいくらいようとも。

そんじゃあアジア一国ではなく多数国で協力してヨーロッパと戦っていくしかない。

そんな活動の一環としてアジアの人に来てもらってJaSSTの中で発表してもらった、話としてはおもしろかった。日本の発表は結構重箱の隅をつつく技術的な話が多いのだが、彼らはテストプロセスとか大きいことを話す。そしてヨーロッパの人たちもどうやってプロセスをするかを話す。ひょっとしたら日本はアジアの中でもおいていかれてしまうのかとも思ってしまう。


ケーパーズジョーンズ

ケーパーズジョーンズと結構話すことができた、まあ役得である。

結構おもしろいというか、彼の話は共感を持てる。あの言い切り型もいい。FPで全て語れると言い切ってしまうが、それに文句を言える人はいないだろう。なんせあの豊かな経験、そして数値をばりばい言われてしまうと。

話していてすぐに数値がばりばり出るのには驚いた、あの歳でよくあんだけの数値を覚えてるなーと関心する。デマルコもそうだし、ケーパーズもそうだけど年齢というのを感じさせない、なんなんだろう。

マイケルジャクソンの無謀さにも驚いた、皆アメリカの年配は元気である。見習うべきである。


この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。