アカウント名:
パスワード:
総合試験以降でバグ出したらなぜなぜやれって客先に言われたんだけど、結局自分達が無能でしたって答えしか導けないんですよね。もしくはお前らの金払いが悪い、か。
失態やらかしたのは事実だし、ぶっちゃけドジこいただけなんだけど、自分たちが無能でしたと報告するのは会社として出来ないし、実作業した部下にそんな思いはさせられないので、空気読めないキャラの自分がごねてルール潰してもらいました。長いお付き合い考えると、プロジェクトのトップとかじゃ出来ないですし。
その総合試験とやらで、バグが見つからない真因を客先がなぜなぜしないのは何故なんだろうか。総合試験を作ったのも自分たち?だったら客先が総合試験を作って、試験も実施すればいいのでは?
なぜ不具合が出るのを前提とした体制を構築しないのか?って言いたくなりますよね。 不具合が出たら直せばいいのよ。
ソフト系って楽でいいなぁハードだと目の前に「動かない物体」が出来上がってくるので直せばいいなんて言っていられない半導体の方だと改版層数を極力少なくするようにしてもマスク改版1回で一千万単位の金が吹っ飛ぶし
でも、OSが謎の動きするとか、RDBMSが挙動不審だとか、他人に振り回される事は少なそう(個人の感想です)
謎の動きをするOSでご迷惑をおかけしてすみません。ちなみにOSも試作段階の不安定なハードで開発することが多いのでそれなりに振り回されます。
ハードとOSの間に挟まれるミドルはどっちからも振り回されるしな
死んでもテヘペロの精神で
一人殺せば殺人犯だけど千人殺せば英雄なのですよ(違
メッサーは殺した数だけ上手くなるってやつですね。
自分で殺したとは言ってない、という解釈があるつまり、死人が出るような現場にいくら立ち会ったか…あれっこれだと、開発の現場(ry
いやぁ、結合までならそれだけで十分でしょうけど、総合以降になったら、手戻りコストが馬鹿にならないので。1文字コード直すだけでも20人日くらいかかる世界ですから。(ソース払い出し、修正、単体、ソース格納、リリース、結合試験、等などなどなど)客先に入れた後なら、リリースにさらに30人日。機密度高いシステムなんで、作業許可取るだけでも1週間以上かかる。
1件減らせるならどんな事でもするって気持ちは分からないでもないが、それはなぜなぜでは無い。
「その体制が問題、あるいは予算にコストが見合ってない」って結論出てるじゃないですか。
リリース以降で不具合が出るのを前提にしちゃダメでしょ。そのためにBDとかPDとかST、UTって段階を踏んでいるんです。ちゃんと各段階で不具合を補足&修正してクローズさせていけば、リリース後に不具合は出ない仕組みになっているはずなんだけどな..
#って書いてて思ったけどこれは工程内での失敗なのになぜなにさせられたって話なのかな?#もしそれなら運用側が開発モデルを理解してないってことだから分析させた側の問題になるけど
リリース以降で不具合が出るのを前提にしちゃダメでしょ。
いや、不具合はどの段階でも出るだろ。人間のやる事なんだから。もちろん、不具合を減らす努力は必要だけど、その努力をしたからと言って、不具合が完全になくなることは無いよ。
もし、本当に「リリース以降で不具合が出るのを前提にし」ない、と言うのなら、瑕疵担保や(ソフトウェア)保守は不要って事になる。でも現実には、そんな製品は(ほとんど)無いし、キミが関わった製品も、そうなってはいないだろ?
経営陣がリリース以降で不具合が出ないのを前提にしたのが、みずほのMINORIのあの体たらく。
> リリース後に不具合は出ない仕組みになっているはずなんだけどな..
いや計算機システムの振る舞いは組みあわせ爆発を起こすことがあるわけでそういう場合、全ケース洗い出しとかはそもそも無理で一定以上の複雑性のあるシステムだと不具合が出るのは不可避に近いでしょう。もちろんコストをかければ不具合の発生率を下げることはできますが、90%の不具合を修正するのに必要なコストと、そこから95%まで不具合を修正するのに必要なコストが同じ…みたいに不具合の発生率を下げるのに必要なコストが上昇しがち。なので、不具合率が一定まで低下したらそれ以上の修正は諦めてリリースするという判断に至っているシステムは世の中にたくさんあります。
BDの後にPDがあるのが間違いなんじゃないかなあ。
事実、BD [wikipedia.org]はPD [wikipedia.org]より後ですもんね。
> リリース後に不具合は出ない仕組みになっているはずなんだけどな..でも現実の世界では有名メーカーの最終製品ですら不具合が溢れています。不具合だと思ったものは仕様なのかもしれませんがw
人間は完璧な存在ではなくミスをするものです。開発は当然のことながら、テスト段階でもいくらでもミスは起こるしそもそも完璧なテストなんて出来ないのです。せいぜい全ての分岐を成立させて全てのコードを走らせるぐらいまでしか現実的ではありません。最初の分岐が成立して次の分岐は不成立、そして更に次の分岐が成立したときだけに不具合がでるなんてケースだとそもそもテストケースも準備されてないことがほとんどでしょう。
あなたはミスをしたことがないのでしょうか?
> ちゃんと各段階で不具合を補足&修正してクローズさせていけば、> リリース後に不具合は出ない仕組みになっているはずなんだけどな..
マイクロソフト「すみません」
総合試験以降で「ドジこいただけ」なんてミスするんじゃ、そりゃ客としては問い詰めたくもなるわな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
突っぱねた事はある (スコア:0)
総合試験以降でバグ出したらなぜなぜやれって客先に言われたんだけど、
結局自分達が無能でしたって答えしか導けないんですよね。もしくはお前らの金払いが悪い、か。
失態やらかしたのは事実だし、ぶっちゃけドジこいただけなんだけど、
自分たちが無能でしたと報告するのは会社として出来ないし、実作業した部下にそんな思いはさせられないので、
空気読めないキャラの自分がごねてルール潰してもらいました。
長いお付き合い考えると、プロジェクトのトップとかじゃ出来ないですし。
Re:突っぱねた事はある (スコア:1)
その総合試験とやらで、バグが見つからない真因を客先がなぜなぜしないのは何故なんだろうか。
総合試験を作ったのも自分たち?
だったら客先が総合試験を作って、試験も実施すればいいのでは?
Re: (スコア:0)
なぜ不具合が出るのを前提とした体制を構築しないのか?って言いたくなりますよね。
不具合が出たら直せばいいのよ。
Re:突っぱねた事はある (スコア:1)
ソフト系って楽でいいなぁ
ハードだと目の前に「動かない物体」が出来上がってくるので直せばいいなんて言っていられない
半導体の方だと改版層数を極力少なくするようにしてもマスク改版1回で一千万単位の金が吹っ飛ぶし
Re: (スコア:0)
でも、OSが謎の動きするとか、RDBMSが挙動不審だとか、他人に振り回される事は少なそう(個人の感想です)
Re: (スコア:0)
謎の動きをするOSでご迷惑をおかけしてすみません。
ちなみにOSも試作段階の不安定なハードで開発することが多いのでそれなりに振り回されます。
Re: (スコア:0)
ハードとOSの間に挟まれるミドルはどっちからも振り回されるしな
Re: (スコア:0)
死んでもテヘペロの精神で
Re:突っぱねた事はある (スコア:1)
Re: (スコア:0)
一人殺せば殺人犯だけど千人殺せば英雄なのですよ(違
Re: (スコア:0)
メッサーは殺した数だけ上手くなるってやつですね。
Re: (スコア:0)
自分で殺したとは言ってない、という解釈がある
つまり、死人が出るような現場にいくら立ち会ったか…あれっこれだと、開発の現場(ry
Re: (スコア:0)
いやぁ、結合までならそれだけで十分でしょうけど、
総合以降になったら、手戻りコストが馬鹿にならないので。
1文字コード直すだけでも20人日くらいかかる世界ですから。
(ソース払い出し、修正、単体、ソース格納、リリース、結合試験、等などなどなど)
客先に入れた後なら、リリースにさらに30人日。
機密度高いシステムなんで、作業許可取るだけでも1週間以上かかる。
1件減らせるならどんな事でもするって気持ちは分からないでもないが、それはなぜなぜでは無い。
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)
> ちゃんと各段階で不具合を補足&修正してクローズさせていけば、
> リリース後に不具合は出ない仕組みになっているはずなんだけどな..
マイクロソフト「すみません」
Re: (スコア:0)
総合試験以降で「ドジこいただけ」なんてミスするんじゃ、そりゃ客としては問い詰めたくもなるわな。