仕様書が正しいことをちゃんとテストしろよ糞SE [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
正しい仕様書からしか正しい実装はできない。
だから仕様書にバグを入れるな
仕様書も100%テストをして、テストをしたというエビデンスを作成しろや エビデンスとは?
テストをしたという証拠
テストに問題がないという証拠ではない。
単にテストをしたかどうかの問題 >>1
客の出す要求仕様書はバグってても意図さえわかればいいだろ
そこからpgが要求確認書や要件定義書を作成して現実と客とをすり合わせる
んで設計実装試験
問題は要件定義〜単体試験までの工程を別の人間が受け持つと問題がおきやすい > 客の出す要求仕様書はバグってても意図さえわかればいいだろ
だめに決まってるだろ >>4
どうだめかは要件定義時にpg側が指摘しないと
お客さんが素人だったときにどうしようもないんじゃないかな?
こうならできますよ?とか
こうなるのでこのままだとできませんとか 何様だか・・・
こんなPG作るやつに仕事だしたくないな まあ仕様書のバグや不明点は下流でキャッチしてうまく処理しろってのは別にいいんだけど
上流の書いた仕様書のバグや不明点への対応が下流のコストになるのは公平な取引じゃないよな
仕様書のバグや不明点は件数に応じて上流に追加費用を請求するのが当たり前の社会になればいいね >>8
そのとおりだね。不具合修正のコストや仕様が不明なときに
仕様を作る上流工程の代理作業コストも請求するべき >>1
すみませんベンダーのPLさん&漏れの部下君 m(。。)m バグっている仕様書を平気でバラ撒くような奴がいるチームは
どうせ仕様書のレビューもテストケースのレビューもテスト結果の再鑑もまともにしていないから
ITかSTでくだらないバグを大量に発生させるのは目に見えている
意味不明な言い訳をいくら並べようが
要するにまともに見ていないってことしか伝わってこないよね
どうせエビデンスが揃っていなくても気付いていないだろうし
開発以前に基本的なことが出来ていない エビデンスって何かわかってる?
正しく動くことじゃない。
テストしたという証拠でもない。
納品申込書だよ。 下手くそな仕様書書く人って
本もあまり読まないし文章もあまり書かないんだろうなってのが良くわかる
章立てや箇条書き、図表を上手く使って人にわかりやすく伝えようという配慮がまるでない 基本的に情報伝達は情報の発信源の方が責任の比率は高いからな
情報発信の時点で元情報を損失している場合や誤った情報を発信している場合
受け手側で情報を復元したり修正するのは非常に困難になる
読解力や理解力とか言っているが
そもそも仕様書は推理小説やクイズ形式のドキュメントじゃないんだよ
訳の分からない設計書を作成して受け手の責任にする前にまともな物を作成しろ >>14はフォーマットの話をしてるのに、元情報の損失だの誤りだの、後付けの前提を持ち込む奴っているよな
お前だよお前>>16
お前みたいな奴のせいで話がこじれるんだよ
自覚しろ馬鹿 >>17
読解力や理解力とか言っているが
そもそも仕様書は推理小説やクイズ形式のドキュメントじゃないんだよ
訳の分からない設計書を作成して受け手の責任にする前にまともな物を作成しろ 動くコードを書いてから設計書におこす方法を取り入れたけど仕事が大分楽になった 要件定義書、基本設計書、外部設計書などは、
完成度がどのぐらいなのか計測する手段がない。
よっていくらいい加減な基本設計書でも
SEは高い給料がもらえる。
実装は全てプログラマに責任を押し付ければよい。
発注者として、下請けに反論は許さない。
よって下請けプログラマは、全てを最初からやり直し。
下請けプログラマは、実はSEの役割もしているわけだ。
日本のプログラマは奴隷だな。 誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
E66VK7IT4P 同値分析してうまいことテストケース作るやりかたがわからん
足かせにしかならない とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
KOBC1 ■ このスレッドは過去ログ倉庫に格納されています