アカウント名:
パスワード:
>・仕事としてそのコードを出荷しても良いかどうかは、「仕様書」を満たしているか否かである。>・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
そう。そのとおりです。ただし、それはまっとうなSEが作った仕様書ならば、という前提が必須です。社内でのみ通用するSEが仕様書を作ると、えてして業務とは違う挙動を含んだ仕様書となります。なぜそうなるかは、まっとうなSEの人にはわかると思います。まず、ソフトウェアの品質を上げようと思ったら、仕様書を作り上げられる人を育てないと、どうにもならないと思いますよ。
こう書
ワンオフ的案件で複数社に発注出すときにバグとか仕様っていうレベルの以前に実戦経験の差みたいなものがありありと出てくるんすよね。出来る業者さんとそうでない業者さんみたいな。
目的の機能満たしたモノを作ってくださいよっていうのをお願いする際に生じる周辺要件をあらかじめちゃんと押さえている業者さんと当たり前のエラー処理さえもこっちで指定しないと動けないレベルの業者さんがいて、その辺を知らない担当が仕様決めしなきゃいかんという状態だと重要度と選択肢と矛盾点に対する決定事項が雪だるま式に増えて最終的に納期と品質が全然変わって来ますね。当然バグの量も。
その辺って技術っていうよりノウハウ的なものなんだと思うので、仕様上なんかしっくり来ないよっていうのに対してどういう補完条件を出したら顧客の決定が早くなるかとか、他社さんはどうやってんの?っていうことに嗅覚を持つといいかもしれないですね。パッケージと違うワンオフみたいな発注側の発注頻度が低い分野の案件だと官民問わずそういうのをやった経験のない人間が発注担当になる割合多いのも見過ごせないところです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
品質が安定していてうらやましい (スコア:3, 興味深い)
俺が師匠に言われたのは、
・BUGが無くなったっと評価したら、その評価がBUGである。
・仕事としてそのコードを出荷しても良いかどうかは、「仕様書」を満たしているか否かである。
・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
・キチンとした「仕様書」が入手出来ていない仕事の場合、「おまえのセンスで何とかしろ。」
・・・そんなオチかよ!!
Re: (スコア:0)
>・仕事としてそのコードを出荷しても良いかどうかは、「仕様書」を満たしているか否かである。
>・プログラマの目からみて明らかにBUGであっても、仕様書通りの挙動であるならそれは「仕様」である。
そう。そのとおりです。ただし、それはまっとうなSEが作った仕様書ならば、
という前提が必須です。
社内でのみ通用するSEが仕様書を作ると、えてして業務とは違う挙動を含んだ
仕様書となります。なぜそうなるかは、まっとうなSEの人にはわかると思います。
まず、ソフトウェアの品質を上げようと思ったら、仕様書を作り上げられる
人を育てないと、どうにもならないと思いますよ。
こう書
Re:品質が安定していてうらやましい (スコア:0)
ワンオフ的案件で複数社に発注出すときにバグとか仕様っていうレベルの以前に実戦経験の差みたいなものがありありと出てくるんすよね。出来る業者さんとそうでない業者さんみたいな。
目的の機能満たしたモノを作ってくださいよっていうのをお願いする際に生じる周辺要件をあらかじめちゃんと押さえている業者さんと当たり前のエラー処理さえもこっちで指定しないと動けないレベルの業者さんがいて、その辺を知らない担当が仕様決めしなきゃいかんという状態だと重要度と選択肢と矛盾点に対する決定事項が雪だるま式に増えて最終的に納期と品質が全然変わって来ますね。当然バグの量も。
その辺って技術っていうよりノウハウ的なものなんだと思うので、仕様上なんかしっくり来ないよっていうのに対してどういう補完条件を出したら顧客の決定が早くなるかとか、他社さんはどうやってんの?っていうことに嗅覚を持つといいかもしれないですね。
パッケージと違うワンオフみたいな発注側の発注頻度が低い分野の案件だと官民問わずそういうのをやった経験のない人間が発注担当になる割合多いのも見過ごせないところです。