詳細設計をしても逆にコーディングしにくくなるだけ

？

ソースコード＝詳細設計

>>2
そうであるべきなのだが実際は・・・。

そもそも詳細設計って都市伝説

ひょっとしてフローチャートまであるとか、それを修正するとか…

グーグルでは詳細設計はしないだろうな

いきなりコーディングして動かしてみて
動いたものを見て直していったほうがいいのではと思うけど
それは通らないんだよね

＞＞ソースコード＝詳細設計
＞そうであるべきなのだが実際は・・・。
そもそもそうであるべきでないような。

誰もが一定レベルのコーディングレベルにあって
読みやすくて保守しやすい書き方ができるなら
ラフな設計図で承認もらったら
あとはソースコードが詳細設計書でもいいと思う。

実際はコピペやコメントアウトやプリプロセッサの嵐
のような糞コードが多いから詳細設計をして
評価とコードを分けざるを得ない

まともにメンテしてある詳細設計書を見たことがない自分は
仕事に恵まれてないんだろうな。きっとそうだ。
世の中には運用開始後何年にもわたってソースとぴったり合うように
メンテされた詳細設計書が存在するんだ。するんだよね？

なんで「詳細設計」というと、コードとイコールな何かを思い浮かべる人が多いんだろう。

詳細設計が、要件定義とコーディングの間の「ソフトウェア設計」、
あるいは、要件定義、概要設計（例えば、UI定義とか外部I/F定義など）とコーディングの
間の「ソフトウェア設計」という意味なら、それがドキュメント化されるべきかどうかは
さておいて、不要と言う人はほとんどいないだろう。

イメージ的にはクラス構造や呼び出し関係まで細かく書いた
UMLでがんばった感のある設計書

>>10

するよ。銀行の汎用機の現場とか行くとちゃんとメンテされてるよ
コボラー乙とか言われそうだけどホントに

基本設計には意味があると思うが
詳細設計にはあまり意味を感じないな

詳細作る奴とPG作る奴が別なら尚更

逆に別なら意味があると思う。
同じなら意味なくね？

そもそもウォーターフォール死ね！

>>15
詳細設計＝コードとほぼ同じくらいのレベルと認識してるので
(Aという変数にBという値を代入とかそういうレベル)
詳細設計が書けるのなら、そいつがコードそのまま書いた方がいいと思ってる。

PGと詳細が別人だったら
その設計書からコードを起こしていくのがすげー無駄に感じるからかな

>>16
各々に長短はあるんだぜ

コーディングしながら設計するスタイルなんで、
設計書だけ先に書けって言われると手が止まってしまう。

ガチガチにメソッドまで設計したつもりだったのに
いざ実装してみると新しいメソッドが欲しくなる

>>18
コードからastah(jude)使って逆仕様書作れば? astahになってムカつくことにフリー版は画像や印刷に透かし
入るようになったから相変わらずjude comm版を使い続けてるけど。

>>19
それくらいはアリだろ。実際はアクティビティレベルの呼出し規約変更を山ほどしたくなるのが世の常。

１クラスあたり１０００行超えたらそのクラスは再設計の寿命がきてる

>>21
1000行で区切る論拠は？　4桁だから？　16進なら0x3E8で3桁だけど？(w

詳細設計なしだと単体テストできないだろ

たかが小さいクラスに単体テストをかけるほど
プログラムが下手なら辞めたほうがいいんじゃないか
論理的思考に穴があるなら何回テストしても抜けが出る

テスト駆動開発って知ってる？

クラスによって単体テストを行わないのはナンセンス
君の言い方だと
この世のソフトにバグは存在しないことにならないか

詳細設計ってのは、ＩＤＥと頭でやって、
詳細設計仕様書はDoxygenで出力、

ってじぶんのじょーしきあってるおね？

>>24
その言い草だとカバレッジすらかけてないようだな。

>>27
クラス図と継承図くらいは必要だろ。

ﾊｧ?(ﾟДﾟ)y─┛~~ >>29

クラス図のグラフィックや継承のHTMLリンクなら、Doxygenがふつーに作ってくれる

>>25 説明して

　 　 　 　　　　　　　｢￣ ｀ヽ､ 　　＿_＿_＿_
　 　 　 　　　　　　　Ｌ -‐ '´ ￣ ｀ヽ- ､　　　〉
　　　　　　　　　　／ 　 　 　　　　　　ヽ＼ /
　　　　　　　　／/ 　/ 　/ 　 　 　ヽヽ　ヽ〈
　 　　　　　　ヽ､レ! {　 ﾑ-t ﾊ　li ､ i　i　　}ﾄ､
　　　　　　　　　ﾊＮ |　lヽ八l ヽｊﾊVヽ､ｉ j/ l　!
　 　　　　　　　/ﾊ. ｌ ヽｋ=＝　,　r= ､ﾉﾙｌ　lＬ」
　　　　　　　　ヽN､ﾊ ｌ　 　┌‐┐ 　 ﾞl ﾉl　l
　 　　　　　　　　　ヽﾄjヽ､　ヽ_ノ 　 ノ//ﾚ′
　　　　r７７７７７７７７７tﾉ｀ ｰ　r ´ﾌ/′
　　　ｊ´ﾆゝ 　　　　　　　ｌ|ヽ 　_/｀＼
　 　〈　‐　知ってるが　ｌﾄ、　/ 　 〃ゝ、
　 　〈､ﾈ.. 　　　　　　 　.ｌＦ Ｖ=＝"／ ｲl.
　　　ト |お前の態度が とニヽ二／　　ｌ
　　　ヽ.|l　　　　 　 　　〈ｰ- 　 !　｀ヽ. 　 ｌ
　 　 　 |l気に入らない ｌﾄﾆ､_ﾉ 　 　 ヾ、!
　 　 　 |l_＿_＿_＿_＿__ｌ| 　　＼ 　　　ソ

>>30
他人と連携する必要がなければそれでいい

作る前にある程度の構想伝えてから着手してるだろうけど

>>33
詳細仕様書が毎日更新できるのに、

＞それでいい

ってなんなの？ばかなの？（ｒｙ

毎日更新される仕様書なんて必要ないぞ

つ [doxygen]

>>36
いや、doxygen使って毎日仕様が後追いで変更かかったら問題だぞ。

必要ないっつかそもそも意味ないよな。仕様を説明するもんが毎日変わっちゃ。

納品物としての詳細
開発終了後の引継ぎ資料としての詳細としてなら
Doxygenはいいと思うよ

でも設計のための設計書としてはどう考えても使えんだろう

そもそも日本語すら不自由な奴が設計書とやらを書くな！、と。
下手な日本語書いてる暇が余ってるなら、直接C言語で書け！

俺は詳細仕様書は書かせてるけど詳細設計書は書かせてないなぁ。
他のチームは詳細設計書を書いてるけど、工数ばかり無駄にかけて品質は悪いし保守しづらくて保守からも文句を言われてるらしい。

最後はコードなんだから、読めば馬鹿でも1週間で全体が把握できるような
キレイなコードを書けよ。まずはそれからだ。

>>37 >>39

だから、仕様書は基本仕様書ﾓﾝﾘｰにしといて、
詳細設計は後からdoxygenすれば良いんじゃねーの？

このスレで書かれてることはプログラム設計じゃねぇの？詳細設計じゃなくて。
と思う俺は世間とずれてるのだろうか？

>>43
基本的に、詳細設計書はPG前に提出するもんだろ。それよりも普通、仕様書変更なんて上司の承認受けないと
出来ないと思ってるんだが、そんなザル会社あるんだ？

お前の会社の文化が世界の標準だとでもおもってんのか
デスマに投げ込むぞ

>>45
>詳細設計書はPG前に提出

受託会社ﾓﾝﾘｰでしょそれは。

デスマ→とりあえず仕様書作ってろ→仕様書つくるためにデスマ→ろくなの出来ない→ダメ出し→
結局ISMSって何？な具合にバグを壁に貼って営業みたいに可視化→PGﾏｰ腐ってやる気なくす→∞地獄

他の部署は仕様書を信じてコッチのコードにアクセスしてくるわけじゃん。
テスト班は仕様書を信じてテストしてるわけじゃん。

そんなにコロコロ仕様書が変わってたら大変じゃね？

だから仕様書なんか信用せず、ソースコードを信用しろ。

>>49
インタフェースさえ決めとけば、中身の設計とかどうでもよくね？

仕様書が信用できないプロジェクトは
デスマの要件を満たしている

>>51
日々更新されるならIF固定という保証無いでしょ

他部門との連携が詳細設計で・・・・ということは
ありえないと思うんだがどうなんだ

俺、このニート生活が終わったらデスマに参加するんだ……

>>52 IFは固定。ただし中の実装がチョコチョコ変わる
そういう話。IF決めないと、そもそも平行で作れないだろ、さすがにそれは俺もまずいと思う。

バグってるんだけど中の実装いじる予算も時間も無いから、I/F変えることにしたから宜しくw

>>52
うちだと実装する言語に縛られるトコからが詳細設計。
だから関数呼び出し的なAPI仕様書は詳細設計書（群）の一部。

てかこのスレじゃ何が詳細設計か分からん状態だし、
雑談にもなんないね。

>>51
> インタフェースさえ決めとけば、中身の設計とかどうでもよくね？
インターフェースってウチは詳細仕様書で決まるんだけど。

うちの場合こんな感じだ。

概要仕様書
・営業がプレゼンで使う資料みたいなやつ
・開発が始まるとあんまり見ない。

外部仕様書
・制約事項などを含めた顧客に何を提供するかの一覧で、顧客との契約内容を文書にしたもの。

内部仕様書
・システムを部分に分割する仕方を記したもの。
・何を実装するかのコンポネント一覧でもある。
・コンポネント間の連携図やコンポネントのスコープ等々を決める。

詳細設計書
・各コンポネント（クラス／関数／サブシステム）のインタフェースと満たすべき要件。
・これが満たされたときコンポネントは単体テスト通過となる。

設計書の中身が各社で違ってるのが話のすれ違いの元なのかもしれないな

基本設計と言いながらも、画面と2,3行程度の説明しか無い、
まるで概要設計のようなものがあったりで

設計書の名称と中身の剥離が起こってる気がするな

ある程度の設計は必要だよ。
重複する似たような変数、状態、遷移があったり、
メンバ変数の中に意味不明なmTmpなんてあったり、
そんな謎ソースコードが紛れ込む可能性は減る。

>・営業がプレゼンで使う資料みたいなやつ
それどこのNTTデータだよ?

Google Waveが公開前に開発終了したみたいだな
今世紀最大のデスマだったに違いないな

公開はした。

ググルってそういう公開＆開発終了、といったライトな開発は通常パスにある。
ま、詳細仕様書は手では書いてないだろうし、手でかいてたら最悪のデスマだろうねｗ

Googleみたいに優秀なエンジニアが集まってるところなら、
仕様書なんてホワイトボードに手書きじゃないの？

白板は発想の具体化用じゃない？
仕様書とかはwiki的なものに個々で纏めてく感じじゃぬ

いや、手って言ったのは、ワープロソフトって意味であって、、、

手じゃないものってのは、ＩＤＥがリアルタイムに図で表示したり、ソースから仕様書動的生成みたいなものを逝ったのだが。。。

グーグルwaveはライトな開発じゃないよね

ライトってのは、開発スタイルがウォーターフォールじゃなくて、って意味で。
ま、”ライト”って言葉で書いたのが間違ってたか。

ウォーターフォールはそもそも作るものが固まってるものを作るようだからな・・

ぐーぐるみたいな未知の領域に踏み込む場合って
そもそも仕様書なんて無さそうだな

ウォーターフォールは
作るものの詳細をガチガチに最初から固めろという事をいってるんだろ

実際は頭の悪い偉いさんの脳内イメージを
こっちが推測しながら短納期開発しなきゃいけないから実現不可能

で、詳細設計を作成するってのはウォーターフォールじゃね？

スパイラルアプローチだとかだと、詳細設計はＩＤＥが表示してくれたり、ソースからジェネレートしたり、データ構造なら設計専用アプリだとか。

そもそもコードから自動生成するものを
設計書などと呼びたく無い

コーディング中に行われた設計を
人間用ドキュメントとして抽出したものだから、問題ないんじゃね？

>>73
コードが設計書だろ、アジャイルの常識的に考えて。
仕様書はラフスケッチ、ソースコードが下書き、ビルドが実際の描画、実行が鑑賞だろうな。
画家的に言うなら。

「コードが設計書」だとしっくりこない、「テストコードが設計書」だとしっくりくる
まだアジャイル能力が低いかな、オレ

テストコードは仕様しか表してないじゃん。
設計がどうなってるかは別問題。

>「テストコードが設計書」
ｲﾐﾌﾒ

>>78
カバレッジツールを勉強しよう。

テストコードは言うなれば、外部仕様書だな。
実行コードそのものが、詳細設計書のような位置づけ。

自動生成されないものは、概要や計画のラフだけでいい。

アジャイル開発をやる場合って、見積書はどう書くの？
と言うか、どうやって費用を見積もればいいの？

>81
つ「アジャイルな見積りと計画づくり」
読んでたら眠くなってほとんど読んでないけど

>>82
ズバリなタイトルの本があるんですね。ググってみたら評判もいい
みたいなんで、早速注文しました。どーもです。

アジャイルな物作りって、永遠に完成しないから、適当な所で収穫するんだろ？

そして翌年以降はバージョンアップで保守料せしめる。

組み込みでアジャイルとかやってみたい

ソニーがよくやってるじゃないか
携帯電話もよくあるな

>>87
それはアジャイルじゃなくて、単に仕様がイイカゲンだからどこまでも中途半端な物しか出来上がらないだけで…

agile

1 敏捷な, 機敏な, すばしこい, はしこい（⇔awkward）
2 活発な, いきいきとした(active)（⇔sluggish）；頭の切れる, 頭の回転が早い

>>86
用語だけアジャイルでもいいなら…・うちで。
イテレーションという名のマイルストーン、とか。

そもそも計画を修正していく権限がないのに
「アジャイルでやりますから」とか言われるんだよな。

イテレーション内で作業が終わらない事が
判明したとたん破綻するだけのプロジェクト。

それが組み込みアジャイル

>>1 はただの未熟なプログラマだろ。

詳細設計書を組んでから書かせるくせに１つ１つ指示してくるところはウゼー

すべてのコントロールにショートカット割り当てるとかどんだけ無茶いうんだ
しかも、アクティブになってると反応してくれないコントロール多い・・・ちゃんとやってよ＞ＭＳ

ソースコードと一対一のフローチャートこそが真の詳細設計

デザインパターンを
どうフローチャートにするのか
みてみたいw

doxygenとかjavadoc使って、詳細設計書を後出しで作るってのも
変な話だよな

無料RPG製作ツール「ロープレジェネレーター」

　直感的操作で簡単なゲームが作れます。 簡単に配布可能な状態に出力することができます。
(HSP製のソースコード付きで、スクリプトの知識があれば自由度の非常に高いカスタマイズ
ができます）
他にも仲間預かり機能（100人も）や、仲間の状態/状態異常を細かく設定できたり、
乗り物が作れたりゲーム中に画像を差し込んだり、回転やフラッシュなどのエフェクト
なんかも簡単に作れる様です。戦闘はデフォだとドラクエ系。
移動は矢印キーの他に、キャラがマウスを追っかけたりするとのこと。
　他にはオートアクションというのがあってオリジナルシステムの製作に役に立つかも
しれない機能です。これは、マップエディタで設定することで、「マップに入った時・
出た時・一歩歩いた時・戦闘開始前」に自動的に実行されるアクションを設定できる
機能です。
■分からないことや要望は掲示板へどうぞ。他にもいろいろ進化中みたい。

>>97
思いっきりショボイんですがとりあえず３Ｄになりませんか？

設計書も成果物の一つとして納品対象だから
ただそれだけのこと

>>96
javadocレベルまで日本語で設計書作って、そこからプログラミング言語に
落とすって、効率悪すぎるからな。

androidのソースにはほとんどコメントが書いてない。
それでも、プログラムの構造がすばらしく、ソースを読むだけで理解可能。
設計書ないと理解できないプログラムは基本的にどこかおかしいのだ。

通信のプロトコル周りは、シーケンス図と状態遷移図がないと難しい

基本設計書に書くからと要件定義書がペラッペラで
詳細設計書に書くからと基本設計書がペラッペラで
リリースが迫ってるからと詳細設計書は後回しで
すでに要件定義者と基本設計者は使えない人間と飛ばされて
いくらなんでもこれはない

基本設計書　と　詳細設計書の書き方を勉強するために
参考になる書籍教えてください。

>>104
プロジェクトリーダーに聞け

詳細設計書かいてたら採算合わないから
今はどこもやめたよね

ほんとに詳細設計書をかかなくて済むようになったらどれだけうれしいか

でもって今まで出してた下請けも閉め出してっから
どこももう今まで作ってたシステム知ってる奴が誰もいなくなったらしいね。

この板っていつも
「大手SIerのウォーターフォール開発に従事しているPG」
という前提で話が進められてる気がする。

今はもうそっちのほうが少数派になってんじゃね？

今のクラウドやらSaaSやらのLAMPなサービスとか、少数のPGでドキュメント書かにガーっと実装して作るでしょ
もう、要件定義、即実装、のノリ。組み込みPGやゲームPGだってそんな感じだよ（両方経験あり）
だから詳細設計書とかいわれると、どこのおとぎ話だ、って印象がある。

組み込みは詳細設計まで書かされるよ。
製品に組み込まれて発売されてしまったらバグ改修が面倒だから。

組み込みの範囲がカーナビとかケイタイとかアプリ方向に拡がったからなぁ。
何か別の分け方が要るのかもしれん。

詳細設計書はソースから自動生成すればいい。
もちろんそんなの誰も読まないがカサにはなる。

>>112
だからそれだと単体試験ができねーっつーの

>>113
単体試験って詳細設計の内容が正しいかどうかをチェックするだけでしょ？

通常先に試験書の作成、コーディングは後ってのを逆にしている連中には到底理解できないんだろうな。

そんな余裕のある職場なんて理解できねーよ

別に単体試験が詳細設計書必須ってわけじゃあるまい？
客の要求→コーディング→結合総合試験→ソースから設計書作成→納品

そもそも客要求聞いたら、もうソースのイメージ付くから
間の設計書は邪魔になるんだよね。

作業分担の為に、何かしらの設計書は必要だけどね。

>>116
同意
データとか富士通とか日立とかそういうとこだけなんだろ
未だにウォーターフォールで無駄なドキュメント大量に撒き散らしながら作ってるのは

>>114
だったら、コーディングの内容が正しいかどうかのチェックはどこでやるの？

俺は逆に詳細設計書がない職場が想像つかん。

設計のレビューとかどうやってんの？
状態遷移表とか書かんの？

>>121
ホワイトボードで十分じゃね

>>122
どうやら人員の異動の有無と規模が
考え方の違いの根っこかも、と思った。

ホワイトボードでごちゃごちゃやることもあるけど
写真とかで電子化して残してるわ。

>>122
そこで書いた内容を、別の日に別の人にも承認してもらう必要がなければ、
十分かもしれないけど・・・

組織だった設計ってのは、時間と人員が余るくらいないとなかなか難しい

業務系のような大きいシステムに関わってる人たちも
設計書を書かないことが多いのでしょうか？

ちょっと手をつけたら根本からしておかしかったとかよくあるもんね
まずは概要伝えてとりあえず形作ってもらって
そっから詳細はつめていく形にしないと正直時間の無駄

やってみなきゃわからないことなんてたくさんあるのに頭の中でそれをすべてやろうとするとか
どう考えても頭のいい行為じゃない
１円も稼いだこと無い奴が僕が２億を貯める計画を机上で綿密に練ってるのと大して変わらない成功率

詳細設計前にプロトタイプ作るのは
基本捨てるの前提だし実装じゃない

>>128
そんなもん作ったら、「それでいいから納品しろ」って言われて、ガクブルの日々が続くだけ。

>>129
そこを拒否出来ないプロジェクトはどうせロクなもん作れないから、
客か上司か、それ言った奴に要件変更に対する書面にハンコ押させて
自分以下の責任だけ回避して諦めろ。

それができたらいいんだが・・・俺はそろそろプログラマの処遇に耐えられないかもしれない
バグ無し＆気が利いたソフトじゃないと感謝されないばかりか給料もあがらない

電機業界はマジで糞だ

まぁ電機はクソだな。
大分ソフトの地位も向上したとは思うけど

>>109
随分と簡単な物しか作って無いんだなぁとしか思わないが、俺の視野が狭いのかな？

基本設計書がまともにできてないのに
詳細設計書を書かないで開発とかそれなんてNECソフト？

>>134
NECとかそこそこきっかり、しっかりしてそうなイメージだったのに
そういうレベルでの開発なんだ。

大きい企業でもそんなカンジの開発多いのかな？

工期短縮の為に設計工程を端折るんだけど、
結合試験の不具合の多さに納品時期を後ろに延ばす事になる。
そして終わりの無い不具合修正とエンバグ退治に追われる。
結局、工期は予定の倍以上になって、ゾンビプロジェクトとなる。

試験仕様書は、どんなテストしたかって事を纏めただけ。

NECソフトはひどいね！

こうやって真面目に議論している皆さんも、理・美容室に行くと「短く」とか「普通に」とか、曖昧な要求しか伝えないわけですが、嫌がらせですか？

2cm切ってって言ってるけど？

素人が行う細かい指示ほど有害なものはない。

「いつもの通りで」

お客様、今日がはじめてのご来店ですよね…？

実装詳細についてはお任せします。

詳細設計いらないからコメント書け

詳細設計に時間さくくらいなら、ソースレビューがっつりやった方がはるかに良いと思うんだがなぁ

コメントがないとさっぱりわからんようなソースはダメぽ。
コメントがあってもわからんソースはもっとダメぽ。

#define BIT31 0x80000000 /* MSB */
だってｗ

詳細設計がないとコーディング出来ません

客先に提供する目的のコードなら、幾ら外野が設計書なんていらねえって言っても、絶対聞くな。
客先が最後に求めるものは、設計書だからな。

基本設計書レベルじゃだいたい穴だらけだけど
コード書いてるうちにその穴がみえてくるわけだから
そのつど設計者に質問できる環境があればそれで十分なんだよな

俺は営業とか企画とか(に相当する)人に、作る商品の青図を描いて
とお願いしてるんだがいつも拒否される。

実装の人だけが考えてるとそいつらが他力本願になるから
そうお願いしてるのに、わかってくれないんだよなぁ・・・

>>5
ネオジ◯パンとかいう会社ではまだフローチャートを使ってた。てか俺も書かされた。
しかも上司がしたり顔でそれをレビューするんだぜ。もう死にたい。
ちなみに先月辞めて転職したよ。

/* 社長室でベッドを見て心が決まった… */

詳細設計書いても実装時にもっとよりよい設計が浮かぶ。
ハッキリ言って詳細設計は意味が無い。その通りに作って無いんだもん。
これって俺の設計能力が足りないだけなんだろうか？

検証したくても設計が終わるまで開発環境が入れられないとかね

何のための規約なんだよって感じ

>>153
自分で答え出してるじゃんw

>>155
君はいつも自分が作った詳細設計通りに実装してるの？
実装時によりよい方法浮かんだりしない？

>>156 気持ちはわかるけど、詳細設計で地固めしないと駄目
思いつきで作るとバグを生成する。

自分で書いてて、ものすごく耳が痛い

一人で作ってるならそれでもいいけどな
たいていは何十人もかけて作るんだから
実装段階で個人プレーは嫌われるだけ。

>>153
もし本当にそうなら、設計段階でそれを思いつけない自分を責めるべきで
違うもの作っててそこを咎められてないんだとしたら、プロジェクトの体勢
がおかしい。

両者を同列に話す必要はない。

基本設計は「穴だらけ」なのではなく、顧客の要望をまとめた「要件定義」が
機能別に分類されただけのもの。
それをどのように実現するのか？が書かれてあるのかが、詳細設計である。

その意味では「どこまで書くべきか？」という問題は職場によって様々だが
なにが書かれてなければいけないのか？という部分では指針として出てくる
ね。

俺のところは個人開発ばかりだが、まるで大規模開発のような責任を要求される
頭おかしい奴等ばかり

>>161
はあ？
大規模開発は一人当たりの責任は薄まってるから。
むしろ１人のほうが全責任背負ってて可哀想だとおもうぞ。

一人で開発してると、コンパイルエラーで吊し上げられないのがいい。

>>163
コンパイルエラーになるようなコードを書いて平気でいられるようならプログラマは
やめておいたほうがいいぞ。コンパイルエラーなんて文法通り書いていれば
簡単に潰せるわけだし。

他のやつが突然発生させた検査例外とか無理

>>164
マルチプラットフォームな開発だと、あるプラットフォーム向けの改修入れたら
他のプラットフォームでコンパイルできなくなったとかよくあるわけだが。

詳細設計要らんってヤツは、
基本設計の抽象的な状態から、
論理木で徐々に具体的にすることも出来んのだろうな。
特にクラス付きの言語なら全体で
どういう使用ケースがあるか把握してないから
継承ツリーやインターフェースを
何度も書き換えるんだろうな。

>>167
わかってねぇなぁ

まず、「こんなもの」っていう概要（メモ書き）だけ渡されるじゃん？
んで、自由に作るわけよ
したら、「ホイホイ、こんなもんできましたよ」って客に見せるわけな
したら、それ見た客が「あのさ、もうちょっとここなんとかなんない？」って意見するわけよ
したら、「ホイホイ」「あのさ」を繰り返してモノ作っていくわけよ
ほいで、客が「まあ、このぐらいでいいじゃろか」ってなったら開発終了なわけな

って流れだからいらねぇんだよ

>>168
うわぁ、それは単なるUIとか搭載している機能とかを顧客と打ち合わせてるだけだろ。

内部的にデータはどうなっていて、どう扱って、どういう順番で処理してるかとか
実装者以外誰も知らない状態じゃネエかｗ
たぶん機能も全容を知る者は実装者以外誰も完全には把握知てないと思われ。

>>169
開発終わってからドキュメント作るよ
ドキュメントの修正とか発生しないし
作る奴にはだいたい全貌わかってんだからこれでいいじゃん
あれこれ細かいことを作る前に決めなきゃいけないからへんなことになるんだよ

終わってからドキュメントを作るor修正すると言って、それが実行されることは
極めて稀である。

>>171
いや、やるよ
次の開発までの間とか大分間開いたりするし
評価期間中とかって暇な時間多かったりするじゃん

専門じゃない最低限のコンサルティングもないんだな。
PG以前に顧客商売としてどうかってレベルだな。

今時詳細設計してるところなんて無駄な工数かけてる馬鹿な連中だけだろ。
あんなもんいらん。金融とか知らんがね。

と思ったが、低レベルPGには必要かもな。

>>174
普通工数を減らす為にやるんだけどな。

>>175
工数は減らんよ。個々にネーミングされる工程数という意味ではな。
工程を計画的に行うんで、期間が短縮される。

詳細設計書をフォーマットどおりに書けば、
ソースコードを吐いてくれるようなシステムがあるんなら別だが、
詳細設計書いても工数は減らん

だなぁ。
詳細設計書コンパイルできて、自動テストにもかけられるようであれば事前に書く意味
あるかもしれないけど。

>>171
ドキュメント先行で進めながらも
ドキュメントと実装が乖離しないことのほうが
ずっと稀だと思う。

全く不要とは言わんけど
ガチでやる必要はないと思う

そもそも設計書って、他人(未来の自分)に見せるもの。
個々個人の成果物に対する、最低限のインターフェースを定義するもの。
だから、最低限各個人の成果物が不整合を起こさないレベルのものは必要。
ソースコードで十分と言うが、ソースは情報が多すぎる。
例えば、設計書に例外を出す過程を詳細に書く必要は無い。
どんな条件で入力されたら、どの例外を返さなきゃならないとか
その程度の情報は必要。
人によっては、例外にすべきものをNullで返すかも知れない。
逆に例外で返すべきじゃないものを
例外で返すかも知れない。
レビューで指摘できれば幸いだが、レビューに設計者全員が
いるとは限らない。
結果、どこかのタイミングで問題が発覚したら全て書き直す事になる。
現実問題、共有され始めたコードを直す訳にいかないので、
そのコードを利用するコードはその場しのぎのコードをちりばめる事になる。

詳細設計しないで実装なんて、おまいら趣味の学生サークルかよｗ
仕事でやってんだぞ、今から作ろうとする物の仔細なディティールまでキッチリデザインしろよ。
途中で事故に遭って仕事出られネエとか、最悪死んじゃうとか、
個人ではフォローできないアクシデントが発生しても、会社が最小限度のロスで済むようにな。

機能単位のインターフェースは詳細設計ではなく外部仕様書だの概要設計に書くから問題無し。
内部の細かい仕様なんて書くのは時間の無駄だし、ドキュメントとコードで同期がとれてる保障も無いから見ても無駄。
詳細設計見て内部の挙動を把握するくらいならコード見た方が正確だし速い。
つまり詳細設計は不要。

>>183
おまい、順番逆だぞｗ
まだ作ってる最中or未着手のプログラムに対して、コード読めば分かるとか、意味不明ｗ

コードなんて作ろうと思ったときにはもうできあがってるモンだろ(ｷﾘｯ)

プログラマって　魔法使い　もしくは　超能力者　だったんだｗ

動けばいいんだよ動けば。細かい事は気にするな。

>>186
確かに、素人からみるとそう思われるわな。

んなこたーない。プログラムが実は簡単な仕事だという事は随分前からばれてる。
だからプログラマの価値がどんどん下がってるわけで。

>>189
玉石混合って言葉があってな。
人当たりのいい石だけが残って
玉はつぶされていったのさ。
それが日本のIT業界さ。

製品レベルの品質保証できる宝石は高いから買われなくなった。
問題出ればネットでアップデータ配信すれば済むところはそっちにシフト

ソースコードは結果で
詳細設計書は「なんでこんな実装してるの？」という質問に対する答えが書かれてればよい

どう実装してるかなんてのはソース見ればわかる
なんでそんな機能を実装してるのかは
ソースみてもわからん

重複せず補完せよ

でも、詳細設計書出せって言って求められるのはどう実装するかなんだよな。

>>192
それはソフトウェア説明書だ。
設計書ってのは設計なんだから、作成する前にデザインするから意味があるんだろｗ

デザインなんて脳内完結するから書かなくてもいい
わざわざ書くのは二度手間

きっちり構造化して、各関数になにが目的かコメントしてあれば充分なはず。

詳細設計出せなんて言われるのは二次請け三次請けの連中だろうな

おまいらどんだけ小規模開発なんだよｗ

>>194
そんな建前で仕事してるから無駄だって言われるんだろｗ

>>199
同じプロジェクトに参加している別会社のプログラマに何を作ろうとしているのか説明するために作るのが詳細設計書
そこを無駄だとしたら、終わりの無い修正地獄が待っている。

仕様の実現手段の詳細に立ち入るのなら
自分のコーディング能力が実装者以上でなければ
実装者のパフォーマンスを制限することになるが
それはいいんだな？

>>201
何言ってんだよw
パフォーマンスが影響する場所なら、それこそキッチリ設計しないとダメだろ。

実装者のパフォーマンスって？　それなんて大道芸人？

だいたい設計書がないと何を正とするか判らないなんて言うけど
それは責任の世界であって純粋なシステムの話じゃないよね。

作りたい奴は作ればいい。俺は作らなくても問題無いから作らない。
と言ってもそんな事は個人の自由で決められる問題でもないが。
結局は会社の方針だな。

>>202
じゃあ実装内容を記述するにあたって
プログラム言語と同等の自由度で設計書を作りこめるの？

あとここでいうパフォーマンスは仕事の速さ上手さだろ常考

外部仕様がキッチリと資料化されていれば他社との間に問題は起きない。
何を作ろうとしているのか説明するために詳細設計書作るってどんなアマチュア相手だよｗ

>>205
意味不明ｗ
プログラマの気分で仕事が速いとか遅いとか、どんだけアマチュアだよｗ

>>206
I/Fも決めないで他社と仕事は出来ないだろｗ
モジュール内部コードを分業してるなら、もっと細かい仕様も必要だしな。

仕様書無しで分業したら、いつの間にか同じ意味の変数が３っつも出来たでござるの巻

誰が気分の話してるんだよｗ

俺のなかではI/Fも外部仕様のうちだ。勿論関数単位でI/Fは明確にしておく。もしや一般的にはこうは解釈しないのか。

>>208
それはおまいの把握能力の問題だろ。

詳細設計書レビューするくらいなら、実際のコードレビューした方がいい。

内部の動作なんてどうでもいい。外から見た挙動が明確なら他社との間に問題は起きない。

>>210
そこまで落とし込むなら実装してるのと変わらないだろ。
頭切り替えてプログラムもデザインの範疇だと認めたら？

>>211
いやいや、担当者の数だけ変数が出来たｗ

I/F決めるだけで実装してるのと変わらないなんて思わないな。
外から見た動作は単純明快でもそれを実現するために複雑な内部動作となるなんて事はいくらでもある。
だが、その複雑さを知る必要はない。

あ、あと、プログラムもデザインの範疇とか意味不明だからどうでもいい。

>>214
実装始めちゃうと、変更できないのよｗ
設計段階では幾らでも変更できるけどな。

>>218
いきなり細かい粒度で書くからでしょ。
なんでもそうだけど最初は粗く書けばいいんだよ。

>>218
実装済のコードに対してリファクタリングとかしないのか。

リファクタリングなんてまさに詳細設計能力の無い無能のためにあるようなもんだな。

>>220
なんで試験まで済ませた「動くコード」に手を加えないとならんの？
それこそ無駄だろ。　

設計書くのが無駄でなんでリファクタリングが無駄じゃないと思えるのか不思議だｗ

詳細設計書書こうが書くまいが、低レベルPGが作った物は糞だからね。
詳細設計書なんて無意味。

>>222
売り切りならともかく保守していくシステムなら当然じゃないの

低レベルPGは他人のソース読んで色んな実装手段を学ぶという事をしないから、ビックリするような糞ソースを量産する

だいたいウォーターフォール型のお役所仕事で
ビジネスの流れの速さについていけるのか？
如何に競争相手より速くサービスをリリースするかが
物を言う業界だってあるんだぜ。

>>224
保守していくシステムなら、なお更　リファクタリングなんて無駄な作業だろ。
動くんだぜそのコードで。　何を直すんだ？

>>226
うちはウォーターフォール型しかやらないから、
それ以外でどうやって作ってるのが是非見てみたい。
見積もりとかどうしてるの？仕様変更は？

>>226
先にリリースしても、不具合だらけで信用落としちゃ元も子もないけどな。

ちょっとした機能追加やパフォーマンス改善なんてよくあるからリファクタリングはするよ。まぁしたくないけどさ。

>>227
たとえば5000行のメソッドの合間を縫って
注意深く一行のコードを差し込む開発を続けるよりは
思い切ってメソッドを書き直したほうが
その後の開発が楽になるだろ。

確かにWebのサービスなんて速さ命って感じがするな

>>231
その5000行のメソッドのリファクタリングを行って、
同じ以上の手間をかけて単体テストするのに値するならやってもいいが
だいたいは自己満足なだけだろ？

>>232
でもって延々と改修工事ですかｗ

将来手を入れる時のために直すんだよ。
自己満足じゃなくて投資。

改修するはめになっても最初にサービス提供する事の方によって大きな利益をあげられるならそれでいいだろ。
裏でプログラマがどんな苦行を強いられてるかなんてどうでもいいわけだし。

>>227
このまま放置してれば保守しにくくなるだろうなぁってところを修正するんだよ。

>>233
単体テストくらい自動化しようよ。

つうか、どれも詳細設計が要らないって話の根拠になってない点

ぶっちゃけると面倒ってのが一番。しかも大した効果が無いときた。

久々に見たらすげー盛り上がっててワロタ

開発終わってからドキュメント作るって言う奴に限って
開発終わったら逃亡してドキュメントを作らない

>>240
コスパ悪いよね

改修の仕事なんだがベースとなってるもののドキュメントが整備されてないんで
改修部分のドキュメントだけつくっても意味がつたえられねー
こまった。

そんな下賎な仕事、誰も理解する気なんか無いから、無問題。

実装なんてどうでもいいんです。何言語でもアセンブラでもＢＡＳＩＣでも。

どんな機能が入ってるか、どんな動作をするのかを書きなさい。
入力と出力を明確にすることが大事。

>>242 つーか思うんだが、プログラマと仕様書書きが同じ人間ってのが理解できん。

プログラマに仕様書書かせたらフローチャート自動生成する馬鹿が出るだけ。

プログラマの９割は書類書きが仕事だろ。
そうでない奴らはみんな只の日雇い労働者だ。

>>246
そのやり方で済んでしまう仕事が多いのは確かだけど、
全てそれで片付くわけではないよ。

>>247
自動生成の何がいけないのかわからん。
手書きのほうがいいっていうこと？

>>250
使ってるツールの機能を最大限利用するとか、他のツールと組み合わせて
効率的かつのんびりやってるより、ツールに使われて一生懸命必死にやってる
奴の方が受けがいいということですよ。

君の低レベルな職場がデフォルトだと思わないように

リファクタリング否定してる奴はプログラマの才能ゼロ

詳細設計書を肯定する奴もプログラマの才能ゼロ

>>253
才能とか数値化できないものに頼ってる時点で組織じゃダメだろ。
個人で活躍するならそれでいいけど、時代を通じて品質を一定に以上保つ目的の会社じゃ不要な人物だ。

詳細の範囲を定義してください。

どういう意図でそういう設計をするか
それを記述することが詳細だよ。

何を作るか、どういうインプットアウトプットを作るかは
要件定義。

>>253
それ、俺も同意

ナルシスト？　自己に溺れるタイプ？

アマチュアからお仕事でプログラムに携わることになったが
設計書に関しては何を信じたらいいのかさっぱりわからぬ
自分は
１．一番最初に携わる箇所=要求仕様=IEEE830が規格として参考に出来る
２．要件定義(3に含むか？要求のうち、ソフトで対応する部分を決める)
３．上流の設計書=基本/概要/UI/構造設計書等場所によって種類も呼称もまちまち
４．詳細設計書=JavadocやDoxygenに相当するもの
な感じで捉えているが、2や3は何を信じればいい？

オブジェクト指向が一般的な今、
4のレベルには例えば「フローチャート」なものは含まれていないため
「※この変数を定義してこれをして」みたいなレベルは設計書には含まない
いわゆるインタフェースであるとか
この関数はこの入力に大してこの結果を返す、レベルまで
でなきゃ管理コストが高すぎる
(インタフェースですら変わりうるというのに)
※みたいなのを詳細設計書と呼ぶなら、1に同意する

実装をフローチャート化する以外は詳細設計にあらず
な職場でしか仕事したことない俺は詳細設計いらないと思ってる
一関数千行とか当たり前の世界だから関数単位のINOUT書いてもわけわかんなくなるし
詳細設計必要派が実際に書いてるものがどんなものか見てみたい

>一関数千行とか当たり前の世界
やな世界だな
作っていい関数の数に制限でもあんのか?

どうりで改行が変なはずだ。

>>1-1000
○○仕様書には□□を書く
なんてのは社によって違うから
なんの意味も無い話

この手の思考停止馬鹿は何も生み出さないばかりでなく、他人を批判する事しか出来ない池沼>>263

254
プログラマは才能が全てだろ。何言ってんだお前？

お前は雑魚PGたくさん集めて業務システムでも作ってろよ笑

>>265
反論になってないんだけど…大丈夫？作業員さん

>>266
まず、お前が才能を否定するならプログラマの能力を数値化する方法を教えてくれよ。
コードの行数とか言うなよ笑

俺は>>254でないし、反論になってない事を指摘しただけだよ。
何故俺が「プログラマの能力を数値化する方法」をレスしなければならないのか。
作業員さん興奮しちゃったのかな。

>>268
反論できないのお前じゃん…
雑魚が

じゃあレスしよう。俺は別に才能を否定しない。
そして、「プログラマの能力を数値化する方法」なんてものは存在しない。
んで、才能なんてものに頼る奴はアホ。

まぁ結局誰かの才能に頼らざるを得ないんだけどな。
それがプログラマかどうかは別として。

お前のレスなんの発展性も面白みもないな。

そういうわけの分からなものに頼るのは組織としてどうよって話し

末端の作業員さんには難しい話しかな

>>273
で、日本企業はお前みたいな普通の人ばっか集めたせいで技術力なくなったんじゃねえの？

今や韓国以下だぞ

なんか熱くなって関係無い話ししてるね。まぁ作業員さんの限界はこの辺かな。

自称「上流のエンジニア」ほど仕様書を残したがらない不思議ｗ
「分かり易い仕様書を書くと仕事を他社に奪われる」と言い訳してたのが印象的だった

人数集めて物作りするスタイルは
量は捌けても質が低くなると思う。
大量生産の弊害と同じことだね。

才能なんて言い方するから荒れるんだよ。
能力って言えよ。

少し複雑な制御条件でもスラスラとコードが書けるとか、そういう普通の能力は必要。
電子回路で言うところの論理合成が無意識にできたり、物事の単純化するのが上手だったり。

ここで才能って言っているのはハッカー級の人材ってことでしょ。

才能とかセンスって言葉で怒るのって、才能がない奴だけだろ

向いてないんだから他の仕事やれよ。営業とか管理とかな。
そして設計と開発に口をだすな

才能なんて数値化出来ないものに頼るのは組織としてどうなのかという話しなのに、
それを無視してあーだこーだと、本当にお前らは頭が悪いんだなぁ。

まぁスレ違いだが。

管理職としての視点が無い底辺作業員だから仕方ないのかな。
でもそういう視点を持って仕事しないと一生底辺作業員なんだぜ。

まぁスレ違いだが。

おまいらの言う数値化とやらは何の役にも立たん。
そんな数値化を有難がる組織なら無いほうが日本のためだよ。
マジで。

>>282
プログラムっていう数値化できないものを無理矢理数値化しようとすることがアホ

センスない

>>285
俺がいつ無理やり数値化しようとしたと言った？
妄想はやめてくれないか。てかアホは黙っておけと。

プログラムを数値化した結果が人月主義、ステップ主義
1Kステップあたりバグ数いくら
なんて馬鹿がまかり通る

そもそも「管理職」の視点でソフト作ろうていうのが間違いなんだけどね。
そうやって日本のソフトは世界で通用しなくなるのさ。

>>286
じゃあ、お前は何を数値化して何に頼って仕事すんの？

俺ぐらいになると全て感覚。数値に頼ってるようじゃまだまだ二流。

定量的評価はプロセス改善の第一歩なんだが。
まぁ否定するのを止めはせんが、世界として見ても
わりと一般的な考え方だ。

知識やノウハウが個人についてしまうと
会社としては困るんだよ

自分が社長になって社員雇ったとして考えてみ？

>>291
だから何を定量化すんだ？

詳細設計の作成と保守のコストはでかすぎるから不要。

プログラム作業のコストにきまってんだろ

>>292
技術は個人の物なんだからしょうがないだろ。
ソフトは本来属人的なものなんだ。

>>295
どうやって数値化すんの？

>>296 属人であってもいいが継承される必要がある
ワガママな人間に技術が宿ったら会社が死ぬ

>>297 まだどの会社も試行錯誤してるよね

数値化にむきになってる奴がいるな

ソフト以外は知らんが、ソフトに限って言えば我儘な人間に技術が宿るなんてのは組織が低レベルな証拠。

お前らってプラグラム能力高いだけで評価される職場にいるんだろうな

>>298
不可能なことを試行錯誤してるのがセンスないっていってんだよ

システム開発の見積もりだって結局はプログラマが経験から算出するしかないんだよ。
いい加減に理解しろ

才能とかセンスとかアホ丸出しだな。よく恥ずかしくないもんだ。

>>303
センスない人きたー笑
なんでこの業界入ったの？

才能だのセンスだの言ってるアホは、自分自身では能力高いと思ってるのに、
実際は評価されない事を不満に思ってるプログラマってところかな。

>>305
不満に思ってるプログラマはソーシャル系に転職する。
業務系なんざ糞食らえだ。

>>306
ソーシャル系ってどう違うの？業務系の土方だから参考までに教えて。

>>307
アイデアを自分で実装できない＝クズ

>>308
ごめん、何言ってるかわからない

こんな質問にも答えられない馬鹿だから評価されずに不満がたまるんだろうな…
馬鹿すぎてどこ行っても駄目だと思う。

>>293
そうさなぁ。
主に生産性と品質。

多くはプロセス面だけどそれを除いてプログラムそのもので言うとと、
複雑度やバグ収束曲線辺りが分かり易くてよく出て来るかな。

プロセス面だと、やっぱりわりとstepベースだったりする。
ドキュメント数、レビュー工数、指摘数、テスト項目数、バグ数とかの
step数ベースの比率。
言語毎に独立して取る。

stepベースで無い物だと、工程間の手戻り指数など。

この辺をベースに見積の生産性指標やリリースの品質指標を出したり
未成熟な工程を分析したりする。

しかし、技術が高い人ほどトータルコストが低くなるってのはいいんだけど
低い人は同じ事やっても倍以上の期間と賃金支払いが得られるってのも事実。

この辺の事を考えないと、技術の高い人は幾らでも経営者に搾取され続ける。

IT土方やってる限りそれは解決不可能だから、プログラマから脱すればいいんだよ。
プログラマしか出来ないなら我慢するしかない。

>>310
お前やっぱり業務系の土方だったのか。

俺もソーシャル系じゃないが、この前ベンチャーに転職した。前はsiで業務系やってたが、クソつまんなくてやめた。
てか、普通のプログラマならsiなんて見切りつけて辞めると思う。ひがやすお然り。

>>308が言ってるsiとの違いは、自分で考えたことを自分で実装できない奴はクズ扱いされるってことだろ。
Siじゃ実装できない奴が普通にでかい顔してるけど。

業務系で求められる技術って大した事無いからな。Fランや高卒のPGがゴロゴロいるし。
そんな技術身につけてもだから何という感じ。

だよな。業務系じゃMMD作れないもん。

MMDってなんだ？　ってぐぐったら、ミクミクダンスかよｗ
あんなんDirectXのサンプルレベルで製作可能だろ。
UIのアイディアだけ…と思うが、あの手のソフトではスタンダードなUIだな。

業務系ではサンプルレベルすら必要ないわけで

そうは言うけど業務系の俺がMMDを造ろうと思ったら
10年は掛かるよ

>>317
じゃあ何か作って見ろよ笑

>>320
だからその「何か」って部分が一番難しいんだろｗ
技術なんて幾ら持ってても、アイディアが無いからヒラリーマンやってんだ。

アイディアよりまずやるかやらないかだろ。
どうせ誰かがやってるから、とかじゃなく
まずやってみろってんだ。

MMDみたいに作者の湧き出るリビドーの洪水にドップリ浸かるくらいじゃないと、
個人レベルで何かを成し遂げるエネルギーにならネエなぁ

MMDは初期バージョンは70時間で組めたらしいから
相当天才だな
しかもアマチュアときた揉んだ

アマチュアの方が技術力あるのは全く珍しくない。

プログラマの技術(笑)なんてググるなりそこらで本買ってくれば簡単に身に付くもんだろ。
例え今は出来なくてもすぐに出来るようになるって時点で低レベル。
新しいサービスや価値観を提供して初めて評価される。
全くお前らは思考回路が雑魚だな。

提供ってより生み出すだな

MMDは3DCGのプラットフォームとなりつつある
すごすぎる。

スレタイの趣旨から外れていってますが

不要って事で結論出てるからなぁ

まともに作ってまともにレビューしてまともに保守してるとこ見た事ないけど、世の中にはそういう所も存在するの？

だから、詳細設計書は、実装前後では必要だけど、それ以降はまったく不要ってのは同意。
つうか、家の設計図だって、建てるまでは重要だけど、建てちまったらまったく無用だからな。

まったく無用ってことはないでしょ。

出来ちまったらソースが最新の詳細仕様だからさ。
メンテナンスされてない詳細設計書なんて誤解の元だろ。

だがな、製作途中では詳細設計書はいわば羅針盤で
何を実装するのかという事を各担当者同士で確認するのに絶対に必要。

>>334
>何を実装するのかという事を各担当者同士で確認するのに絶対に必要。

具体的にどう使うの？

何を実装するかは詳細設計には書かない。どう実装するかは書くが。

変更とかするときに詳細仕様がないと困るよね？

>>336
はあ？
おまい、ここはソート処理をやるとか、書かないの？
でもって入力は何何で、出力は何何ってやるんじゃねえの？
どう実装するかの方こそ無意味だろ。　バイナリソートかバブルソートかなんてTPOだし。

別に困らないなぁ。コードが全てだから。
詳細設計書の保守にかかるコストも無駄だし。

…ああ、バブルソートかバイナリソートかまでは書くな。たまに。

入出力は明確にするが、内部動作なんていちいち書かない。
機能単位、関数単位のI/Fが明確ならそれで良し。

「どう実装」というのは、いわゆる処理の流れみたいなもののことじゃないの？

>>341
だから、I/Fだけじゃ何も出来ないだろ。
その処理は何をする処理なのか、それは重要だぞ。
ある目的を果たす処理はどれか、を知らないと利用できねえよｗ

>>342
それこそ実装者が考えれば良い問題だろ。

>>343
入出力を明確にするって書いてるだろ。
それが分かれば利用出来る。

例えるなら.NETのヘルプみたいな感じで公開する関数レベルで外部仕様が明確なら何の問題も起きないが。

>>345
入出力条件だけで何をする処理か分かるのか？

>>347
ああ、ごめんごめん、処理概要は書くよ。

簡単な処理の流れくらい書いておかないと実装工程時に質問攻めにされるからねえ。

お前ら的にはビジネスロジックはどの仕様書に書くの？

ビジネスロジックを詳細設計に書くというのなら、そりゃー必要だな。業務固有のロジックなんてプログラマ知らんし。

運用マニュアルに書くんじゃね？

ふむ、詳細設計書は不要という事で一件落着だな。

>>353
だから、I/Fは書くんだろ？
それが詳細設計書じゃないのか？

一人月未満の案件であれば不要かもしれないね。

ビジネスロジックは別紙に記載してある。
機能単位、関数単位で、何をしたいのか明確になっている。

これで詳細設計無いと実装出来ないプログラマって存在価値あるの？

>>354
それを詳細設計と呼ぶなら俺は書いてるなｗ
内部動作なんてどうでもいいから書かないし、それを詳細設計と呼ぶと理解してた。

そうか、詳細設計って何？から始めないから駄目なのか。

別紙←笑うところ？

そういうどうでもいい所に突っ込むのやめようぜ。

詳細設計書の主な記載内容は、（実装時の）関数名と機能、（実装時の）引数名ととりうる値、あとは実装時に留意するポイントなど
モノによっては構造体の詳細（これも実装時の名称まで）や、構造体の関連図など。
って感じじゃね？

フローチャート書いて実装とほぼ一対一の詳細設計書も存在するけど…
書いてて発狂しそうになった。

具体的に処理内容まで書く事は少ないよ。
そこがキモである場合を除いて、大体は実装者に任せる。

>>361
組込み系ではそんな感じだねｗ
もうフローチャートレベルでデバッグまで可能みたいなｗ

いやいや「別紙」の内容がまさに詳細設計なんだが、
どうしても詳細設計と言いたくないのかねえと勘ぐってしまう。

お前ら上司やお客さんに言われていやいや書いてんだろ？

詳細設計書を喜んで書いてる奴を見たことない。必要ない書類なんだから当たり前だよな

>>364
俺の職場はそうではないってだけだよ。
俺んとこの詳細設計は>>361

そんなこと言ったら、すべての成果物は不要ってことになるが・・・

>>365
いや、詳細設計書無いと、チーム開発できないから書いてるよ。

>>366
おまいの会社の言うところの詳細設計書を、これからは実装詳細図と呼ぼう。

>>361 のところは詳細設計というよりもプログラム設計と言った方が正しいかも。

でもさ、プログラマって基本的に外注が多いから、品質にばらつき出るだろ。
>>361の詳細設計書かないで実装させて、パフォーマンスに問題出たら上司にしかられるんだぜ。
アホな実装する奴たまにいるから。

中国に出した時はマジ洒落にならんものが上がってきた

組み込み系は業務系よりも品質的にシビアだから、
フローチャートとかソースコードレベルの処理記載が必要なんだろうね。

詳細設計書って実装より時間掛かる

>>374
まあ、日本のプログラマの仕事の９割は書類作りだからな。

トヨタ式詳細設計だとint i = 0;だけで5行ぐらい必要になるし

>>371
設計書を書いてる時間があるならコード書けよ。
自分の仕事が非効率だと思わないの？

5行にならないｗ

1. 整数型 i を宣言する
2. 1で宣言した i に 0 を代入する

>>377
設計書はどうでもいいからとにかくソースを作れ作れ作れみたいな現場であればあんたの意見は正しいが、
世の中そういう現場ばかりじゃないのよ。

なるだろ。

１．整数型 i を宣言する。
２．整数型とは〜

余裕

自分の職場以外の環境を知らない奴らが何言っても無駄だけどな。

開発プロセス無視して作って問題起きたらヤバいからね。ある程度大きな会社はどこもそうでしょ。

逆に問題させ起きなければ陰で何しても良いと言えなくもないが

この流れ読んでると、プログラマは35歳くらいで辞めたいとマジ思う
疲れる

IT土方だとプログラマのキャリアなんて無いからね。さっさと辞めるが正解。

極端で一方的な人がいると、どうしても不毛な議論になりがち。仕方がないさ。

極端で一方的な人ほどお荷物なのが現実

>>380
ログとかしょーもない共通機能の設定だけで10行くらい飛びます

>>382
じゃあ一生同じように仕事してろ
業務系seは本当に救い様がない

>>389
職人面してドカタやってな

>>389 はコミュニケーション能力がない典型的な例だな。かわいそうに。

日本のITがいつまでもダメな理由がよくわかるな

日本のＩＴのどこが具体的にダメなんですか？

>>393
プログラミングという職人業を、
ただの労働者のルーチンワークだと勘違いしているところ。

コストパフォーマンス悪い奴らを切れない所だよ。

コストパフォーマンスが悪い奴らとは具体的にどういう人たちですか？

何も考えずに上司から命令された設計書を作り続ける奴

>>390
プログラマを土方とか言ってる人って、きっと業務系のコードしか書いたことないんだろうな

>>398
残念ながらメーカー系。

プログラマがドカタなんじゃなくて
開発プロセスを意識しない人がドカタ。

開発プロセス軽視してるのは人売りの底辺プログラマだろ。可哀想だから責めるな。

ウォーターフォール意識されても迷惑w

>>382
>開発プロセス無視して作って問題起きたらヤバいからね。

そうそう。
開発プロセスさえ守っておけば、
その成果がどんなに悲惨なものであっても
営業的には逃げられるからね。
そこ、重要なところだよ。

アジャイルでも開発プロセスはあるよ。念のため。

>>399
"メーカー系"って何？

もしかしてメーカーを作っているの？
「会社設立支援システム」みたいな感じ？

>>403
いや、そんなの当然だけどw
お前らウォーターフォールしか知らないくせに、開発プロセスとかドヤ顔で言ってるから笑えるんだよw

アジャイルを謳っている突貫工事もあるね。念のため。

どうせ突貫工事しかしないのに、開発プロセスとか言われても。

お前らってほんと糞会社で働いてるんだなぁ

>>407
そらお前が突貫工事しか出来ない会社に居るだけ

トヨタのKANBANとかがアジャイル界隈でもてはやされて逆輸入されてきて、
勘違いしたのがライン工と同レベルみたいな認識の管理職とがが増えたな。

保守運用やインフラあたりなら同じことの繰り返しで無駄（）笑をなくすとか
言って、各週での作業の詳細を洗い出してとか意味があるんだろうけどな。

開発はある期間、似たことはやっても同じことをやるわけでもないし、繰り返し
作業なんて保守運用と違ってほとんどやらないから、月初めは○○やって、
中旬くらいは××を、とか無いんだけどな。 個人の作業詳細を洗い出す以前に
やることあるっぺ？

http://itpro.nikkeibp.co.jp/article/COLUMN/20110221/357430/

ある意味真だけど極論だなぁ。
少なくとも「一人で」てのは無いわ。
ベンチャーなら良いけど。

一人で全部やるなら組織に所属してる意味がねぇ。

開発以外も一人で回すんかよ

>>404
メーカー系、ユーザー系、独立系、位は知っておかないと就職できないぞ。

>>412
＞ある意味真だけど極論だなぁ。
＞少なくとも「一人で」てのは無いわ。
＞ベンチャーなら良いけど。
全然極論じゃない。開発なら一人か二人でやるのが一番効率いいんだよ。

逆に、SIみたいに100人とかで開発するのは愚の骨頂だな。そんなことするから大量の設計書を書くハメになんだよ

>>415
多分、おちょくられてるんだと思うよ。お前。

>>415
>メーカー系、ユーザー系、独立系、位は知っておかないと就職できないぞ。

いや、俺は別に「偽装派遣の営業職」になんて
なりたくないんだけどなぁ

納期が無いならそりゃ一人でやるのが一番効率いいけどなあ

自己満足の仕事とプロの仕事は違う

プロの仕事ってのは納期と製品への責任を負うことだよ
技術のあるなしじゃない。
技術があっても納期を守らない、責任を負わないなら
そんなのはプロとは言わない

いや、報酬と労力のバランスが取れた仕事を勝ち取れるのが、プロ。
報酬に見合わないくそ仕事しか回ってこないのは　ゴミ

報酬ももらえないのに責任しょわされて脅されるのは　奴隷

>>420
だれに言ってんの？w

>>419
いくら一人でも期間が10年とかだと効率悪そうだけど。

>>420
そうなると「プロの研究者」と呼べるような人は
この世に一人としていなくなる訳で・・・

勿論、研究職も実績が大事なのは分るけど、
「納期を守ること」がプロの必須条件と言われると
「ちょっと違うんじゃないの？」って気がする。

別に研究職でなくたって、実際世の中には、
「出来るかどうかやってみなければ分らない」
仕事というのは山ほどある。
というかソフトウエア開発の仕事って、
多かれ少なかれそういう要素を必ず持っている。

そこら辺、どうよ？

なんで研究職が出てくるんだよ。ここはIT土方板だアホ。

人売り企業の使い捨てプログラマのお前らは責任なんて一切無いんだろうな

>>425
そうだな。

時たま、３行だけ読んで
脊髄反射で書き込まれたレスとかを見かけると、
つくづくそう思うよ。

>>416
最低2人は要る。
出来る奴一人でやってるとソイツが事故ると仕事が止まんのよ。
そういうリスクを無視してるから極論っつった。

スーパープログラマーが病気で倒れても
なんとかするために作るのが仕様書なんだよな

>>429
コード見て全て把握できる奴じゃないと、代わりは務まらないだろ。
てか、一流のプログラマは無駄なドキュメントなんか作らん。

ひとりで出来る程度の規模の仕事なら、始めからやり直しても大したことない。

それは一理あるかもしれない

で、お前ら詳細設計書いてるの？

>>431
会社としちゃ完全に無駄な出費だけどな

大抵の場合は詳細設計書書く工数が浮く。

機能設計書のバグがもっとも多く摘出されるのは、詳細設計書を作る作業である。

>>430
こういう事言う奴の仕事引き継いだ。
最悪だった。
何が正しいのか解らん。

個人的には優越感なんだろうが、会社にとっちゃあ凡人に引き継げない仕事を置いて行く奴の方が屑

詳細設計書にも金払ってくれるなら書く
それだけ

>>438
コードを全部追えば動きはわかるが、仕様が不明。
実装が仕様で経緯が不明じゃ、客から問い合わせがあったときに、それが意図した動きかどうかの判断が出来ない。
よって迅速に対応出来ず、無駄な時間を使い、会社として損失になる。

いくら凝ったプログラムほ書きかたができても、人に引き継げない仕事の仕方をしてる奴はプロじゃないと思う。

>>430
未来を正確に予知出来るなら、無駄なものを作らずにすむんだろうな。
まあ、そんなエスパーはいないわけで、無駄になるかも知れないが、保険的な
意味でも作っておいた方がいいときのが多い。

書き捨てのつもりで書いたコードが何年も生き残ってるなんて思ってもみないし、
それでもどっこい生き残ってる経験をしたことある奴は多いだろ？

学生の時に学校の勉強なんて何の役にも立たないと思っていて、今も変わらずに
いるか、あの時、もうちょっと真面目に勉強しておけばと思う奴の差だったりもする。

>>440
仕様が不明なのと詳細設計が無いのは別問題だな。
詳細設計だけはあるんだが、仕様が不明な引き継ぎなんて腐るほどある。

仕様不明設計不明　顧客激怒

お前らDRYって知ってる？少しは勉強した方がいいぞ。

詳細設計書作ってソースコードと二重管理するとかないからw
馬鹿のすることだぞ？

>>444
DRYよりラガーのほうがいいな

>>444
開発時には、レビュアの視点を意味的なところに集中させるために作る。
要求される品質と使えるコストが悪い時は作らなくて良いし、
極端な話、実装が終わったら破棄しても良い。

引継では、主にプログラムを俯瞰するための資料が要るんであって、
コード一行一行の全ての説明が要る訳じゃない。

まぁ詳細設計書に何書くか何てバラバラだな。
うちだとクラス図やコラボ図は詳細設計扱い。

さすがにプログラミングを低級な仕事だと蔑む馬鹿は居なくなったなｗ

別に適当に書いてもどうにかなるところまで
全部詳細に書くから無駄に感じるんだよな
そのあたりのさじ加減を見抜く力が必要なんだろうけど

プログラミングは低級な仕事だろ。所詮は末端作業員。

>>449
>>411

だから何としか言いようがないな。お前自信が末端作業員なのは変わらない。
そのうち工場労働者と大差無い扱いになるよ。

お前の仕事と一緒にするなｗ

まぁせいぜい現実逃避がんばれ。末端作業員君。

どこまでをプログラマと呼ぶかは、日本じゃ微妙なトコだの

仕様書と設計書をまぜこぜにしてるやつ多くね

逆に、仕様書と設計書を明確に分けようとする職場は、
大概、組織が硬直化しているものだよ。

上意下達が徹底しすぎていて、
下からの提案を吸い上げるなんてことは
絶対にしない。

>>449
お前が仕事で関わってるプログラムは、本当に誰でも書けるんだろうなー

お前がレベル低い仕事してるってのがよくわかった

>>449 がいう末端作業員の能力によってプロジェクトの成否が決まると言っても過言ではないのに。
ただし上流や中流が仕様不確定という汚物を下流に垂れ流さなければ、その限りではないが。

>>458
いや、それは違うだろう。
プログラマは末端作業員だろう。
ピラミッドスタイルの大規模開発に限っては。
プログラマ自身が創造的な仕事を選択しないといけない。

ごめん
末端作業員の能力によってプロジェクトの成否は決まらない
だね
なんせ末端だからね

ピラミッドに例えるならば、末端の土台がしっかりしていないとピラミッドなんて建てられないわ。
末端の土台を軽視しすぎてはいないか。

高卒でも十分に務まるんだから軽視されても仕方ない。簡単なお仕事なんですよ。

まぁその簡単なお仕事ですらマトモに出来ない奴がいるのは事実だが、そんなゴミの話しをしてもね。

なんか今だに上流気取って偉そうにしてる奴いるけど、クラウドが浸透してきたらお前らの仕事なくなるからねw

生き残るのは最上流のコンサルと優秀なプログラマだけ。SEとかいう意味わからん職業は無くなるよw

はは、じゃあお前ら生き残れないなｗ

いつになったらクラウドが浸透するの？

クラウド関連のビジネスは物凄い勢いで数字伸ばしてる。というかクラウド以外で伸びてるとこない。

オーダーメイドのエンタープライズアプリケーションの開発がある限り、
クラウドが浸透してもＳＥ（笑）は安泰だよｗ

今思えばPC事業売り払ってさっさとクラウド型サービスに移行したIBMとかマジぱねえ

企業向けのクラウドビジネスといえば、googleとかsalesforceしか思い浮かばないｗ

クラウドって名前がついてる粗悪品…

ウイルスバスター2011
http://bbs.kakaku.com/bbs/K0000148256/

データセンターにWebサーバ置いてサービス提供すればそれだけでクラウドって言えるからな

クラウドってのは最後は情報スパイに行き着くとおもってる
知らず知らずのうちに中国にデータサーバがあったとかワロえないことに

>>473
昨日の日経のトップ記事読めアホ。
世の中はお前のようなアホばかりじゃないぞ。

ハウジングの契約して、サーバ買って、サーバ管理は下にまかせて、開発するとか
クラウド使わなくてもいい身分になりてぇな

でもここってコーディングのこと話すとこじゃないの？

>>473
こういうの老害っていうんだよなw

クラウドは虚業。コーディングは実業。
googleの収入源はあくまで広告収入という事実。

>>468
だから、クラウドが浸透したらオーダーメイドが無くなるんだって。馬鹿

プログラマの視野の狭さがよく分かるな

クラウドは今までのパッケージソフトと変らんだろ。
カスタムするコトロがアウトソーシング可能だから競争相手が今までと違う層になるだけ。

クラウドいいぞ。　職場や自宅あっちこっちのPCから仕事を再開できる。

自宅で仕事再開出来るってどんな零細ですか

>>480
情報流出www

今時自宅で仕事してる馬鹿者に仕事発注なんて怖すぎて無理

情報流出を恐れて職場のネット禁止するのって日本以外でもあるのかな？
あれってアホすぎるよな

>>482
ネットつないでて大丈夫なんですか？

>>481
在宅勤務制度は大手でもそれなりに流行りものだと思う

大手ではそうせざるを得ない場合にするのであって、それが当たり前ではない

情報流出って言っても
PCから先は全部暗号化されてるから無問題。
機密保持契約があるから、流出した場合は自分（自社）の責任

でも流出元が特定できないから、もし事態が起こってもこういう環境が一番先に切られる。
調査の果てに依頼先が流出させていただけでもなぁ…

電気代ってばかにならんのよ。
これを削減するためには、自宅で仕事させるのが一番。

長期なら作業場所を確保するだけの土地家屋代（家賃）も節約できるｗ

コンプライアンスが流行すれば鍵を二重にし
インフルエンザが流行すればマスク着用を義務付ける
大手ってホント能無しだな

>>487
なんかワークライフバランスだか働き方の多様性だかそんな名目で、
最近はむしろ週一ぐらいの利用が推奨されてたりする。

なんのアピールなのか良く分からんよアレ。
労災対策？

「クラウドが浸透したらオーダーメイドが無くなる」の根拠と流れがわかりませんが、
「風が吹けば桶屋が儲かる」の途中過程を説明するように教えてください。

SIerが言うクラウドでコスト削減並みに良く判らない理屈なので無視して可

オーダーメイドは金も時間もかかるから、既に存在してるクラウドサービスを利用する方向に向かってる
クラウドは単なるバズワードではなく、本当に色んなサービスが次から次へと出てきているし、乗り換えてる企業も多い
とは言っても、オーダーメイドしてクラウドで利用ってのもまだまだ続くだろう

オーダーメイド喫茶

>>494
それってSaaSとか業務向けDSLとかそういう話だよね。
AWSとかGAEとかとは違うよね。

既に存在しているサービスをそのまま利用すればいいけど、
たいていはカスタマイズが発生するんだろ。カスタマイズは無料でやってくれるの？ｗ

どの企業でも必要な業務はどんどんクラウド化が進む
企業独自の基幹業務はオーダーメイドせざるを得ないが

クラウドのカスタムって言っても、UIを切り貼りとか既存の手続きを付け加えたり出来るだけだからなぁ…

業務を変える事によるコストよりもクラウド利用によるコスト削減の方が大きいと判断すれば
業務を変えてでもクラウド利用にはなるね
現場は必死に抵抗するだろうけども

パッケージソフトのカスタマイズで金と時間がかかるようなことを、
クラウドなら大丈夫ですなんてことは言えないわな。

良く考えたら、俺は業務アプリなんてエクセルだけで全部できると思ってる組み込み系の人間だったw

そりゃー昔なんてエクセルすら無かったんだから可能だろ。通信手段が確保されていればだけど。
でもそれだと非効率だからアプリ開発してるわけで。

Excelマクロで書かれた業務用アプリケーションをSky Drive上に配置したらクラウド化です（爆）

>>504
PaaSだ。
なんの問題も無い。

>>502
Excelで全部できるってのは間違いじゃないよ
汎用性が高いからね。
だけど、それは効率的にできるってことじゃない。

包丁はなんでも切れるけど、
皮むきならピーラーのほうが早くて効率的なのと一緒。

えー、詳細設計・・・コーディング・・・

あっ失礼しました

詳細設計は不要で結論出てるから

どこに？

俺の脳内に

機能単位、関数単位でI/Fと機能が明確ならそれ以上の細かい内部動作を示す資料は不要だと思う。
これに反論ある奴いる？

俺はない。その意見に完全同意。

設計とコードが綺麗なら要らない。
複数のフラグが絡み合う50以上の関数なら欲しい。
今そんなソースを引き継いで泣きそうになってる。

>>511
設計書をレビューするんなら、内部動作まで必要(コードレビューで代用できるけど)
四両として残すだけならIFだけでOK

同意。それ以上詳細でソースと同期が取れてる現場に当たったことがないオレ。
どーせそんなもんだこんな会社に来る仕事。

それどころかI/Fと機能だって、ソースのコメントさえもウソが書いてあるとこばっかだぜフハハハ

俺の仕事のパターンは大体機能仕様書もらって(コード書いて仕様書のミス・検討不足指摘して直させて)*テスト仕様書作ってテストして(仕様変更要求あってコード直して)*最後に詳細設計書起こして納品、って感じ。

詳細設計書を事前に完璧に作り上げる、なんていうのは予算が無限にあって堅牢性も極限まで追求されて万が一の時の責任を出来るだけ分散させる必要がある場合にしか現実的じゃないと思う。

>>517
その詳細設計書って誰か読んでるの？つーかハッキリ言うと意味ある？
納品物として必要というのではなく、活用されているという意味で必要なのだろうか。
と思ったがそんな事聞かれても分からんか。

うちは外注する時詳細設計書も出させるけど、誰もマトモに読んでない。

>>518
現時点では誰も読んでないな。
でももし俺がある日突然事故ったりして死んだら
その後に保守する事になった奴が読むんだと思う。

あ、*じゃなくて+だったorz

うちだと、ソフト要求仕様、アーキ設計、詳細設計、実装。
プロセス間スレッド間のシーケンスぐらいまでアーキ設計で、
その内部の状態遷移や共通APIなんかは詳細設計の範疇。

だから詳細設計書が結構デカくて、無いと困る。

>>522
お前、才能ないよ

>>522
共通API、って？
一般的には「API」っては「外からこういうことをされたらこう返しますよ」というルール、なので
それを定義するのは詳細設計の前だと思うんだけど。

>>522
無いと困るって、誰が困るの？
お前は設計書を書かないとコード書けないの？
それとも、他の人にコード書かせるとか効率悪いことやってんの？

>>525
他の人にコード書かせないと終わらない仕事なんて幾らでもあるぞ
つうかおまいの想像する開発規模ってどんだけ小さいんだよ。

視野の狭い自称優秀ＰＧ（笑）がいるね。

大きいことが良いことじゃないって言ってるじゃないの

>>524
俺は>522じゃないが、それは現場によるな。

どこからどこまでを区切るかってのはかなり現場ごとに差がある。下手するとプロジェクト
単位で変わってくるので一概には言えないが、それでも大抵の場合「機能」と「入出力」に
関することは基本設計（＝機能設計）、「実装」に関することは以降の詳細設計（プログラム
設計やI/F）という風に区切っておけばいいかと思う。

＃　たまに、基本設計で詳細レベルを求められるから詳細な二回低位の火分からなくなる
＃　現場もある。

んで、詳細なんて誰も見ないよってここで主張してる人は、けっこう小規模人数の開発では
ないかと思う。自分で書いて自分でコーディングしてテストして・・・という方式。
しかし、大規模になればなるほど、設計書を元にテスト項目を仕上げる場合が絶対と言って
いいほどなので、かなり重要になってくる。

・単体テスト＝詳細設計書に書かれているものを基に作成
・結合テスト＝基本設計（＝機能設計）書に書かれているものを基に作成

おおまかにいえば、以下のこういうＶ字型の感じでテスト工程と設計工程がむず美ついてる
現場ってのは、ある。

（基本設計）＼　　　　／（総合テスト≒本番テスト）
（Ｉ／Ｆ設計）　＼　　／　（結合テスト）
（詳細設計）　　＼／　　（単体テスト）

ふむ。日本でおｋな部分がｗ

>>529
> ＃　たまに、基本設計で詳細レベルを求められるから詳細な二回低位の火分からなくなる
> ＃　現場もある。

＃　たまに、基本設計で詳細レベルを求められるから詳細になに書いていいのか分からなくなる
＃　（書くものがない）現場もある。


> おおまかにいえば、以下のこういうＶ字型の感じでテスト工程と設計工程がむず美ついてる
> 現場ってのは、ある。

おおまかにいえば、以下のこういうＶ字型の感じでテスト工程と設計工程が結びついている
現場っていうのは、ある。

大体、設計書を数階層に分ける事自体が問題なんだよ。

設計書は設計書。

基本だの詳細だの、無駄に分類するから
おかしくなる。

だからひとりで作る規模ならどうでもいい話なんだから
おまいらの話はどうでもいいんだよｗ

大規模システム作って、それでいくら儲かるんだろ。
バブル建築と同じ匂いがするね。

>>531
設計書は設計書。

それはそうだが、人の思考プロセスからいってアバウト→詳細にっていうのは普通だろう。
それが資料として成り立っているのが各種設計書なのであって。

たとえば、君はレストランをやってたり勉めてたりしているとする。まず客から「肉料理が欲しい」
とアバウトな注文を受けて、「チキン南蛮」をいきなり出すとしたら、それはおかしい。

＃　君はまさにそう言うことを言っている。設計書がないということは客に明確に提示できてない
＃　のだから。どういうものなのかを。

たいていは「どのような種類の肉か？」「焼いて欲しいのか煮て欲しいのか」って尋ねるでしょ。
好みのものをこちらは出そうとするんだから。
んでもって、それら要望をちゃんと聞き分けて（たいていは通常のレシピにないものを頼まれる
店なので）レシピを構築して、調理する。

そのレシピが粗酒とウェアで言えば設計書だったり仕様書だったりするわけ。料理と開発、両者の
作業の違いを念頭にすれば、例えのうまくない部分は吸収できるかな？と思う。


ちなみに、チキン南蛮と書いたのは「うちは宮崎料理専門です」って看板出してるのにお客から
「名古屋コーチンくれ」と言われた感じの不幸なお店を暗に表現ｗ

文頭が全部「うちでは」になってしまった・・・
下記全部うちの部の話な。

>>524
共通APIと呼ばれてるのは、プロセス間通信とかログ出力とか
そういう複数のプロセスで統一化して利用するモジュールのI/F。

アーキ設計は大まかな構成までで、言語的な話は出て来ない。

>>525
外部I/Fの実装レベルな仕様は詳細設計時に決めるんで
担当者が変わるモジュール間のやり取りをする人が困る。
モジュールの外部I/F仕様書は詳細設計書のサブセット。

あと俺はある程度以上の規模になると
状態遷移表とか書いて整理しないと
自信持ってコード書けないな。
10×10ぐらいでもうダメだ。
まぁ才能はないのかもな。

最近はマ板にも変な外人が書きこむようになったのか？
日本語がひどすぎる上に、まともな例示にすらなってないんだが

>>534
別に問題を分割して考えること自体は否定しないよ。

分割する際、個別の問題の性質を考慮せず、
十把一絡げに"基本"だの"詳細"だの分割するやり方が
駄目なんだよ。

1本のソースコードの実装を2チームで分担する時、
奇数行の担当と偶数行の担当に振り分けようとするのと
同じ位に怪しげ。

>>537
「個別の問題の性質」て何のこと？

別に、本に例えれば、第１章が用件定義、第２章が設計概要、第３章が設計詳細、第４章がテスト
とかって感じで最後に１冊にまとめればいいと思うよ。

端的に、
「それをそのままプログラムにすればいい、って言うぐらい細かい詳細設計書をコーディングの前に書き上げろ」
っていうのは無駄、っていうところまではOK?>all
そこまですんならそれ日本語じゃなくてプログラム言語で書けばいいじゃんって話で。

>>540
会社や業種による　組込みの分野だと、コードと１対１そのままの詳細を要求される。　事もある。

IPAがなぁ・・・

>>526
いや、詳細設計書を書いてる時間があるなら、自分でコード書いたほうが絶対早いだろ。

お前プログラム書いたことある？

>>543
おいおい、そのコードを検査して合格出してって作業しないでISO取得できる企業なんて無いんだぞｗ

本当のこと言えばISOとか自体糞だろ。
金儲かればいいじゃん。

>>544
そんな作業なんかしなくたって、作業の記録さえあれば
ISO は取れますが、何か？

>>546
だからその記録を誰が作るんだって話だろ
つうか捏造かよｗ　終わってるな。

>>547
>終わってるな。

ああ。
ISO 自体が、な。

>>548
おまいの会社がだｗ
捏造した試験結果なんて提出して、そこで問題が発生したら損害賠償ものだろｗ

ISOとか馬鹿じゃねえの？
あんなの客からしたら何の意味もないだろw

>>549
>捏造した試験結果なんて提出して、そこで問題が発生したら損害賠償ものだろ

捏造していない試験結果を出しても、そこで問題が発生したら損害賠償ものですが、
何か？

っていうか、話の流れ的には >>549 は、自身が関わっているプロジェクトの
大きさを誇っているようだが、普通、規模が大きいプロジェクトというものは、
そんな詳細な記録の提出を求められることはない。
いや、あることはあるのだが、それは「紙の束」として求められるだけで、
いざ障害が発生した時も見直されることがない。
そんなのは他の資料の山に埋没してしまっているから意味が無い。
実際に行われる事といえば、その担当者を引きずり出して糾弾するだけだ。

蛇足だけど、一般的にこういう大きなプロジェクトの管理者は
極めて「おおざっぱ」な性格だったりするんだよな。
こういう所に >>548 みたいな人間を配置すると、
各人が些末な作業に追われてしまい
その結果プロジェクトは破綻するからね。

ISOよりCMMIのがまだ良いかなー

CMMIも当てにならん。愛知県岡崎市の図書館システムの事件がその例。

ってか監査系の資料なんて結局後付けで作るわけだから
コーディングには関係ないよな。

>>553
分野のノウハウであって、要件から漏れてたら
プロセスじゃどうしようも無いからなー

図書館システムの件は、要件漏れとかいう次元じゃなく、プログラマのスキルが原因だからな。

プロジェクトが成功するかどうかは、プログラマのスキルで決まるという、良い証明たよ。
設計書をせっせと作っても全く意味がないという証明でもある。

開発プロセスを重視して設計書書くと、各機能ごとの記述レベルを
均一にするためにコーディング時に見る必要ないような単純な機能の
設計書を作りに時間を浪費して、複雑で本当に重要な部分の設計書が
書ききれないことが多い。本末転倒…orz

下手にコードと一対一対応できるような詳細設計書書いてしまうと、
リファクタリングできないんだよな。
関数内部のフローをちょっと変えるのでも、設計書レベルで書きなおしてレビュー通さないと
いけなくなる。

>>558
だな。リファクタリング出来ないっていうデメリットはデカすぎる。
これに反論できる詳細設計書賛成論者いるの？

んー、なんだか詳細設計書＝機能処理記述書と勘違いしている方がいらっしゃるようで。
機能処理記述書は詳細設計書の一部であって、すべてではないよ。

>>558>>559
詳細設計書がどうというか。

過度に実績主義でリファクタリングさせて貰えないことが多い。
動いてる物は触るな、と。
それ前提でスケジュール作られるからリファクタリングしてる余裕もない。

詳細設計書をどこまで詳細に書くかなんて瑣末な問題だよ。
箇条書だけなら大した手までもない。
図示必須ならキレるかも知らんが。

>>559
それは「出来ない」ではなく「手間がかかる」だ。
反論としては「やるべき事はちゃんとやれ！」となる。

>>555
分野のノウハウ以前の問題で
三菱の奴等がコード読めてればそもそも起こらなかった事件。
そんな連中が語るプロセスなど何の役にも立たない。

>>562
自動テストでも細かくは書かないんだぜ
実装に依存するテストは寿命が短いからな

>>562
お前はセンスな(ry

だいたい「ちゃんとやれ」って言うほうは言い放しだが
実作業が回らなければ意味が無いだろ。

>>560
>機能処理記述書は詳細設計書の一部であって、すべてではないよ。

それは「それは本当の・・・じゃない」系の詭弁だね。
http://d.hatena.ne.jp/tt_clown/20060417/p1

裏を返せば「正しい詳細設計書」なる概念が
如何に"あやふや"なものであるかの証拠とも言える。

つーか今時、詳細設計書としてクラス名・メソッド名・引数・戻り値・処理手順（ソースコードと同等のレベル）を
実装前に完璧に記述するプロジェクトなんてあるのか？

せいぜい機能ごとの処理概要を書いて、クラス・メソッド設計は実装時にプログラマが考えてね
というくらいじゃない？

>>567
詳細設計書は企業やプロジェクトによって内容が違うからねえ。
ここまでの議論は、クラス名・メソッド名・引数・戻り値・処理手順（ソースコードと同等のレベル）を
実装前に文書化しますか？しませんか？ということだと認識している。

>>566
実作業が回らなくなれば、次は回るようにするために
しっかり設計してくるだろう。
何度かやらせても、一向に改善の兆しが見えなければ
その担当者を切ればよい。

完全にやれた試しが無い人物が出世して、部下に完全にやれと言っててワロタ
まぁ部下って俺なんだが

うちもISO取得してるけど、実態はグダグダだな。ぶっちゃけどこもそうなんじゃないの？

関数作るには面倒くさいレビューと承認が必要なおかげで
１０００行クラスの関数が平気で作られてた現場があったなー。

>>569
もし、上司がこいつだったら会社辞めるわw
馬鹿すぎて説得すんの不可能だし。

>>569
ちゃんと設計すると、昔の仕様を元に設計したコードを使い続けるより
今の仕様に合わせてリファクタリングした方がいいよねっていう事になるんだよねー。

クラス図とかを基本設計工程でPLが適当に作ったのが製造工程でも生きてて、
クラスやメソッドを一個追加するだけで承認が必要になる現場ならあったな。
もちろんそんなのは面倒なので適当にprivateメソッドやstaticメソッド大量のクソみたいなソースになってた
(privateメソッドやユーティリティ系クラスは承認がいらなかった)。

>>573
「クリーンルーム開発」って知っているか？

世間ではそれなりに評価されているらしいが、
やろうとしていることの本質は
>>569 と同じだと思う。

>>569
おまいのやり方ではコスト削減など望むべくも無い。
使えないIT担当てのは得てしてこんなものだ。

「クリーンルーム開発」てのは特許汚染を回避するための方法だろ？

>>572
デスマーチの予感しかしないわ。

>>558
それは１：１ってところがダメなんだと思うんだけどなぁ。

詳細設計が必要だと感じてる人は俺も含めてここにいるわけだが、別に１：１しか認めないと言うことを前提に書いてる
わけじゃないんでね。そこを不要派は勘違いしてる。
実現方式を書けって言っても内容の細かさにまで必要派が書かないのは、そこんとこはバランスだろって思ってるし、
場所やプロジェクトで様々なことを理解してるからだと思うよ。

>>578
そっちじゃない方。
http://ja.wikipedia.org/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%83%AB%E3%83%BC%E3%83%A0

>>579
そのとおり、デスマーチだったよｗ

納期がやばそうなんでドキュメントなんて後回しで、とにかく実装って事はまぁあるだろう。
んで、大事なのは、プロジェクト終了後に何故そうなったのか、今後そうならない為にどんな対策をうつか。
といった反省会みたいな事をチームでしっかり行って、意識を共有出来るかどうかだと思う。
中小零細はこういうのまずやらないから、過去の過ちを平気で繰り返す。

>>568
> つーか今時、詳細設計書としてクラス名・メソッド名・引数・戻り値・処理手順（ソースコードと同等のレベル）を
> 実装前に完璧に記述するプロジェクトなんてあるのか？

正直、それが（チーム単位でも会社単位でもいいが）外部向けでなければ要らんと思う。それこそ関数のヘッダ
にコメントで書けば済むレベルといえよう。

>>569 は受託開発とパッケージ開発のどちらのことを言っている？

中小零細だと話が来た時点で既に納期が過ぎていたなんてのは普通にあるわけで、
そんなの中小零細レベルで反省会やってもどうにもなんねーよ。

まぁ人売りしかやらないとこはそもそも反省会とか出来ないなｗ

>>583
> 納期がやばそうなんでドキュメントなんて後回しで、とにかく実装って事はまぁあるだろう。

あぁ、あるねぇあるある。一番問題なのは納期！なんだがそこはまぁ言わないでおくとしても
たしかにそういうのってないよな。＞反省会

終わって良かったお疲れさんで打ち上げするくらいか。大企業でも下に丸投げでそれだし、
下も目の前の悪夢が終わって次の悪夢を見る前のちょっとした安堵のの日々に目を奪われ
てるのかもねぇ。

PDCAが大事ってよく言われるだろ？お前らもPDCAサイクル回せよ。じゃないと何も変わらないぜ。

>>537
ごめんな。>>534だが、想定してるものがどういうものかよく分からんので
反応しようがない。

>>568
基本設計から関わってるようなプログラマなら細かなところは言わなくても把握してるだろうけど、
後から参加したプログラマの場合、そういうの知らないからどこかでレビューする必要があるわけで、
それが詳細設計書な場合は多い。

デスマーチＰＪって常識的に考えてあり得ないことが、
平然とルール化されてるから不思議だよな。
誰の為だかわからないルールがどんどん作られて
いつのまにか拡大解釈されていく。

誰かがミスしたら、再発防止策まで報告してルール化しないといけないから、ミスするたびに
くだらないルールが増える。

>>593
そのミスってどういうレベルのミス？

プロジェクト全体の予定工数よりも実質工数が少なかったためしがない。
なぜだろう。スケジュール立てる時に多めに時間とるのはそんなに難しい事なのだろうか。

>>591
そりゃ途中参画のプログラマにとっては、ソースコードレベルの設計書があれば楽だな。
だけど、自分が途中参画のプログラマだったとして、ソースコードレベルの設計書を見せられた日には、
「設計書としてそこまで書くくらいならソースコードを書けよバカ」と思うかもしれないｗ

>>594
どのレベルって言われても、ミスはミスでしかないんだが
影響範囲で言えば、他チームに及ぶようなものかな。

>>590
個々の問題（＝機能といえば分るか？）の性質に基づいた
設計書を書けばよい、という事。

例えば最初の分析によって、
分割された機能が通信関係ならシーケンス図、DB なら ER 図を作るとか。
一見あたりまえの事だが、ここで問題にしているのは、
それら多様な設計書に対して「基本設計書」とか「詳細設計書」などという
形式張った分類をしてしまうこと。

弊害の具体例？つい先ほどのレスにもあったよ。
>>557 とか。

よく「詳細設計書に何を書くべき」かで
議論の食い違いが発生するけど、それは当然の事。
だって、各システム（や、その開発を行う各組織）毎に
適切な設計書の形が違うから。

だから、いっそのことそれらをまとめて「設計書」といえば
済むんじゃないの？ というのが >>537 の主張。
所詮「基本」だの「詳細」だのなんて分類できないんだからさ。
そのプロジェクトに必要な「設計書」を作ればよい。

>>595
そんなの"難しい"に決まっているだろ？

銭カネの話に直結するんだぞ？

>>599
結局火を吹いて後から人員追加するから、一人ひとりの生産性低いよね。
後から大量に追加するくらいなら最初からもう少し多めに参加させて
長い期間プロジェクトに関わらせた方が生産性は高くなるだろうから、
正確な見積もりをした方がトータルコストは下がると思うけど。

まぁとにかく火を吹いてから人を大量投入ってのは本当に馬鹿げてる。
そいつら対して役に立たないし。

プロジェクトに余裕出たらPMの評価下がるのかと思うほど毎回余裕が無い。どう考えても意図的。

>>600
お前、お客さんに
「何でこんなに高いんですか？　他社の見積もりでは、
この金額の７割を提示してきていますよ？」
って言われた時、
「はい。我が社はリスクを考えて
多めに人員を投入していますから」
って言えるか？
（ま、その結果が自身の給料に響いてこない立場であれば
言えるのだろうけどな）

>>601
実際、PMの評価が下がるんじゃねえの？

>>602
大前提として、いつも決まった客から仕事貰ってるし、赤が出る事は滅多に無い。
見積もりで他社と競うなんて事は殆ど無い。

見積もりが厳しいからプロジェクトが火を吹いてるんじゃないんだよね。
多分、単純にPMがアホなんだと思う。

>>602
そこで「この金額だと上手くいかないだろう」
と予告して、その通りになれば
客もおまいの言うことを信用するようになる。

基本設計３ヶ月、機能設計３ヶ月、詳細設計１ヶ月　PG＝２日

実際のPG期間が短すぎるうちのPJ。

>>605
設計しすぎだね…

>>603
>大前提として、いつも決まった客から仕事貰ってるし、赤が出る事は滅多に無い。
>見積もりで他社と競うなんて事は殆ど無い。

じゃあ、こういうシチュエーションは？
「何でこんなに高いんですか？　以前、同じような仕事をお願いした時、
この金額の７割で受けてくれましたよね？」

>見積もりが厳しいからプロジェクトが火を吹いてるんじゃないんだよね。
>多分、単純にPMがアホなんだと思う。

いつも火を噴かせながらも、赤が出ていないんであれば、
実際そいつは優秀なPMだろ。

お前、そいつの手の中で踊らされているんだよ。

客の言いなりかよｗ

>>607
ぶっちゃけそれはよく分からん。客と金銭面の交渉した事無いし。

でも、終盤になるといつも火を吹いてて、後から人員投入しまくってる時点で優秀だとは思えないなぁ。
最初から必要な人員を揃えていれば、もっとコストは抑えられるし品質は上がると俺は思う。
あと、メンバーの精神面にも良い。これはとても大切。

滅多に無いとは言ったけど、たまーに大赤字が出る事はあるみたい。
俺が入社する前だけど。まぁそれはどこもそうだろうけどね。

管理職の中には「プログラマは厳しいスケジュールにして尻を叩かないと真面目に働かない」
と思ってる人が多いのではないかと最近思う。

なんか物凄く脱線したけど詳細設計ってメンドクサイよね

>>609
>あと、メンバーの精神面にも良い。これはとても大切。

その「大切」というのは「誰にとって大切」なのかを、
よーく考えてみろ。

お前にとってか？
プロジェクトメンバー全員にとってか？
それとも会社にとってか？

実際、プロジェクト途中でボロボロと人が抜けていったり、
自殺者が出たり、とかいう程ひどい状態ならば、
既にそのPMは降格されていると思うがな。

てか、スケジュール作るときバッファ取るのは基本だろ。
それは大手でも中小でも変わらん

>>612
俺自身、プロジェクトメンバー、会社、全てかな。
全ては生産性の為。うちのプロジェクトは生産性が低い。
開発の7割位は外注なんだけど、いつも短期間で大量の外注を使うという手法だからね。
もっと速い段階から外注を入れておけば火はふかないはず。

鬱になって2年位会社に来ない人とかいるよ。
つーか俺はその人に会った事が無いｗ
半年ほどで鬱から復帰した人は他の部署に逝ったｗ
こういうのが原因でPMが降格されたって事はない。

スケジュールにバッファを与えると必ずバッファも使ってしまうから、
バッファはプロジェクトマネージャが隠し持っている形になっていることが多い。

余裕があると拘る必要の無い所に拘って時間を無駄に使うプログラマは確かにいるからなぁ。
やっぱり厳しいスケジュールにして尻を叩くのが正解なのか。

客先に出張して仕様を詰めるはずのオッサンどもが
客先話し合ったことを全然資料にまとめずに
パワポのきたねー図だけ投げて「これが決まった要求仕様だ」
とかいうから俺の会社は終わってる

よく仕事できてるよな
謎だ

無いよりマシ

>>616
それはあるなー
ゲーム会社いたときに構築されたタスクシステム（業界用語、タスクではない）がいまでもトラウマだわ

仕事だ、やれ。

>>603
入社以来ずっと同じ顧客だけ担当して、
大きな失敗がなければＰＭがそのまま管理職になってくパターンだな。

プログラマに余計な時間を使わせたくないならば
プログラムを書かせる以外の事をやらせないことだ。
彼らはプログラムを書くこと以外で受けるストレスを
書かなくてもいいプログラムを書くことで消化する。

>>598
たぶん、そこまでいくと「設計に対するスタンス」ではなく、「設計書の分類法」になってくるな。


> それら多様な設計書に対して「基本設計書」とか「詳細設計書」などという
> 形式張った分類をしてしまうこと。

機能を書くのと、実装方法を書くのでは内容や目的がまるっきり違う。ので、そういう分け方を
するのはごく自然なことだと思うんだよね。

両者は段階としてまるっきり違う。若い頃は俺も徹底的にたたき込まれた。

設計といわれてプログラム主体でモノを頭に思い描く人ってぇのは、実は機能設計ができてない。
「実現したい業務・作業」を基に、どのようなシステムであればそれが救済されたり、簡素化される
のか・・・ってとこに主眼があり、それを書く。プログラム言語は頭にはない状態なわけです。


> よく「詳細設計書に何を書くべき」かで
> 議論の食い違いが発生するけど、それは当然の事。

そだね。そこについては何を書いたらいいかは現場によってもプロジェクトによっても会社によって
も範囲やレベルは変わってくると思うよ。


> だから、いっそのことそれらをまとめて「設計書」といえば
> 済むんじゃないの？ というのが >>537 の主張。

ただ単に設計書と言ってもいいけど、このスレでは詳細設計＝実装方法・手段についてのことに
ついての話だからな。いっそ、機能設計を省いて話した方がいいかもね。

>>623
なんか若い時に変な知識を叩き込まれちゃったまたいだね。

機能設計するにしても、プログラムでどういう風に実装するか考えとかないと駄目だろ。

シナにオフショアするときは詳細設計してやらないと
余裕でゴミみたいなソースを寄越してくるぜ
あの受け入れでファイル開いた時の阿鼻叫喚と言ったら無い

>>625
オフショア使うより自分で書いた方が早いと思わないのかな？

詳細設計するのは自分じゃなくて下請けだから関係なくね

オフショアしたのに効率悪かった→下請けのスキルがなかった→ウチは悪くない

>>626
625じゃないが、クソ安いからな。

会社の施策でまず使うって話になってて、教育も仕事の内に入ってる。
が、どうせ教育が終わったらもっと条件良いトコに取られる。

>>624
機能を決める時点で実装可能性を考えないといけない、のは同意だけど
(じゃないとwebアプリでボタン押すとローカルでCD焼く、みたいなトンデモ要求が出てくるw)

それと>>623が言ってることはちょっと違うと思うぞ

オフショア、特に海外のマに仕事させるときは「常識だろそんな事は」という概念は捨てること。
そうしないととんでもない羽目に合う

どっちか言うと日本の方がズレてる

オフショア大成功した例ってあるのかな。
どこかITニュースサイトとかにそんな記事あったら誰か教えて。

えこPシステムとかが成功例？

>>632
成功しなきゃダメだろ普通はｗ
そういう意味では失敗例はニュースになっても、成功例は噂にも載らないのが常識。

どんなに中身グチャグチャで受け入れの中の人がデスマっても、トータルコストが下がれば大成功

人件費の差分で儲けるっていうビジネスモデルが終わってる。
プログラマは絶対に考えつかない発想だ。くだらなすぎてw

>>636
そんな事言えるのは、自分自身が儲けのビジネスモデルを確立してる時だけじゃね？
そうでないのにそんな発言してるなら、ただの負け犬の遠吠えってやつ。

コスト削減のために生産拠点を途上国に移すなんてIT以外でも当たり前にやってるのに何言ってるのこいつ

>>635
コストにはイニシャルコストとランニングコストってのがあって、イニシャルコストが
どんなに安くても、ランニングコストを含めたらそれ以上になっちゃ意味ないんだよ。

いまだとファイナライズコストでも言えばいいのか、捨てるのにもコストがかかる
ようになったからさらに先を見越して考えなきゃならない。

>>638
ITなのにそんなことやってるから馬鹿なんだよ。
ITを建設業なんかと同一視してる馬鹿に言っても無駄だろうけど

>>640
>ITなのにそんなことやってるから馬鹿なんだよ。

理解出来ないな。これ、説明してくれる？
それで儲かってるなら何の問題も無いと俺は思うが。

ITは実は労働集約産業では無いからだろ？

>>641
プログラムの勉強すればわかると思うよ。
わからなかったら才能ないからあきらめろ。

>>643
説明出来ないなら煽るなアホ。

>>644
こんなこと説明しないとわかんない奴は既に終わってるんだよ。

なんでITきたんだ？

>>645
そういうのいいから>>641に答えてくれないか。
コスト削減の為に生産拠点を途上国に移すのは自然な流れであって、
それで儲けが出れば良しと俺は思っている。

ER図もない規約もない超大雑把な設計概要だけ見て
詳細なテーブルの結合条件を含んだ設計書を書かされるという今までの中で
トップレベル的に酷い現場に来た。
質問ありきで質問しなければ絶対に詳細がわからないとか糞すぎてバックレたくなる。
この業界はなんでこうなんだよ。わざとやってるようにしか思えんわ

>>647
SIが終わってるってのは、業界の常識だぞ。
早く転職の準備しろ。

>>646
コスト削減のやり方が間違ってる。
ITの目的は自動化によって人件費を削減することだろ？
オフショアで安い人件費でコストを削減するのは、テクノロジー企業のやり方じゃないよね。わかる？

>>647
逆に考えるんだ。
完全なドキュメントがあって、あとはそれを読むだけで作れるという世界なら、
国内プログラマの需要は無くなってしまうと。

設計概要から自分で納得のいくER図やテーブルを設計できるというのは、
大変かもしれないけどヤリガイのある仕事でウラヤマスイと
メンテしかやらせてもらえない漏れがテスト

>>649
反論になっていない。テクノロジー企業のやり方とか意味不明。
違法でも何でも無いし、オフショアでコスト削減が出来るのならそれで良し。

オフショアで具体的に何パーセントくらいコスト削減できてんの？

>>652
やっぱ終わってたな、お前。
オフショアの仕事にやりがい感じてんなら、せいぜい頑張ってくれ。

未来はないと思うけど

>>654
俺がいつオフショアの仕事にやりがいを感じてると言ってんだろう。
君は話しにならないね。

>>623
>両者は段階としてまるっきり違う。若い頃は俺も徹底的にたたき込まれた。

いや、違わないよ。明白な切れ目なんて無い。
分りやすい例を挙げると、非手続き型の言語による実装なんて、
場合によっては「機能だけ」を書いているように感じられる事があるだろ？

「若いときにたたき込まれた」から、違うように感じるだけだよ。
（・・・ちょっと嘘っぽいかな。逆に全ての設計書が離散的なのかもしれない）

イヌイットの人たちは、雪を表す言葉を１００種類以上もっていて、
彼らにとっては、それらの違いは自明なことらしい。
これと同じく、>>623 の育ってきた文化が
そう思わせているだけだよ。

>>656

横レス失礼する。
自分には>>623の「両者は段階としてまるっきり違う」は
きわめて常識的な事柄であると感じたよ。

>分りやすい例を挙げると、非手続き型の言語による実装なんて、
>場合によっては「機能だけ」を書いているように感じられる事があるだろ？

自分はPrologとHaskellを設計段階(プロトタイピングやシミュレーション)に使うけど、
そう感じる事は無いね。Prologの場合、純粋な述語論理で表現できるのは
コード全体でせいぜい２割程度にすぎない。(対象コードはファクトを除くルールに限定)
他は、非論理的な否定やカット、あるいは関数的なリスト処理、手続き的なI/Oで
占められる。Haskellについても同様で、更にエンティティやオブジェクトの関連を
モデル化するのに(Prologのように関連ではなく)いちいち関数として表現しなくては
ならないから、これは機能ではなく実装(アルゴリズムあるいは解法)にすぎないと感じる。

非手続き型言語を使えば使うほど、機能と実装のギャップの大きさを意識させられる。
機能とはユーザから見たモデルであり、実装とはアルゴリズム(あるいは解法)だと思う。

>>656
それは機能に「似せて」書いてあるからだ。
本来意味の無い命令の羅列が
人間にとって文章のように意味を持つのは
そういうトリックがあるから。

>>658
ム板のProlog宿題スレはその典型的な一例だな
彼らはそれで満足している様子だからあえて議論する気にはなれないが....

何か面倒臭い話してるな。

「このソフトはこんな事ができるようにしますよ」が機能仕様書で
「こんな事が出来るようにするために内側はこうしますよ」が詳細設計でしょ。
ユーザーが読んで得るものがある範囲が機能仕様書。
ユーザーが読んでも「何のこっちゃ意味わからんがまあうまくやってくれ」となる領域が詳細設計。

家建てるのに例えれば
間取り図面や建築予定図や内装イメージ図が機能仕様書。
部材一覧だとか作り付け家具の据え付けマニュアルだとか、釘の打ち方ノコギリの引きかたが詳細設計。

機能仕様書と詳細設計は密着してるけど、その間に境界線はある。

まぁ世の中にはUIデザインすることを設計と呼んでるところもあるからな。
そして、設計したからあとは誰でもできるよねと、新人に丸投げw

また家に例える馬鹿が出たよ

>>653
うまくいったケースで20%カットぐらいだった。
機能設計貰っての請け負いで結合テストまでのうち、
一部の詳細設計から単体テストまでと結合テストのオペレートを任せた。
単純に一人の値段が1/5ぐらいなんで、かなりオーバーヘッドがデカい印象。
もう少しこっちが使い方を学べば、まだ削れると思うけど、
今んとこ安定感がない。
転職とか引き抜きとかで人の入れ替わりが激しいのがキツい。
労働条件に魅力ないのか、日本以外の大手に流れちゃうっぽい。

>>1
同感〜。

エクセルでプログラム設計書を作成するんだが、
エクセルで楽な設計と、コードに落としたときに
楽な設計が違うんだよな。

エクセルの設計書だとオブジェクト指向も取り入
れるのが難しいし。

などと意味不明なこと言っており、関係者も苦慮しているとの報告も出ています。

>>657
>これは機能ではなく実装(アルゴリズムあるいは解法)にすぎないと感じる。
それは、ここでいう「残りの８割が存在する」という主張だろ？
こっちは「最初の２割が存在する」という事を主張している訳。

設計と実装との間にさえ、明確な切れ目なんてない。
まして「設計書」と呼ばれる一連の書類群においてをや。
（同じように「SEとPG の差」って話もあるね）

>非手続き型言語を使えば使うほど、機能と実装のギャップの大きさを意識させられる。
「へっ！ドシロートが戯言抜かしてやがる。
どうやったら機能の定義にカットが出てくるんだよ」とか
愚痴りたい（？）のかもしれないけど、別にこちらだって
非手続き型言語に幻想を抱いている訳じゃない。

・・・ところで RDB 関係の「詳細設計書」って、
どう書いているんだろ？ 見たことない。
SQL に直接落とし込める文章とか書いているのかな。

たしかに、コーディングしにくいから、
日本人マに仕事があるんだよな。
感謝すべきか。

１０００行のプログラムでも、設計書が糞過ぎて
問い合せても帰ってこないし、
そのかわりそれだけで１ヶ月以上給与もらってるよｗ

設計書がまともだったら
とっくに終わっていて、今頃次の仕事探し中だったぜ。

>>668
そんな仕事で楽しいか？
スキルも上がらんから将来苦労しそう

>>667
> ・・・ところで RDB 関係の「詳細設計書」って、
> どう書いているんだろ？ 見たことない。
> SQL に直接落とし込める文章とか書いているのかな。

具体的には何を想定していってるんだ？
チョコ右折落とし込める文章書くならSQLまんまでももういいだろ的に
感じるが。

なんだよチョコ右折って

すまね。直接、だ。寝る。

Sqlに設計書なんていらね。

世の中には詳細設計書に SQL をそのまま書かせる現場ってのがあってだな・・・

詳細設計なんだから普通だろ。

工エエェェ(´д｀)ェェエエ工
それやると改修コストが無駄にかかるから基本やらないようにしてんだが
といいつつ去年の今頃だったか、そんな設計書書かされる案件やってたなあ・・・

SQLを書いてやらないとシナ人が実装できないと泣きつくので仕方なく書かされた
あんな恥ずかしい設計書を書いたのは後にも先にもあのデスマ案件だけだわ

とおもったら今のデスマでも書かされそうです
IBMのオフショアはホンマ地獄やでえええ＞＜

お前らオフショアなんて非効率な仕事よくできるよなー

オフショアで選ぶ国として
成功と失敗を教えてくれ。

詳しいことは言えないが中国は失敗だった。
奴ら技術力無い。

まあ、国内と同じで会社によりけりだろうけどな。

>>679
お前らは技術力あんのか？
自社で作れバカ

中国にやらせるなら、設計部分もやらせないと意味なくね？

設計が５ヶ月、PG１週間、テスト２ヶ月で
PGの部分だけいくら安い中国でやっても全然やすくならんよ。

>>681
まず、そのスケジュールがおかしいことに気付こうw

オフショアの難しい所は、中国人は技術力をつけるとすぐにもっと良い会社に転職してしまう点にある。
前回うまくいったから今回また同じ会社使おうと思っても、その時に使った(成長した)技術者はもういない。

>>679
身近で聞く分には、インドは良いらしい。

>>683
そのとおり、ＰＧのエースクラスは１年後には半分も残ってない。
結果、新人が作った意味不明なコードが納品されてくる。

>>673
> 世の中には詳細設計書に SQL をそのまま書かせる現場ってのがあってだな・・・

俺も今そういう職場で働いてるぜ。

大概は機能設計書も詳細設計書もゴミ。

毎回のごとく
「こういう設計書が回ってきてるんですが、本当にこういうことがやりたいんですか？」
って現場や上位へのヒアリングからやり直すはめになる。

コードを日本語で書いたような詳細設計を見るたびバカかと思う
メンテしきれずに乖離してるし追加開発時にも同じ物を要求されるので足枷にしかならん

ぴゅう太BASIC使いの漏れはコードを日本語で書いてるけどなｗ

>>685
大丈夫、中国人に限った話じゃない

>>688
バカだろ稾

>>685
じゃあお前がコードかけよ

それだとオフショアにならねぇｗ

上司が書いた(デバッグしてない)糞コードを詳細設計代わりにして
コーディングするのが苦痛でならない

丸投げするならはじめっから俺にやらせろ

>>693
一回、要件定義書を書き起こせよｗ

そういうのに限って時間の無駄とか言い出すんだよｗ

そんな糞企業に勤めてる時点で本人も糞だろ。
自社の開発プロセス見直すか、そこよりマトモな企業に転職するかしろよ。
まぁそれが出来るならここで愚痴ってないだろうが。

「こんな糞コード書く人に言われるのは心外です。」
って言ってあげればｗ

正常系が動いてればほとんど完成と思ってる人だからさ
仕様書の重要性がわかってないんだよね

え？　UI部分や通信部分でもない限り正常系だけで十分だろ。

定義が違うのかもしれんが、正常系だけだとよくて50%くらいじゃないかな

とんでもないアホか、正常系に対する認識の違いだろうな。
俺はどんなシステムであっても正常系だけで十分とは全く思えないが。

べつに結合以降絶対に来ない値なんて試験しても無駄だしな。

値のチェックは正常系の範囲内でしょ

どの範囲を正常動作の範囲かという話だと意見も別れよう。画面作ってる人と
裏方のバッチとかサーバ側オンラインでも違うしね。

たとえば、日付を扱う処理でも、UIで用いる場合は１〜３１以外でも正しくエラーを返すことが求められるので正常系の範囲。
でも、内部処理中は、呼び出す側で既に１〜３１の範囲内になっているはずなので、範囲外は異常系。

手動スタックをコレクションクラスのスタックに置き換えたら「なんでそんなことするの？」と怒られました。
こっちのセリフだ文句いうなら自分でやれよクソガー

手動スタックとは
push、popメソッドがあるわけではなく、クライアントが自分でインデックスを操作して
ただの配列をスタックのように振舞わせる抽象化なにそれ機構。
はらわたが飛び散ってて大変保守しにくい

pushとpopがないスタックって・・・

問題だと認識してるなら何とかしろよ。
実装するまでの工程がグダグダで実装時になんとかするって
低レベルすぎて恥ずかしく無いのかね。
まぁ意識の低い末端作業員にそんな事言っても仕方ないかもしれんが。

動けばいいんだよ。細かい事は気にするな。

正論吐いてりゃそれで済む世界に住んでる人は楽そうでいいね

原発事故の後処理もグダグダで今に至る。
日本人の管理なんてそんな程度。

言語仕様もなく、解釈も曖昧な、独自構文でいきなりコーディングする。

それが、詳細設計。

人為ミスを防ぐコンパイラの恩恵を受けることも出来ず。あらたなオレオレ文法を学ぶオーバーヘッドも追加発生する。

詳細設計を書く自称設計者は、自分の書いた設計書を、どうコードに落とし込むか理解していない。だってコードを書く能力がない落第者が見栄張って設計者と名乗っているだけだから。

それが、詳細設計。

>>712
それはお前の環境が劣悪なのが問題

まぁ詳細設計書くときも補完機能が欲しいよな。

>>713
良質な環境だと、どんななのかkwsk

>>715

713 じゃないけど、良質な環境だとコーディングが限りなく詳細設計に重なる

またまたまたご冗談をｗ
設計とコーディングが重なっちゃうなんてデスマフラグ立ってるじゃねえかｗ

あ、表現が悪かったかな？
俺が言いたいのは >>2

詳細設計＝日本語プログラミング？

　多分、詳細設計書とソフトウェアドキュメントを混同している輩がちらほらといるな。
　前者はプログラム組む前に、妥当性を検討するなど文字通り設計の用途に用いて、プログラム製作後はテスト仕様書などを起こすくらいで不要な物
　後者はプログラムがどのような概念で実装されているかを言葉や図表で理解できるように作成するもの。こちらはプログラムが動いている限りプログラムコードと共にメンテナンス

詳細設計書から単体テスト項目を起こすとしたら
mallocがNULL返したときの挙動も書かないと
これのテストを通さないことになる

仕様書に書かないならソースコードから
単体テスト項目を起こさざるを得ない

うちではエラー処理はコーダーにまかせて単体テスト項目も
ソースコードから起こしてるけど普通はどうするもんなんだろう

>>720
概念は非常に同意だが

詳細設計書とソフトウェアドキュメントって名称の定義が
それっていうのはあまり一般的とは思えない

したがって混同している輩呼ばわりはいささか理不尽な感じがする

同じく概念同意 >>720

でも、詳細設計→テスト仕様に起こすのって、
そのためにコーディング中も詳細設計を随時更新
することになって、すごい手間かけてたりしません？

詳細設計に色々書きすぎて破綻してるのかなぁ。
関数仕様一覧とか、ｲﾗﾈ気がする。。

単体試験は、C1でブレークポイント入れて、
変な動きしないか見てた気がする。改修だけど。

>>721
mallocがNULLを返した時ってつまりメモリ不足時の挙動だと思うけど、
それが仕様書に書いてないってことは、そもそもテストする必要はないんじゃね？
仕様書に書いてないってことは、そういう状況は想定外ってことでしょ？

仕様書に書いてないと、プログラマによってそのままスルーする奴、エラー出力する奴、
ログに残す奴、assertする奴、例外出す奴、いろいろいるかもしれないのに、一体
それらの何を正解として、テストするつもり？

そういう一般項目はまとめて別紙に記述するもんだろ。

別紙に書こうが、それはつまり仕様書ってことだろ。
共通仕様も個別仕様も仕様は仕様。仕様に書いてあれば
テストは出来る。
仕様に書いてないことはテストしようがない。なぜなら正解
がわからないから。

>>724
理想はそうなんだけど現実でそういう運用は難しいんではないかと
なので他の現場ではどのへんを落としどころとしてるのかを知りたいです
詳細設計にそこまで細かいこと書くのは大変だしコーダーからも不評だし

むしろ仕様書に明記してないことをどうやってテストしてるのか知りたいわ

>>728
やるとしたらソースコードからやるしか思いつかない

俺個人の意見はそこの実装はコーダーに任せてテストしないでいい
なんだけど、こんなのが受け入れられるとは思ってない

>>728さんのところでは仕様書にキッチリと書くなんだね

クライアントならともかくサーバー用のアプリなら
メモリ不足の時のエラー処理は設計書に書かれてることが多いなぁ

そりゃ要件として必要なことはきっちり書くよ。
だって書いてなきゃ、それが実装されてないことの責任を誰がもつの？　
どうやって品質を担保するの？

ソースに書いてあることをもとにやるテストに意味なんてあるの？
ソースに書いてあるんだから、テストやる必要なくね？
それで設計工程が短縮されたとしても、結局は遠回りだと思うけど。

設計者が果たすべき責任をプログラマに押しつけてるようにしか
思えない。

>>726
一見正しいことが書かれている。
でも、テスト畑の人達はもっと別のこと言ってなかったかなあ

・高負荷時やメモリが逼迫している状況でもプログラムが落ちないこと。
・システムエラーや例外が発生した場合は、ユーザにその旨を通知するとともに、
　内容をログに出力し、管理者宛てにメールを送信すること。

みたいなことを共通仕様書に書いておくだけで、いくらでもマの責任を追及できる。

>>727
どこまで詳細設計に書くかって問題はあるけど、
メモリ確保できないケースを書き漏らすのはありえない。

＞・高負荷時"や"メモリが逼迫している状況で"も"

なにこの無限責任

>>735
そこは無限ってほどでもないだろ。
突然CPU100%食い始める常駐ソフトなんていくらでもあるじゃない。.net Frameworkとかウィルスソフトとか

このスレ初めて見たけど、開発現場によるようなことでも、さも一般的かのように主張してるやつ多すぎるｗ

>>737
kwsk

>>737
しかたないよ。たいていの人は自分の環境しか知らないんだから。

メモリ確保できない場合の動作保証って出来るの？
メモリ確保できないって異常事態だしハード・運用よりの不具合でない？

メモリ確保できない場合
ってのがどういうことなのかを考えないと

載ってるハードによるだろw
携帯アプリなら自アプリだけ終了
OS無しとか単純な完全独立ソフトならシステム異常
PCならもういちどトライしてみそとかw

>>740
メモリ足りなくても、データぶっ壊さずに終了するとか。

ハッカソンとかでアドリブでアプリをガシガシ作る時代に
詳細設計って…プｗ

バグがあったらアップデートすりゃすむならそうすれば良いし、
そうでないなら堅く作らにゃダメって話で、時代は別に関係ない。

インフラが整ってアップデートが簡単になった分野が増えただけ。

メモリ確保できないのがどうしてハード・運用よりの問題なんだよ。
プロセスが増えて、ヒープが枯渇すれば、メモリ確保できなくなるだろが。
普通のアプリだって、画像編集ソフトなんかで、がしがし画像を開いていけば
そのうちメモリ不足になる。そん時にいきなりアプリが落ちたんじゃ、糞ソフトの
レッテルを貼られることになる。完全にアプリ側の問題。

fxやchromeも、タブを開きまくったら落ちるから糞ソフト

それは、お前が入れてる糞エクステンションのせい

>>746は、この世にはパソコンアプリや携帯アプリしか無いと思ってる情弱w

>>749
kwsk

>>748
Fxは起動してるだけで実メモリ以上のメモリを使うからほんと迷惑してたけど、
Webサイトによってはそうでもなかったりする。

しかし、シンプルなページに見えてもなぜかメモリを食ってるWebサイトが多い。

Fxって何？　FireFoxのこと？　巷じゃFxって言うの？

>Firefox のスペルは? 短縮形は?
> Firefox のスペルは最初の F だけが大文字になります (FireFox は間違いです)。好ましい短縮形は「Fx」か「fx」です。

http://mozilla.jp/firefox/1.5.0.12/releasenotes/#FAQ

web系の奴らに設計とか、馬の耳に念仏だろｗ

>>751
∨
[[[[[[[[[[[[ Fxは起動してるだけで実メモリ以上のメモリを使うからほんと迷惑してたけど、 ]]]]]]]]]]]]（きリッッッッ!!!キリッッ!!キリッッきリッッッ
∨∨∨∨
[[[[[[[[[[[[ Webサイトによってはそうでもなかったりする。 ]]]]]]]]]]]](キリッ！キリッッッ!!!!キリッッッッキリ！！！！キリッッッ!!!!ッッッッ！
∧∧∧∧∧（キリ
∨
[[[[[[[[[[[[[ しかし、シンプルなページに見えてもなぜかメモリを食ってるWebサイトが多い。 ]]]]]]]]]]]]](キリッッッキリッ！！ッ

ゴミじゃねーか

ホントお前キモいわ

天使とuyは同一人物なのか？
はたまた糞ビと同一なのか

http://hibari.2ch.net/test/read.cgi/news4vip/1310186887/l50

駄スレを埋め立てようぜ

天使ちゃんマジ基地

通常4ヵ月かかっていたプロセスを、3週間で完了させられた
通常4ヵ月かかっていたプロセスを、3週間で完了させられた
通常4ヵ月かかっていたプロセスを、3週間で完了させられた

　モデルベース開発というアプローチとMathWorksのツールを利用することで、開発のスピード
と製品の品質が向上し、通常4ヵ月かかっていたプロセスを、3週間で完了させられた。
MathWorksのツールでモデルベース開発を進めることで、最終的なハードウェアを使用した
テストではなく、要求仕様や初期の設計で問題点を特定し、早い段階で解決できた。また、
モデルベース開発を採用したことで、デザインレビューのスピードが上がり、欠陥や要求仕様
の問題点の発見をより効率的に行なえた。エラーを早期に発見し、やりなおし作業を減らす
ことで、高品質のコントローラを以前の2割の時間で完成させられた。
http://www.keyman.or.jp/3w/prd/92/20033192/

　キ　ー　ボ　ー　ド　叩　い　て　銭　が　稼　げ　る　時　代　は　終　わ　っ　た

で？
お前の経験談で語れよ

詳細設計ないと基本設計できないでしょ
基本設計ないと要件定義できないでしょ
要件定義ないと見積もりできないでしょ
見積もりないと開発やるかどうか決定できないでしょ

コーディングは詳細設計なんか無視してやればいいよ
基本設計終われば、もう詳細設計なんか誰も見ないし

>>762
なんかかなり順番逆だぞｗ

>>762
一体何が始まったんだｗ

ウォータークライムモデルか

ヒルクライムでよくね。納期直前に初めてすべての見積りが確定する。

これ実現できたら最高じゃないか…

詳細設計ってなんぞ…

言羊糸田言殳言十

>>769
知ってるぞ！
それ機能細分化ってんだろ？

細分化されてるような気がするな
言は共通してるからひとつの関数に統合できるぞ

十殳田羊糸言3

同僚は、思い付くままにコーディングしているけど、同僚のコードは読みにくい

ひょっとして、そいつがきちんと設計しても、読みにくいコードしか書けないんじゃないの？

まともなコード見たことない人でしょ

一人で小さいものしか書いたことないんでしょ

内部・詳細における設計というものは、本来、抽象化をより進めるための過程の資料にはず。設計を揉みに揉んで実際のコーディング量をとにかく減らす。それが出来無きゃ設計じゃない。

プログラムの仕様書は入力と出力が何で何をしているかがはっきり分かればいい。
詳細仕様書は有害無益
他人のプログラムのメンテはソースを追うしかないんだよ。

> 他人のプログラムのメンテはソースを追うしかないんだよ。

まともな設計がないからそうなる。
設計と言いつつ、要件定義と画面イメージだったりする奴とかな。

まあ、それも設計のうちといえばそうなんだが、
俺が言ってるのはアプリケーション土台の設計。
要件定義も画面も参考程度にあるだけでいい。
これらの機能を実装できる設計を考えるための参考として使うだけだから。

あとは何のフレームワークを使って、どういうコーディングスタイルで、
こんな場合はここにコードを書くと決めたり、使用するライブラリを整備してと、
各機能を実装するための共通の基盤それが俺が言ってる設計

この設計がちゃんとできていれば、ソースを見なくても「あそこにある」とわかるようになる。

>>779
ソース見ずにメンテ出来るのかｗ

設計と実装の剥離が激しいと、両方ともまともでもどうしたものかと思うけどな。

設計では、状態ごとにイベントに応じた処理が書いてあるのに、
実装ではイベントごとに状態に応じたコードがかかれていたりすると
こいつの頭はどうなってるんだろうか？と思うことがある。

>>780
誰がそんな事いった？

>>782

>>779が言ってるだろ
>まともな設計がないからそうなる。

>>783

>まともな設計がないからそうなる。

↓

> ソース見ずにメンテ出来るのかｗ

どうすながるのかさっぱりわからん。

>>784

>>778
>他人のプログラムのメンテはソースを追うしかないんだよ。

>>779
>まともな設計がないからそうなる。

つまりまともな設計があれば他人のプログラムのメンテはソースを追わなくてもいいわけだろ？

ソースを追うとソースを見るの違い
わかってないの？

結局はソースを追わないと何やらかしてるか分からねえよな。

まともな設計ができてれば
コードを追わなくてもどこになにが書いてあるか
どこを修正すればいいかがわかるよ。

というか、そういうことがわかるように設計すんの。
コードを追うのは、ソフトウェア開発で
時間がかかる所の一つだからね。
無駄はとことんなくさないといけない。

この業界、他人に設計書求める前に、てめえが設計書ちゃんと書けよって話だけどな。

>>788
あんた甘すぎるよ
バグってのはほんの些細な間違いでも起こる。
こういうのはソースに当たるしかない。

>>786
ここで言うソースを見るというのはソースを追うって言う意味
文脈から判断しろ

だってプログラムって、設計者の思惑通り動くんじゃなくて、書かれたコードの通りに動くんだもん。
設計書がどんなに立派に整備されて、どんなにそれに忠実にコードを起こしても、
それでも混入するBUGは設計書からは見つけられないのさｗ

テストだけで途方に暮れる汎用機向けの仕様だとは思うがなぁ

> だってプログラムって、設計者の思惑通り動くんじゃなくて、書かれたコードの通りに動くんだもん。

なんで、設計者の思惑の次が、動作になるんだろうな。

設計者の思惑の次は、思惑通りにコードを書いているか、その後にコードが思惑通りに動いているかだろ。
間を一つ飛ばすから、ちゃんとした設計したのに、コードがめちゃくちゃってことになるんだろう。

コードにバグがあっても、それが設計で想定した通りの場所に書いてあれば
修正は容易なんだよ。バグのあるコードよりも厄介なのは、
コードが正しい場所に書かれていないことだ。

>>794
>コードが正しい場所に書かれていないことだ。

だからコードを見ないとそれを確かめられないだろ
頭痛くなるなｗ

よく分からないから3行で説明して

ってのを徹底出来ないと、ソース読んだほうが早い

ソースコードは設計書の一形態であるというのに

>>797
そんなもん文脈によるだろ

ていうか、「ソースが設計書(ｷﾘｯ」派の人たちって、プログラミングと製造業は違うとか言いながらも
設計やら製造やらの言葉の定義を製造業のアナロジーで語っちゃうダブスタ馬鹿ばかり

>>794
おまいは２行目以降を無視して勝手な講釈繰り広げるな馬鹿ｗ
どんなに設計書に忠実にコードを起こしても、設計書通りに動かないなんてザラにあるんだよ。

高級言語からアセンブラコードには機械翻訳でほぼ完ぺきだけど、
設計書から高級言語への翻訳は人がやるから誤りが混入しやすいって話をしてるのに。

>>798
ん？ 明らかにソースコードは設計書だけど、
> 設計やら製造やらの言葉の定義を製造業のアナロジーで語っちゃう
って何の話だ？

ソースコード＝設計書っていうのは
世界中のソフトウェアに詳しい人が
共通して言ってる言葉なんだが
それに反論する気かな？

じゃあプログラマじゃなくてデザイナーでも名乗ってろよ

>>801
その主張のソースはあるんかいな？

この文脈での”設計”は英語に直したら
アーキテクチャだぞ。

だから、名乗るのならアーキテクトが正解。

>>804
スレタイを読み直せ
詳細設計のどこがアーキテクチャ設計になるのかと小一時間....

え？ 詳細設計はデザインって言いたいの？

設計・・・アーキテクチャ
詳細設計・・・プログラミング
入力作業・・・コーディング
コンパイル・・・製造

俺の知らない世代では
プログラマとコーダーの仕事がちゃんと分かれていたらしい。

プログラマが考えたものを、コーダーは打つだけ。
そう、コーディングとは入力作業のみを表す。

詳細設計とは何かをはっきり定義しないことには議論にならない

詳細設計書の１行にソース２、３行が対応するようなものを意味するなら
そんなものは有害無益。
ところがこれを要求する管理者が多い。
こういうこと要求するのはプログラミングの素人か思慮の浅い人間、つまり平たく言うとアホ。

>>808
プログラマが詳細設計書を書きコーダーが書くのか？
その詳細設計書のレベルにもよるがもし詳細設計書の１行とプログラムの１行が対応するようなものだと
プログラマが直接書いた方が早いし間違いも少ない。

コンピューターが時間貸しだったり入力がパンチカードだったりで、特殊な技術者に素早く打たせた方が経済的だった時代の話じゃないの？

>>811
プログラマーがコーディング用紙にプログラムを書き、それをパンチャーがカードにパンチするという時代はあった。

>>807-808

目からうろこだ。ありがと。

>>808
プログラマ = パンチカードに打ち込むべき内容を考えた上、打ち込む文字も考える人
コーダー = パンチカードに何か打ち込む事務員

という時代はあったようだ。
近い関係としては、原稿を手書きするライターと、ライターの文章を清書するタイピストだわな。


詳細設計書とコード(エディタに打ち込む文字列)が一致しなくなったら、
コーダーって語は通用しないとは思うよ。
詳細設計書を読んで解釈する作業が発生したら、作業者をコーダーとは呼べない。
そいつはプログラマだ。

詳細設計書とコードは一致するものだ。
なぜならコード＝詳細設計書なのだから。

今の時代、コードを入力するだけの仕事はなく、
プログラマが詳細設計を考え、直接コードを入力する。
そう、コードは詳細設計そのものなのだ。

ま、もし、別の何かの資料を見て、まったく頭を働かせなくて
書いてある文章をそのまま一対一で単純変換してコードを書けるんだとしたら、
その資料は詳細設計でプログラムは別の何かと読んでいいけどね。
そんなのないでしょ。

受け売りうっざ

>>815
あー、俺の言い方が悪かったな。
コードが詳細設計だというのは分かる。

>>814で言った「詳細設計書」ってのは、例えばExcelで書いてある

　・引数で渡されたTargetUserをチェックし、空なら例外を飛ばす
　・TargetUserのnameに値が入っていない場合は例外を飛ばす

みたいな意味不明の説明と、意味不明なシーケンス図が末尾についてるゴミ資料だ。
ITが分からない管理職を分かった気にさせるためだけの資料な。
どうせ3秒見てからシカトするんで書かなくてもいい気はするが。

まぁ「業務系」の世界だわな。

業務系っていうか、アップデートしづらいターゲットなら
わりかしそういう詳細設計書書くよ。

逆にWebサービスとかβ版からでも提供最優先の分野は
そんなことやってられない。

>>816 そういうのはその受け売りが間違っていることを示してから言うもんだ。

ミーティングにて

「今日から○○機能の設計に入る予定です」
『え？もうコーディングに入れるでしょ？』
「はい、なので設計書の作成に入ります」
『は？』
「Javaで設計書を書きます」

>>820
その受け売りはソースコード以外は設計ではないような言い方をしている点で
間違っているが、このスレでそんなことを言っている奴はいない。

『この機能だけど、作るのにどれくらいかかりそう？』
「設計に10日、製造に10秒です」
『え』
「製造とはコンパイルのことです」

>>821
横レスだけど、「プログラミングは設計である」とか「コンパイルは製造業である」みたいな
ソフトウェア開発に製造業メタファーを勝手にあてはめて得意げに語るヤシは存在するだろ
>>820,822そんなのを皮肉っているんじゃないかと....

間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価
http://www.amazon.co.jp/dp/477414343X
★★★★★ (5つ星のうち4.8)

P68 製造業と開発プロセスについて

読めよ。ソースコードが設計書だってわかるから。

一品ものを作ってる工場とかは、製造業じゃないんだなw

>>825
プログラミングは設計業。
コンパイル作業が製造にあたるわけだから、
ソフトウェア開発しているのなら製造業でもあるよ。

プログラムソースというシステムの設計図を作る訳だから、コーディングは設計だよね。

何言ってるの
プログラミングは工芸だよ

>>524
その本はAmazonの書評にもあるけどアーキテクト初心者向けの入門書。
そういった入門書では初心者にも分かりやすいようメタファー(比喩、たとえ)を使って書かれることがある。
それをそのまま鵜呑みにし定石/常識だと思い込んで現場で使ってしまうのが初心者の怖いところ。
残念だが>>824の入門書は、文献としては参考にならない。

>>826
日本独特の文化に「ソフトウェア工場」というのがある。(いや、あったというべきか....)
ただし、その意味はソフトウェア開発を製造業として見なして品質管理が実践されていたわけではない。
これも勘違いしやすい点。製造業のような均一な品質の保証を志向することは基礎理念にはあるが、
コンパイルを製造工程と見なすことは無く、あくまでコーディング工程の一部でしかない。

>>827
文系にわかりやすく説明するための方便を信じてる奴がいるとは。

>>829
参考にならないと言っているのはお前だけ。
そして、それよりも参考になるものを出してもいない。

誰がお前の言うことに説得力を感じるだろうか。

>>827
プログラムとコーディングは別物だよ。

設計図を作る作業はプログラミング。
それを書く行為がコーディング。

実際は書きながらプログラミングするので境界がわかりにくいが、
昔はコーディング専用職というものがあった。
その時代はパソコンを使うのに時間制限があったりした。
その時代で効率よくパソコンを使うとなれば、プログラミングは頭で考え紙に書く、
それをコーダーがパソコンで高速に打つ。という役割分担が理解できるだろう。

>>824
本読まなくてもこれで十分。
http://www.google.co.jp/search?q=code+as+design

>>833
「コードは設計」でググっただけやんｗ

やっぱりまだ日本では
Code as Designの考え方は
普及してないのかね？

未だに反論する奴がいるしｗ

>>834
そう。それで十分なのに、 >>2 で FA なのに、未だにこのザマだ。
どういうことなのか理解に苦しむ。

>>835
普及もなにも、やることは一緒なのに呼び方だけ変えてなんになるんだっていう話ｗ

ドヤ顔したいだけっしょ
俺はわかってるんだーみたいなｗ

"Code as Design" isn't "Code is Design"!!

Code as Designの訳語は「設計としてのコード」あるいは「コードを設計とみなす」であって、
「コードは設計である」じゃないんだけどなあ..... 困ったもんだ

>>838
なにが困るの？

>>820のような漫才が起きる

ふーん
まぁせいぜい啓蒙活動がんばれや

OSのソースコードを、基本ソフトの設計書っていうのはあほ。

いえいえ、どこかの異世界では ソースコード = 設計書 だそうな

自分の書いたソースコードが設計と思えない人は、
行き当たりばったりのコードを書いてる人なんだろうな。

うん、設計として意図が全然含まれてないコードも
世の中にはあるよ。それを糞コードと余分だけどね。

>>836
設計書はアホでも読めなきゃ困ると思ってるアホがいるから
アホに読めてもいいことなんか無いからアホでも読めるようにする必要ないのに

>>845
もう少しまともな文章が書けるようになったら、アホを叩く権利をあげるよ

ソースコードは命令の集まりにすぎないのでそれ自体に意味は無い。
しかし文章に似せて書くことで、あたかも自然言語のように読めてしまう。

このトリックを使うにあたってプログラマの腕の差が出る。

俺は毎日毎日意味のないものを製造してたのか…

大手にＰＧとして派遣されてるけど
ブリッジＳＥ（笑）なる糞社員が
顧客から１００得た情報を５０しか理解できず、そのうちの３０しかＰＧに展開しないもんだから品質がとんでもないことになってる
下流に行くほど必要な情報が削がれていくってｗｗｗ

そらまぁ派遣なんて馬の骨だからなぁ・・・

>849
このはしを渡るべからず

ブリッジSEってオフショアやるときのSEじゃないの？

本来いらんポジションの金食い虫が、金食うだけならまだしも、邪魔ばかりするって話なんじゃねーの？

>大手にＰＧとして派遣

身から出た錆とはいえ、ご愁傷さまです

コーディングから先

コーディングしたモノの引き継ぎ用の説明書としては意味あるけど
作るときは邪魔なだけだわな

そんな考えも、規模によっては撤回せざるおえないだけだぞｗ
おまいがいかに小規模な物しか手掛けてなかったって言ってるだけだしなｗ

基礎が出来てない人間にいきなりコーディングやらせると「正常系は一応動く」ってだけのゴミしか出来ないからなあ
コード見ない層には問題点が伝わらないからずっと放置されたりするし

正常系だけでもマトモに動くなら大したものだｗ

>>857
規模によって必要になるってのは、設計がダメなだけだ。

大規模開発は全体を把握してる人間も減るし、ドキュメント作業も増えるし、
後工程での修正も認められない雰囲気になるしで糞設計が蔓延しがち

大規模開発＝ゴミの山

ソースもドキュメントも働いてる人間も全部ゴミ

>>857
詳細なもんに大しての仕様だから
詳細仕様って言うんだろ
仕様の範囲すら理解できないお前はそれ以下だろww

>>863
明確な定義なんて無いだろ。

詳細設計書を機能仕様書と言ってるところ意外と多い
そんで機能仕様書を見積書と言ったりとか

結局、詳細設計書として書くべきものとは何なんだ。

死ぬほど詳細なコラボレーション図

>>867
死ぬほど詳細って言ってる粒度ってどんなもの？
作るタイミングは後から生成？

>>865
例外を持ち出す馬鹿登場

作ったもんのプレビューだろ
基本設計からプロトタイプもつくりだせない低級プログラマはやとうな

>>870
詳細設計要らない厨か

大規模なシステムは小規模に分割すべき

詳細設計なしで単体・結合ってどうやるんですか？
テスターに全項目のテスト仕様書作成して渡してくれるんですか？
うちはテスターがテスト仕様書作成しないといけないのに詳細設計イミフで要件定義とコード表しかなくて死にそう・・・。
早く開発に入れて・・・。

そういうとこは別にまじめにテストしなくていいよ。
ようはテスト仕様書という成果物があればいいだけ。
内容はどうでもよい。適当に書いといてくれ。

どんなに難解なソースでも読める自信がある自分としては、
難解な日本語でわけのわからない文字の羅列の詳細設計とか死んでほしいｗ

ていうか詳細設計書って、プログラムくみやすくするための下準備イメージ

このクラスのこのメソッドよんで
設定値を書いといて。

そうしたら組みながら色んなドキュメント開かなくていいし。すぐコーディングできる。
あらかじめ使うクラスも列挙しててくれると組み始めもスムーズ

どう組むかはプログラマしだいだし、そこはソースレビューでみんな足並みそろえたらいいやんっていう。
たまにif文とかどうコーディングするかもかいてるやつあって、意味不明。
結局基本設計見て組んだったわ

wordの詳細設計書は読むのも書くのも面倒なんだよ
クラスの枠組みと詳細なコメントが書いてあってロジックは未記載なソースファイルで十分だろ

>>877
それはwordの使い方が下手だから。

詳細仕様はできれば理由を中心に書いて欲しい。
どうやってるかは実装みればわかるけど、どうしてそういう実装や仕様にしたのか
とかの理由はコードからは読み取れないから、それを補完する役割をして欲しい。

>>877
文章を書けない小学生ですか？

素人でもわかるように書ける（表現？できる）人はいないと思うけど

>>879
ああ、それはあるな
「○○ではなくて□□なのはなぜか」ってのが当時の担当者の頭の中だけにしかないってのは困る

めっちゃ色々詳細にコーディングじみた詳細設計する会社にあたったんだが、
やりづらい
使ってるクラスも書いてないし
簡単なER図もついてない。
とりあえずDBへのI/Oはつけようや…
最悪データの流れさえみえたらなにやりたいかは大体検討つくし。

>>879
昔はそういうことを詳細設計書としてまとめてたんだよな、実現方式ってのを

今の時代に詳細設計書いてるとこなんてあるの？
どうせ書いても誰も見ないのに。

証拠として形に残しておくことが重要なんだよ
後で揉め事になった時のために

あと、言った言わないなんてのも避けるためにも書いといたほうがいいのよな
今の若い子とかホント書かんけど

詳細設計って自分用にメモ書きするためのものだろ？

頭の中で整理できないものは紙に書いてまとめてる。
で、コーディングしてテストして設計に戻ってとか繰り返す。

てかさ、詳細設計に時間かかる前提で話ししてるけど
そんなに時間かかるか?
俺なら20画面ぐらい１日で書けるぞ、190関数ぐらいだが
ちなみにクラス図の、シーケンス図、関数設計書、単体設計書等だが
まぁコーディングも１日35画面ぐらい開発するけどね。
詳細設計嫌いなひとって単に作業スキルが低いだけじゃないの?
まぁ回りにも１日2画面ぐらいしか作業できない人もいるけどね
苦手=無駄と言われてもな
大手企業や外国のお客さんだと、書かなくちゃいけないしね
まぁ、作業スキルあげてどんなお客さんにも対応できるようにしようよ
一様プロなんだからさ

画面ってw
まぁ画面ならコピペでやればそんなもんか。

３５画面やってるあなたは、２画面のひとの17.5倍の給料もらって嬉しいですね。

そりゃ、it土方の自営業だから
実績残して評価上げて契約金上げて貰ってるよ
会社員なんかで、人の倍なんて働かないよ
半年ごとに契約金+1万あげるのだって
個人事業者には大事な事なんだよ
自分の力で家も買ったし家族もやしなってるんだ
普通の人と同じ能力で同じ金額なんてあるわけないだろ
it土方だろうと、プロとしてやってるんだよ
君たちはどうなんだい?
ただの技術者かい?それともプロのビジネスマンかい?

そもそも個人の割り当てで35画面ある時点でキレるかも知れん。
本当に35画面も必要なのか、共通化して動的に生成する部分を考えれば
もっと減らせるだろうとか言う。

まぁ案件にもよるよ
病院系とかや専用機械系の画面は
目的に合わせて画面あるから、画面多くなるよ
ちなみに、現場では外注のリーダーもやってるから
画面数は他の外注ができない分を
俺が肩代わりして納期に間に合わせているだけだよ
担当した開発業種が多いし、新規開発からの参加多いから
客先評価は高いよ

ほんとに画面だけ作ってるんじゃなかろうな

仕事によっては、画面だけもあるし
コアだけの仕事もあるよ
産業機械からCad,webの申し込み画面や
大学病院の診察システム、飲食店レジや
カーナビ、会計システムや
生産管理システムまで幅広く開発してきたしね
規模も一人から200人体制の開発まで経験してるよ
言語だって、Cやvb,vbaやvc++,delphiにHTMLにjava
最近は、ActionScriptで開発してるよ
データベースもOrakuruやaccessなどもできるしね
ハードウェアのメンテナンスや
昔だけどコンピュータ学校の先生にも指導していたこともあるよ
まぁ、Windowsなんてなかった時代からこの業界にいるから
経験だけは豊富だよ
昔は、ソフトバンクもパソコンショップだったんだがね(´・ω・`)

結局、IT技術者のは、年をとると
SEなどの中間職になるか
現場のPGになるか
どちらかを選ばなくちゃいけないんだよ
精神を病みながらSEでいくか
肉体を病みながらPGでいくか
逃げちゃうか(´・ω・`)
まぁ、不器用な俺は、PGに特化して飯食ってるわけだ
IT業界は、数年ごと景気の波があるから
会社員でずっと行けるなんて保証はどこにもないんだよ
君たちは、年をとったときどうするんだい?
45歳になってから首きられたら、派遣でもなるのかい?
書類なんてものは、客先が決めるもんだ
自分が嫌いだからと言って、詳細設計も出来ないようなら給料安いよ
能力の低い技術者の末路は、悲しいもんだよ

先が見えないのは個人事業主だって同じこと

いかれた顧客と折衝しながらＰＧの仕事するぐらいだったら
田舎に帰ってコンビニバイトでもしたほうがマシ

コンビニバイトがんばれ(´・ω・`)

まだ首になってねえよ！

仕事がクソくだらなすぎて、まったく進まない。

誰の役にも立たない詳細設計書作り。

サンプルやらマニュアルやら基本設計やらのExcelファイルを5つも6つも開いて、数十のシートを行き来して、ほとんどコピペ。

シートを探してる間に目的を忘れて、フリーズ。
しばし夢の世界を漂い、ふと気がつくと1時間ぐらい過ぎてる。

基本設計は抜けだらけで、質問して修正待ちで作業中断。

言語のAPIもオブジェクト指向も完全に握りつぶしたフレームワーク。
クラス間依存しまくりで、再利用性ゼロ。

テストは手動。先行開発された画面はバグだらけ。

進捗遅れまくりで慢性的な人手不足。
集まってくるのは挨拶もできないキモオタばかり。

>>902
> 基本設計は抜けだらけで、質問して修正待ちで作業中断。
>
> 言語のAPIもオブジェクト指向も完全に握りつぶしたフレームワーク。
> クラス間依存しまくりで、再利用性ゼロ。

プログラミングの前に上記の事がわかったんなら詳細設計は無駄じゃないだろ

>>903
コーディングで分かるだろ