正しい設計書の書き方

設計書って、どんな項目があって、どんな内容を書くのがいいの？
お勧めのテンプレートとかない？
参考になるサイトもあったら教えてくれ。
って言うか、教えて下さい。

>>1
アホでつか？

なぜ本を読まないのか？
なぜ本屋に行かないのか？
なぜ２ｃｈにスレを立てて聞くのか？！

・免責事項を漏れなく記載する事。
・賞味期限を記載する事。

ｔ

ソースコードがあれば後は何もいらんよ？

>>1
お前が設計しようとしているものはどんな仕様で、
それを実現するには何が必要なんだ？

>>3
正直、見た事無い。

まずは今すぐに3chをミロ。木構造や3Dアニメーションに就いてやってる。

>>9
あ、テレビか・・・

http://www.3ch.jp/
を開いちゃったよorz

>1
成果物を作るために必要なｲﾝﾌﾟｯﾄはなにか、と考えれ。

プログラミングの時点で、基本設計レベルのバグが見つかることが多い。
しかもいろんなプロジェクトで。まったく。。

行間の読めない奴らに聞いた漏れが一番あほだったなやっぱし。

行間を読まなければならない仕様書は駄目だなｗ

>>14
特に日本の設計書では、行間を読む必要があるものが多いのも事実。
そこが日本の良いやり方だったりするのも事実？

>>15
＞そこが日本の良いやり方だったりするのも事実？
誰がどう「良い」なんて言ってるの？

お客にとって都合が「良い」なんだろうね。
きっちり書いておかないと赤字になったりデスマったりするよ。

設計書といってもいろいろあるが

>>18
>>1は行間を読めと言ってるよｗ

まぁ、>>1の行間には何も書いてないわけで。

>>13
とりあえず、「>>1が一番あほだった」ことには同意。

>>8同意
自分も最近レビューで叩かれまくったので、本屋に行ったり
アマゾンでそれなり検索したけど無かったぞ。
業務系ならばありそうだが、制御は無かった。
>>12
滝では仕方ないのでは？

設計書って、どんな項目があって、どんな内容を書くのがいいの？
（ド素人の俺にはさっぱりだよ）
お勧めのテンプレートとかない？
（考える力がさっぱりな俺はいつもテンプレートまかせなんだ）
参考になるサイトもあったら教えてくれ。
（ググろうにもキーワードがさっぱり・・・）
って言うか、教えて下さい。
（あぁ、さっぱりした）

>>23の行間を読むスレ

設計書は作る事が目的じゃないからなぁ。

>> 22
オープンソースや、ベンダーの開発ツールに、
設計ドキュメントがついていない？

なんでもかんでも、設計書があると思うな、バカモンがぁ！！

って、仕変の多い会社の上司とか口にしそう。

>>22
設計に関する本が無いってどういう類のネタですか？

>>1
設計書といわれても色々あるけど、
まず、求められているものが何かを書いて、
それをどうやって実現していて、数ある設計選択肢のなかからなぜそれを
やったのかを書くのが良いと思うぞ。

設計書ってのは、ウソが３割混じってると思うのが妥当と最近感じられ。

1や行間を読めと言うSEは、言語仕様だけを理解してプログラミングするPGの様なモンだ。

つまりコンパイル出来るソースを記述する事が目的で満足し、
バグが出たら、それはコンピュータや言語が悪いと言う。そんなPGと一緒だ。

いや、そんなPGはいないから、よってそいつらは寄生虫な訳だ。

1は職業プログラマではない

いろいろ試行錯誤した結果、俺にはソースコード中に解説を入れながらコーディングして、
プログラムが完成したらソースに埋め込んだコメントからツールでドキュメント生成。
それを詳細仕様書として納めるのがかなりベターなんじゃないかと思うようになった。
とりあえずdoxygen使ってます。

まあ、かのクヌース先生も、この技法でTeX設計した訳だし、かなり現実的な方法なんじゃないかと
思ってます。

ひとりで全部コーディングするならそれでもよかろう。>>33

手抜き設計書でできるプログラムは各PG独自に空想した仕様でできている。
あ〜あ、恐ろしや。

>各PG独自に空想した仕様

設計書というよりも仕様書が手抜きなんだろ？

UIと帳票（ユーザが実際目にする動き）を書類にして出し、それで承認とる。
それで十分だろ。

>>36
設計書のスレですが。

>>36
余白にUDATE項目とチェック項目を手書きしなきゃダメだ

UIと帳票って設計と違うの？

設計書っていうのはウソが多めに入ってる、その代わり予算内で実装可能な要件少なめ
これに大盛りに仕様変更！　これ最強！！
しかしこれをすると、デスマに向かって一直線という片刃のつるｇ（ｒｙ

「別にツルギでなくてもケンでもいいよな」とか思ったものの一応辞書検索してみたら
ttp://dictionary.goo.ne.jp/search.php?MT=%BD%F4%BF%CF&kind=&mode=0&jn.x=33&jn.y=14
> もろは 0 【▽諸刃】
>
> 刃物で両面または両側に刃が付いていること。また、そのもの。両刃(りようば)。
> ⇔片刃
> ――の剣(つるぎ)
> 相手にも打撃を与えるが、こちらもそれと同じくらいの打撃を受けるおそれがあることのたとえ。
とか書いてあったので>>40を煽らなくて良かったと胸をなでおろしている奴の数→

>36
UIには帳票を含むんだが

>>42　ほんとかよ。

広義には含むんじゃないの。ユーザとコンピュータの接点だから。
だいたいのシステムだとUI = 画面と帳票
他のUIって業務システムだとある?

>44
他の連携するシステム間とのインターフェース

そりゃＵはいらないじゃん。

データフォーマットはユーザーインタフォース…じゃないな…

物理的なスイッチとか。

UI工程では、システムの外部仕様の定義を行う
ユースケース (利用者にとって業務的に意味のある目的を完了するまでのプロセス) を単位に
外部仕様を定義

...やっぱ他の連携するシステムとのインタフェース設計はこのタイミングだな

必要な書類は、客用のUI設計書 だけでOKってことでいい？

ま、他システムとデータやり取りするときは、Excelとかで適当に対応表とか
加工方法みたいのを書くんだけどね（自己流）。
プログラムやらスクリプトやらテーブル設計やらはしょっちゅう修正・変更する
ので、細かい設計書なんか作ってる暇ない（つか、無理）ので、メモみたいなの
を簡単な手製DBにごちゃごちゃって書いて残す程度。

テスト時には、客に出して仕様書とソース(紙に出力)をみながら、期待通りに
動くか確認。 ま、これだと開発者以外がテストするのは厳しいかな。

以前、「ソフトウェアドキュメンテーション」(株式会社デンソークリエイト、
150頁)って本を\3000も出して買ったんだが、「そんな一杯、書類作れるかよ」
って感じでほとんど読まずに本棚に埋もれてる。

>>50
引き出しは肥やしとけよ。
プロジェクトによって必要な設計書は全く変わってくるんだから。

ま、そうなんだろね。何十人もで開発するなら、情報共有・確認するのに一杯
書類作って、大変な手間かけて更新作業するんだろな。　それも現場に
よって、いろいろとやり方が違うと。　なんとなくわかる。

うちは小さいので、このまんまの自己流でいくわ。
２ｃｈは勉強になるなー

>>52
開発者の人数だけの問題じゃないんだけどなぁ。
客が完全に同類同規模で似た要求似た期間似た予算で、
開発者のレベルも毎回ほぼ一定のプロジェクトを
続けられる会社なんであれば、それでもかまわないと思うけど。
そうで無いなら・・・

仕様書は裏紙で使ってます。
なので、仕様書がたくさんないと困ります。

まぁ、俺はIT業界長くて、仕事を出す方の側の人間だが、
本に書いてあるような理想的な設計書があるプロジェクト
に出会ったことないよ。大手だろうが小さいところだろうが、
どこも同じだ。
・・・システム開発終了後、出来上がったシステムをもとに
して、設計書を起こし直すのさ。納品物にあるから、しかたなく・・・

外設：見栄えよいこと
内設：中国人でも理解できること

概要設計書
要件定義書
データベース定義書
基本設計書
基本仕様書
詳細設計書
詳細仕様書
単体テスト仕様書
単体テスト報告書
結合テスト仕様書
結合テスト報告書
総合テスト仕様書
総合テスト報告書
バグ報告書
プロジェクト会議議事録
チーム打ち合わせ議事録
システム連絡表
開発スケジュール予定
開発スケジュール実績
テストスケジュール予定
テストスケジュール実績
進捗報告書

IT後進国であり続けるのも大変です。

仕様書＝発注者向け
設計書＝開発者向け

ってことでＯＫ？

>>57
それらの設計書が全て必要になる開発規模はどれくらい？
まさか１０ｋから３０ｋくらいの小規模開発では必要ないよね。

>>57
運用設計書と操作説明書と構成一覧表は？

５Ｗ１Ｈって意識してますか？

糞上司は、技術屋なんだからＨｏｗを最初に書けと言っておられます。
ハァ？というような文章の出来あがりです。

５Ｗ１Ｈの順番は切り口によって変えるべきでしょうが
糞上司は週報も議事録もＨｏｗを最初に書けと言っておられます。

口頭による報告もＨｏｗから始めないと聞いてくれません。
Ｈｏｗを聞いて「ほうほう」と言わせないと話しすら聞いてくれません。

意識的にＨｏｗを最初に持ってくるのは、訓練として良いものなのでしょうか？

性格が変わりそうです。
うちの会社の人しゃべりかたが独特です。
やめるべきでしょうか？

>>61
漏れ、頭悪いから想像つかないわ。「どのように」が最初なんだよな？
しかも、「ほうほう」と言わせないといけないんだよな？
「ギャフン」と言わせるくらい難しい。。。

>>59
20M あたりから必要なんじゃないかな。
ISO のために書いてるようなもんだけど。

総開発費用中のドキュメント料の割り合いって30％位？

>>61
Howってことはプログラムリストを載せれば良い。

ＤＦＤとER図と画面定義と帳票定義とＤＢ定義があれば十分。
テスト仕様書なんて書かない。工数の無駄。
出来上がって動いて、客が文句言わなければ、なんでもＯＫ。
俺は、信頼で仕事をする。ドキュメントを大量に書くことを要求
されるのは、信頼されてないからさ。

>>66
すごい偏りｗ

ちっ。小魚か。

>>68
もう少し辛抱を学べ

ところで、要件定義の段階で、
アプリケーションの画面設計やモックアップ作ったりする？
モックアップの枝葉末節の操作機能の詳細を要件定義で決める？

>>70
>アプリケーションの画面設計やモックアップ作ったりする？
これは極力やっている。
逆に画面やアウトプットのイメージが全く無しで設計しても
あんまり意味無い様な。
自分がやったのが小規模案件ばかりだからか？

>モックアップの枝葉末節の操作機能の詳細を要件定義で決める？
これは本来やっちゃイカンだろ。
(と言いつつモックアップ見せると枝葉しか見ないのが多い...)

>(と言いつつモックアップ見せると枝葉しか見ないのが多い...)

これが一番厳しいんだよね。
あくまでロジックとか一切含んでいないモックアップだけなのに、
実運用を正確に想定したデータの並びを要求されたり、
枝葉のキメも「要件定義に含める」と要求されたり。
気持ちは分かるのだが、それは後のフェーズでもできると思うのだけれど。

毎回アドリブ

>>73
もれも
もれも
もももももれも
たきもち
たきもろ
たらららろ

滝本

プログラムが行う処理を一字一句書いてある。
おまけとして図表も書いてあるし、フローチャート(UMLに非ず)も書いてある。
今後の懸案・他仕様書の参照も書かれており、この仕様書を見ているだけで開発は行える。

テストは仕様書を蛍光ペンで塗る。仕様書を塗ればテストは完了。
別テスト仕様書作る必要なし。詳細設計詳しすぎ。（境界値とか"例"として、仕様書に書いてある）
いいなぁ、時間も金もあるプロジェクトって。

いや、Ｈのプロジェクトなんだけど。

>>75
そこで書いてる「テスト」ってのは「部品or部品の組み合わせレベルの単体テスト」っつー意味？
単体でも業務的なデータの流れや、結合までのテストまでできちゃう仕様書なの？

>>76
単体テストと結合テストまではカバーできる。
Ｈ用語(?)でDD,UT,CTまではその仕様書を使う。

ハッキリ言って、超かったるい上に超無駄。
まあ、ほとんど仕様変更がないプロジェクトだからできる業かと。
設計(だけ)に３年とかありえねー･･･。

>>77
ありがとん。結合までカバーできるテストも可能な仕様書か。
うちだと、詳細設計書＝テスト仕様書だが、
>>77でいう UT までしかできないなぁ。

色々考えてみるかな。

今、プログラムの改修で詳細設計見てるがぜんぜんわからん。

基本的に、
１．どういう風に
２．どういう意図で
３．要は何をしたいのか？（ここ重要）
を書いてくれたらＯＫ。

だいたい、どこのテーブルに何を放り込むとか、ＳＱＬ書かれても
そんなことはプログラム見りゃわかんだよ。。。

プログラム設計って時間の無駄だよな
プログラム組んだ方が設計は早いし、
プログラム見た方が引き継ぎも早い

そもそもプログラム設計仕様書って、
嘘が多すぎて信用できないよ

あと、グローバル変数って重要な割に管理がいい加減じゃないか？

機能設計書→コーディング→詳細設計書の順で作るのが正しい

>>79
あーなんか漏れと同じ職場かも

こんなとこで愚痴ってないで周知しろ、てか会議の場で主張しろ
新人ばっかでやってるのにベテランは何の方針も示さずにいて、
まともなもんが出てくるわけないだろが

>>81
仕様書の名前は違うがウチも同じだ。

詳細設計書＆テスト仕様書→実装→さらに詳細な詳細設計書