アカウント名:
パスワード:
ソース自体が設計書(の一部)なんですが。大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート(あえてカタカナ)には書くことどころか、読み取ることも出来ない。(ソースよりは判ったふりはしやすい)
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
>ソース自体が設計書(の一部)なんですが。
こういうこという奴は「私はバカです」って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
ソースには本当に「a - b」しか書いてないと思ってんの?
まともなソースなら、どのようなことが要求されているのかは変数/関数名やコメントからある程度分かるように書くから、少なくとも要求仕様と実装のどちらかがおかしいということぐらいはほとんどの場合分かるよ。
自分がクソの役にも立たない書類をずっと書いてた事実を認められないのかな?
今は実装のミスについて話しているんです。要件定義のミスについての話はしていません。
要件定義の部分は「税額の計算が必要」でしょ。
①明細税額の合計に税率を駆けるのか、②明細に税率かけて合計するのかは基本設計フェーズでヒアリングして落とし込む部分ですよ。要件でここまで細かくやる人は私はほぼ見たことがないです。
そこで、そのヒアリングしたものを設計書に落とし込まないで、①が正解なのに②で実装してしまった場合、どうやって②の実装がミスと気づくんですか?
本人でなく、後から別の人間が保守作業する前提で保守する人間がどうやってわかるんですか?
>要件でここまで細かくやる人は私はほぼ見たことがないです
実際はともあれ。本来要件定義時にヒアリングしてここまで細かくやるべきだよね。重要なビジネス要件でしょ?「税額の計算が必要」てのは要件定義の前の「要求」定義の話題だよ。
てかさ、ソースで+-間違えたって、設計書で+-間違えたって、同じ話じゃ?
2回人の手が介在するからチェック機構も2倍働くと言うのは、同時に、2回人の手が介在するから間違える確率も2倍、ってのも忘れてはいけない。
結局の所、木主が言ってる事って「設計書」があるかどうかの問題ではなく「テスト仕様書」の問題なのでは。
合計値と書かれているところに、マイナスの演算子使ってるソースはおかしいんじゃね?(仕様どおりに動いてたとしても、おかしいと思う)
で、設計書もなしにどうやって「テスト仕様書」作るの?
それこそ要求を設計に落とし込んだドキュメントなけりゃ、まちがったソースコードを元に「a-b」のテスト仕様書しか作れなくてテストの意味もテスト仕様書作る意味もないわけだが
#2770927 が想像しているソースコード:
int func0001(int a, int b){ return a - b;}
実際のソースコード:
/* * a と b の合計値を求める。 */int get_sum(int a, int b){ /* * 合計値なのに - なのはおかしいと思うが、 * 問い合わせても『それで正しい』の一点張りだった。 */ return a - b;}
>で、設計書もなしにどうやって「テスト仕様書」作るの?テストってのは要求を満たしているかをチェックするんだから、要求をもとに作るに決まってる。
>それこそ要求を設計に落とし込んだドキュメントなけりゃ、そこの認識がずれている。『設計』という言葉を使っているけど、やってること(やるべきこと)は『概略的な要求』を『詳細な要求』として詰めること、あるいはシステムの『設計』をもとにプログラムに対する『要求』を決めることなんだよ。プログラマからみれば、そこでやっていることはまだ『要求仕様の作成』なの。
そりゃテストケースとかソースコードにDoxygen形式でコメントしておくんだろ。で、仕様書が必要なら自動生成。
> >で、設計書もなしにどうやって「テスト仕様書」作るの?> テストってのは要求を満たしているかをチェックするんだから、要求をもとに作るに決まってる。
その要求はなにに書いてあるんだよ?
最初の2行しか読めないの? 後半にその答えは書いてあるんだけど。
確かにテストのためには必要ですが、他工程のために莫大な工数を無償でかけるのは無理無理無理です。
結局これだよね。
すごいね。
要求仕様 ・・・受注額の税金を計算して請求書に出力
としてしか書いて無くて、
設計書なしで、各明細に税率を架けたものを合計した税額がただしいのか、明細の税抜き金額に税率を架けたものがただしいのか(実際にこの辺は会社毎流儀が違う)
わかるんだ。しかも国が違えば消費税率も違う。固定でやってたとして、それがただしいのか違うのか。実装のミスなのかわかるんだ、すごいね(棒
それを発注元の担当者にヒアリングをして実装をするのが日本のプログラマです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
ソース自体 (スコア:2)
ソース自体が設計書(の一部)なんですが。
大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート(あえてカタカナ)には書くことどころか、読み取ることも出来ない。(ソースよりは判ったふりはしやすい)
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
Re: (スコア:0, 興味深い)
>ソース自体が設計書(の一部)なんですが。
こういうこという奴は「私はバカです」
って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、
実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
Re:ソース自体 (スコア:0)
ソースには本当に「a - b」しか書いてないと思ってんの?
まともなソースなら、どのようなことが要求されているのかは変数/関数名や
コメントからある程度分かるように書くから、少なくとも要求仕様と実装の
どちらかがおかしいということぐらいはほとんどの場合分かるよ。
Re: (スコア:0)
自分がクソの役にも立たない書類をずっと書いてた事実を認められないのかな?
Re: (スコア:0)
今は実装のミスについて話しているんです。
要件定義のミスについての話はしていません。
Re: (スコア:0)
要件定義の部分は「税額の計算が必要」
でしょ。
①明細税額の合計に税率を駆けるのか、②明細に税率かけて合計するのかは基本設計フェーズで
ヒアリングして落とし込む部分ですよ。要件でここまで細かくやる人は私はほぼ見たことがないです。
そこで、そのヒアリングしたものを設計書に落とし込まないで、
①が正解なのに②で実装してしまった場合、どうやって②の実装がミスと気づくんですか?
本人でなく、後から別の人間が保守作業する前提で保守する人間がどうやってわかるんですか?
Re: (スコア:0)
色々説明しだすとウォーターフォールにおける役割分担の切り分け自体の
潜在的な問題とかそこまで踏み込まなきゃならないんだけど、
少なくとも今挙げている例は『設計』という言葉を使っていながら、
実際は要求仕様を詰めていることに他ならないよね。
# 『設計書』っていう名前を使っていることもウォーターフォールの大きな問題の 1つだよな。
# 次工程に対する要求仕様だと認識を改めればもうちょっとマシになる気がする。
Re: (スコア:0)
>要件でここまで細かくやる人は私はほぼ見たことがないです
実際はともあれ。本来要件定義時にヒアリングしてここまで細かくやるべきだよね。
重要なビジネス要件でしょ?
「税額の計算が必要」てのは要件定義の前の「要求」定義の話題だよ。
Re: (スコア:0)
てかさ、
ソースで+-間違えたって、
設計書で+-間違えたって、
同じ話じゃ?
2回人の手が介在するからチェック機構も2倍働くと言うのは、
同時に、
2回人の手が介在するから間違える確率も2倍、
ってのも忘れてはいけない。
結局の所、木主が言ってる事って「設計書」があるかどうかの問題ではなく「テスト仕様書」の問題なのでは。
Re: (スコア:0)
合計値
と書かれているところに、マイナスの演算子使ってるソースはおかしいんじゃね?
(仕様どおりに動いてたとしても、おかしいと思う)
Re: (スコア:0)
で、設計書もなしにどうやって「テスト仕様書」作るの?
それこそ要求を設計に落とし込んだドキュメントなけりゃ、
まちがったソースコードを元に「a-b」のテスト仕様書しか作れなくてテストの意味もテスト仕様書作る意味もないわけだが
Re: (スコア:0)
#2770927 が想像しているソースコード:
実際のソースコード:
Re: (スコア:0)
>で、設計書もなしにどうやって「テスト仕様書」作るの?
テストってのは要求を満たしているかをチェックするんだから、要求をもとに作るに決まってる。
>それこそ要求を設計に落とし込んだドキュメントなけりゃ、
そこの認識がずれている。『設計』という言葉を使っているけど、
やってること(やるべきこと)は『概略的な要求』を『詳細な要求』として詰めること、
あるいはシステムの『設計』をもとにプログラムに対する『要求』を決めることなんだよ。
プログラマからみれば、そこでやっていることはまだ『要求仕様の作成』なの。
Re: (スコア:0)
そりゃテストケースとかソースコードにDoxygen形式でコメントしておくんだろ。
で、仕様書が必要なら自動生成。
Re: (スコア:0)
> >で、設計書もなしにどうやって「テスト仕様書」作るの?
> テストってのは要求を満たしているかをチェックするんだから、要求をもとに作るに決まってる。
その要求はなにに書いてあるんだよ?
Re: (スコア:0)
最初の2行しか読めないの? 後半にその答えは書いてあるんだけど。
Re: (スコア:0)
確かにテストのためには必要ですが、他工程のために
莫大な工数を無償でかけるのは無理無理無理です。
Re: (スコア:0)
結局これだよね。
Re: (スコア:0)
すごいね。
要求仕様 ・・・受注額の税金を計算して請求書に出力
としてしか書いて無くて、
設計書なしで、
各明細に税率を架けたものを合計した税額がただしいのか、
明細の税抜き金額に税率を架けたものがただしいのか(実際にこの辺は会社毎流儀が違う)
わかるんだ。しかも国が違えば消費税率も違う。固定でやってたとして、それがただしいのか違うのか。
実装のミスなのかわかるんだ、すごいね(棒
それを発注元の担当者にヒアリングをして実装をするのが日本のプログラマです。