まさにこれ。 > ある値 a と b を合計する値を求めるのが要求と仕様だったとして、 > 実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」 って言ってるけど、そもそも設計書の段階で間違われてたらどうすんだと。 更にソースでは要求仕様をきちんと満たしてたりすると、余計に混乱するわけです。 プログラミングでは、重複を避けろと言われますが、同じ内容を別の言語で重複して書くのは愚行です。 *BSD や Linux にすら設計書がないのに、明らかにそれら以下の規模や複雑さのソフトに設計書が必要である明確な根拠があるとは思えないです。
ソース自体 (スコア:2)
ソース自体が設計書(の一部)なんですが。
大体、他の物作りでも、自然言語だけでは正確な指示は出来ないので、その仲介として図面などが存在して、それらはとてもじゃないけど、シロート(あえてカタカナ)には書くことどころか、読み取ることも出来ない。(ソースよりは判ったふりはしやすい)
要するに、「セッケーショがぁ」と騒ぐ上司は、他の物作りの場面で図面とか判ったふりをする奴。ポンチ絵でも描いてわたしゃ納得しますって。
Re: (スコア:0)
社内SEなんで自分も設計書なんて作ったことなかったんですが、こないだ初めてお客さんに納品するツールを作んないといけなくなって、その「納品」のために設計書を書かされました。納品物としての設計書を。
ほんと、ソース見ろって言いたかったです。でも見せたところでお客さんが理解できるわけないし、社内で共有する人だっていないし、作る前から作る意味がないことがわかってたのに結局その更新とかに時間がとられて非常に腹立たしかったですね……。
Re:ソース自体 (スコア:2)
そういう単なるエビデンスとしての設計書を求められるような場合は、
Doxygen とかの自動化ツールでババーッと作っちゃうのがいいですね。
だいたいある程度のボリュームの文書が存在することが重要であって、
中身なんて結局まともに読まれないことの方が多いし。
Re: (スコア:0)
それが外と仕事するって事でしょ。
社内で適当に便利ツール作ってるのとは違うんだから立場を認識しないと。
そもそも社内SEだったとしてもあなたが退職した後の人間にいちいちソースを追って動きを理解していけと?
まあcsvファイルを読み込んで一括処理しますみたいなExcelのVBAだけやってますとかならそれでもいいけどさ。
Re: (スコア:0)
半年後)
納品先の社長「今日から一緒に働くことになったA君だ。前職は○○ソフトで働いていたベテランSEで社内システムを管理してもらう」
「A君、早速だが半年前に納品されたツールを見ておいてくれ。」
・・・
A「社長、何ですかツール。コードを見ましたが無駄だらけだしnullになるケースがありそうですよ。設計書も納品されてないようですし
電話で問い合わせたのですが当事の担当はもう辞めてしまったそうです。」
Re: (スコア:0, 興味深い)
>ソース自体が設計書(の一部)なんですが。
こういうこという奴は「私はバカです」
って言ってるのと同じだと思ってる。
要求書とそれを実現する実装方法を抽象化した「設計書」がない限り「実装のミス」はわかりません。
ある値 a と b を合計する値を求めるのが要求と仕様だったとして、
実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
ソースを設計書というなら「a - b」が正となり、それしか資料がなくなるのだから。
Re:ソース自体 (スコア:2)
それは「よ、う、き、ゅ、う、し、よ、う、し、ょ」
例えば、車は「エンジンが付いてて、タイヤがあって、流線型で」とか。当然そんなものでは、いきなり物が作れるはずがない。
「自然言語」は「設計書」として不完全なツールに過ぎない。
もちろん要求仕様書は非常に重要で、ある状況に対して最終的な結果はすべてそこにあるので、首っ引きで参照しながらソースを書きます。しかし、それは設計書ではない。
設計書は作る側に渡すもので、提供される側が必要とすべきものではない。(その次に別の製作者に渡すために、保管ということでは必要だが)
図面だとそれが理解出きるのに、ソフトウエアだとなぜ理解されないんだろう。
Re: (スコア:0)
ウォーターフォールモデルと上流/下流工程の考え方に汚染されたSIer脳では、基本/詳細設計で行うことのみが設計でありその成果物が設計書で、開発(プログラミング)とは前工程の設計書のとおりに作るものなんですよ。
間違いが2点。
基本/詳細設計の成果物には、開発工程に対する要求仕様書という側面があるということ。
粒度が違うだけでプログラミングもまた設計だということ。
Re: (スコア:0)
あなたの理屈で必要なのは要求仕様書であって、設計書ではない。
そして要求仕様書は設計者が書くものじゃない。
Re: (スコア:0)
要求仕様書なんて
「なにがしたい」(ものを買いたい、売りたい。)
レベルで「実現方法(機能仕様、機能設計)」はないでしょうが。
必要なのは「機能と実装の設計」
「コーディング仕様書なんていらない」のは同意できますが「機能実現の為の実装設計書」は必要です。
「どういうDBでどのテーブルはどういう意味を持ち、どのフィールドは何のためで、
どういう計算で入るべきか。」
それが「要求仕様書?あほか」
上記がない限り実装でミスってもけっしてわかりません。
Re: (スコア:0)
>「機能実現の為の実装設計書」は必要です。
>「どういうDBでどのテーブルはどういう意味を持ち、どのフィールドは何のためで、
>どういう計算で入るべきか。」
機能を上から下まできっちり詰めることができるのなら、それは即ちそのまま
ソースコードに落とし込めるということで、それなら最初からソースコードに
そういうことを書けばいい。
そういう意味で『ソースコードは設計書』なんです。
# それにね、だいたい同じ頭で「機能実現の為の実装設計書」と「ソースコード」を
# 書いたところで、両方に同じ間違いをするのが関の山でしょ。
Re: (スコア:0)
フィールドを計算する関数ごとに「テーブルの意味」「関連する別のフィールド」「別のテーブルの意味」
すべてかくんですか?
そもそもシステム全体でDBを複数使用している場合、
「システム全体では使用してもそのクラスでは使用しない
が値としては関連してくる」
とかいくらでもあるわけで。
# それにね、だいたい同じ頭で「機能実現の為の実装設計書」と「ソースコード」を
# 書いたところで、両方に同じ間違いをするのが関の山でしょ。
だからこそ
「コーディング設計書」でなくて「なにをしたいか、何をするべきか、システム全体の中で何を担って、
なにを行って、返す値は何で、システム全体でどういう意味を持つか」
の「設計書」が必要なんですよ。
後で他の人間がみて、「ここでバカやってる」ってわかるように。
そもそも「何を求められていたか、そこで何するべきだったか」
がわからなくてどうやって「やっていることのミス見つけるの?」
Re: (スコア:0)
>「コーディング設計書」でなくて「なにをしたいか、何をするべきか、システム全体の中で何を担って、
>なにを行って、返す値は何で、システム全体でどういう意味を持つか」
もしかして知らないのかもしれないけれど、まともなプログラマならそういうこともソースコード中に
ある程度ちゃんと書いておくものなのです。
Re: (スコア:0)
システム全体の設計書がないのに「システム全体の中で何を担うか」を書けるんだW
一次開発だけでなく、メンテで増えるときにも「システム全体の中でどう」ってかけるんだW
ソースにW
みたことないわW
一次開発と2次開発以降やメンテナが開発と同じ人間とは限らないわけで。
毎回メンテナはシステムすべてのソースを読めと?
Re: (スコア:0)
ソースコードの中に書いておいて自動生成すればその要件は満たせるね。
ドキュメントと突き合せずにソースで直接突き合せられるからソースに書くほうが合理的。
別に書いてたら整合性を保つ手間も増えるし、同じことを2セット書くとかミス増えるだけじゃん。
にもかかわらずドキュメントで同じことをもう一度書くことの意義はどこにあるんですかね。
Re:ソース自体 (スコア:1)
ソースコードと一対一で対応しているドキュメントじゃカバーできない、
全体を俯瞰する情報のために設計書が必要なんですよ。
Re: (スコア:0)
○○画面の××ボタンの処理の仕様が知りたいというシチュエーションがあったとしましょう。
ソースコードから自動生成したドキュメントしかない場合、
まず○○画面のソースがどれかをドキュメントツリーを掘って探す必要があります。
首尾よく○○画面のソースから作られたドキュメントを見つけ××ボタンの処理だというA関数の項を見つけました。
しかしA関数のドキュメントを見ても概要は書いてあるが詳細が何も書いていない。
さて困った、仕方ないからA関数のソースを探してきて読んでみて謎が解けました。
A関数ではB関数を呼んでいて主要な処理はB関数で行っていたのです。
B関数のドキ
Re: (スコア:0)
システム全体の設計書、こそみたことないWW
無い物を前提にされても困る。
Re: (スコア:0)
>システム全体の中で何を担って、
これをソースコードやコメントに書いたら、そのソースは失格。
関数やクラスなんてのは、システムの別のモジュールや、別のシステムでもそのまま再利用されることを前提に書くものなのだから。
システム全体俯瞰の思想をソースコードやコメントに持ち込んだら、「密結合」になってしまいます。
(動作が粗結合でも、ソースとして密結合になってしまう)
システム全体の俯瞰からみた立ち位置やどことどこでどういう役割を果たすかはソースコードとは別のドキュメントにしない限り失格です。
Re: (スコア:0)
まさにこれ。
> ある値 a と b を合計する値を求めるのが要求と仕様だったとして、
> 実装が a - b になっていた場合、「ソースだけ見ても実装のミスとわかる人はいない。」
って言ってるけど、そもそも設計書の段階で間違われてたらどうすんだと。
更にソースでは要求仕様をきちんと満たしてたりすると、余計に混乱するわけです。
プログラミングでは、重複を避けろと言われますが、同じ内容を別の言語で重複して書くのは愚行です。
*BSD や Linux にすら設計書がないのに、明らかにそれら以下の規模や複雑さのソフトに設計書が必要である明確な根拠があるとは思えないです。
Re:ソース自体 (スコア:1)
それだと誰も設計レビューしてないみたいだ。
*BSD や Linux にすら設計書がないのに、
IRC や ML のログが暗黙の設計書だったりする。
ときにはアスキーアートまで駆使して説明することもあるよ。
Re: (スコア:0)
>プログラミングでは、重複を避けろと言われますが、同じ内容を別の言語で重複して書くのは愚行です。
この一文でわかる通り、
いらないと言ってる人間がそうぞうしてるのは「コーディング設計書」であって「機能仕様書、実装設計書」
じゃないんだよなぁ。
それこそ2回かくのばかばかしいんで。
(#2770957)
Re: (スコア:0)
オープンソースほどドキュメントが豊富に揃ってれば、設計書書かなくてもいいかもしれませんね。
Linuxなんて本屋に行けば、カーネルコードの設計書がいくらでもあるんですから。
Re: (スコア:0)
ちょっと聞きたいんだけど、『実装設計書』は
1. どういう立場の人が
2. どういう立場の人向けに
3. どのようなことを目的として
書くものなの?
プログラマ=設計者なら、プログラマが書くもの=ソースコードこそが設計書だと
思うんだけど、プログラムに関する設計書がソースコード以外に必要ということは
プログラマは設計者では無い(所謂コーダー)と考えているということ?
それとも『設計書』という名前が適切ではないということ?
(例えば、ユーザー向けにI/Fの仕様書はソースコードと別に必要だと思うけど、
それに設計書という名前が付いているのは適切ではないというように。)
Re: (スコア:0)
プログラマ=設計者なら、プログラマが書くもの=ソースコードこそが設計書
だからこれが間違い
プログラマ=設計者=保守作業者、メンテナ(機械化人間にでもなって寿命を超えて永遠に)
ならいらないかもね。
1.設計者が
2.プログラマまたはメンテナ向けに
3.システム全体、クラス、関数の用途、それぞれの目的と実装と採用ロジックを記述するもの
かな。
ここでループするとか、そういう「コーディング設計書」はいらない。
必要な機能は何で、どういうロジック理論で、どう実装するか。
たとえば基幹システムでの単価が「移動平均」なのか「固定単価」か
ソートして返す関数が必要で
Re: (スコア:0)
タレこみが言っている『設計書』(それにプログラマ視点での設計書)と、あなたが言っている『設計書』が違うものだっていうのはよく分かった。
名前は『基本設計書』『詳細設計書』でも、プログラマに対して『こういう仕様で作るように』と出すものだからプログラマの側からすればそれが要求仕様書になる。
(もっと言うと、システムの『設計書』とプログラム/モジュールに対する『要求仕様書』は性質が異なるものなのに『基本設計書』『詳細設計書』と一括りにしているところにも問題はある。)
元々タレこみが問題にしているのは、ソースコードを作成し終わった後で、そのソースコードの内容を逐一説明するような設計書を作る必要があるか、ということ(だと私は理解している)。
Re: (スコア:0)
タレこみをよく読みましょう。元のタレこみは「ドキュメントそのものを否定してます」
>ソースコードを作成し終わった後で、そのソースコードの内容を逐一説明するような設計書を作る必要があるか
自動生成でできるのがこれ。これだとそもそも「何がしたいのかわからない」
だから「別につくれ(要求仕様書、基本設計書)といわれたのでしょう」
Re: (スコア:0)
「必要な事はコメントに書いてあるし、お望みとあらばドキュメント化して自動出力も可能にしてあったのだ。」
ってことだから、この自動生成で出力されるのは処理を日本語で表現したゴミとは違うんじゃないかな。
ちゃんとしたメタデータが出力されるにもかかわらず文書化を要求されるということならば
・自動生成のフォーマットであることを拒否された
・自動生成では粒度が細かすぎた(詳細なドキュメントというものそれ自体を拒否された)
・自動生成のシステムを単純に毛嫌いしていた
・タレこみ人のコメントから生成されるドキュメントでは不足だった(としたら手書きでもダメだと思うんだが…)
など何かしらクソみたいな理由があると思われます。
もちろん、タレこみ人のコメントや自動生成のためのメタデータが全体的にゴミだったという可能性もありますけど。
Re: (スコア:0)
なるほど、タレコミ主はウォーターフォールモデルで出来上がってくるダメ設計書しか知らないから『設計書なんて一切必要ない』と思い込んじゃっているのか。
Re: (スコア:0)
本当に必要なドキュメントは、あなたが言う『要求仕様書、基本設計書』とは違う何かだよ。
Re: (スコア:0)
自分は余り多人数での開発はした事が無いですが、
その数少ない経験では、
・ソースを持ち寄る。
・押し合いへし合いで、やばいと思ったら早めに概念を
分ける提案をする。
のが常で、
全体を見晴るかせる文書がいるなら、実装工程の後に
別工程を新設するより無いと思う。
Re:ソース自体 (スコア:1)
Re: (スコア:0)
これって、コメントに記せば済む話じゃないの?
むしろ、設計書に分かれてて、記述箇所に物理的距離が生じるとメンテナンス性が悪化すると思う。
Re: (スコア:0)
大概の開発プロジェクトでは「設計工程」と呼ばれるものが存在していると思いますが。
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)
すごいね。
要求仕様 ・・・受注額の税金を計算して請求書に出力
としてしか書いて無くて、
設計書なしで、
各明細に税率を架けたものを合計した税額がただしいのか、
明細の税抜き金額に税率を架けたものがただしいのか(実際にこの辺は会社毎流儀が違う)
わかるんだ。しかも国が違えば消費税率も違う。固定でやってたとして、それがただしいのか違うのか。
実装のミスなのかわかるんだ、すごいね(棒
それを発注元の担当者にヒアリングをして実装をするのが日本のプログラマです。