アカウント名:
パスワード:
どこぞの製造業の会社の偉い人が、「ハードはこれだけの品質のものを作れるのに、ソフトウェアはどうしてバグをなくせないんだ」とおっしゃっているそうですが、LHCの件はぜひ知っていただきたいところ。規模がでかくて特注品なら、ハードだろうがソフトだろうが不具合はあるものです。
…って、言い訳したいよう。(;;)
>それでも検出数が所定目標に達しなければ堂々と胸を張ればいい。
テストの合否に関係なく「発見され、潰されたバグの数」が規定に達してなければ無条件で突き返す元請けがいるらしいですよ。
バグが全く発見できないソフトウェアは、永久に納品できないってこと？
製作フェーズ直前でプログラマチームが変更になった。ものすごく優秀な連中。結果、彼らが作成したソースコードは静的検査を掛けてもテストツールかましてもエラーがほとんど出ない。ソフトウェア結合テスト段階でもバグの発生が20件程度しかない。明らかに仕様をきちんと纏めあげた上流工程の奴らと実装を確実にこなすプログラマたちのおかげで高品質なソフトウェアが組みあがっている。例外処理も完全に潰しているし、ランダムテストでもびくともしない。すばらしい出来。
問題は会社の品質管理支援ツール。当初の設定ではバグ検出数を700件と想定して、テスト期間3ヶ月を通して収束する形で計画を立てている。コーディングミスや仕様の誤りなどを含んでバグ条件を設定してあるので今回全く当て嵌まらない。困ったツールで、想定バグ件数に達しないとツール上はフェーズが完了できないというとんでもない仕様。結果、会社のPMOをだます為だけに嘘のバグ報告書を大量に作成して、現実のテストフェーズとは別に管理する羽目になった。プロジェクトは納期より早く完了。立上から1週間後からは関係者は交代で長期の休暇に入った。顧客からは感謝状。しかしツール上は計画したとおりのバグと総合テスト後の障害が発生している事になっている。
そんな今後もありえないような事態で誤って受理拒否する確率より、過去の実績を元に算出した「一定比率のバグの存在」を基準に受け取るほうがトータルでの品質向上に繋がるってことでしょ。
あまり敷居を高くすると本当に受理できなくなるから、95%とか99%の納品物を受理できる程度の「最低バグ発見比率」を定めて運用してると思われ。
この基準だけだとバグが見つかるほど受理されやすくなるから、当然「これ以上見つかるようならダメダメでしょ」という累計発見数なども使った受理基準も整備されてるはず。そういう統計的管理を目指してる所なら。
品質を担当している立場から言わせてもらうと、こういう不誠実な技術者がいるからいつまでたってもソフト品質は上がらない。
品質管理に限らず、技術に関わる事象はすべて正確な計測と考察とフィードバックが計画的な遂行や効果の改善に大きく寄与する。その根幹となる前提を崩し、自分だけが規則を破り人を欺き楽をすることは、同僚やそのプロダクトに関わるすべての人に対する愚弄だ。
手管を弄するのは渉外のすることで、技術者のすることではない。まっとうな技術者の態度というのは#1512433のようなものだ。
このような技術者は「腐ったリンゴ」だ。「不誠実」は隣のリンゴに容易に蔓延する。
だが、ちょっと待って欲しい。高品質なソフトウェアではなく、バグレポート100個を求める顧客にそれを提供するのは誠実な技術者ではなかろうか？
特注品は関係ないな。最近はハード屋さんもFPGAのおかげでボロボロバグ入りのハードよこしますよ。＃どうしてもパフォーマンスでないときにハードアシストしてって(ハード的観点で)割とぎりぎりになっても泣きつけるので便利ではあるんだが＜FPGA
＞ハードはこれだけの品質のものを作れるのに、ソフトウェアはどうしてバグをなくせないんだ
ソフトウエアはデジタルなので生産するときにはそのまんままるのまんまコピーされます。また、コピーすることにはほとんどコストがかかりませんから、特に近年はメディアの大容量化、回線の大容量化でここにソフトウエアそのものを変更することをともなうコスト改善が絡むことは非常に少ないはずです。ですから、ここに人の手や目が入る余地はありませんし、量産してもできてくるものは毎回同じものができるはずです。従って、同じソフトなら、生産すればするほど（
>ソフトウエアはデジタルなので生産するときにはそのまんままるのまんまコピーされます
そのコピーのマスターが、工業製品でいうところの「試作品」だってことがそもそもの問題。工業製品のように、全く同じ仕様で何度も再実装を繰り返せば品質も向上させられますよ。普通はそんなことに金や時間をかけたりしないだけです。
まぁ、目くじら立てずにゆっくりみてあげることが大切大きなプロジェクトの宿命です。
やっと稼動準備が整って、最初の衝突実験を行うのが2012年 [google.com]になるんですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
「同様のバグがないか水平展開して調査したところ、他に2件…」 (スコア:1, オフトピック)
どこぞの製造業の会社の偉い人が、「ハードはこれだけの品質のものを作れるのに、ソフトウェアはどうしてバグをなくせないんだ」とおっしゃっているそうですが、LHCの件はぜひ知っていただきたいところ。規模がでかくて特注品なら、ハードだろうがソフトだろうが不具合はあるものです。
…って、言い訳したいよう。(;;)
Re: (スコア:0)
品質チェックのときにうるさく言われるとかあるんですよねー。
自分の作ったものに不具合はないとは言い切れないけど何か変だと思うんですけどね...
# Japanese Gentlemen Stand Up Please!
Re:「同様のバグがないか水平展開して調査したところ、他に2件…」 (スコア:1, すばらしい洞察)
喰わせるテストデータや条件を変えていってバグを出すんだって。
それでも検出数が所定目標に達しなければ堂々と胸を張ればいい。
自分でバグしこんでどうするよ。
Re: (スコア:0)
>それでも検出数が所定目標に達しなければ堂々と胸を張ればいい。
テストの合否に関係なく「発見され、潰されたバグの数」が規定に達してなければ無条件で突き返す元請けがいるらしいですよ。
Re: (スコア:0)
一度や二度のテストをパスすることじゃない。
Re: (スコア:0)
バグが全く発見できないソフトウェアは、永久に納品できないってこと？
Re:「同様のバグがないか水平展開して調査したところ、他に2件…」 (スコア:1, 興味深い)
製作フェーズ直前でプログラマチームが変更になった。ものすごく優秀な連中。
結果、彼らが作成したソースコードは静的検査を掛けてもテストツールかましてもエラーがほとんど出ない。
ソフトウェア結合テスト段階でもバグの発生が20件程度しかない。
明らかに仕様をきちんと纏めあげた上流工程の奴らと実装を確実にこなすプログラマたちのおかげで高品質なソフトウェアが組みあがっている。例外処理も完全に潰しているし、ランダムテストでもびくともしない。すばらしい出来。
問題は会社の品質管理支援ツール。
当初の設定ではバグ検出数を700件と想定して、テスト期間3ヶ月を通して収束する形で計画を立てている。
コーディングミスや仕様の誤りなどを含んでバグ条件を設定してあるので今回全く当て嵌まらない。
困ったツールで、想定バグ件数に達しないとツール上はフェーズが完了できないというとんでもない仕様。
結果、会社のPMOをだます為だけに嘘のバグ報告書を大量に作成して、現実のテストフェーズとは別に管理する羽目になった。
プロジェクトは納期より早く完了。立上から1週間後からは関係者は交代で長期の休暇に入った。顧客からは感謝状。
しかしツール上は計画したとおりのバグと総合テスト後の障害が発生している事になっている。
Re: (スコア:0)
下請に甘んじることもなかろうて。
Re: (スコア:0)
そんな今後もありえないような事態で誤って受理拒否する確率より、
過去の実績を元に算出した「一定比率のバグの存在」を基準に
受け取るほうがトータルでの品質向上に繋がるってことでしょ。
あまり敷居を高くすると本当に受理できなくなるから、95%とか
99%の納品物を受理できる程度の「最低バグ発見比率」を定めて
運用してると思われ。
この基準だけだとバグが見つかるほど受理されやすくなるから、
当然「これ以上見つかるようならダメダメでしょ」という累計発見数なども
使った受理基準も整備されてるはず。そういう統計的管理を目指してる所なら。
Re: (スコア:0)
とあるユーザから「バグが少なすぎる」という痛烈なクレームにビックリ。
なんでもそのユーザの検収部門には、規模に応じた数のバグを指摘して改修させるノルマがあるそうで、次もこんなこと(バグがとても見つけにくいレベルで納品)をしたら絶対に検収上げないぞ、仕事ナメんなってネチネチと。しかも報復的に、ウルトラCクラスの嫌がらせとしか思えない内容のバグを指摘してきた。
仕様には書かれていないが根本に関わる部分だったので、それはもう大変なことになりました。
そういうのは社外だけでなく社内からも言われることがあって、社内規則では、
・テスト項目はテスト開始前にすべて作成してレビューを受けること
・類似バグであっても、複数のテスト項目に該当する場合は個別にカウントする(1つにまとめて数えてはいけない)
となっていて、その日のテスト実施項目数にバグ発見数が比例してしまう。
にもかかわらず、日別のバグ発見数の推移をみて収束してないと言われる。
Re:「同様のバグがないか水平展開して調査したところ、他に2件…」 (スコア:1, すばらしい洞察)
品質を担当している立場から言わせてもらうと、
こういう不誠実な技術者がいるからいつまでたってもソフト品質は上がらない。
品質管理に限らず、技術に関わる事象はすべて
正確な計測と考察とフィードバックが計画的な遂行や効果の改善に大きく寄与する。
その根幹となる前提を崩し、自分だけが規則を破り人を欺き楽をすることは、
同僚やそのプロダクトに関わるすべての人に対する愚弄だ。
手管を弄するのは渉外のすることで、技術者のすることではない。
まっとうな技術者の態度というのは#1512433のようなものだ。
このような技術者は「腐ったリンゴ」だ。
「不誠実」は隣のリンゴに容易に蔓延する。
Re:「同様のバグがないか水平展開して調査したところ、他に2件…」 (スコア:1, おもしろおかしい)
だが、ちょっと待って欲しい。
高品質なソフトウェアではなく、バグレポート100個を求める顧客にそれを提供するのは誠実な技術者ではなかろうか？
Re: (スコア:0)
>まっとうな技術者の態度というのは#1512433のようなものだ。
その渉外担当が真っ当じゃないから困るんですよ。
＃たまにいるよね、おまえ実は客先の人間なんじゃね？っていう営業。
Re: (スコア:0)
> その根幹となる前提を崩し、自分だけが規則を破り人を欺き楽をすることは、
> 同僚やそのプロダクトに関わるすべての人に対する愚弄だ。
その通り。
だが、その言葉は開発をやっている技術者よりも、まず品質管理部門に言うべきだ。
品質管理部門は開発部門からのフィードバックを拒み、形骸化したプロセスを開発部門に押し付ける。
しかも自らは計測も考察も行わず、もっぱら開発部門にレポートを書かせて、その上で、現実離れした妄想でツッコミを入れて開発部門の邪魔ばかりする。
品質管理部門なんか潰して、その人員を、開発部門の中の人として品質管理のための下僕として配置したほうがいいと思うんだわ。
Re: (スコア:0)
特注品は関係ないな。
最近はハード屋さんもFPGAのおかげでボロボロバグ入りのハードよこしますよ。
＃どうしてもパフォーマンスでないときにハードアシストしてって(ハード的観点で)割とぎりぎりになっても泣きつけるので便利ではあるんだが＜FPGA
Re: (スコア:0)
＞ハードはこれだけの品質のものを作れるのに、ソフトウェアはどうしてバグをなくせないんだ
ソフトウエアはデジタルなので生産するときにはそのまんままるのまんまコピーされます。また、コピーすることにはほとんどコストがかかりませんから、特に近年はメディアの大容量化、回線の大容量化でここにソフトウエアそのものを変更することをともなうコスト改善が絡むことは非常に少ないはずです。ですから、ここに人の手や目が入る余地はありませんし、量産してもできてくるものは毎回同じものができるはずです。従って、同じソフトなら、生産すればするほど（
Re: (スコア:0)
>ソフトウエアはデジタルなので生産するときにはそのまんままるのまんまコピーされます
そのコピーのマスターが、工業製品でいうところの「試作品」だってことがそもそもの問題。
工業製品のように、全く同じ仕様で何度も再実装を繰り返せば品質も向上させられますよ。
普通はそんなことに金や時間をかけたりしないだけです。
バグはどこでも起こるもの (スコア:1)
まぁ、目くじら立てずにゆっくりみてあげることが大切
大きなプロジェクトの宿命です。
ヒッグス粒子の発見を早く (スコア:1)
OSがどんどん上がる (スコア:0)
こうやってどんどん遅れて (スコア:0)
やっと稼動準備が整って、最初の衝突実験を行うのが2012年 [google.com]になるんですね。