10/08/01 16:20:35
？
2:仕様書無しさん
10/08/01 16:21:34
ソースコード＝詳細設計
3:仕様書無しさん
10/08/01 18:22:57
>>2
そうであるべきなのだが実際は・・・。
4:仕様書無しさん
10/08/01 19:12:39
そもそも詳細設計って都市伝説
5:仕様書無しさん
10/08/01 19:57:38
ひょっとしてフローチャートまであるとか、それを修正するとか…
6:仕様書無しさん
10/08/01 20:20:18
グーグルでは詳細設計はしないだろうな
7:仕様書無しさん
10/08/02 04:29:39
いきなりコーディングして動かしてみて
動いたものを見て直していったほうがいいのではと思うけど
それは通らないんだよね
8:仕様書無しさん
10/08/02 04:43:23
＞＞ソースコード＝詳細設計
＞そうであるべきなのだが実際は・・・。
そもそもそうであるべきでないような。
9:仕様書無しさん
10/08/02 13:39:14
誰もが一定レベルのコーディングレベルにあって
読みやすくて保守しやすい書き方ができるなら
ラフな設計図で承認もらったら
あとはソースコードが詳細設計書でもいいと思う。
実際はコピペやコメントアウトやプリプロセッサの嵐
のような糞コードが多いから詳細設計をして
評価とコードを分けざるを得ない
10:仕様書無しさん
10/08/02 13:50:45
まともにメンテしてある詳細設計書を見たことがない自分は
仕事に恵まれてないんだろうな。きっとそうだ。
世の中には運用開始後何年にもわたってソースとぴったり合うように
メンテされた詳細設計書が存在するんだ。するんだよね？
11:仕様書無しさん
10/08/02 14:29:29
なんで「詳細設計」というと、コードとイコールな何かを思い浮かべる人が多いんだろう。
詳細設計が、要件定義とコーディングの間の「ソフトウェア設計」、
あるいは、要件定義、概要設計（例えば、UI定義とか外部I/F定義など）とコーディングの
間の「ソフトウェア設計」という意味なら、それがドキュメント化されるべきかどうかは
さておいて、不要と言う人はほとんどいないだろう。
12:仕様書無しさん
10/08/02 15:00:21
イメージ的にはクラス構造や呼び出し関係まで細かく書いた
UMLでがんばった感のある設計書
13:仕様書無しさん
10/08/02 16:27:25
>>10
するよ。銀行の汎用機の現場とか行くとちゃんとメンテされてるよ
コボラー乙とか言われそうだけどホントに
14:仕様書無しさん
10/08/02 16:34:47
基本設計には意味があると思うが
詳細設計にはあまり意味を感じないな
詳細作る奴とPG作る奴が別なら尚更
15:仕様書無しさん
10/08/02 18:28:32
逆に別なら意味があると思う。
同じなら意味なくね？
16:仕様書無しさん
10/08/02 20:44:46
そもそもウォーターフォール死ね！
17:仕様書無しさん
10/08/02 22:27:40
>>15
詳細設計＝コードとほぼ同じくらいのレベルと認識してるので
(Aという変数にBという値を代入とかそういうレベル)
詳細設計が書けるのなら、そいつがコードそのまま書いた方がいいと思ってる。
PGと詳細が別人だったら
その設計書からコードを起こしていくのがすげー無駄に感じるからかな
>>16
各々に長短はあるんだぜ
18:仕様書無しさん
10/08/02 23:17:37
コーディングしながら設計するスタイルなんで、
設計書だけ先に書けって言われると手が止まってしまう。
19:仕様書無しさん
10/08/02 23:19:16
ガチガチにメソッドまで設計したつもりだったのに
いざ実装してみると新しいメソッドが欲しくなる
20:仕様書無しさん
10/08/02 23:41:59
>>18
コードからastah(jude)使って逆仕様書作れば? astahになってムカつくことにフリー版は画像や印刷に透かし
入るようになったから相変わらずjude comm版を使い続けてるけど。
>>19
それくらいはアリだろ。実際はアクティビティレベルの呼出し規約変更を山ほどしたくなるのが世の常。
21:仕様書無しさん
10/08/03 00:21:42
１クラスあたり１０００行超えたらそのクラスは再設計の寿命がきてる
22:仕様書無しさん
10/08/03 12:15:17
>>21
1000行で区切る論拠は？ 4桁だから？ 16進なら0x3E8で3桁だけど？(w
23:仕様書無しさん
10/08/04 01:23:00
詳細設計なしだと単体テストできないだろ
24:仕様書無しさん
10/08/04 06:32:51
たかが小さいクラスに単体テストをかけるほど
プログラムが下手なら辞めたほうがいいんじゃないか
論理的思考に穴があるなら何回テストしても抜けが出る
25:仕様書無しさん
10/08/04 09:42:30
テスト駆動開発って知ってる？
26:仕様書無しさん
10/08/04 10:43:44
クラスによって単体テストを行わないのはナンセンス
君の言い方だと
この世のソフトにバグは存在しないことにならないか
27:仕様書無しさん
10/08/04 11:55:38
詳細設計ってのは、ＩＤＥと頭でやって、
詳細設計仕様書はDoxygenで出力、
ってじぶんのじょーしきあってるおね？
28:仕様書無しさん
10/08/04 12:39:26
>>24
その言い草だとカバレッジすらかけてないようだな。
29:仕様書無しさん
10/08/04 14:43:06
>>27
クラス図と継承図くらいは必要だろ。
30:仕様書無しさん
10/08/04 15:51:41
ﾊｧ?(ﾟДﾟ)y─┛~~ >>29
クラス図のグラフィックや継承のHTMLリンクなら、Doxygenがふつーに作ってくれる
31:仕様書無しさん
10/08/04 18:07:53
>>25 説明して
32:仕様書無しさん
10/08/04 19:11:58
｢￣ ｀ヽ､ ＿_＿_＿_
Ｌ -‐ '´ ￣ ｀ヽ- ､ 〉
／ ヽ＼ /
／/ / / ヽヽ ヽ〈
ヽ､レ! { ﾑ-t ﾊ li ､ i i }ﾄ､
ﾊＮ | lヽ八l ヽｊﾊVヽ､ｉ j/ l !
/ﾊ. ｌ ヽｋ=＝ , r= ､ﾉﾙｌ lＬ」
ヽN､ﾊ ｌ ┌‐┐ ﾞl ﾉl l
ヽﾄjヽ､ ヽ_ノ ノ//ﾚ′
r７７７７７７７７７tﾉ｀ ｰ r ´ﾌ/′
ｊ´ﾆゝ ｌ|ヽ _/｀＼
〈 ‐ 知ってるが ｌﾄ、 / 〃ゝ、
〈､ﾈ.. .ｌＦ Ｖ=＝"／ ｲl.
ト |お前の態度が とニヽ二／ ｌ
ヽ.|l 〈ｰ- ! ｀ヽ. ｌ
|l気に入らない ｌﾄﾆ､_ﾉ ヾ、!
|l_＿_＿_＿_＿__ｌ| ＼ ソ
33:仕様書無しさん
10/08/04 19:23:29
>>30
他人と連携する必要がなければそれでいい
作る前にある程度の構想伝えてから着手してるだろうけど
34:仕様書無しさん
10/08/05 14:28:34
>>33
詳細仕様書が毎日更新できるのに、
＞それでいい
ってなんなの？ばかなの？（ｒｙ
35:仕様書無しさん
10/08/05 15:38:51
毎日更新される仕様書なんて必要ないぞ
36:仕様書無しさん
10/08/05 16:29:06
つ [doxygen]
37:仕様書無しさん
10/08/05 19:26:36
>>36
いや、doxygen使って毎日仕様が後追いで変更かかったら問題だぞ。
38:仕様書無しさん
10/08/05 19:51:39
必要ないっつかそもそも意味ないよな。仕様を説明するもんが毎日変わっちゃ。
39:仕様書無しさん
10/08/05 22:48:20
納品物としての詳細
開発終了後の引継ぎ資料としての詳細としてなら
Doxygenはいいと思うよ
でも設計のための設計書としてはどう考えても使えんだろう
40:仕様書無しさん
10/08/06 02:11:15
そもそも日本語すら不自由な奴が設計書とやらを書くな！、と。
下手な日本語書いてる暇が余ってるなら、直接C言語で書け！
41:仕様書無しさん
10/08/06 02:35:57
俺は詳細仕様書は書かせてるけど詳細設計書は書かせてないなぁ。
他のチームは詳細設計書を書いてるけど、工数ばかり無駄にかけて品質は悪いし保守しづらくて保守からも文句を言われてるらしい。
42:仕様書無しさん
10/08/06 08:03:12
最後はコードなんだから、読めば馬鹿でも1週間で全体が把握できるような
キレイなコードを書けよ。まずはそれからだ。
43:仕様書無しさん
10/08/06 09:11:09
>>37 >>39
だから、仕様書は基本仕様書ﾓﾝﾘｰにしといて、
詳細設計は後からdoxygenすれば良いんじゃねーの？
44:仕様書無しさん
10/08/06 09:15:44
このスレで書かれてることはプログラム設計じゃねぇの？詳細設計じゃなくて。
と思う俺は世間とずれてるのだろうか？
45:仕様書無しさん
10/08/06 09:58:08
>>43
基本的に、詳細設計書はPG前に提出するもんだろ。それよりも普通、仕様書変更なんて上司の承認受けないと
出来ないと思ってるんだが、そんなザル会社あるんだ？
46:仕様書無しさん
10/08/06 10:27:03
お前の会社の文化が世界の標準だとでもおもってんのか
デスマに投げ込むぞ
47:仕様書無しさん
10/08/06 15:36:02
>>45
>詳細設計書はPG前に提出
受託会社ﾓﾝﾘｰでしょそれは。
48:仕様書無しさん
10/08/06 18:58:20
デスマ→とりあえず仕様書作ってろ→仕様書つくるためにデスマ→ろくなの出来ない→ダメ出し→
結局ISMSって何？な具合にバグを壁に貼って営業みたいに可視化→PGﾏｰ腐ってやる気なくす→∞地獄
49:仕様書無しさん
10/08/07 00:23:22
他の部署は仕様書を信じてコッチのコードにアクセスしてくるわけじゃん。
テスト班は仕様書を信じてテストしてるわけじゃん。
そんなにコロコロ仕様書が変わってたら大変じゃね？
50:仕様書無しさん
10/08/07 00:45:02
だから仕様書なんか信用せず、ソースコードを信用しろ。
51:仕様書無しさん
10/08/07 00:55:52
>>49
インタフェースさえ決めとけば、中身の設計とかどうでもよくね？
52:仕様書無しさん
10/08/07 01:14:01
仕様書が信用できないプロジェクトは
デスマの要件を満たしている
>>51
日々更新されるならIF固定という保証無いでしょ
他部門との連携が詳細設計で・・・・ということは
ありえないと思うんだがどうなんだ
53:仕様書無しさん
10/08/07 04:26:51
俺、このニート生活が終わったらデスマに参加するんだ……
54:仕様書無しさん
10/08/07 07:40:42
>>52 IFは固定。ただし中の実装がチョコチョコ変わる
そういう話。IF決めないと、そもそも平行で作れないだろ、さすがにそれは俺もまずいと思う。
55:仕様書無しさん
10/08/07 21:28:40
バグってるんだけど中の実装いじる予算も時間も無いから、I/F変えることにしたから宜しくw
56:仕様書無しさん
10/08/07 21:30:41
>>52
うちだと実装する言語に縛られるトコからが詳細設計。
だから関数呼び出し的なAPI仕様書は詳細設計書（群）の一部。
てかこのスレじゃ何が詳細設計か分からん状態だし、
雑談にもなんないね。
57:仕様書無しさん
10/08/07 23:53:39
>>51
> インタフェースさえ決めとけば、中身の設計とかどうでもよくね？
インターフェースってウチは詳細仕様書で決まるんだけど。
58:仕様書無しさん
10/08/08 00:10:39
うちの場合こんな感じだ。
概要仕様書
・営業がプレゼンで使う資料みたいなやつ
・開発が始まるとあんまり見ない。
外部仕様書
・制約事項などを含めた顧客に何を提供するかの一覧で、顧客との契約内容を文書にしたもの。
内部仕様書
・システムを部分に分割する仕方を記したもの。
・何を実装するかのコンポネント一覧でもある。
・コンポネント間の連携図やコンポネントのスコープ等々を決める。
詳細設計書
・各コンポネント（クラス／関数／サブシステム）のインタフェースと満たすべき要件。
・これが満たされたときコンポネントは単体テスト通過となる。
59:仕様書無しさん
10/08/08 18:02:23
設計書の中身が各社で違ってるのが話のすれ違いの元なのかもしれないな
基本設計と言いながらも、画面と2,3行程度の説明しか無い、
まるで概要設計のようなものがあったりで
設計書の名称と中身の剥離が起こってる気がするな
60:仕様書無しさん
10/08/08 22:14:53
ある程度の設計は必要だよ。
重複する似たような変数、状態、遷移があったり、
メンバ変数の中に意味不明なmTmpなんてあったり、
そんな謎ソースコードが紛れ込む可能性は減る。
61:仕様書無しさん
10/08/08 22:42:27
>・営業がプレゼンで使う資料みたいなやつ
それどこのNTTデータだよ?
62:仕様書無しさん
10/08/09 08:25:39
Google Waveが公開前に開発終了したみたいだな
今世紀最大のデスマだったに違いないな
63:仕様書無しさん
10/08/09 11:31:42
公開はした。
64:仕様書無しさん
10/08/09 13:26:27
ググルってそういう公開＆開発終了、といったライトな開発は通常パスにある。
ま、詳細仕様書は手では書いてないだろうし、手でかいてたら最悪のデスマだろうねｗ
65:仕様書無しさん
10/08/09 13:32:46
Googleみたいに優秀なエンジニアが集まってるところなら、
仕様書なんてホワイトボードに手書きじゃないの？
66:仕様書無しさん
10/08/09 13:43:56
白板は発想の具体化用じゃない？
仕様書とかはwiki的なものに個々で纏めてく感じじゃぬ
67:仕様書無しさん
10/08/09 17:36:46
いや、手って言ったのは、ワープロソフトって意味であって、、、
手じゃないものってのは、ＩＤＥがリアルタイムに図で表示したり、ソースから仕様書動的生成みたいなものを逝ったのだが。。。
68:仕様書無しさん
10/08/09 17:37:51
グーグルwaveはライトな開発じゃないよね
69:仕様書無しさん
10/08/09 17:42:33
ライトってのは、開発スタイルがウォーターフォールじゃなくて、って意味で。
ま、”ライト”って言葉で書いたのが間違ってたか。
70:仕様書無しさん
10/08/09 17:57:09
ウォーターフォールはそもそも作るものが固まってるものを作るようだからな・・
ぐーぐるみたいな未知の領域に踏み込む場合って
そもそも仕様書なんて無さそうだな
71:仕様書無しさん
10/08/09 18:58:27
ウォーターフォールは
作るものの詳細をガチガチに最初から固めろという事をいってるんだろ
実際は頭の悪い偉いさんの脳内イメージを
こっちが推測しながら短納期開発しなきゃいけないから実現不可能
72:仕様書無しさん
10/08/10 09:12:55
で、詳細設計を作成するってのはウォーターフォールじゃね？
スパイラルアプローチだとかだと、詳細設計はＩＤＥが表示してくれたり、ソースからジェネレートしたり、データ構造なら設計専用アプリだとか。
73:仕様書無しさん
10/08/11 00:01:15
そもそもコードから自動生成するものを
設計書などと呼びたく無い
74:仕様書無しさん
10/08/11 00:26:48
コーディング中に行われた設計を
人間用ドキュメントとして抽出したものだから、問題ないんじゃね？
75:仕様書無しさん
10/08/11 02:30:33
>>73
コードが設計書だろ、アジャイルの常識的に考えて。
仕様書はラフスケッチ、ソースコードが下書き、ビルドが実際の描画、実行が鑑賞だろうな。
画家的に言うなら。
76:仕様書無しさん
10/08/11 06:45:30
「コードが設計書」だとしっくりこない、「テストコードが設計書」だとしっくりくる
まだアジャイル能力が低いかな、オレ
77:仕様書無しさん
10/08/11 07:46:05
テストコードは仕様しか表してないじゃん。
設計がどうなってるかは別問題。
78:仕様書無しさん
10/08/11 10:21:43
>「テストコードが設計書」
ｲﾐﾌﾒ
79:仕様書無しさん
10/08/11 18:10:39
>>78
カバレッジツールを勉強しよう。
80:仕様書無しさん
10/08/11 19:53:43
テストコードは言うなれば、外部仕様書だな。
実行コードそのものが、詳細設計書のような位置づけ。
自動生成されないものは、概要や計画のラフだけでいい。
81:仕様書無しさん
10/08/16 05:35:59
アジャイル開発をやる場合って、見積書はどう書くの？
と言うか、どうやって費用を見積もればいいの？
82:仕様書無しさん
10/08/16 12:24:04
>81
つ「アジャイルな見積りと計画づくり」
読んでたら眠くなってほとんど読んでないけど
83:81
10/08/16 15:04:45
>>82
ズバリなタイトルの本があるんですね。ググってみたら評判もいい
みたいなんで、早速注文しました。どーもです。
84:仕様書無しさん
10/08/18 00:23:00
アジャイルな物作りって、永遠に完成しないから、適当な所で収穫するんだろ？
85:仕様書無しさん
10/08/18 03:47:21
そして翌年以降はバージョンアップで保守料せしめる。
86:仕様書無しさん
10/08/24 01:21:57
組み込みでアジャイルとかやってみたい
87:仕様書無しさん
10/08/24 01:56:43
ソニーがよくやってるじゃないか
携帯電話もよくあるな
88:仕様書無しさん
10/08/24 07:54:18
>>87
それはアジャイルじゃなくて、単に仕様がイイカゲンだからどこまでも中途半端な物しか出来上がらないだけで…
89:仕様書無しさん
10/08/24 09:59:42
agile
1 敏捷な, 機敏な, すばしこい, はしこい（⇔awkward）
2 活発な, いきいきとした(active)（⇔sluggish）；頭の切れる, 頭の回転が早い
90:仕様書無しさん
10/08/24 21:28:51
>>86
用語だけアジャイルでもいいなら…・うちで。
イテレーションという名のマイルストーン、とか。
91:仕様書無しさん
10/08/27 00:59:33
そもそも計画を修正していく権限がないのに
「アジャイルでやりますから」とか言われるんだよな。
イテレーション内で作業が終わらない事が
判明したとたん破綻するだけのプロジェクト。
それが組み込みアジャイル
92:仕様書無しさん
11/01/01 21:56:56
>>1 はただの未熟なプログラマだろ。
93:仕様書無しさん
11/01/01 22:30:24
詳細設計書を組んでから書かせるくせに１つ１つ指示してくるところはウゼー
すべてのコントロールにショートカット割り当てるとかどんだけ無茶いうんだ
しかも、アクティブになってると反応してくれないコントロール多い・・・ちゃんとやってよ＞ＭＳ
94:仕様書無しさん
11/01/02 00:42:47
ソースコードと一対一のフローチャートこそが真の詳細設計
95:仕様書無しさん
11/01/02 01:13:37
デザインパターンを
どうフローチャートにするのか
みてみたいw
96:仕様書無しさん
11/01/02 03:57:19
doxygenとかjavadoc使って、詳細設計書を後出しで作るってのも
変な話だよな
97:仕様書無しさん
11/01/02 10:11:33
無料RPG製作ツール「ロープレジェネレーター」
直感的操作で簡単なゲームが作れます。 簡単に配布可能な状態に出力することができます。
(HSP製のソースコード付きで、スクリプトの知識があれば自由度の非常に高いカスタマイズ
ができます）
他にも仲間預かり機能（100人も）や、仲間の状態/状態異常を細かく設定できたり、
乗り物が作れたりゲーム中に画像を差し込んだり、回転やフラッシュなどのエフェクト
なんかも簡単に作れる様です。戦闘はデフォだとドラクエ系。
移動は矢印キーの他に、キャラがマウスを追っかけたりするとのこと。
他にはオートアクションというのがあってオリジナルシステムの製作に役に立つかも
しれない機能です。これは、マップエディタで設定することで、「マップに入った時・
出た時・一歩歩いた時・戦闘開始前」に自動的に実行されるアクションを設定できる
機能です。
■分からないことや要望は掲示板へどうぞ。他にもいろいろ進化中みたい。
98:仕様書無しさん
11/01/02 13:15:40
>>97
思いっきりショボイんですがとりあえず３Ｄになりませんか？
99:仕様書無しさん
11/01/02 16:39:13
設計書も成果物の一つとして納品対象だから
ただそれだけのこと
100:仕様書無しさん
11/01/02 17:07:34
>>96
javadocレベルまで日本語で設計書作って、そこからプログラミング言語に
落とすって、効率悪すぎるからな。
101:仕様書無しさん
11/01/12 18:43:27
androidのソースにはほとんどコメントが書いてない。
それでも、プログラムの構造がすばらしく、ソースを読むだけで理解可能。
設計書ないと理解できないプログラムは基本的にどこかおかしいのだ。
102:仕様書無しさん
11/01/13 03:15:09
通信のプロトコル周りは、シーケンス図と状態遷移図がないと難しい
103:仕様書無しさん
11/01/13 22:42:53
基本設計書に書くからと要件定義書がペラッペラで
詳細設計書に書くからと基本設計書がペラッペラで
リリースが迫ってるからと詳細設計書は後回しで
すでに要件定義者と基本設計者は使えない人間と飛ばされて
いくらなんでもこれはない
104:仕様書無しさん
11/02/07 22:55:25
基本設計書 と 詳細設計書の書き方を勉強するために
参考になる書籍教えてください。
105:仕様書無しさん
11/02/08 09:05:46
>>104
プロジェクトリーダーに聞け
106:仕様書無しさん
11/02/08 18:55:08
詳細設計書かいてたら採算合わないから
今はどこもやめたよね
107:仕様書無しさん
11/02/08 22:20:26
ほんとに詳細設計書をかかなくて済むようになったらどれだけうれしいか
108:仕様書無しさん
11/02/09 01:26:10
でもって今まで出してた下請けも閉め出してっから
どこももう今まで作ってたシステム知ってる奴が誰もいなくなったらしいね。
109:仕様書無しさん
11/02/09 11:48:51
この板っていつも
「大手SIerのウォーターフォール開発に従事しているPG」
という前提で話が進められてる気がする。
今はもうそっちのほうが少数派になってんじゃね？
今のクラウドやらSaaSやらのLAMPなサービスとか、少数のPGでドキュメント書かにガーっと実装して作るでしょ
もう、要件定義、即実装、のノリ。組み込みPGやゲームPGだってそんな感じだよ（両方経験あり）
だから詳細設計書とかいわれると、どこのおとぎ話だ、って印象がある。
110:仕様書無しさん
11/02/09 12:07:37
組み込みは詳細設計まで書かされるよ。
製品に組み込まれて発売されてしまったらバグ改修が面倒だから。
111:仕様書無しさん
11/02/09 12:18:46
組み込みの範囲がカーナビとかケイタイとかアプリ方向に拡がったからなぁ。
何か別の分け方が要るのかもしれん。
112:仕様書無しさん
11/02/09 15:27:41
詳細設計書はソースから自動生成すればいい。
もちろんそんなの誰も読まないがカサにはなる。
113:仕様書無しさん
11/02/09 17:26:29
>>112
だからそれだと単体試験ができねーっつーの
114:仕様書無しさん
11/02/09 18:23:16
>>113
単体試験って詳細設計の内容が正しいかどうかをチェックするだけでしょ？
115:仕様書無しさん
11/02/09 18:49:52
通常先に試験書の作成、コーディングは後ってのを逆にしている連中には到底理解できないんだろうな。
116:仕様書無しさん
11/02/09 19:04:29
そんな余裕のある職場なんて理解できねーよ
117:仕様書無しさん
11/02/09 20:40:26
別に単体試験が詳細設計書必須ってわけじゃあるまい？
客の要求→コーディング→結合総合試験→ソースから設計書作成→納品
そもそも客要求聞いたら、もうソースのイメージ付くから
間の設計書は邪魔になるんだよね。
118:仕様書無しさん
11/02/09 20:42:35
作業分担の為に、何かしらの設計書は必要だけどね。
119:仕様書無しさん
11/02/09 21:01:43
>>116
同意
データとか富士通とか日立とかそういうとこだけなんだろ
未だにウォーターフォールで無駄なドキュメント大量に撒き散らしながら作ってるのは
120:仕様書無しさん
11/02/09 23:11:33
>>114
だったら、コーディングの内容が正しいかどうかのチェックはどこでやるの？
121:仕様書無しさん
11/02/09 23:20:25
俺は逆に詳細設計書がない職場が想像つかん。
設計のレビューとかどうやってんの？
状態遷移表とか書かんの？
122:仕様書無しさん
11/02/09 23:30:41
>>121
ホワイトボードで十分じゃね
123:仕様書無しさん
11/02/09 23:46:41
>>122
どうやら人員の異動の有無と規模が
考え方の違いの根っこかも、と思った。
ホワイトボードでごちゃごちゃやることもあるけど
写真とかで電子化して残してるわ。
124:仕様書無しさん
11/02/09 23:55:35
>>122
そこで書いた内容を、別の日に別の人にも承認してもらう必要がなければ、
十分かもしれないけど・・・
125:仕様書無しさん
11/02/10 00:31:18
組織だった設計ってのは、時間と人員が余るくらいないとなかなか難しい
126:仕様書無しさん
11/02/10 08:46:24
業務系のような大きいシステムに関わってる人たちも
設計書を書かないことが多いのでしょうか？
127:仕様書無しさん
11/02/10 09:05:26
ちょっと手をつけたら根本からしておかしかったとかよくあるもんね
まずは概要伝えてとりあえず形作ってもらって
そっから詳細はつめていく形にしないと正直時間の無駄
やってみなきゃわからないことなんてたくさんあるのに頭の中でそれをすべてやろうとするとか
どう考えても頭のいい行為じゃない
１円も稼いだこと無い奴が僕が２億を貯める計画を机上で綿密に練ってるのと大して変わらない成功率
128:仕様書無しさん
11/02/10 09:53:08
詳細設計前にプロトタイプ作るのは
基本捨てるの前提だし実装じゃない
129:仕様書無しさん
11/02/10 11:45:30
>>128
そんなもん作ったら、「それでいいから納品しろ」って言われて、ガクブルの日々が続くだけ。
130:仕様書無しさん
11/02/11 11:54:10
>>129
そこを拒否出来ないプロジェクトはどうせロクなもん作れないから、
客か上司か、それ言った奴に要件変更に対する書面にハンコ押させて
自分以下の責任だけ回避して諦めろ。
131:仕様書無しさん
11/02/11 14:25:04
それができたらいいんだが・・・俺はそろそろプログラマの処遇に耐えられないかもしれない
バグ無し＆気が利いたソフトじゃないと感謝されないばかりか給料もあがらない
電機業界はマジで糞だ
132:仕様書無しさん
11/02/11 16:15:17
まぁ電機はクソだな。
大分ソフトの地位も向上したとは思うけど
133:仕様書無しさん
11/02/12 02:10:39
>>109
随分と簡単な物しか作って無いんだなぁとしか思わないが、俺の視野が狭いのかな？
134:仕様書無しさん
11/02/12 05:37:03
基本設計書がまともにできてないのに
詳細設計書を書かないで開発とかそれなんてNECソフト？
135:仕様書無しさん
11/02/12 10:45:44
>>134
NECとかそこそこきっかり、しっかりしてそうなイメージだったのに
そういうレベルでの開発なんだ。
大きい企業でもそんなカンジの開発多いのかな？
136:仕様書無しさん
11/02/12 11:46:52
工期短縮の為に設計工程を端折るんだけど、
結合試験の不具合の多さに納品時期を後ろに延ばす事になる。
そして終わりの無い不具合修正とエンバグ退治に追われる。
結局、工期は予定の倍以上になって、ゾンビプロジェクトとなる。
137:仕様書無しさん
11/02/12 13:16:10
試験仕様書は、どんなテストしたかって事を纏めただけ。
138:仕様書無しさん
11/02/12 14:56:39
NECソフトはひどいね！
139:仕様書無しさん
11/02/12 19:23:45
こうやって真面目に議論している皆さんも、理・美容室に行くと「短く」とか「普通に」とか、曖昧な要求しか伝えないわけですが、嫌がらせですか？
140:仕様書無しさん
11/02/12 19:29:03
2cm切ってって言ってるけど？
141:仕様書無しさん
11/02/12 20:46:04
素人が行う細かい指示ほど有害なものはない。
142:仕様書無しさん
11/02/12 21:56:13
「いつもの通りで」
143:仕様書無しさん
11/02/13 00:37:00
お客様、今日がはじめてのご来店ですよね…？
144:仕様書無しさん
11/02/13 01:00:07
実装詳細についてはお任せします。
145:仕様書無しさん
11/02/15 01:45:35
詳細設計いらないからコメント書け
146:仕様書無しさん
11/02/15 01:49:14
詳細設計に時間さくくらいなら、ソースレビューがっつりやった方がはるかに良いと思うんだがなぁ
147:仕様書無しさん
11/02/15 02:58:53
コメントがないとさっぱりわからんようなソースはダメぽ。
コメントがあってもわからんソースはもっとダメぽ。
#define BIT31 0x80000000 /* MSB */
だってｗ
148:仕様書無しさん
11/02/15 07:27:20
詳細設計がないとコーディング出来ません
149:仕様書無しさん
11/02/15 15:01:06
客先に提供する目的のコードなら、幾ら外野が設計書なんていらねえって言っても、絶対聞くな。
客先が最後に求めるものは、設計書だからな。
150:仕様書無しさん
11/02/15 21:11:44
基本設計書レベルじゃだいたい穴だらけだけど
コード書いてるうちにその穴がみえてくるわけだから
そのつど設計者に質問できる環境があればそれで十分なんだよな
151:仕様書無しさん
11/02/15 23:00:28
俺は営業とか企画とか(に相当する)人に、作る商品の青図を描いて
とお願いしてるんだがいつも拒否される。
実装の人だけが考えてるとそいつらが他力本願になるから
そうお願いしてるのに、わかってくれないんだよなぁ・・・
152:仕様書無しさん
11/02/15 23:37:33
>>5
ネオジ◯パンとかいう会社ではまだフローチャートを使ってた。てか俺も書かされた。
しかも上司がしたり顔でそれをレビューするんだぜ。もう死にたい。
ちなみに先月辞めて転職したよ。
/* 社長室でベッドを見て心が決まった… */
153:仕様書無しさん
11/02/16 01:09:32
詳細設計書いても実装時にもっとよりよい設計が浮かぶ。
ハッキリ言って詳細設計は意味が無い。その通りに作って無いんだもん。
これって俺の設計能力が足りないだけなんだろうか？
154:仕様書無しさん
11/02/16 01:36:47
検証したくても設計が終わるまで開発環境が入れられないとかね
何のための規約なんだよって感じ
155:仕様書無しさん
11/02/16 03:04:41
>>153
自分で答え出してるじゃんw
156:仕様書無しさん
11/02/16 21:16:16
>>155
君はいつも自分が作った詳細設計通りに実装してるの？
実装時によりよい方法浮かんだりしない？
157:仕様書無しさん
11/02/16 21:50:12
>>156 気持ちはわかるけど、詳細設計で地固めしないと駄目
思いつきで作るとバグを生成する。
自分で書いてて、ものすごく耳が痛い
158:仕様書無しさん
11/02/17 01:45:30
一人で作ってるならそれでもいいけどな
たいていは何十人もかけて作るんだから
実装段階で個人プレーは嫌われるだけ。
159:仕様書無しさん
11/02/17 19:01:52
>>153
もし本当にそうなら、設計段階でそれを思いつけない自分を責めるべきで
違うもの作っててそこを咎められてないんだとしたら、プロジェクトの体勢
がおかしい。
両者を同列に話す必要はない。
160:仕様書無しさん
11/02/17 19:05:32
基本設計は「穴だらけ」なのではなく、顧客の要望をまとめた「要件定義」が
機能別に分類されただけのもの。
それをどのように実現するのか？が書かれてあるのかが、詳細設計である。
その意味では「どこまで書くべきか？」という問題は職場によって様々だが
なにが書かれてなければいけないのか？という部分では指針として出てくる
ね。
161:仕様書無しさん
11/02/17 19:26:06
俺のところは個人開発ばかりだが、まるで大規模開発のような責任を要求される
頭おかしい奴等ばかり
162:仕様書無しさん
11/02/17 19:43:57
>>161
はあ？
大規模開発は一人当たりの責任は薄まってるから。
むしろ１人のほうが全責任背負ってて可哀想だとおもうぞ。
163:仕様書無しさん
11/02/17 22:30:10
一人で開発してると、コンパイルエラーで吊し上げられないのがいい。
164:仕様書無しさん
11/02/18 01:19:34
>>163
コンパイルエラーになるようなコードを書いて平気でいられるようならプログラマは
やめておいたほうがいいぞ。コンパイルエラーなんて文法通り書いていれば
簡単に潰せるわけだし。
165:仕様書無しさん
11/02/18 01:22:30
他のやつが突然発生させた検査例外とか無理
166:仕様書無しさん
11/02/18 07:15:02
>>164
マルチプラットフォームな開発だと、あるプラットフォーム向けの改修入れたら
他のプラットフォームでコンパイルできなくなったとかよくあるわけだが。
167:仕様書無しさん
11/02/21 08:20:24.14
詳細設計要らんってヤツは、
基本設計の抽象的な状態から、
論理木で徐々に具体的にすることも出来んのだろうな。
特にクラス付きの言語なら全体で
どういう使用ケースがあるか把握してないから
継承ツリーやインターフェースを
何度も書き換えるんだろうな。
168:仕様書無しさん
11/02/21 08:46:05.92
>>167
わかってねぇなぁ
まず、「こんなもの」っていう概要（メモ書き）だけ渡されるじゃん？
んで、自由に作るわけよ
したら、「ホイホイ、こんなもんできましたよ」って客に見せるわけな
したら、それ見た客が「あのさ、もうちょっとここなんとかなんない？」って意見するわけよ
したら、「ホイホイ」「あのさ」を繰り返してモノ作っていくわけよ
ほいで、客が「まあ、このぐらいでいいじゃろか」ってなったら開発終了なわけな
って流れだからいらねぇんだよ
169:仕様書無しさん
11/02/21 11:39:18.45
>>168
うわぁ、それは単なるUIとか搭載している機能とかを顧客と打ち合わせてるだけだろ。
内部的にデータはどうなっていて、どう扱って、どういう順番で処理してるかとか
実装者以外誰も知らない状態じゃネエかｗ
たぶん機能も全容を知る者は実装者以外誰も完全には把握知てないと思われ。
170:仕様書無しさん
11/02/21 12:42:11.02
>>169
開発終わってからドキュメント作るよ
ドキュメントの修正とか発生しないし
作る奴にはだいたい全貌わかってんだからこれでいいじゃん
あれこれ細かいことを作る前に決めなきゃいけないからへんなことになるんだよ
171:仕様書無しさん
11/02/21 13:26:37.73
終わってからドキュメントを作るor修正すると言って、それが実行されることは
極めて稀である。
172:仕様書無しさん
11/02/21 13:29:34.22
>>171
いや、やるよ
次の開発までの間とか大分間開いたりするし
評価期間中とかって暇な時間多かったりするじゃん
173:仕様書無しさん
11/02/21 21:35:09.41
専門じゃない最低限のコンサルティングもないんだな。
PG以前に顧客商売としてどうかってレベルだな。
174:仕様書無しさん
11/02/21 22:03:34.19
今時詳細設計してるところなんて無駄な工数かけてる馬鹿な連中だけだろ。
あんなもんいらん。金融とか知らんがね。
と思ったが、低レベルPGには必要かもな。
175:仕様書無しさん
11/02/22 07:52:10.61
>>174
普通工数を減らす為にやるんだけどな。
176:仕様書無しさん
11/02/22 11:15:33.35
>>175
工数は減らんよ。個々にネーミングされる工程数という意味ではな。
工程を計画的に行うんで、期間が短縮される。
177:仕様書無しさん
11/02/22 21:55:35.99
詳細設計書をフォーマットどおりに書けば、
ソースコードを吐いてくれるようなシステムがあるんなら別だが、
詳細設計書いても工数は減らん
178:仕様書無しさん
11/02/22 22:00:52.55
だなぁ。
詳細設計書コンパイルできて、自動テストにもかけられるようであれば事前に書く意味
あるかもしれないけど。
179:仕様書無しさん
11/02/22 22:14:13.72
>>171
ドキュメント先行で進めながらも
ドキュメントと実装が乖離しないことのほうが
ずっと稀だと思う。
180:仕様書無しさん
11/02/22 23:24:44.39
全く不要とは言わんけど
ガチでやる必要はないと思う
181:仕様書無しさん
11/02/23 08:27:59.82
そもそも設計書って、他人(未来の自分)に見せるもの。
個々個人の成果物に対する、最低限のインターフェースを定義するもの。
だから、最低限各個人の成果物が不整合を起こさないレベルのものは必要。
ソースコードで十分と言うが、ソースは情報が多すぎる。
例えば、設計書に例外を出す過程を詳細に書く必要は無い。
どんな条件で入力されたら、どの例外を返さなきゃならないとか
その程度の情報は必要。
人によっては、例外にすべきものをNullで返すかも知れない。
逆に例外で返すべきじゃないものを
例外で返すかも知れない。
レビューで指摘できれば幸いだが、レビューに設計者全員が
いるとは限らない。
結果、どこかのタイミングで問題が発覚したら全て書き直す事になる。
現実問題、共有され始めたコードを直す訳にいかないので、
そのコードを利用するコードはその場しのぎのコードをちりばめる事になる。
182:仕様書無しさん
11/02/23 11:41:05.02
詳細設計しないで実装なんて、おまいら趣味の学生サークルかよｗ
仕事でやってんだぞ、今から作ろうとする物の仔細なディティールまでキッチリデザインしろよ。
途中で事故に遭って仕事出られネエとか、最悪死んじゃうとか、
個人ではフォローできないアクシデントが発生しても、会社が最小限度のロスで済むようにな。
183:仕様書無しさん
11/02/23 19:05:29.33
機能単位のインターフェースは詳細設計ではなく外部仕様書だの概要設計に書くから問題無し。
内部の細かい仕様なんて書くのは時間の無駄だし、ドキュメントとコードで同期がとれてる保障も無いから見ても無駄。
詳細設計見て内部の挙動を把握するくらいならコード見た方が正確だし速い。
つまり詳細設計は不要。
184:仕様書無しさん
11/02/23 19:22:56.05
>>183
おまい、順番逆だぞｗ
まだ作ってる最中or未着手のプログラムに対して、コード読めば分かるとか、意味不明ｗ
185:仕様書無しさん
11/02/23 19:28:18.38
コードなんて作ろうと思ったときにはもうできあがってるモンだろ(ｷﾘｯ)
186:仕様書無しさん
11/02/23 20:03:53.84
プログラマって 魔法使い もしくは 超能力者 だったんだｗ
187:仕様書無しさん
11/02/23 20:23:07.94
動けばいいんだよ動けば。細かい事は気にするな。
188:仕様書無しさん
11/02/23 20:51:04.37
>>186
確かに、素人からみるとそう思われるわな。
189:仕様書無しさん
11/02/23 20:52:56.77
んなこたーない。プログラムが実は簡単な仕事だという事は随分前からばれてる。
だからプログラマの価値がどんどん下がってるわけで。
190:仕様書無しさん
11/02/23 21:04:11.67
>>189
玉石混合って言葉があってな。
人当たりのいい石だけが残って
玉はつぶされていったのさ。
それが日本のIT業界さ。
191:仕様書無しさん
11/02/23 21:25:23.29
製品レベルの品質保証できる宝石は高いから買われなくなった。
問題出ればネットでアップデータ配信すれば済むところはそっちにシフト
192:仕様書無しさん
11/02/23 21:39:50.27
ソースコードは結果で
詳細設計書は「なんでこんな実装してるの？」という質問に対する答えが書かれてればよい
どう実装してるかなんてのはソース見ればわかる
なんでそんな機能を実装してるのかは
ソースみてもわからん
重複せず補完せよ
193:仕様書無しさん
11/02/23 21:42:54.41
でも、詳細設計書出せって言って求められるのはどう実装するかなんだよな。
194:仕様書無しさん
11/02/23 21:46:02.45
>>192
それはソフトウェア説明書だ。
設計書ってのは設計なんだから、作成する前にデザインするから意味があるんだろｗ
195:仕様書無しさん
11/02/23 21:56:03.29
デザインなんて脳内完結するから書かなくてもいい
わざわざ書くのは二度手間
196:仕様書無しさん
11/02/23 21:57:30.10
きっちり構造化して、各関数になにが目的かコメントしてあれば充分なはず。
197:仕様書無しさん
11/02/23 21:57:59.25
詳細設計出せなんて言われるのは二次請け三次請けの連中だろうな
198:仕様書無しさん
11/02/23 21:59:39.54
おまいらどんだけ小規模開発なんだよｗ
199:仕様書無しさん
11/02/23 23:13:43.77
>>194
そんな建前で仕事してるから無駄だって言われるんだろｗ
200:仕様書無しさん
11/02/23 23:17:54.46
>>199
同じプロジェクトに参加している別会社のプログラマに何を作ろうとしているのか説明するために作るのが詳細設計書
そこを無駄だとしたら、終わりの無い修正地獄が待っている。
201:仕様書無しさん
11/02/23 23:23:51.18
仕様の実現手段の詳細に立ち入るのなら
自分のコーディング能力が実装者以上でなければ
実装者のパフォーマンスを制限することになるが
それはいいんだな？
202:仕様書無しさん
11/02/23 23:28:03.10
>>201
何言ってんだよw
パフォーマンスが影響する場所なら、それこそキッチリ設計しないとダメだろ。
実装者のパフォーマンスって？ それなんて大道芸人？
203:仕様書無しさん
11/02/23 23:30:49.14
だいたい設計書がないと何を正とするか判らないなんて言うけど
それは責任の世界であって純粋なシステムの話じゃないよね。
204:仕様書無しさん
11/02/23 23:32:30.41
作りたい奴は作ればいい。俺は作らなくても問題無いから作らない。
と言ってもそんな事は個人の自由で決められる問題でもないが。
結局は会社の方針だな。
205:仕様書無しさん
11/02/23 23:34:04.76
>>202
じゃあ実装内容を記述するにあたって
プログラム言語と同等の自由度で設計書を作りこめるの？
あとここでいうパフォーマンスは仕事の速さ上手さだろ常考
206:仕様書無しさん
11/02/23 23:34:29.24
外部仕様がキッチリと資料化されていれば他社との間に問題は起きない。
何を作ろうとしているのか説明するために詳細設計書作るってどんなアマチュア相手だよｗ
207:仕様書無しさん
11/02/23 23:42:39.70
>>205
意味不明ｗ
プログラマの気分で仕事が速いとか遅いとか、どんだけアマチュアだよｗ
>>206
I/Fも決めないで他社と仕事は出来ないだろｗ
モジュール内部コードを分業してるなら、もっと細かい仕様も必要だしな。
208:仕様書無しさん
11/02/23 23:44:06.09
仕様書無しで分業したら、いつの間にか同じ意味の変数が３っつも出来たでござるの巻
209:仕様書無しさん
11/02/23 23:44:18.03
誰が気分の話してるんだよｗ
210:仕様書無しさん
11/02/23 23:45:45.16
俺のなかではI/Fも外部仕様のうちだ。勿論関数単位でI/Fは明確にしておく。もしや一般的にはこうは解釈しないのか。
211:仕様書無しさん
11/02/23 23:45:52.57
>>208
それはおまいの把握能力の問題だろ。
212:仕様書無しさん
11/02/23 23:46:06.47
詳細設計書レビューするくらいなら、実際のコードレビューした方がいい。
213:仕様書無しさん
11/02/23 23:46:22.24
内部の動作なんてどうでもいい。外から見た挙動が明確なら他社との間に問題は起きない。
214:仕様書無しさん
11/02/23 23:47:17.51
>>210
そこまで落とし込むなら実装してるのと変わらないだろ。
頭切り替えてプログラムもデザインの範疇だと認めたら？
215:仕様書無しさん
11/02/23 23:48:11.29
>>211
いやいや、担当者の数だけ変数が出来たｗ
216:仕様書無しさん
11/02/23 23:49:07.14
I/F決めるだけで実装してるのと変わらないなんて思わないな。
外から見た動作は単純明快でもそれを実現するために複雑な内部動作となるなんて事はいくらでもある。
だが、その複雑さを知る必要はない。
217:仕様書無しさん
11/02/23 23:50:03.64
あ、あと、プログラムもデザインの範疇とか意味不明だからどうでもいい。
218:仕様書無しさん
11/02/23 23:50:11.70
>>214
実装始めちゃうと、変更できないのよｗ
設計段階では幾らでも変更できるけどな。
219:仕様書無しさん
11/02/23 23:51:51.89
>>218
いきなり細かい粒度で書くからでしょ。
なんでもそうだけど最初は粗く書けばいいんだよ。
220:仕様書無しさん
11/02/23 23:54:18.91
>>218
実装済のコードに対してリファクタリングとかしないのか。
221:仕様書無しさん
11/02/23 23:55:34.45
リファクタリングなんてまさに詳細設計能力の無い無能のためにあるようなもんだな。
222:仕様書無しさん
11/02/23 23:56:37.03
>>220
なんで試験まで済ませた「動くコード」に手を加えないとならんの？
それこそ無駄だろ。
設計書くのが無駄でなんでリファクタリングが無駄じゃないと思えるのか不思議だｗ
223:仕様書無しさん
11/02/23 23:58:59.46
詳細設計書書こうが書くまいが、低レベルPGが作った物は糞だからね。
詳細設計書なんて無意味。
224:仕様書無しさん
11/02/23 23:59:08.33
>>222
売り切りならともかく保守していくシステムなら当然じゃないの
225:仕様書無しさん
11/02/24 00:00:04.75
低レベルPGは他人のソース読んで色んな実装手段を学ぶという事をしないから、ビックリするような糞ソースを量産する
226:仕様書無しさん
11/02/24 00:02:39.59
だいたいウォーターフォール型のお役所仕事で
ビジネスの流れの速さについていけるのか？
如何に競争相手より速くサービスをリリースするかが
物を言う業界だってあるんだぜ。
227:仕様書無しさん
11/02/24 00:03:08.78
>>224
保守していくシステムなら、なお更 リファクタリングなんて無駄な作業だろ。
動くんだぜそのコードで。 何を直すんだ？
228:仕様書無しさん
11/02/24 00:03:59.50
>>226
うちはウォーターフォール型しかやらないから、
それ以外でどうやって作ってるのが是非見てみたい。
見積もりとかどうしてるの？仕様変更は？
229:仕様書無しさん
11/02/24 00:04:22.06
>>226
先にリリースしても、不具合だらけで信用落としちゃ元も子もないけどな。
230:仕様書無しさん
11/02/24 00:04:50.05
ちょっとした機能追加やパフォーマンス改善なんてよくあるからリファクタリングはするよ。まぁしたくないけどさ。
231:仕様書無しさん
11/02/24 00:05:54.37
>>227
たとえば5000行のメソッドの合間を縫って
注意深く一行のコードを差し込む開発を続けるよりは
思い切ってメソッドを書き直したほうが
その後の開発が楽になるだろ。
232:仕様書無しさん
11/02/24 00:07:44.81
確かにWebのサービスなんて速さ命って感じがするな
233:仕様書無しさん
11/02/24 00:11:45.06
>>231
その5000行のメソッドのリファクタリングを行って、
同じ以上の手間をかけて単体テストするのに値するならやってもいいが
だいたいは自己満足なだけだろ？
234:仕様書無しさん
11/02/24 00:12:54.64
>>232
でもって延々と改修工事ですかｗ
235:仕様書無しさん
11/02/24 00:14:29.06
将来手を入れる時のために直すんだよ。
自己満足じゃなくて投資。
236:仕様書無しさん
11/02/24 00:15:39.48
改修するはめになっても最初にサービス提供する事の方によって大きな利益をあげられるならそれでいいだろ。
裏でプログラマがどんな苦行を強いられてるかなんてどうでもいいわけだし。
237:仕様書無しさん
11/02/24 00:18:51.14
>>227
このまま放置してれば保守しにくくなるだろうなぁってところを修正するんだよ。
238:仕様書無しさん
11/02/24 00:20:55.44
>>233
単体テストくらい自動化しようよ。
239:仕様書無しさん
11/02/24 00:24:29.29
つうか、どれも詳細設計が要らないって話の根拠になってない点
240:仕様書無しさん
11/02/24 00:34:55.02
ぶっちゃけると面倒ってのが一番。しかも大した効果が無いときた。
241:仕様書無しさん
11/02/24 06:11:35.06
久々に見たらすげー盛り上がっててワロタ
242:仕様書無しさん
11/02/24 06:48:44.87
開発終わってからドキュメント作るって言う奴に限って
開発終わったら逃亡してドキュメントを作らない
243:仕様書無しさん
11/02/24 07:00:13.13
>>240
コスパ悪いよね
244:仕様書無しさん
11/02/24 07:03:42.86
改修の仕事なんだがベースとなってるもののドキュメントが整備されてないんで
改修部分のドキュメントだけつくっても意味がつたえられねー
こまった。
245:仕様書無しさん
11/02/24 13:25:29.55
そんな下賎な仕事、誰も理解する気なんか無いから、無問題。
246:仕様書無しさん
11/02/24 18:38:34.50
実装なんてどうでもいいんです。何言語でもアセンブラでもＢＡＳＩＣでも。
どんな機能が入ってるか、どんな動作をするのかを書きなさい。
入力と出力を明確にすることが大事。
247:仕様書無しさん
11/02/24 18:40:27.60
>>242 つーか思うんだが、プログラマと仕様書書きが同じ人間ってのが理解できん。
プログラマに仕様書書かせたらフローチャート自動生成する馬鹿が出るだけ。
248:仕様書無しさん
11/02/24 19:25:07.02
プログラマの９割は書類書きが仕事だろ。
そうでない奴らはみんな只の日雇い労働者だ。
249:仕様書無しさん
11/02/24 21:11:00.85
>>246
そのやり方で済んでしまう仕事が多いのは確かだけど、
全てそれで片付くわけではないよ。
250:仕様書無しさん
11/02/24 23:22:37.87
>>247
自動生成の何がいけないのかわからん。
手書きのほうがいいっていうこと？
251:仕様書無しさん
11/02/25 00:15:10.46
>>250
使ってるツールの機能を最大限利用するとか、他のツールと組み合わせて
効率的かつのんびりやってるより、ツールに使われて一生懸命必死にやってる
奴の方が受けがいいということですよ。
252:仕様書無しさん
11/02/25 00:17:39.45
君の低レベルな職場がデフォルトだと思わないように
253:仕様書無しさん
11/02/25 09:27:31.67
リファクタリング否定してる奴はプログラマの才能ゼロ
詳細設計書を肯定する奴もプログラマの才能ゼロ
254:仕様書無しさん
11/02/25 14:22:16.77
>>253
才能とか数値化できないものに頼ってる時点で組織じゃダメだろ。
個人で活躍するならそれでいいけど、時代を通じて品質を一定に以上保つ目的の会社じゃ不要な人物だ。
255:仕様書無しさん
11/02/25 16:39:27.02
詳細の範囲を定義してください。
256:仕様書無しさん
11/02/25 18:08:21.64
どういう意図でそういう設計をするか
それを記述することが詳細だよ。
何を作るか、どういうインプットアウトプットを作るかは
要件定義。
257:仕様書無しさん
11/02/25 22:43:24.26
>>253
それ、俺も同意
258:仕様書無しさん
11/02/25 22:45:20.33
ナルシスト？ 自己に溺れるタイプ？
259:仕様書無しさん
11/02/25 23:12:22.15
アマチュアからお仕事でプログラムに携わることになったが
設計書に関しては何を信じたらいいのかさっぱりわからぬ
自分は
１．一番最初に携わる箇所=要求仕様=IEEE830が規格として参考に出来る
２．要件定義(3に含むか？要求のうち、ソフトで対応する部分を決める)
３．上流の設計書=基本/概要/UI/構造設計書等場所によって種類も呼称もまちまち
４．詳細設計書=JavadocやDoxygenに相当するもの
な感じで捉えているが、2や3は何を信じればいい？
オブジェクト指向が一般的な今、
4のレベルには例えば「フローチャート」なものは含まれていないため
「※この変数を定義してこれをして」みたいなレベルは設計書には含まない
いわゆるインタフェースであるとか
この関数はこの入力に大してこの結果を返す、レベルまで
でなきゃ管理コストが高すぎる
(インタフェースですら変わりうるというのに)
※みたいなのを詳細設計書と呼ぶなら、1に同意する
260:仕様書無しさん
11/02/26 14:54:23.10
実装をフローチャート化する以外は詳細設計にあらず
な職場でしか仕事したことない俺は詳細設計いらないと思ってる
一関数千行とか当たり前の世界だから関数単位のINOUT書いてもわけわかんなくなるし
詳細設計必要派が実際に書いてるものがどんなものか見てみたい
261:仕様書無しさん
11/02/26 15:00:05.29
>一関数千行とか当たり前の世界
やな世界だな
作っていい関数の数に制限でもあんのか?
262:仕様書無しさん
11/02/26 15:12:42.13
どうりで改行が変なはずだ。
263:仕様書無しさん
11/02/26 17:12:18.72
>>1-1000
○○仕様書には□□を書く
なんてのは社によって違うから
なんの意味も無い話
264:仕様書無しさん
11/02/26 17:52:23.70
この手の思考停止馬鹿は何も生み出さないばかりでなく、他人を批判する事しか出来ない池沼>>263
265:仕様書無しさん
11/02/26 23:40:11.65
254
プログラマは才能が全てだろ。何言ってんだお前？
お前は雑魚PGたくさん集めて業務システムでも作ってろよ笑
266:仕様書無しさん
11/02/26 23:46:22.13
>>265
反論になってないんだけど…大丈夫？作業員さん
267:仕様書無しさん
11/02/27 00:01:49.15
>>266
まず、お前が才能を否定するならプログラマの能力を数値化する方法を教えてくれよ。
コードの行数とか言うなよ笑
268:仕様書無しさん
11/02/27 00:05:32.08
俺は>>254でないし、反論になってない事を指摘しただけだよ。
何故俺が「プログラマの能力を数値化する方法」をレスしなければならないのか。
作業員さん興奮しちゃったのかな。
269:仕様書無しさん
11/02/27 00:12:52.50
>>268
反論できないのお前じゃん…
雑魚が
270:仕様書無しさん
11/02/27 00:14:56.40
じゃあレスしよう。俺は別に才能を否定しない。
そして、「プログラマの能力を数値化する方法」なんてものは存在しない。
んで、才能なんてものに頼る奴はアホ。
271:仕様書無しさん
11/02/27 00:20:50.77
まぁ結局誰かの才能に頼らざるを得ないんだけどな。
それがプログラマかどうかは別として。
272:仕様書無しさん
11/02/27 00:21:32.32
お前のレスなんの発展性も面白みもないな。
273:仕様書無しさん
11/02/27 00:22:02.46
そういうわけの分からなものに頼るのは組織としてどうよって話し
274:仕様書無しさん
11/02/27 00:23:28.64
末端の作業員さんには難しい話しかな
275:仕様書無しさん
11/02/27 00:27:56.02
>>273
で、日本企業はお前みたいな普通の人ばっか集めたせいで技術力なくなったんじゃねえの？
今や韓国以下だぞ
276:仕様書無しさん
11/02/27 00:29:51.95
なんか熱くなって関係無い話ししてるね。まぁ作業員さんの限界はこの辺かな。
277:仕様書無しさん
11/02/27 06:28:12.86
自称「上流のエンジニア」ほど仕様書を残したがらない不思議ｗ
「分かり易い仕様書を書くと仕事を他社に奪われる」と言い訳してたのが印象的だった
278:仕様書無しさん
11/02/27 10:19:34.20
人数集めて物作りするスタイルは
量は捌けても質が低くなると思う。
大量生産の弊害と同じことだね。
279:仕様書無しさん
11/02/27 11:27:00.28
才能なんて言い方するから荒れるんだよ。
能力って言えよ。
少し複雑な制御条件でもスラスラとコードが書けるとか、そういう普通の能力は必要。
電子回路で言うところの論理合成が無意識にできたり、物事の単純化するのが上手だったり。
280:仕様書無しさん
11/02/27 11:49:35.86
ここで才能って言っているのはハッカー級の人材ってことでしょ。
281:仕様書無しさん
11/02/27 14:45:26.75
才能とかセンスって言葉で怒るのって、才能がない奴だけだろ
向いてないんだから他の仕事やれよ。営業とか管理とかな。
そして設計と開発に口をだすな
282:仕様書無しさん
11/02/27 20:43:54.16
才能なんて数値化出来ないものに頼るのは組織としてどうなのかという話しなのに、
それを無視してあーだこーだと、本当にお前らは頭が悪いんだなぁ。
まぁスレ違いだが。
283:仕様書無しさん
11/02/27 20:45:57.46
管理職としての視点が無い底辺作業員だから仕方ないのかな。
でもそういう視点を持って仕事しないと一生底辺作業員なんだぜ。
まぁスレ違いだが。
284:仕様書無しさん
11/02/27 21:10:30.78
おまいらの言う数値化とやらは何の役にも立たん。
そんな数値化を有難がる組織なら無いほうが日本のためだよ。
マジで。
285:仕様書無しさん
11/02/27 21:40:29.30
>>282
プログラムっていう数値化できないものを無理矢理数値化しようとすることがアホ
センスない
286:仕様書無しさん
11/02/27 21:45:35.51
>>285
俺がいつ無理やり数値化しようとしたと言った？
妄想はやめてくれないか。てかアホは黙っておけと。
287:仕様書無しさん
11/02/27 22:02:58.81
プログラムを数値化した結果が人月主義、ステップ主義
1Kステップあたりバグ数いくら
なんて馬鹿がまかり通る
288:仕様書無しさん
11/02/27 22:09:47.02
そもそも「管理職」の視点でソフト作ろうていうのが間違いなんだけどね。
そうやって日本のソフトは世界で通用しなくなるのさ。
289:仕様書無しさん
11/02/27 22:20:15.63
>>286
じゃあ、お前は何を数値化して何に頼って仕事すんの？
290:仕様書無しさん
11/02/27 22:47:27.44
俺ぐらいになると全て感覚。数値に頼ってるようじゃまだまだ二流。
291:仕様書無しさん
11/02/27 22:49:14.64
定量的評価はプロセス改善の第一歩なんだが。
まぁ否定するのを止めはせんが、世界として見ても
わりと一般的な考え方だ。
292:仕様書無しさん
11/02/27 22:52:21.98
知識やノウハウが個人についてしまうと
会社としては困るんだよ
自分が社長になって社員雇ったとして考えてみ？
293:仕様書無しさん
11/02/27 22:53:54.89
>>291
だから何を定量化すんだ？
294:仕様書無しさん
11/02/27 22:54:09.08
詳細設計の作成と保守のコストはでかすぎるから不要。
295:仕様書無しさん
11/02/27 22:56:06.44
プログラム作業のコストにきまってんだろ
296:仕様書無しさん
11/02/27 22:56:48.93
>>292
技術は個人の物なんだからしょうがないだろ。
ソフトは本来属人的なものなんだ。
297:仕様書無しさん
11/02/27 22:57:22.05
>>295
どうやって数値化すんの？
298:仕様書無しさん
11/02/27 22:59:17.87
>>296 属人であってもいいが継承される必要がある
ワガママな人間に技術が宿ったら会社が死ぬ
>>297 まだどの会社も試行錯誤してるよね
299:仕様書無しさん
11/02/27 22:59:18.29
数値化にむきになってる奴がいるな
300:仕様書無しさん
11/02/27 23:00:40.30
ソフト以外は知らんが、ソフトに限って言えば我儘な人間に技術が宿るなんてのは組織が低レベルな証拠。
301:仕様書無しさん
11/02/27 23:03:09.47
お前らってプラグラム能力高いだけで評価される職場にいるんだろうな
302:仕様書無しさん
11/02/27 23:08:23.68
>>298
不可能なことを試行錯誤してるのがセンスないっていってんだよ
システム開発の見積もりだって結局はプログラマが経験から算出するしかないんだよ。
いい加減に理解しろ
303:仕様書無しさん
11/02/27 23:11:44.93
才能とかセンスとかアホ丸出しだな。よく恥ずかしくないもんだ。
304:仕様書無しさん
11/02/27 23:13:14.53
>>303
センスない人きたー笑
なんでこの業界入ったの？
305:仕様書無しさん
11/02/27 23:16:35.82
才能だのセンスだの言ってるアホは、自分自身では能力高いと思ってるのに、
実際は評価されない事を不満に思ってるプログラマってところかな。
306:仕様書無しさん
11/02/27 23:22:16.72
>>305
不満に思ってるプログラマはソーシャル系に転職する。
業務系なんざ糞食らえだ。
307:仕様書無しさん
11/02/27 23:26:43.66
>>306
ソーシャル系ってどう違うの？業務系の土方だから参考までに教えて。
308:仕様書無しさん
11/02/27 23:27:57.61
>>307
アイデアを自分で実装できない＝クズ
309:仕様書無しさん
11/02/27 23:30:06.59
>>308
ごめん、何言ってるかわからない
310:仕様書無しさん
11/02/27 23:42:16.70
こんな質問にも答えられない馬鹿だから評価されずに不満がたまるんだろうな…
馬鹿すぎてどこ行っても駄目だと思う。
311:仕様書無しさん
11/02/27 23:58:57.26
>>293
そうさなぁ。
主に生産性と品質。
多くはプロセス面だけどそれを除いてプログラムそのもので言うとと、
複雑度やバグ収束曲線辺りが分かり易くてよく出て来るかな。
プロセス面だと、やっぱりわりとstepベースだったりする。
ドキュメント数、レビュー工数、指摘数、テスト項目数、バグ数とかの
step数ベースの比率。
言語毎に独立して取る。
stepベースで無い物だと、工程間の手戻り指数など。
この辺をベースに見積の生産性指標やリリースの品質指標を出したり
未成熟な工程を分析したりする。
312:仕様書無しさん
11/02/28 00:00:24.96
しかし、技術が高い人ほどトータルコストが低くなるってのはいいんだけど
低い人は同じ事やっても倍以上の期間と賃金支払いが得られるってのも事実。
この辺の事を考えないと、技術の高い人は幾らでも経営者に搾取され続ける。
313:仕様書無しさん
11/02/28 00:04:19.66
IT土方やってる限りそれは解決不可能だから、プログラマから脱すればいいんだよ。
プログラマしか出来ないなら我慢するしかない。
314:仕様書無しさん
11/02/28 00:04:45.96
>>310
お前やっぱり業務系の土方だったのか。
俺もソーシャル系じゃないが、この前ベンチャーに転職した。前はsiで業務系やってたが、クソつまんなくてやめた。
てか、普通のプログラマならsiなんて見切りつけて辞めると思う。ひがやすお然り。
>>308が言ってるsiとの違いは、自分で考えたことを自分で実装できない奴はクズ扱いされるってことだろ。
Siじゃ実装できない奴が普通にでかい顔してるけど。
315:仕様書無しさん
11/02/28 00:09:19.70
業務系で求められる技術って大した事無いからな。Fランや高卒のPGがゴロゴロいるし。
そんな技術身につけてもだから何という感じ。
316:仕様書無しさん
11/02/28 00:20:53.91
だよな。業務系じゃMMD作れないもん。
317:仕様書無しさん
11/02/28 12:27:13.82
MMDってなんだ？ ってぐぐったら、ミクミクダンスかよｗ
あんなんDirectXのサンプルレベルで製作可能だろ。
UIのアイディアだけ…と思うが、あの手のソフトではスタンダードなUIだな。
318:仕様書無しさん
11/02/28 12:50:16.48
業務系ではサンプルレベルすら必要ないわけで
319:仕様書無しさん
11/02/28 12:54:27.85
そうは言うけど業務系の俺がMMDを造ろうと思ったら
10年は掛かるよ
320:仕様書無しさん
11/02/28 20:41:36.02
>>317
じゃあ何か作って見ろよ笑
321:仕様書無しさん
11/02/28 21:34:08.35
>>320
だからその「何か」って部分が一番難しいんだろｗ
技術なんて幾ら持ってても、アイディアが無いからヒラリーマンやってんだ。
322:仕様書無しさん
11/02/28 21:43:25.19
アイディアよりまずやるかやらないかだろ。
どうせ誰かがやってるから、とかじゃなく
まずやってみろってんだ。
323:仕様書無しさん
11/02/28 21:48:38.81
MMDみたいに作者の湧き出るリビドーの洪水にドップリ浸かるくらいじゃないと、
個人レベルで何かを成し遂げるエネルギーにならネエなぁ
324:仕様書無しさん
11/02/28 21:51:56.59
MMDは初期バージョンは70時間で組めたらしいから
相当天才だな
しかもアマチュアときた揉んだ
325:仕様書無しさん
11/02/28 21:56:52.45
アマチュアの方が技術力あるのは全く珍しくない。
326:仕様書無しさん
11/02/28 22:07:31.01
プログラマの技術(笑)なんてググるなりそこらで本買ってくれば簡単に身に付くもんだろ。
例え今は出来なくてもすぐに出来るようになるって時点で低レベル。
新しいサービスや価値観を提供して初めて評価される。
全くお前らは思考回路が雑魚だな。
327:仕様書無しさん
11/02/28 22:08:32.61
提供ってより生み出すだな
328:仕様書無しさん
11/02/28 22:09:12.43
MMDは3DCGのプラットフォームとなりつつある
すごすぎる。
329:仕様書無しさん
11/02/28 22:19:30.15
スレタイの趣旨から外れていってますが
330:仕様書無しさん
11/02/28 22:30:47.39
不要って事で結論出てるからなぁ
331:仕様書無しさん
11/02/28 22:31:57.44
まともに作ってまともにレビューしてまともに保守してるとこ見た事ないけど、世の中にはそういう所も存在するの？
332:仕様書無しさん
11/02/28 22:35:57.26
だから、詳細設計書は、実装前後では必要だけど、それ以降はまったく不要ってのは同意。
つうか、家の設計図だって、建てるまでは重要だけど、建てちまったらまったく無用だからな。
333:仕様書無しさん
11/02/28 22:39:52.10
まったく無用ってことはないでしょ。
334:仕様書無しさん
11/02/28 22:43:34.59
出来ちまったらソースが最新の詳細仕様だからさ。
メンテナンスされてない詳細設計書なんて誤解の元だろ。
だがな、製作途中では詳細設計書はいわば羅針盤で
何を実装するのかという事を各担当者同士で確認するのに絶対に必要。
335:仕様書無しさん
11/02/28 22:49:23.82
>>334
>何を実装するのかという事を各担当者同士で確認するのに絶対に必要。
具体的にどう使うの？
336:仕様書無しさん
11/02/28 22:49:51.66
何を実装するかは詳細設計には書かない。どう実装するかは書くが。
337:仕様書無しさん
11/02/28 22:53:18.84
変更とかするときに詳細仕様がないと困るよね？
338:仕様書無しさん
11/02/28 22:56:41.27
>>336
はあ？
おまい、ここはソート処理をやるとか、書かないの？
でもって入力は何何で、出力は何何ってやるんじゃねえの？
どう実装するかの方こそ無意味だろ。 バイナリソートかバブルソートかなんてTPOだし。
339:仕様書無しさん
11/02/28 22:57:05.13
別に困らないなぁ。コードが全てだから。
詳細設計書の保守にかかるコストも無駄だし。
340:仕様書無しさん
11/02/28 22:58:14.29
…ああ、バブルソートかバイナリソートかまでは書くな。たまに。
341:仕様書無しさん
11/02/28 22:58:15.73
入出力は明確にするが、内部動作なんていちいち書かない。
機能単位、関数単位のI/Fが明確ならそれで良し。
342:仕様書無しさん
11/02/28 22:58:42.02
「どう実装」というのは、いわゆる処理の流れみたいなもののことじゃないの？
343:仕様書無しさん
11/02/28 22:59:58.44
>>341
だから、I/Fだけじゃ何も出来ないだろ。
その処理は何をする処理なのか、それは重要だぞ。
ある目的を果たす処理はどれか、を知らないと利用できねえよｗ
344:仕様書無しさん
11/02/28 23:01:24.95
>>342
それこそ実装者が考えれば良い問題だろ。
345:仕様書無しさん
11/02/28 23:01:25.80
>>343
入出力を明確にするって書いてるだろ。
それが分かれば利用出来る。
346:仕様書無しさん
11/02/28 23:03:40.78
例えるなら.NETのヘルプみたいな感じで公開する関数レベルで外部仕様が明確なら何の問題も起きないが。
347:仕様書無しさん
11/02/28 23:03:42.92
>>345
入出力条件だけで何をする処理か分かるのか？
348:仕様書無しさん
11/02/28 23:05:37.73
>>347
ああ、ごめんごめん、処理概要は書くよ。
349:仕様書無しさん
11/02/28 23:05:53.83
簡単な処理の流れくらい書いておかないと実装工程時に質問攻めにされるからねえ。
350:仕様書無しさん
11/02/28 23:07:30.79
お前ら的にはビジネスロジックはどの仕様書に書くの？
351:仕様書無しさん
11/02/28 23:09:15.41
ビジネスロジックを詳細設計に書くというのなら、そりゃー必要だな。業務固有のロジックなんてプログラマ知らんし。
352:仕様書無しさん
11/02/28 23:11:26.95
運用マニュアルに書くんじゃね？
353:仕様書無しさん
11/02/28 23:17:22.01
ふむ、詳細設計書は不要という事で一件落着だな。
354:仕様書無しさん
11/02/28 23:18:49.55
>>353
だから、I/Fは書くんだろ？
それが詳細設計書じゃないのか？
355:仕様書無しさん
11/02/28 23:20:45.99
一人月未満の案件であれば不要かもしれないね。
356:仕様書無しさん
11/02/28 23:21:38.02
ビジネスロジックは別紙に記載してある。
機能単位、関数単位で、何をしたいのか明確になっている。
これで詳細設計無いと実装出来ないプログラマって存在価値あるの？
>>354
それを詳細設計と呼ぶなら俺は書いてるなｗ
内部動作なんてどうでもいいから書かないし、それを詳細設計と呼ぶと理解してた。
357:仕様書無しさん
11/02/28 23:22:51.87
そうか、詳細設計って何？から始めないから駄目なのか。
358:仕様書無しさん
11/02/28 23:23:14.48
別紙←笑うところ？
359:仕様書無しさん
11/02/28 23:23:48.23
そういうどうでもいい所に突っ込むのやめようぜ。
360:仕様書無しさん
11/02/28 23:28:30.94
詳細設計書の主な記載内容は、（実装時の）関数名と機能、（実装時の）引数名ととりうる値、あとは実装時に留意するポイントなど
モノによっては構造体の詳細（これも実装時の名称まで）や、構造体の関連図など。
って感じじゃね？
361:仕様書無しさん
11/02/28 23:30:12.20
フローチャート書いて実装とほぼ一対一の詳細設計書も存在するけど…
書いてて発狂しそうになった。
362:仕様書無しさん
11/02/28 23:30:19.42
具体的に処理内容まで書く事は少ないよ。
そこがキモである場合を除いて、大体は実装者に任せる。
363:仕様書無しさん
11/02/28 23:31:56.74
>>361
組込み系ではそんな感じだねｗ
もうフローチャートレベルでデバッグまで可能みたいなｗ
364:仕様書無しさん
11/02/28 23:35:37.91
いやいや「別紙」の内容がまさに詳細設計なんだが、
どうしても詳細設計と言いたくないのかねえと勘ぐってしまう。
365:仕様書無しさん
11/02/28 23:41:30.06
お前ら上司やお客さんに言われていやいや書いてんだろ？
詳細設計書を喜んで書いてる奴を見たことない。必要ない書類なんだから当たり前だよな
366:仕様書無しさん
11/02/28 23:43:00.93
>>364
俺の職場はそうではないってだけだよ。
俺んとこの詳細設計は>>361
367:仕様書無しさん
11/02/28 23:43:41.53
そんなこと言ったら、すべての成果物は不要ってことになるが・・・
368:仕様書無しさん
11/02/28 23:43:48.23
>>365
いや、詳細設計書無いと、チーム開発できないから書いてるよ。
369:仕様書無しさん
11/02/28 23:45:27.26
>>366
おまいの会社の言うところの詳細設計書を、これからは実装詳細図と呼ぼう。
370:仕様書無しさん
11/02/28 23:46:31.98
>>361 のところは詳細設計というよりもプログラム設計と言った方が正しいかも。
371:仕様書無しさん
11/02/28 23:47:21.19
でもさ、プログラマって基本的に外注が多いから、品質にばらつき出るだろ。
>>361の詳細設計書かないで実装させて、パフォーマンスに問題出たら上司にしかられるんだぜ。
アホな実装する奴たまにいるから。
372:仕様書無しさん
11/02/28 23:49:17.31
中国に出した時はマジ洒落にならんものが上がってきた
373:仕様書無しさん
11/02/28 23:50:52.11
組み込み系は業務系よりも品質的にシビアだから、
フローチャートとかソースコードレベルの処理記載が必要なんだろうね。
374:仕様書無しさん
11/02/28 23:51:51.80
詳細設計書って実装より時間掛かる
375:仕様書無しさん
11/02/28 23:53:25.13
>>374
まあ、日本のプログラマの仕事の９割は書類作りだからな。
376:仕様書無しさん
11/03/01 00:19:55.49
トヨタ式詳細設計だとint i = 0;だけで5行ぐらい必要になるし
377:仕様書無しさん
11/03/01 00:23:39.11
>>371
設計書を書いてる時間があるならコード書けよ。
自分の仕事が非効率だと思わないの？
378:仕様書無しさん
11/03/01 00:23:53.01
5行にならないｗ
1. 整数型 i を宣言する
2. 1で宣言した i に 0 を代入する
379:仕様書無しさん
11/03/01 00:35:51.35
>>377
設計書はどうでもいいからとにかくソースを作れ作れ作れみたいな現場であればあんたの意見は正しいが、
世の中そういう現場ばかりじゃないのよ。
380:仕様書無しさん
11/03/01 00:38:41.86
なるだろ。
１．整数型 i を宣言する。
２．整数型とは～
余裕
381:仕様書無しさん
11/03/01 00:38:47.22
自分の職場以外の環境を知らない奴らが何言っても無駄だけどな。
382:仕様書無しさん
11/03/01 00:42:25.70
開発プロセス無視して作って問題起きたらヤバいからね。ある程度大きな会社はどこもそうでしょ。
383:仕様書無しさん
11/03/01 00:43:19.85
逆に問題させ起きなければ陰で何しても良いと言えなくもないが
384:仕様書無しさん
11/03/01 00:43:21.57
この流れ読んでると、プログラマは35歳くらいで辞めたいとマジ思う
疲れる
385:仕様書無しさん
11/03/01 00:44:27.58
IT土方だとプログラマのキャリアなんて無いからね。さっさと辞めるが正解。
386:仕様書無しさん
11/03/01 00:45:29.60
極端で一方的な人がいると、どうしても不毛な議論になりがち。仕方がないさ。
387:仕様書無しさん
11/03/01 04:43:12.16
極端で一方的な人ほどお荷物なのが現実
388:仕様書無しさん
11/03/01 04:54:12.14
>>380
ログとかしょーもない共通機能の設定だけで10行くらい飛びます
389:仕様書無しさん
11/03/01 05:41:39.79
>>382
じゃあ一生同じように仕事してろ
業務系seは本当に救い様がない
390:仕様書無しさん
11/03/01 20:03:57.79
>>389
職人面してドカタやってな
391:仕様書無しさん
11/03/01 20:27:09.84
>>389 はコミュニケーション能力がない典型的な例だな。かわいそうに。
392:仕様書無しさん
11/03/01 20:42:12.99
日本のITがいつまでもダメな理由がよくわかるな
393:仕様書無しさん
11/03/01 20:50:32.82
日本のＩＴのどこが具体的にダメなんですか？
394:仕様書無しさん
11/03/01 21:02:49.00
>>393
プログラミングという職人業を、
ただの労働者のルーチンワークだと勘違いしているところ。
395:仕様書無しさん
11/03/01 21:10:20.30
コストパフォーマンス悪い奴らを切れない所だよ。
396:仕様書無しさん
11/03/01 21:13:54.90
コストパフォーマンスが悪い奴らとは具体的にどういう人たちですか？
397:仕様書無しさん
11/03/01 21:39:49.31
何も考えずに上司から命令された設計書を作り続ける奴
398:仕様書無しさん
11/03/01 21:54:25.71
>>390
プログラマを土方とか言ってる人って、きっと業務系のコードしか書いたことないんだろうな
399:仕様書無しさん
11/03/01 22:24:52.88
>>398
残念ながらメーカー系。
プログラマがドカタなんじゃなくて
開発プロセスを意識しない人がドカタ。
400:仕様書無しさん
11/03/01 22:32:09.70
開発プロセス軽視してるのは人売りの底辺プログラマだろ。可哀想だから責めるな。
401:仕様書無しさん
11/03/01 22:46:12.70
ウォーターフォール意識されても迷惑w
402:仕様書無しさん
11/03/01 22:55:25.88
>>382
>開発プロセス無視して作って問題起きたらヤバいからね。
そうそう。
開発プロセスさえ守っておけば、
その成果がどんなに悲惨なものであっても
営業的には逃げられるからね。
そこ、重要なところだよ。
403:仕様書無しさん
11/03/01 22:59:21.36
アジャイルでも開発プロセスはあるよ。念のため。
404:仕様書無しさん
11/03/01 23:02:24.93
>>399
"メーカー系"って何？
もしかしてメーカーを作っているの？
「会社設立支援システム」みたいな感じ？
405:仕様書無しさん
11/03/01 23:04:45.72
>>403
いや、そんなの当然だけどw
お前らウォーターフォールしか知らないくせに、開発プロセスとかドヤ顔で言ってるから笑えるんだよw
406:仕様書無しさん
11/03/01 23:07:08.90
アジャイルを謳っている突貫工事もあるね。念のため。
407:仕様書無しさん
11/03/01 23:29:25.26
どうせ突貫工事しかしないのに、開発プロセスとか言われても。
408:仕様書無しさん
11/03/01 23:35:57.51
お前らってほんと糞会社で働いてるんだなぁ
409:仕様書無しさん
11/03/01 23:37:18.90
>>407
そらお前が突貫工事しか出来ない会社に居るだけ
410:仕様書無しさん
11/03/02 01:27:43.35
トヨタのKANBANとかがアジャイル界隈でもてはやされて逆輸入されてきて、
勘違いしたのがライン工と同レベルみたいな認識の管理職とがが増えたな。
保守運用やインフラあたりなら同じことの繰り返しで無駄（）笑をなくすとか
言って、各週での作業の詳細を洗い出してとか意味があるんだろうけどな。
開発はある期間、似たことはやっても同じことをやるわけでもないし、繰り返し
作業なんて保守運用と違ってほとんどやらないから、月初めは○○やって、
中旬くらいは××を、とか無いんだけどな。 個人の作業詳細を洗い出す以前に
やることあるっぺ？
411:仕様書無しさん
11/03/02 07:18:09.87
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
412:仕様書無しさん
11/03/03 00:26:48.13
ある意味真だけど極論だなぁ。
少なくとも「一人で」てのは無いわ。
ベンチャーなら良いけど。
413:仕様書無しさん
11/03/03 09:00:42.46
一人で全部やるなら組織に所属してる意味がねぇ。
414:仕様書無しさん
11/03/03 10:55:42.39
開発以外も一人で回すんかよ
415:仕様書無しさん
11/03/03 21:10:34.46
>>404
メーカー系、ユーザー系、独立系、位は知っておかないと就職できないぞ。
416:仕様書無しさん
11/03/03 21:16:46.15
>>412
＞ある意味真だけど極論だなぁ。
＞少なくとも「一人で」てのは無いわ。
＞ベンチャーなら良いけど。
全然極論じゃない。開発なら一人か二人でやるのが一番効率いいんだよ。
逆に、SIみたいに100人とかで開発するのは愚の骨頂だな。そんなことするから大量の設計書を書くハメになんだよ
417:仕様書無しさん
11/03/03 21:18:55.29
>>415
多分、おちょくられてるんだと思うよ。お前。
418:仕様書無しさん
11/03/03 21:24:02.79
>>415
>メーカー系、ユーザー系、独立系、位は知っておかないと就職できないぞ。
いや、俺は別に「偽装派遣の営業職」になんて
なりたくないんだけどなぁ
419:仕様書無しさん
11/03/03 21:28:35.61
納期が無いならそりゃ一人でやるのが一番効率いいけどなあ
420:仕様書無しさん
11/03/03 21:53:52.88
自己満足の仕事とプロの仕事は違う
プロの仕事ってのは納期と製品への責任を負うことだよ
技術のあるなしじゃない。
技術があっても納期を守らない、責任を負わないなら
そんなのはプロとは言わない
421:仕様書無しさん
11/03/03 21:57:21.72
いや、報酬と労力のバランスが取れた仕事を勝ち取れるのが、プロ。
報酬に見合わないくそ仕事しか回ってこないのは ゴミ
報酬ももらえないのに責任しょわされて脅されるのは 奴隷
422:仕様書無しさん
11/03/03 22:01:13.30
>>420
だれに言ってんの？w
423:仕様書無しさん
11/03/03 22:11:50.49
>>419
いくら一人でも期間が10年とかだと効率悪そうだけど。
424:仕様書無しさん
11/03/03 22:18:41.58
>>420
そうなると「プロの研究者」と呼べるような人は
この世に一人としていなくなる訳で・・・
勿論、研究職も実績が大事なのは分るけど、
「納期を守ること」がプロの必須条件と言われると
「ちょっと違うんじゃないの？」って気がする。
別に研究職でなくたって、実際世の中には、
「出来るかどうかやってみなければ分らない」
仕事というのは山ほどある。
というかソフトウエア開発の仕事って、
多かれ少なかれそういう要素を必ず持っている。
そこら辺、どうよ？
425:仕様書無しさん
11/03/03 22:20:02.88
なんで研究職が出てくるんだよ。ここはIT土方板だアホ。
426:仕様書無しさん
11/03/03 22:26:19.38
人売り企業の使い捨てプログラマのお前らは責任なんて一切無いんだろうな
427:仕様書無しさん
11/03/03 22:29:38.51
>>425
そうだな。
時たま、３行だけ読んで
脊髄反射で書き込まれたレスとかを見かけると、
つくづくそう思うよ。
428:仕様書無しさん
11/03/03 22:33:08.73
>>416
最低2人は要る。
出来る奴一人でやってるとソイツが事故ると仕事が止まんのよ。
そういうリスクを無視してるから極論っつった。
429:仕様書無しさん
11/03/03 22:51:45.84
スーパープログラマーが病気で倒れても
なんとかするために作るのが仕様書なんだよな
430:仕様書無しさん
11/03/03 23:24:33.26
>>429
コード見て全て把握できる奴じゃないと、代わりは務まらないだろ。
てか、一流のプログラマは無駄なドキュメントなんか作らん。
431:仕様書無しさん
11/03/03 23:42:00.58
ひとりで出来る程度の規模の仕事なら、始めからやり直しても大したことない。
432:仕様書無しさん
11/03/03 23:51:04.69
それは一理あるかもしれない
433:仕様書無しさん
11/03/03 23:53:12.47
で、お前ら詳細設計書いてるの？
434:仕様書無しさん
11/03/03 23:57:50.04
>>431
会社としちゃ完全に無駄な出費だけどな
435:仕様書無しさん
11/03/04 00:05:46.01
大抵の場合は詳細設計書書く工数が浮く。
436:仕様書無しさん
11/03/04 00:29:43.72
機能設計書のバグがもっとも多く摘出されるのは、詳細設計書を作る作業である。
437:仕様書無しさん
11/03/04 00:57:01.52
>>430
こういう事言う奴の仕事引き継いだ。
最悪だった。
何が正しいのか解らん。
438:仕様書無しさん
11/03/04 01:02:55.76
個人的には優越感なんだろうが、会社にとっちゃあ凡人に引き継げない仕事を置いて行く奴の方が屑
439:仕様書無しさん
11/03/04 01:22:21.84
詳細設計書にも金払ってくれるなら書く
それだけ
440:仕様書無しさん
11/03/04 02:08:41.66
>>438
コードを全部追えば動きはわかるが、仕様が不明。
実装が仕様で経緯が不明じゃ、客から問い合わせがあったときに、それが意図した動きかどうかの判断が出来ない。
よって迅速に対応出来ず、無駄な時間を使い、会社として損失になる。
いくら凝ったプログラムほ書きかたができても、人に引き継げない仕事の仕方をしてる奴はプロじゃないと思う。
441:仕様書無しさん
11/03/04 02:48:08.96
>>430
未来を正確に予知出来るなら、無駄なものを作らずにすむんだろうな。
まあ、そんなエスパーはいないわけで、無駄になるかも知れないが、保険的な
意味でも作っておいた方がいいときのが多い。
書き捨てのつもりで書いたコードが何年も生き残ってるなんて思ってもみないし、
それでもどっこい生き残ってる経験をしたことある奴は多いだろ？
学生の時に学校の勉強なんて何の役にも立たないと思っていて、今も変わらずに
いるか、あの時、もうちょっと真面目に勉強しておけばと思う奴の差だったりもする。
442:仕様書無しさん
11/03/04 03:27:32.27
>>440
仕様が不明なのと詳細設計が無いのは別問題だな。
詳細設計だけはあるんだが、仕様が不明な引き継ぎなんて腐るほどある。
443:仕様書無しさん
11/03/04 06:28:44.06
仕様不明設計不明 顧客激怒
444:仕様書無しさん
11/03/04 06:34:15.44
お前らDRYって知ってる？少しは勉強した方がいいぞ。
詳細設計書作ってソースコードと二重管理するとかないからw
馬鹿のすることだぞ？
445:仕様書無しさん
11/03/04 07:26:18.78
>>444
DRYよりラガーのほうがいいな
446:仕様書無しさん
11/03/04 07:39:01.47
>>444
開発時には、レビュアの視点を意味的なところに集中させるために作る。
要求される品質と使えるコストが悪い時は作らなくて良いし、
極端な話、実装が終わったら破棄しても良い。
引継では、主にプログラムを俯瞰するための資料が要るんであって、
コード一行一行の全ての説明が要る訳じゃない。
まぁ詳細設計書に何書くか何てバラバラだな。
うちだとクラス図やコラボ図は詳細設計扱い。
447:仕様書無しさん
11/03/04 22:13:20.09
さすがにプログラミングを低級な仕事だと蔑む馬鹿は居なくなったなｗ
448:仕様書無しさん
11/03/04 22:46:00.20
別に適当に書いてもどうにかなるところまで
全部詳細に書くから無駄に感じるんだよな
そのあたりのさじ加減を見抜く力が必要なんだろうけど
449:仕様書無しさん
11/03/04 23:22:48.27
プログラミングは低級な仕事だろ。所詮は末端作業員。
450:仕様書無しさん
11/03/04 23:29:18.70
>>449
>>411
451:仕様書無しさん
11/03/04 23:33:18.93
だから何としか言いようがないな。お前自信が末端作業員なのは変わらない。
そのうち工場労働者と大差無い扱いになるよ。
452:仕様書無しさん
11/03/04 23:38:06.05
お前の仕事と一緒にするなｗ
453:仕様書無しさん
11/03/04 23:43:27.50
まぁせいぜい現実逃避がんばれ。末端作業員君。
454:仕様書無しさん
11/03/05 00:02:20.17
どこまでをプログラマと呼ぶかは、日本じゃ微妙なトコだの
455:仕様書無しさん
11/03/05 00:57:12.50
仕様書と設計書をまぜこぜにしてるやつ多くね
456:仕様書無しさん
11/03/05 01:33:33.82
逆に、仕様書と設計書を明確に分けようとする職場は、
大概、組織が硬直化しているものだよ。
上意下達が徹底しすぎていて、
下からの提案を吸い上げるなんてことは
絶対にしない。
457:仕様書無しさん
11/03/05 07:49:35.02
>>449
お前が仕事で関わってるプログラムは、本当に誰でも書けるんだろうなー
お前がレベル低い仕事してるってのがよくわかった
458:仕様書無しさん
11/03/05 10:38:53.69
>>449 がいう末端作業員の能力によってプロジェクトの成否が決まると言っても過言ではないのに。
ただし上流や中流が仕様不確定という汚物を下流に垂れ流さなければ、その限りではないが。
459:仕様書無しさん
11/03/05 11:07:56.34
>>458
いや、それは違うだろう。
プログラマは末端作業員だろう。
ピラミッドスタイルの大規模開発に限っては。
プログラマ自身が創造的な仕事を選択しないといけない。
460:仕様書無しさん
11/03/05 11:09:25.86
ごめん
末端作業員の能力によってプロジェクトの成否は決まらない
だね
なんせ末端だからね
461:仕様書無しさん
11/03/05 11:19:29.79
ピラミッドに例えるならば、末端の土台がしっかりしていないとピラミッドなんて建てられないわ。
末端の土台を軽視しすぎてはいないか。
462:仕様書無しさん
11/03/05 11:22:00.27
高卒でも十分に務まるんだから軽視されても仕方ない。簡単なお仕事なんですよ。
463:仕様書無しさん
11/03/05 11:22:46.16
まぁその簡単なお仕事ですらマトモに出来ない奴がいるのは事実だが、そんなゴミの話しをしてもね。
464:仕様書無しさん
11/03/05 11:23:25.86
なんか今だに上流気取って偉そうにしてる奴いるけど、クラウドが浸透してきたらお前らの仕事なくなるからねw
生き残るのは最上流のコンサルと優秀なプログラマだけ。SEとかいう意味わからん職業は無くなるよw
465:仕様書無しさん
11/03/05 11:25:22.05
はは、じゃあお前ら生き残れないなｗ
466:仕様書無しさん
11/03/05 11:26:28.30
いつになったらクラウドが浸透するの？
467:仕様書無しさん
11/03/05 11:27:13.56
クラウド関連のビジネスは物凄い勢いで数字伸ばしてる。というかクラウド以外で伸びてるとこない。
468:仕様書無しさん
11/03/05 11:29:42.45
オーダーメイドのエンタープライズアプリケーションの開発がある限り、
クラウドが浸透してもＳＥ（笑）は安泰だよｗ
469:仕様書無しさん
11/03/05 11:32:29.08
今思えばPC事業売り払ってさっさとクラウド型サービスに移行したIBMとかマジぱねえ
470:仕様書無しさん
11/03/05 11:39:39.89
企業向けのクラウドビジネスといえば、googleとかsalesforceしか思い浮かばないｗ
471:仕様書無しさん
11/03/05 12:14:52.77
クラウドって名前がついてる粗悪品…
ウイルスバスター2011
URLﾘﾝｸ(bbs.kakaku.com)
472:仕様書無しさん
11/03/05 12:36:30.24
データセンターにWebサーバ置いてサービス提供すればそれだけでクラウドって言えるからな
473:仕様書無しさん
11/03/05 12:45:27.58
クラウドってのは最後は情報スパイに行き着くとおもってる
知らず知らずのうちに中国にデータサーバがあったとかワロえないことに
474:仕様書無しさん
11/03/05 12:54:19.53
>>473
昨日の日経のトップ記事読めアホ。
世の中はお前のようなアホばかりじゃないぞ。
475:仕様書無しさん
11/03/05 12:58:54.01
ハウジングの契約して、サーバ買って、サーバ管理は下にまかせて、開発するとか
クラウド使わなくてもいい身分になりてぇな
でもここってコーディングのこと話すとこじゃないの？
476:仕様書無しさん
11/03/05 13:26:31.96
>>473
こういうの老害っていうんだよなw
477:仕様書無しさん
11/03/05 13:36:53.68
クラウドは虚業。コーディングは実業。
googleの収入源はあくまで広告収入という事実。
478:仕様書無しさん
11/03/05 13:38:50.08
>>468
だから、クラウドが浸透したらオーダーメイドが無くなるんだって。馬鹿
479:仕様書無しさん
11/03/05 13:43:58.78
プログラマの視野の狭さがよく分かるな
480:仕様書無しさん
11/03/05 13:48:56.81
クラウドは今までのパッケージソフトと変らんだろ。
カスタムするコトロがアウトソーシング可能だから競争相手が今までと違う層になるだけ。
クラウドいいぞ。 職場や自宅あっちこっちのPCから仕事を再開できる。
481:仕様書無しさん
11/03/05 13:50:25.31
自宅で仕事再開出来るってどんな零細ですか
482:仕様書無しさん
11/03/05 13:50:28.31
>>480
情報流出www
483:仕様書無しさん
11/03/05 13:58:03.49
今時自宅で仕事してる馬鹿者に仕事発注なんて怖すぎて無理
484:仕様書無しさん
11/03/05 14:03:29.13
情報流出を恐れて職場のネット禁止するのって日本以外でもあるのかな？
あれってアホすぎるよな
485:仕様書無しさん
11/03/05 14:05:01.44
>>482
ネットつないでて大丈夫なんですか？
486:仕様書無しさん
11/03/05 14:12:49.82
>>481
在宅勤務制度は大手でもそれなりに流行りものだと思う
487:仕様書無しさん
11/03/05 14:14:22.35
大手ではそうせざるを得ない場合にするのであって、それが当たり前ではない
488:仕様書無しさん
11/03/05 14:15:37.22
情報流出って言っても
PCから先は全部暗号化されてるから無問題。
機密保持契約があるから、流出した場合は自分（自社）の責任
でも流出元が特定できないから、もし事態が起こってもこういう環境が一番先に切られる。
調査の果てに依頼先が流出させていただけでもなぁ…
489:仕様書無しさん
11/03/05 14:18:20.13
電気代ってばかにならんのよ。
これを削減するためには、自宅で仕事させるのが一番。
長期なら作業場所を確保するだけの土地家屋代（家賃）も節約できるｗ
490:仕様書無しさん
11/03/05 14:48:31.31
コンプライアンスが流行すれば鍵を二重にし
インフルエンザが流行すればマスク着用を義務付ける
大手ってホント能無しだな
491:仕様書無しさん
11/03/05 14:49:05.85
>>487
なんかワークライフバランスだか働き方の多様性だかそんな名目で、
最近はむしろ週一ぐらいの利用が推奨されてたりする。
なんのアピールなのか良く分からんよアレ。
労災対策？
492:仕様書無しさん
11/03/05 14:49:58.10
「クラウドが浸透したらオーダーメイドが無くなる」の根拠と流れがわかりませんが、
「風が吹けば桶屋が儲かる」の途中過程を説明するように教えてください。
493:仕様書無しさん
11/03/05 14:51:25.19
SIerが言うクラウドでコスト削減並みに良く判らない理屈なので無視して可
494:仕様書無しさん
11/03/05 14:54:47.18
オーダーメイドは金も時間もかかるから、既に存在してるクラウドサービスを利用する方向に向かってる
クラウドは単なるバズワードではなく、本当に色んなサービスが次から次へと出てきているし、乗り換えてる企業も多い
とは言っても、オーダーメイドしてクラウドで利用ってのもまだまだ続くだろう
495:仕様書無しさん
11/03/05 14:57:51.01
オーダーメイド喫茶
496:仕様書無しさん
11/03/05 15:01:37.76
>>494
それってSaaSとか業務向けDSLとかそういう話だよね。
AWSとかGAEとかとは違うよね。
497:仕様書無しさん
11/03/05 15:07:57.84
既に存在しているサービスをそのまま利用すればいいけど、
たいていはカスタマイズが発生するんだろ。カスタマイズは無料でやってくれるの？ｗ
498:仕様書無しさん
11/03/05 15:09:35.88
どの企業でも必要な業務はどんどんクラウド化が進む
企業独自の基幹業務はオーダーメイドせざるを得ないが
499:仕様書無しさん
11/03/05 15:10:01.91
クラウドのカスタムって言っても、UIを切り貼りとか既存の手続きを付け加えたり出来るだけだからなぁ…
500:仕様書無しさん
11/03/05 15:11:08.01
業務を変える事によるコストよりもクラウド利用によるコスト削減の方が大きいと判断すれば
業務を変えてでもクラウド利用にはなるね
現場は必死に抵抗するだろうけども
501:仕様書無しさん
11/03/05 15:11:59.72
パッケージソフトのカスタマイズで金と時間がかかるようなことを、
クラウドなら大丈夫ですなんてことは言えないわな。
502:仕様書無しさん
11/03/05 15:17:24.92
良く考えたら、俺は業務アプリなんてエクセルだけで全部できると思ってる組み込み系の人間だったw
503:仕様書無しさん
11/03/05 15:20:30.97
そりゃー昔なんてエクセルすら無かったんだから可能だろ。通信手段が確保されていればだけど。
でもそれだと非効率だからアプリ開発してるわけで。
504:仕様書無しさん
11/03/05 15:22:21.33
Excelマクロで書かれた業務用アプリケーションをSky Drive上に配置したらクラウド化です（爆）
505:仕様書無しさん
11/03/05 15:33:17.57
>>504
PaaSだ。
なんの問題も無い。
506:仕様書無しさん
11/03/05 15:46:56.34
>>502
Excelで全部できるってのは間違いじゃないよ
汎用性が高いからね。
だけど、それは効率的にできるってことじゃない。
包丁はなんでも切れるけど、
皮むきならピーラーのほうが早くて効率的なのと一緒。
507:仕様書無しさん
11/03/05 16:11:57.99
えー、詳細設計・・・コーディング・・・
あっ失礼しました
508:仕様書無しさん
11/03/05 16:19:56.92
詳細設計は不要で結論出てるから
509:仕様書無しさん
11/03/05 16:25:43.50
どこに？
510:仕様書無しさん
11/03/05 16:31:49.65
俺の脳内に
511:仕様書無しさん
11/03/05 16:58:35.99
機能単位、関数単位でI/Fと機能が明確ならそれ以上の細かい内部動作を示す資料は不要だと思う。
これに反論ある奴いる？
512:仕様書無しさん
11/03/05 17:03:50.88
俺はない。その意見に完全同意。
513:仕様書無しさん
11/03/05 17:09:50.94
設計とコードが綺麗なら要らない。
複数のフラグが絡み合う50以上の関数なら欲しい。
今そんなソースを引き継いで泣きそうになってる。
514:仕様書無しさん
11/03/05 17:13:56.07
>>511
設計書をレビューするんなら、内部動作まで必要(コードレビューで代用できるけど)
四両として残すだけならIFだけでOK
515:仕様書無しさん
11/03/05 17:14:08.10
同意。それ以上詳細でソースと同期が取れてる現場に当たったことがないオレ。
どーせそんなもんだこんな会社に来る仕事。
516:仕様書無しさん
11/03/05 17:16:37.05
それどころかI/Fと機能だって、ソースのコメントさえもウソが書いてあるとこばっかだぜフハハハ
517:仕様書無しさん
11/03/05 23:21:46.06
俺の仕事のパターンは大体機能仕様書もらって(コード書いて仕様書のミス・検討不足指摘して直させて)*テスト仕様書作ってテストして(仕様変更要求あってコード直して)*最後に詳細設計書起こして納品、って感じ。
詳細設計書を事前に完璧に作り上げる、なんていうのは予算が無限にあって堅牢性も極限まで追求されて万が一の時の責任を出来るだけ分散させる必要がある場合にしか現実的じゃないと思う。
518:仕様書無しさん
11/03/05 23:32:31.92
>>517
その詳細設計書って誰か読んでるの？つーかハッキリ言うと意味ある？
納品物として必要というのではなく、活用されているという意味で必要なのだろうか。
と思ったがそんな事聞かれても分からんか。
519:仕様書無しさん
11/03/05 23:35:50.30
うちは外注する時詳細設計書も出させるけど、誰もマトモに読んでない。
520:517
11/03/05 23:57:22.53
>>518
現時点では誰も読んでないな。
でももし俺がある日突然事故ったりして死んだら
その後に保守する事になった奴が読むんだと思う。
521:517
11/03/05 23:59:21.36
あ、*じゃなくて+だったorz
522:仕様書無しさん
11/03/06 00:31:33.64
うちだと、ソフト要求仕様、アーキ設計、詳細設計、実装。
プロセス間スレッド間のシーケンスぐらいまでアーキ設計で、
その内部の状態遷移や共通APIなんかは詳細設計の範疇。
だから詳細設計書が結構デカくて、無いと困る。
523:仕様書無しさん
11/03/06 00:55:14.66
>>522
お前、才能ないよ
524:仕様書無しさん
11/03/06 09:01:57.37
>>522
共通API、って？
一般的には「API」っては「外からこういうことをされたらこう返しますよ」というルール、なので
それを定義するのは詳細設計の前だと思うんだけど。