アカウント名:
パスワード:
ソース自体が設計書（の一部）なんですが。大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート（あえてカタカナ）には書くことどころか、読み取ることも出来ない。（ソースよりは判ったふりはしやすい）
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
＞ソース自体が設計書（の一部）なんですが。
こういうこという奴は「私はバカです」って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
ソースには本当に「a - b」しか書いてないと思ってんの?
まともなソースなら、どのようなことが要求されているのかは変数/関数名やコメントからある程度分かるように書くから、少なくとも要求仕様と実装のどちらかがおかしいということぐらいはほとんどの場合分かるよ。
すごいね。
要求仕様 ・・・受注額の税金を計算して請求書に出力
としてしか書いて無くて、
設計書なしで、各明細に税率を架けたものを合計した税額がただしいのか、明細の税抜き金額に税率を架けたものがただしいのか（実際にこの辺は会社毎流儀が違う）
わかるんだ。しかも国が違えば消費税率も違う。固定でやってたとして、それがただしいのか違うのか。実装のミスなのかわかるんだ、すごいね（棒
今は実装のミスについて話しているんです。要件定義のミスについての話はしていません。
要件定義の部分は「税額の計算が必要」でしょ。
①明細税額の合計に税率を駆けるのか、②明細に税率かけて合計するのかは基本設計フェーズでヒアリングして落とし込む部分ですよ。要件でここまで細かくやる人は私はほぼ見たことがないです。
そこで、そのヒアリングしたものを設計書に落とし込まないで、①が正解なのに②で実装してしまった場合、どうやって②の実装がミスと気づくんですか？
本人でなく、後から別の人間が保守作業する前提で保守する人間がどうやってわかるんですか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
ソース自体 (スコア:2)
ソース自体が設計書（の一部）なんですが。
大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート（あえてカタカナ）には書くことどころか、読み取ることも出来ない。（ソースよりは判ったふりはしやすい）
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
Re: (スコア:0, 興味深い)
＞ソース自体が設計書（の一部）なんですが。
こういうこという奴は「私はバカです」
って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、
実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
Re: (スコア:0)
ソースには本当に「a - b」しか書いてないと思ってんの?
まともなソースなら、どのようなことが要求されているのかは変数/関数名や
コメントからある程度分かるように書くから、少なくとも要求仕様と実装の
どちらかがおかしいということぐらいはほとんどの場合分かるよ。
Re: (スコア:-1)
すごいね。
要求仕様 ・・・受注額の税金を計算して請求書に出力
としてしか書いて無くて、
設計書なしで、
各明細に税率を架けたものを合計した税額がただしいのか、
明細の税抜き金額に税率を架けたものがただしいのか（実際にこの辺は会社毎流儀が違う）
わかるんだ。しかも国が違えば消費税率も違う。固定でやってたとして、それがただしいのか違うのか。
実装のミスなのかわかるんだ、すごいね（棒
Re: (スコア:0)
今は実装のミスについて話しているんです。
要件定義のミスについての話はしていません。
Re: (スコア:0)
要件定義の部分は「税額の計算が必要」
でしょ。
①明細税額の合計に税率を駆けるのか、②明細に税率かけて合計するのかは基本設計フェーズで
ヒアリングして落とし込む部分ですよ。要件でここまで細かくやる人は私はほぼ見たことがないです。
そこで、そのヒアリングしたものを設計書に落とし込まないで、
①が正解なのに②で実装してしまった場合、どうやって②の実装がミスと気づくんですか？
本人でなく、後から別の人間が保守作業する前提で保守する人間がどうやってわかるんですか？
Re:ソース自体 (スコア:0)
色々説明しだすとウォーターフォールにおける役割分担の切り分け自体の
潜在的な問題とかそこまで踏み込まなきゃならないんだけど、
少なくとも今挙げている例は『設計』という言葉を使っていながら、
実際は要求仕様を詰めていることに他ならないよね。
# 『設計書』っていう名前を使っていることもウォーターフォールの大きな問題の 1つだよな。
# 次工程に対する要求仕様だと認識を改めればもうちょっとマシになる気がする。