- 1 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
- 外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
- 885 名前：仕様書無しさん mailto:sage [2012/10/06(土) 19:29:18.82 ]
- UMLがいまいち普及しないのは、保守的云々以前に
単純にExcel方眼紙と対等に戦える糞だからじゃね？
- 886 名前：仕様書無しさん mailto:sage [2012/10/07(日) 01:52:17.45 ]
- UMLで設計したら時間も労力も余分に必要だからだよ。
細部の設計も表現しづらいし。
- 887 名前：仕様書無しさん mailto:sage [2012/10/07(日) 02:28:43.71 ]
- UMLはモデリング言語の名前の通り、
設計したものを、UMLで記述するという風に使うものであって、
UMLで設計するという言い方はおかしいぞ。
- 888 名前：仕様書無しさん mailto:sage [2012/10/07(日) 04:14:36.37 ]
- 単純に、UMLだけで設計書が完結するわけじゃないからな。
ある程度書き方に自由度があるから、伝えやすいというのと誤解させやすいと
いうのがあるから、結局のところ短納期で毎回違う人とやり取りするには精度の
問題が今までと変わらんから。
実装側に厳密にするとコード書くのと変わらないし、設計側に厳密にすると
実装に支障をきたすし、学習しなければならないというところまできてないよな。
フローチャートレベルで授業のカリキュラムや情報処理技術者試験みたいな
公的な資格試験に組み込まれてれば違ってくるんだろうけどね。
- 889 名前：仕様書無しさん [2012/10/07(日) 11:16:50.29 ]
- >>887
じゃあどうやって設計すんだよ
論理的じゃない設計してそうだな〜〜お前
- 890 名前：仕様書無しさん mailto:sage [2012/10/07(日) 13:52:56.45 ]
- UMLで論理的な設計wwww
- 891 名前：仕様書無しさん [2012/10/07(日) 14:58:29.08 ]
- UMLはお客さんも理解できる（ﾄﾞﾔｧ
とか書いてあった時期あったけどそんな奴居た事無いよな
国のエロい人が色々決めてたけどあんなの揃えてたら金いくらあっても足らんし
- 892 名前：仕様書無しさん mailto:sage [2012/10/07(日) 17:18:57.20 ]
- そもそも、ちゃんとした設計とか学んだことなくてニュアンスでやってるひとは多いと思うわー
- 893 名前：仕様書無しさん [2012/10/07(日) 18:10:41.62 ]
- Excelで結合セルを駆使して設計する方法は完璧に学習した。
- 894 名前：仕様書無しさん mailto:sage [2012/10/07(日) 18:16:43.07 ]
- 途中から別のプロジェクトに入ってまず困るのは、全体を概観できる資料がないこと。
よくあるのが、全体構成図では、「営業サーバ」、「総務サーバ」とか書いてあるのに、
設計資料ではいきなり、「○○（パッケージソフト名）サーバ#1」とかになってて、
「○○#1」と「営業サーバ」の対応は、設定やってる運用グループに聞かないとわからないとか。
- 895 名前：仕様書無しさん mailto:sage [2012/10/08(月) 01:35:51.59 ]
- UMLってIT業界において、この十年間で最も衰退した技術だよな。
フレームワークや開発手法が成熟するのが早かったから、大部分が実際の開発には不要になってしまった。
本当にドキュメントが必要な部分は、UMLで記述しきれないような複雑な仕様やシステム外の業務的な背景。
- 896 名前：仕様書無しさん mailto:sage [2012/10/08(月) 01:40:26.22 ]
- いや、普通に書籍等に書いてある図は
UMLなんだが・・・
- 897 名前：仕様書無しさん mailto:sage [2012/10/08(月) 02:06:38.91 ]
- フレームワークもなぁ。
要件やメカニズムのどの部分が、どのフレームワークのどの機能で実現されてるのかが
分かる資料がつくられてなかったりすると悲惨。
DI多用してたりして、末端のPGのコードとDIしたコードがバッティングしてたりすると、
PGには原因がわからない(開発用と顧客用で切り替えとかをやってたりすると最悪）
それでもそのあたりを設計したアーキテクトがプロジェクトに残ってれば聞けばわかるが、
基本設計行程が終わったら別のプロジェクトに移るなんてやりかたしてたら、
プロジェクト内に問題解決できる人がいない（または解析しないとわからない）
状態になる。
- 898 名前：仕様書無しさん mailto:sage [2012/10/08(月) 08:03:32.57 ]
- >>895がフレームワークべったりな開発だけしか経験してないんだなとしか。
- 899 名前：仕様書無しさん mailto:sage [2012/10/08(月) 11:14:39.30 ]
- フレームワーク作る側がUMLを書いてると思ってるのかな？ww
あんなのドカタ専用ツールだと見なして無視してるけどね
- 900 名前：仕様書無しさん mailto:sage [2012/10/08(月) 11:58:23.35 ]
- とりあえず、本当にフレームワーク・・・というか、
その種のプロジェクトの中心人物は、社交的で、
不用意に他人をけなしたりしないけどね。
- 901 名前：仕様書無しさん mailto:sage [2012/10/08(月) 12:04:37.02 ]
- 社交的で人当たり良くても、内心で「こいつらアホだな〜、猿か？」と思ってます
- 902 名前：仕様書無しさん mailto:sage [2012/10/08(月) 12:11:50.57 ]
- いや、おまえにとってそう見える相手はフレームワーク製作者に限らないだろ。
- 903 名前：仕様書無しさん mailto:sage [2012/10/08(月) 12:19:55.89 ]
- アホに生まれた子って可哀想。
ただでさえアホだと馬鹿にされてるのに、
死ぬ程働いても給料1000万にも届かないし。
ほんと同じ立場に立ったら自殺するわ。
- 904 名前：仕様書無しさん mailto:sage [2012/10/08(月) 19:52:14.70 ]
- >>896
だいたい書籍書いてる奴なんて実際の大規開発現場知らない奴ばかりだろ
UMLだけで書くのに都合の悪い例を排除してるというか…そもそも実務経験がなさ過ぎて想像もできないんじゃないか？
- 905 名前：仕様書無しさん mailto:sage [2012/10/08(月) 20:06:20.83 ]
- UML知らない奴ほど、全部UMLで書こうとする。
- 906 名前：仕様書無しさん mailto:sage [2012/10/08(月) 23:54:32.38 ]
- ユースケース図は粒度の決め方がアナログ過ぎ、ロバスト図はある程度以上の複雑さを表現しようとすると、2次元じゃ無理ゲー。
- 907 名前：仕様書無しさん mailto:sage [2012/10/09(火) 00:02:11.70 ]
- ユースケース図の仕様に粒度は定められてない。
どう決めるかは使う側の問題。
ロバストネス図はそもそも、不必要な複雑さを省くために考えられたもので、
本当に複雑なものをわざわざモデリングしようとするのは本末転倒。
というか、批判するなら、規格書とか、発案者の書いた本ちゃんと読めよ。
- 908 名前：仕様書無しさん mailto:sage [2012/10/09(火) 02:15:14.11 ]
- UMLがない時代でもそれなりに設計なんかしてたんだし、特に必要という訳ではないかもしれんが、
あればより良いものだけど、要る派の言ってる事も要らない派の言ってる事も極端だよ。
- 909 名前：仕様書無しさん mailto:sage [2012/10/09(火) 03:24:36.52 ]
- まて、ここ最近のレスで要る派なんていたか？
- 910 名前：仕様書無しさん mailto:sage [2012/10/09(火) 03:31:45.51 ]
- 極端なのは、要る派と要らない派しかいない前提の >>908
の言ってることじゃね？
- 911 名前：仕様書無しさん mailto:sage [2012/10/09(火) 03:32:44.01 ]
- 利用価値0じゃないという意見はあったけど、
アンチからみるとちょっとでも使ってる人は要るよ派に見えてると思ってる
敵を作って戦わわないと気がすまない的な
- 912 名前：仕様書無しさん mailto:sage [2012/10/09(火) 10:09:17.74 ]
- じゃぁUMLの代わりに何つかう？っていう話になると、
結局UMLが無難ってことになる。
- 913 名前：仕様書無しさん [2012/10/09(火) 10:19:01.02 ]
- Excelのセルをちまちま埋めて仕様書を書いていく快感はUMLごときでは得られはせぬ。
- 914 名前：仕様書無しさん mailto:sage [2012/10/09(火) 12:34:17.78 ]
- それは仕様書だね。設計書とは違う。
- 915 名前：仕様書無しさん mailto:sage [2012/10/09(火) 20:20:14.25 ]
- UMLがどうのとかはぶっちゃけどうでもいいよ。求められれば使うだけ
だがな、ドキュメントとして文章めいたこと書くのにExcel使うのはいい加減やめにしてもらいたい
二度と修正を入れない使い捨てなら構わんが、保守を考えたらExcelドキュメントなんてうんこよりひどい
- 916 名前：仕様書無しさん mailto:sage [2012/10/09(火) 21:19:43.34 ]
- ワードで書くよ〜って言ったら嫌な顔するくせに
- 917 名前：仕様書無しさん [2012/10/09(火) 22:27:10.85 ]
- まともに変更履歴も残さないUMLは使い物にならない
設計書で重要なのは変更履歴と変更理由
現状はソース見れば誰でもわかる
- 918 名前：仕様書無しさん mailto:sage [2012/10/09(火) 23:41:24.45 ]
- それはバージョン管理システムの仕事だろ。
UMLでも、変更ごとにコミットしてコメントちゃんと入れれば無問題。
バージョン管理システム使わずにコメントだけで変更履歴残そうとして
しっちゃかめっちゃかになったソースだと、ろくに流れも追えなくなる。
- 919 名前：仕様書無しさん mailto:sage [2012/10/10(水) 07:15:32.32 ]
- たとえバージョン管理システム使ってても
diff取れないバイナリで書いてりゃ威力半減
- 920 名前：仕様書無しさん mailto:sage [2012/10/10(水) 07:40:25.34 ]
- そのあたりは使うツールによりけりだが・・・
とりあえず、diff が取れる代替え手段ってなんかあるの？
- 921 名前：仕様書無しさん mailto:sage [2012/10/10(水) 07:42:02.80 ]
- diff とか言い出すと、 word や Excel より TeX だよな。
- 922 名前：仕様書無しさん mailto:sage [2012/10/10(水) 17:36:08.65 ]
- TeXだと冗長になるし、なんかそれ用のエンジン使うのが賢いんだろうな。本当は。
- 923 名前：仕様書無しさん [2012/10/10(水) 20:40:25.74 ]
- >>920
エクセルに1文1セルで書いて、隣の列に
1列1バージョンで改変有無と理由を記載
フィルタを使えば瞬時に差分が見られる
- 924 名前：仕様書無しさん mailto:sage [2012/10/10(水) 20:54:09.99 ]
- >>923
それで事足りる案件なら、自分だって Diff もバージョン管理システムも、
UML も使わないよ。
- 925 名前：仕様書無しさん mailto:sage [2012/10/10(水) 23:46:17.39 ]
- そういうのは大抵が打ち消し線だらけだったりカラフルだったりになるから
いろいろ糞だけどね
場当たり対応をコード以外でも多用してるだけだし
- 926 名前：仕様書無しさん mailto:sage [2012/10/11(木) 06:43:08.22 ]
- 技術文章としての体裁を要求されたり、図表使ったら終わるだろ、それ。
- 927 名前：仕様書無しさん [2012/10/13(土) 13:18:12.48 ]
- 上流工程の資料の作成が凄いネックになってる気がしてならない。
開発者の視点で厳密に書くと「こんなんじゃユーザがわからん」といってハネられる。
ユーザにわかるように書くと表現があいまいになって、開発者には意味不明になる。
この矛盾に悩みつつ、ダメだしを回避する資料を完成させるのに絶望的に時間がかかって、
プロジェクトの予備工数がほとんど消える。
最後にはタイムオーバでダメ出しする人間が折れることになるが、
なんだかんだで、ユーザにも開発者にも3割方意味不明な資料ができあがる。
この3割方意味不明な資料を使って予備工数がない状態で開発がスタートする・・・。
- 928 名前：仕様書無しさん mailto:sage [2012/10/13(土) 15:51:58.47 ]
- ユーザー用と開発者用それぞれ別のドキュメント作ればいいだけでは？
むしろ作るべきでは？
- 929 名前：仕様書無しさん mailto:sage [2012/10/13(土) 16:10:43.54 ]
- まず、そのための工数がとられてるプロジェクトをみたことがない。
あと、開発スタート後に鬼のように湧いてくる仕様変更を、
二重化したドキュメントに反映してメンテナンスしていくコストも大変。
- 930 名前：仕様書無しさん mailto:sage [2012/10/14(日) 17:30:47.51 ]
- dfdとer(テーブルと多重度のみでOK。カラムは主キーのみでいい)意外不要。
- 931 名前：仕様書無しさん mailto:sage [2012/10/14(日) 17:43:10.49 ]
- 一人で作る程度のシステムで、クライアントがそれで納得してくれて、
その後の運用メンテも同じ担当者が続ける前提なら、それでなんとかなるかもしれん。
- 932 名前：仕様書無しさん mailto:sage [2012/10/15(月) 02:52:27.14 ]
- 成果物が糞じゃない前提なら、ドキュメントの必要性は減ると思うよ
webとかだったら画面遷移とかあると理解度は上がると思うけど、
マニュアルと動くものがあれば事足りるからなくてもいい
クラス図があると関連は理解しやすいけど
名前やパッケージ、IDEの機能で追っかけるのは簡単だからなくてもいい
まぁ作成や保守にかかるコストと教育にかけるコストと、教育対象者の質次第だな
劣悪なのはドキュメントがいくらあっても結局理解しないし、
できる奴は(ちゃんとしたシステムであれば)その場にあるので難なくこなせると思う
- 933 名前：仕様書無しさん mailto:sage [2012/10/15(月) 12:49:11.89 ]
- 技術的なドキュメントとして重要なのは基本設計と運用設計のほうだと思う。
基本設計資料がちゃんとしていれば、詳細設計は無くてもなんとかなる。
でも今、実際は、基本設計、運用設計、詳細設計で、ドキュメント量の比率としては、2:1:7 ぐらいじゃないか。
自分は、6:3:1 ぐらいでもいいと思う。
- 934 名前：仕様書無しさん mailto:sage [2012/10/15(月) 15:22:41.07 ]
- 詳細設計書 = ソースコードだからねぇ。
本当の必要な量で言えば、一番多い。
だけど、ソースコードを補足するものだけに
すれば、逆に少なくなる。
詳細設計の量が多いところは
ソースコードが詳細設計書だって
わかってない。
|
 |
