正直詳細設計書いらないよね？

全部要件定義で突っ込めばよくない？
インプットアウトプット、DBとか環境設定、処理の概要くらいはみたいけどほとんど使われない設計書を大量生産するのってアホみたい。

現場でも実はソース書いてから設計書つくりましたみたいなことが多いし、客も設計書なんかみてないし、保守のSEも設計書よりも問い合わせではコード見て判断する方が多いし、バグ改修でも設計書みながらバグ改修するやつなんていないでしょ。

だれの為に作られてだれの為にメンテしてるの？日本以外のITの進んだ国でも同じことをやっているのだろうか？

5分でかけるコードのために1ヶ月かけて資料と検証をしているようなものだ。

ソースみたり検索しただけじゃ直ぐにわからない情報をパパッとわかるようにまとめたものは必要だと思うけど、過剰すぎて誰も使ってない求めてない情報まで一生懸命メンテしてない？

まとめ
今みたいな詳細設計書はいらないと思う

IT先進国のアメリカでもエクセルで大量に設計書を作っているのかだれか教えてください。

DBのなんかよくわからんパラメーターの設定一覧ならあったほうがいいと思う
でも基本いらないでしょ、どんなときに使うの？
アメリカとか設計書どうなってるんだろう、調べたら日本みたいな設計書はないって書いてあったけど

議論にすらならないのか・・・

ソースを見て判断しなければならないのはドキュメントの保守が行われていないせいであってドキュメント自体は必要だろ。

Javadocがあれば、詳細設計書は要らないかも。
ドキュメントは、後で使うものだけにしたほうがいいというのは同意。

上司がドキュメントしかみないしドキュメントをみて判断をするからドキュメント自体は必要なのはわかる。
でも必要最小限にしたい、20以上のフォルダの中にそれぞれ10～50のファイルがあってさらに1冊印刷するだけで数百ページになったりするものもある。
いくらなんでも過剰だとおもうし、保守なんてできないと思う（メンテしてることにしてるだけ）。
しかもどこの現場にいっても設計書のフォーマットが違ってどう読めばいいのか慣れが必要なんだよ
テーブルだけで300以上あるシステムとかだとDB設計書やSQLだけで恐ろしい量になったりするのもわかるけどさ

なにが必要な情報でなにが不要なのか日本中で統一して欲しいし、教科書てきなものも必要だと思う

アメリカが世界最先端で生産性も高いならアメリカに習えばいいと思ったけど検索しても情報がでてこないんだよね

テスト仕様書ってどの段階で誰が描くのが適切なんでしょうか？

職場ではプログラム担当者(新卒一年目の私)がプログラムを書き終わってから
テスト仕様書を自分で書いて自分でテストしてるのですが
なんだか違和感というかこれ違うんじゃないかっていう感覚があって自信が持てません…

どこの現場いってもそんなもんだよ
マトリクス式で全ての結果にDBと画像の証拠をExcelに貼り付けさせるような時間のかかるテストを要求するところもあるし殆ど時間くれないとこもある(;´д｀)

工程
要件定義　　-　　基本設計（外部設計）-詳細設計（内部設計）-実装
↓　　　　　　　　↓　　　　　　　　　↓　　　　　　　　　↓
システムテスト　　結合テスト　　　　　単体テスト　　　　　プログラムテスト

的なものを勝手にイメージしてるんだけどPS（プログラムテスト）なんてどこも存在しないから
プログラムテストと単体テストを一緒にやるかんじなるのかな？
単体テストは修正したロジックの分岐を全て試すべき！
とかいわれる
詳細設計で決めたこと全部満たしてるかと修正したロジックの分岐を全部通してみる（そのときにデッドロジックに気づいたりもする）
あとは境界値と異常値の確認くらいかな？
結合テストでは修正とは関係なくてもデータパターンを一通り試したり、あとは要件定義とか外部設計で決められたこと全部満たしてるかとかそんな感じかな？

現場の顔伺いながら自己流でやってきてるから参考にならないかも(^_^;)

１つの画面を5日で作るのと20日で作るの、お金になるのは後者。だから書類は多ければ多いほどいい。
SIERなら常識。

テストで大事なのはステップ数と件数だから、全部同じ人がやらないと調整しにくいだろ？
バグが多ければテスト項目から削ったり設計書を直したり、少なければバグが出るテスト項目増やしたりして対応できる。

現場はまじで場所によりけりだからね～
もし先輩がついてないならすごい心細いね、どこの会社に雇われてるのかもわからなくなるしｗ

手動で画面ペタペタとって黙視確認とか何とかならんのかねぇ。。

作業が独立するので、テスト流す人と貼る人と確認する人が並列で動けるので動きが速い現場もある。
一概には何ともいえない。一人で直列にやればいつまでかかるかわからんことにもなる。

めちゃくちゃ上手に設計する人の下で開発できたらすごい楽しく仕事できるんじゃないかという期待を持ってしまう。

パイプラインで作業やるのに、設計情報全部出そろってから開発するわけないんだ。
今はこなれてない設計でも、見切り発車して開発しはじめるパイプライン上等なんだ。

他の人は詳細設計書ある部分プログラミングしてるけど俺の担当してるとこ詳細設計書ないんだけど(;´д｀)

詳細設計書ができる前に開発が始まる、開発がほぼ終わってから詳細設計書に作業がもどるってことが起こるってことは詳細設計書は開発には必要ないんじゃないかって思っちゃうよね。あくまでもそのあとの保守に必要なだけなんじゃないかとか

マジレスすると規模がデカいプロジェクトだと詳細設計書は必須
あと、コードより図や一覧表の方が全体を理解しやすい
末端のエンジニアも全体が分からないと困る
詳細設計書を省く場合でもパラメータシートは必要

魂けがれなく、道けわし

基本設計書は客に納品することが多いからいるよね
詳細はなくていい
基本設計書で不足してる情報を補足する資料があればいい

請負でやる場合、要件定義や基本設計は完了していることが前提だけどな。
準委任契約で開発やってんのかね？

一応書いとかないと貰ったソースで謎のフラグが行ったり来たりしてカオスになるぞw

詳細設計書があればフラグの状態読めるのかよ
馬鹿か

変なフラグ作らせないためだろ

結局ソースと不一致で無意味だろ
馬鹿か

謎のフラグを使うのがNG
詳細設計書を作る暇があるなら
ソースレビューして叩きまくったほうが有意義

詳細設計書からソース自動作成される日も近い

コードいじくりまわしているプログラマが一番気持ち悪い。

うちのシステム、設計書で5GBあるんだが
俺一度も開いたことないファイル山ほどあると思う

今やコードファーストがトレンドだろ
詳細設計ってコボラーかよw

ドキュメントがいらないといってるのは末端だからじゃないの？
ウォーターフォールで工程間の入れ替え考えたらその発想はあり得ないよ

ごめん、足りてないものがあった、Graphviz。
あとはGnu Globalが時々役に立つ事がある（バークレーDBの知識は必要だが）。

要件定義と基本設計さえ、しっかりしていればいい。