アカウント名:
パスワード:
総合試験以降でバグ出したらなぜなぜやれって客先に言われたんだけど、結局自分達が無能でしたって答えしか導けないんですよね。もしくはお前らの金払いが悪い、か。
失態やらかしたのは事実だし、ぶっちゃけドジこいただけなんだけど、自分たちが無能でしたと報告するのは会社として出来ないし、実作業した部下にそんな思いはさせられないので、空気読めないキャラの自分がごねてルール潰してもらいました。長いお付き合い考えると、プロジェクトのトップとかじゃ出来ないですし。
なぜ不具合が出るのを前提とした体制を構築しないのか?って言いたくなりますよね。 不具合が出たら直せばいいのよ。
リリース以降で不具合が出るのを前提にしちゃダメでしょ。そのためにBDとかPDとかST、UTって段階を踏んでいるんです。ちゃんと各段階で不具合を補足&修正してクローズさせていけば、リリース後に不具合は出ない仕組みになっているはずなんだけどな..
#って書いてて思ったけどこれは工程内での失敗なのになぜなにさせられたって話なのかな?#もしそれなら運用側が開発モデルを理解してないってことだから分析させた側の問題になるけど
リリース以降で不具合が出るのを前提にしちゃダメでしょ。
いや、不具合はどの段階でも出るだろ。人間のやる事なんだから。もちろん、不具合を減らす努力は必要だけど、その努力をしたからと言って、不具合が完全になくなることは無いよ。
もし、本当に「リリース以降で不具合が出るのを前提にし」ない、と言うのなら、瑕疵担保や(ソフトウェア)保守は不要って事になる。でも現実には、そんな製品は(ほとんど)無いし、キミが関わった製品も、そうなってはいないだろ?
経営陣がリリース以降で不具合が出ないのを前提にしたのが、みずほのMINORIのあの体たらく。
> リリース後に不具合は出ない仕組みになっているはずなんだけどな..
いや計算機システムの振る舞いは組みあわせ爆発を起こすことがあるわけでそういう場合、全ケース洗い出しとかはそもそも無理で一定以上の複雑性のあるシステムだと不具合が出るのは不可避に近いでしょう。もちろんコストをかければ不具合の発生率を下げることはできますが、90%の不具合を修正するのに必要なコストと、そこから95%まで不具合を修正するのに必要なコストが同じ…みたいに不具合の発生率を下げるのに必要なコストが上昇しがち。なので、不具合率が一定まで低下したらそれ以上の修正は諦めてリリースするという判断に至っているシステムは世の中にたくさんあります。
BDの後にPDがあるのが間違いなんじゃないかなあ。
事実、BD [wikipedia.org]はPD [wikipedia.org]より後ですもんね。
> リリース後に不具合は出ない仕組みになっているはずなんだけどな..でも現実の世界では有名メーカーの最終製品ですら不具合が溢れています。不具合だと思ったものは仕様なのかもしれませんがw
人間は完璧な存在ではなくミスをするものです。開発は当然のことながら、テスト段階でもいくらでもミスは起こるしそもそも完璧なテストなんて出来ないのです。せいぜい全ての分岐を成立させて全てのコードを走らせるぐらいまでしか現実的ではありません。最初の分岐が成立して次の分岐は不成立、そして更に次の分岐が成立したときだけに不具合がでるなんてケースだとそもそもテストケースも準備されてないことがほとんどでしょう。
あなたはミスをしたことがないのでしょうか?
> ちゃんと各段階で不具合を補足&修正してクローズさせていけば、> リリース後に不具合は出ない仕組みになっているはずなんだけどな..
マイクロソフト「すみません」
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
突っぱねた事はある (スコア:0)
総合試験以降でバグ出したらなぜなぜやれって客先に言われたんだけど、
結局自分達が無能でしたって答えしか導けないんですよね。もしくはお前らの金払いが悪い、か。
失態やらかしたのは事実だし、ぶっちゃけドジこいただけなんだけど、
自分たちが無能でしたと報告するのは会社として出来ないし、実作業した部下にそんな思いはさせられないので、
空気読めないキャラの自分がごねてルール潰してもらいました。
長いお付き合い考えると、プロジェクトのトップとかじゃ出来ないですし。
Re: (スコア:0)
なぜ不具合が出るのを前提とした体制を構築しないのか?って言いたくなりますよね。
不具合が出たら直せばいいのよ。
Re:突っぱねた事はある (スコア:0)
リリース以降で不具合が出るのを前提にしちゃダメでしょ。
そのためにBDとかPDとかST、UTって段階を踏んでいるんです。
ちゃんと各段階で不具合を補足&修正してクローズさせていけば、
リリース後に不具合は出ない仕組みになっているはずなんだけどな..
#って書いてて思ったけどこれは工程内での失敗なのになぜなにさせられたって話なのかな?
#もしそれなら運用側が開発モデルを理解してないってことだから分析させた側の問題になるけど
Re:突っぱねた事はある (スコア:1)
リリース以降で不具合が出るのを前提にしちゃダメでしょ。
いや、不具合はどの段階でも出るだろ。人間のやる事なんだから。
もちろん、不具合を減らす努力は必要だけど、その努力をしたからと言って、不具合が完全になくなることは無いよ。
もし、本当に「リリース以降で不具合が出るのを前提にし」ない、と言うのなら、瑕疵担保や(ソフトウェア)保守は不要って事になる。
でも現実には、そんな製品は(ほとんど)無いし、キミが関わった製品も、そうなってはいないだろ?
Re: (スコア:0)
経営陣がリリース以降で不具合が出ないのを前提にしたのが、みずほのMINORIのあの体たらく。
Re: (スコア:0)
> リリース後に不具合は出ない仕組みになっているはずなんだけどな..
いや計算機システムの振る舞いは組みあわせ爆発を起こすことがあるわけで
そういう場合、全ケース洗い出しとかはそもそも無理で
一定以上の複雑性のあるシステムだと不具合が出るのは不可避に近いでしょう。
もちろんコストをかければ不具合の発生率を下げることはできますが、
90%の不具合を修正するのに必要なコストと、そこから95%まで不具合を修正するのに必要なコストが同じ…
みたいに不具合の発生率を下げるのに必要なコストが上昇しがち。
なので、不具合率が一定まで低下したらそれ以上の修正は諦めてリリースする
という判断に至っているシステムは世の中にたくさんあります。
Re: (スコア:0)
BDの後にPDがあるのが間違いなんじゃないかなあ。
Re:突っぱねた事はある (スコア:1)
事実、BD [wikipedia.org]はPD [wikipedia.org]より後ですもんね。
Re: (スコア:0)
> リリース後に不具合は出ない仕組みになっているはずなんだけどな..
でも現実の世界では有名メーカーの最終製品ですら不具合が溢れています。
不具合だと思ったものは仕様なのかもしれませんがw
人間は完璧な存在ではなくミスをするものです。
開発は当然のことながら、テスト段階でもいくらでもミスは起こるし
そもそも完璧なテストなんて出来ないのです。
せいぜい全ての分岐を成立させて全てのコードを走らせるぐらいまでしか現実的ではありません。
最初の分岐が成立して次の分岐は不成立、そして更に次の分岐が成立したときだけに不具合がでる
なんてケースだとそもそもテストケースも準備されてないことがほとんどでしょう。
あなたはミスをしたことがないのでしょうか?
Re: (スコア:0)
> ちゃんと各段階で不具合を補足&修正してクローズさせていけば、
> リリース後に不具合は出ない仕組みになっているはずなんだけどな..
マイクロソフト「すみません」