アカウント名:
パスワード:
そもそも「バグの数=ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか?」は大抵の場合、NOですから。
上流工程の段階から仕様をきちんと煮詰められる(プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる)人間が携わっていれば、そんなにひどいモノはできない気がするんですけどね。
#でもスーツ着て客の前に出るのが面倒だから引きこもり気味の巫女なのでAC#ACの意味がないのは芸風です(言い切った)
品質管理って上流は上流であるし下流も下流なりにあると思うんだけど。だから、
なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか?」は大抵の場合、NOですから。
これの対極には「本当に顧客が使いたい完璧な仕様ではあるがバグが多すぎ」ってのがあるんでしょうね。そういう下流工程でのQCの話題に、上流がきっちりしていたら下流もオッケーだろというのは乱暴というよりも議論の前提が違いますよ。
上流工程がきっちりしてたらってのは「本当に顧客が使いたい完璧な仕様ではあるがバグが多すぎ」からバグを取り除きつつ顧客が満足できる仕様にすることなんじゃないの?
それができりゃ苦労しないけどさ……
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
そもそも (スコア:3, 興味深い)
そもそも「バグの数=ソフトウェアの品質」という短絡的な考え方がソフトウェアの品質を下げてます。なぜなら「バグがなければ本当に顧客が使いたい完璧なソフトウェアなのか?」は大抵の場合、NOですから。
上流工程の段階から仕様をきちんと煮詰められる(プログラムで処理できるか、実装にどれくらいコストがかかるか、代替案があるか、を判断できる)人間が携わっていれば、そんなにひどいモノはできない気がするんですけどね。
#でもスーツ着て客の前に出るのが面倒だから引きこもり気味の巫女なのでAC
#ACの意味がないのは芸風です(言い切った)
Re: (スコア:0)
品質管理って上流は上流であるし下流も下流なりにあると思うんだけど。
だから、
これの対極には「本当に顧客が使いたい完璧な仕様ではあるがバグが多すぎ」ってのがあるんでしょうね。そういう下流工程でのQCの話題に、上流がきっちりしていたら下流もオッケーだろというのは乱暴というよりも議論の前提が違いますよ。
Re:そもそも (スコア:0)
上流工程がきっちりしてたらってのは「本当に顧客が使いたい完璧な仕様ではあるがバグが多すぎ」からバグを取り除きつつ顧客が満足できる仕様にすることなんじゃないの?
それができりゃ苦労しないけどさ……