アカウント名:
パスワード:
ソース自体が設計書(の一部)なんですが。大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート(あえてカタカナ)には書くことどころか、読み取ることも出来ない。(ソースよりは判ったふりはしやすい)
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
>ソース自体が設計書(の一部)なんですが。
こういうこという奴は「私はバカです」って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
ソースには本当に「a - b」しか書いてないと思ってんの?
まともなソースなら、どのようなことが要求されているのかは変数/関数名やコメントからある程度分かるように書くから、少なくとも要求仕様と実装のどちらかがおかしいということぐらいはほとんどの場合分かるよ。
すごいね。
要求仕様 ・・・受注額の税金を計算して請求書に出力
としてしか書いて無くて、
設計書なしで、各明細に税率を架けたものを合計した税額がただしいのか、明細の税抜き金額に税率を架けたものがただしいのか(実際にこの辺は会社毎流儀が違う)
わかるんだ。しかも国が違えば消費税率も違う。固定でやってたとして、それがただしいのか違うのか。実装のミスなのかわかるんだ、すごいね(棒
今は実装のミスについて話しているんです。要件定義のミスについての話はしていません。
てかさ、ソースで+-間違えたって、設計書で+-間違えたって、同じ話じゃ?
2回人の手が介在するからチェック機構も2倍働くと言うのは、同時に、2回人の手が介在するから間違える確率も2倍、ってのも忘れてはいけない。
結局の所、木主が言ってる事って「設計書」があるかどうかの問題ではなく「テスト仕様書」の問題なのでは。
で、設計書もなしにどうやって「テスト仕様書」作るの?
それこそ要求を設計に落とし込んだドキュメントなけりゃ、まちがったソースコードを元に「a-b」のテスト仕様書しか作れなくてテストの意味もテスト仕様書作る意味もないわけだが
>で、設計書もなしにどうやって「テスト仕様書」作るの?テストってのは要求を満たしているかをチェックするんだから、要求をもとに作るに決まってる。
>それこそ要求を設計に落とし込んだドキュメントなけりゃ、そこの認識がずれている。『設計』という言葉を使っているけど、やってること(やるべきこと)は『概略的な要求』を『詳細な要求』として詰めること、あるいはシステムの『設計』をもとにプログラムに対する『要求』を決めることなんだよ。プログラマからみれば、そこでやっていることはまだ『要求仕様の作成』なの。
> >で、設計書もなしにどうやって「テスト仕様書」作るの?> テストってのは要求を満たしているかをチェックするんだから、要求をもとに作るに決まってる。
その要求はなにに書いてあるんだよ?
最初の2行しか読めないの? 後半にその答えは書いてあるんだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
ソース自体 (スコア:2)
ソース自体が設計書(の一部)なんですが。
大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート(あえてカタカナ)には書くことどころか、読み取ることも出来ない。(ソースよりは判ったふりはしやすい)
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
Re: (スコア:0, 興味深い)
>ソース自体が設計書(の一部)なんですが。
こういうこという奴は「私はバカです」
って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、
実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
Re: (スコア:0)
ソースには本当に「a - b」しか書いてないと思ってんの?
まともなソースなら、どのようなことが要求されているのかは変数/関数名や
コメントからある程度分かるように書くから、少なくとも要求仕様と実装の
どちらかがおかしいということぐらいはほとんどの場合分かるよ。
Re: (スコア:-1)
すごいね。
要求仕様 ・・・受注額の税金を計算して請求書に出力
としてしか書いて無くて、
設計書なしで、
各明細に税率を架けたものを合計した税額がただしいのか、
明細の税抜き金額に税率を架けたものがただしいのか(実際にこの辺は会社毎流儀が違う)
わかるんだ。しかも国が違えば消費税率も違う。固定でやってたとして、それがただしいのか違うのか。
実装のミスなのかわかるんだ、すごいね(棒
Re: (スコア:0)
今は実装のミスについて話しているんです。
要件定義のミスについての話はしていません。
Re: (スコア:0)
てかさ、
ソースで+-間違えたって、
設計書で+-間違えたって、
同じ話じゃ?
2回人の手が介在するからチェック機構も2倍働くと言うのは、
同時に、
2回人の手が介在するから間違える確率も2倍、
ってのも忘れてはいけない。
結局の所、木主が言ってる事って「設計書」があるかどうかの問題ではなく「テスト仕様書」の問題なのでは。
Re: (スコア:0)
で、設計書もなしにどうやって「テスト仕様書」作るの?
それこそ要求を設計に落とし込んだドキュメントなけりゃ、
まちがったソースコードを元に「a-b」のテスト仕様書しか作れなくてテストの意味もテスト仕様書作る意味もないわけだが
Re: (スコア:0)
>で、設計書もなしにどうやって「テスト仕様書」作るの?
テストってのは要求を満たしているかをチェックするんだから、要求をもとに作るに決まってる。
>それこそ要求を設計に落とし込んだドキュメントなけりゃ、
そこの認識がずれている。『設計』という言葉を使っているけど、
やってること(やるべきこと)は『概略的な要求』を『詳細な要求』として詰めること、
あるいはシステムの『設計』をもとにプログラムに対する『要求』を決めることなんだよ。
プログラマからみれば、そこでやっていることはまだ『要求仕様の作成』なの。
Re: (スコア:0)
> >で、設計書もなしにどうやって「テスト仕様書」作るの?
> テストってのは要求を満たしているかをチェックするんだから、要求をもとに作るに決まってる。
その要求はなにに書いてあるんだよ?
Re:ソース自体 (スコア:0)
最初の2行しか読めないの? 後半にその答えは書いてあるんだけど。