設計書を作ってるせいで生産性落ちてないか？

概要設計書、外部設計書、詳細設計書
クラス図、シーケンス図、状態遷移図、アクティビティ図
リファレンスマニュアル、レビュー管理記録、成果物リスト、・・・・・・・

アホか、、

外設した後はさっさとコーディングした方が
設計書なんかで妄想してるより何倍も多くのことが分かるっての。
で、実装とテストが終わったあとに
改めて補足のドキュメントまとめた方が明らかにソースと食い違いのないものができる。。

だいたい「ソフトウェア 設計書」でググったら
現状懐疑論ばっかじゃねーか。

設計書よりも
デバッグ期間とか、発生数／対応数のグラフだけ毎日書くひとじゃねえの？

>>2

そういう単純作業は派遣社員にでもやらせるのが勝ち組

後から作るから問題なし。

つーか今時
＞概要設計書、外部設計書、詳細設計書
こりゃねーだろｗ

製作を外注するならともかく意思疎通しやすい距離で作業するんなら、
全くもっていらないんじゃない？

>1の会社はいまだにステップ数で見積もってるんだろうな…

1は形式的手法も知らないDQN工員

今は短納期が基本だから設計書なんて書かない。
仕様書はデータベースの定義だけあればいい

1.概要設計書をでっちあげる
2.概要設計書をコピーして少し書き足す→外部設計書
3.外部設計書をコピーして少し書き足す→詳細設計書
4.1〜3の成果物を大切に保管
5.DB定義書と機能メモをもとに実装

なんてことを、ここ数年続けてる。

実際には外部に発注する以外作った設計書の使い道がない。
ただ、ISO9001の審査を通すために毎回作ってる。

ドキュメントは重要だが、たいていは客に提出するドキュメントを作った時点で
力尽きてしまい、開発用のドキュメントがおざなりになってしまう・・・

各種ドキュメントを作成するのはいいとして、
ソースコードのほうだけ修正してドキュメントを修正しない
ということ。

コンピュータを使っているのに、
人間が手作業で対応関係を把握して、
まるで写経のようにドキュメントを更新するのは、
なんかもうアホらしい。

詳細仕様についてもJavaDocなんてアホらしかった。
書き写す元と先の距離がとても近いだけで、
結局は同じファイル上でコピペをすることになる。

ソースコード上でさえ情報を一元管理できない。

俺のすごいところは何万行のプログラムでも
一度もコンパイルすることなく一気に書き上げる。

いちいち動作確認しながら作るやり方は素人

>>13
天才

>>1
その通りだが、本当にそんなたくさんドキュメント作ってるのけ？

>>13
すごいなぁ。

自分は記憶力が足りないので何万行も頭の中に入りきらない。
きっちり把握できる分量で区切ってテストしてる。

書いてみて、コンパイルしてみて、動かしてみて
というのを数十行ごとにやっている人に、
「お前、ちゃんとわかってないで書いてるだろ?
そんなのは、たまたま動いているだけだぞ。」
なんて偉そうなことを言っている自分だけど・・・。

だが、そうやって一気に書き上げられたプログラムに
何件バグが含まれているかについては一切言及されてない件について。















あれ、俺釣られた？

>13
じゃあ次は cat 一発でのプログラミングに挑戦だな

設計書がない方が自由にできると思われ

お前等設計書が無い開発したら絶対こんな事言わなくなるぞ
現職がそうなんだが、口頭で仕様、機能追加、クライアントの言うがままを丸丸営業が持ってくる
コーディングルールすら無い
で、
「コーディングルールや要件定義書と仕様書（技術者側の）と設計書が無ければ開発しない様にしましょう。
品質管理の点からも、プロジェクトの進め方にしても開発にかかる負担を減らす事が出来ます。」

と、上に進言したら

上の人間に営業出身の奴しかいないせいか
「そんな窮屈にしたら開発の自由度が損なわれる（自分達がドキュメント書いた結果自分達の責任が露呈するのが嫌）」
「設計書のママに組んでも面白くないだろ？ウチの良い所がスポイルされてしまう（もう必死）」etc

要件定義書、設計書、仕様書は技術者の防御手段だと思っていいよ
時間掛けても書くべき、生産性云々よりも重要

>>20
その通り。俺はバカだったから経験として知ってる。

>>20
技術者のっていうより受注側の防御手段だろ。

そこでXPですよ

>>22
馬鹿だな。敵は身内にも居るんだよ。

>>24
何を信用したらいいのかな？
恐いよ

>>25
信じられるのは自分の力のみ。
バカ営業や、なんちゃってSEが勝手に客の仕様変更要望を受け付けてしまうことはよくある話。
紙に残ってないと責任の所在が不明確になり、結局末端に押し付けられてしまう。

>>20
>口頭で仕様、機能追加、クライアントの言うがままを丸丸営業が持ってくる
論外。だが、んなことぁこのｽﾚで語ることではない。

後から書く書く詐欺にあったらちょっとは考えが変わるとおもう。

発注する側に回って身に染みた。

で、数年たって保守とかやらされてみそ。

設計書？メモ残ってるから見て！
ソース？バグとか変更で使ってないとこ残ってるかも？
ビルド？どーやるんだっけ？Make残ってない？え、バッチ？

ご注文は？　　　 　 ∫　 　 ／⌒ヽ　　……　設計書一式。
　　　　　　　 　　　　　~━⊂(　^ω^)つ-、
　 ∧,,∧　　　　　　　　／／/　　 /_/:::::/
　(　´∀｀)　　　　　　　|:::|/⊂ヽノ|:::| ／」
　/　φ口o　　　　 ／￣￣旦￣￣￣／|
　しー-Ｊ　　　　／＿＿＿＿＿＿／ | |
　　　　　　　　　| |-----------| |

悪の組織に連れ去られる直前に博士が孫娘に託し、奪いにやって来るあまたの敵とヒーローが闘う。











それは、設計図。

>>15
結構本当なのであった

http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
ソフトウェア設計とは何か？

・プログラム・リスティングとはソフトウェア設計を表現したドキュメントです。

・多くの様々なソフトウェア設計記法は，有益なものとなる可能性を秘めています。
補助ドキュメントやツールも同様に，設計プロセスを円滑にする支援となります。しかし，
これらはソフトウェア設計ではありません。

それは一部の意見だろ。

>>32には古代の暗号マクロに満ち満ちたアセンブラソースをたっぷりふりかけて煮込みたい。

設計図もなしに大勢で一つの物を作れるわけが無い。

>>34 それぞれがそれぞれの味付けしたソース持ち込んで闇なべ作ってたプロジェクト知ってるぞ。

無論破綻した。

うちは大抵２〜３人でやるような規模の小さいプロジェクトしか受けないから
結構ドキュメント周りはいいかげんだし、それで何とかなってるなぁ

>>36 まあ、自分で作ったの数年たってからみてみそ。

間違っても人に投げるなよ。

>>37
あームリムリ、数年も留まってないだろうから
人が書いたソースの解読から始まるなんてザラ

２〜３人程度のプロジェクトなら、機能分担とI/Fきっちり決めて、口頭とソースだけで済むよ。
疑問な点はその都度直接聞いて、分かったらソースに注釈で記述。

だ・か・ら

そういう考え方が徹夜につながるんだよ。
割り増しもらえるからいいって？

や　な　こ　っ　た

>>39
２〜３人程度なら必要ないね。

>>39
技量（理論の勉強と経験からの学び）のある人間で集まったら
その通りだね。ものによっては、業務フローも欲しいね。
業務遂行の道具であるシステムの目的を忘れてしまったら本末転倒だしね。

まあ、この業界自己厨が多いのは確かだな。

自分さえよければ、他はどうなっても別にいいっていう糞が
その後メンテをするって事はまったく考えていないと（笑

仕様書は別見積もり

で、ソース以外に何も無いってのを人に分投げる、と。

http://pc11.2ch.net/test/read.cgi/prog/1104753899/

既存システム関連の仕事で稼動中システムの書類やソースがもらえることが
殆ど無い。ソース貰ってもメイク通らないでやんの。
何にもよこさねえで作らせるんなら新規開発した方が早いわ。

ごちゃぐちゃのソースもらって頭抱えるなら、設計書もらって再設計しろのほうが
なんぼかましなことか。

プロジェクト管理がしっかりできていれば、突貫、残業はそんなにないはず。
PGも、GTD、TOC、CCPMを勉強して、残業しないで済むように頑張ろう！
人生は一度きり。
マジでプライベートを充実させる時間がなかったら、後悔するかもよ。

http://www.amazon.co.jp/dp/4806123315/
CD‐ROM付 目標を突破する 実践プロジェクトマネジメント

大手企業、各地方自治体で続々採用!
現場で使える「プロジェクトマネジメント」のノウハウが一冊に凝縮されました。
「納期が遅れる6つの理由」をはじめ、多くのプロジェクトに共通する問題点を提示、
独自の手法によってこれらの問題を解決に導くまでを、図やイラストを豊富に使ってオールカラーで解説しています。
徹夜、寝袋、乱雑な机、いつまでも終わらない仕事……。
「こんな毎日はもういやだ!」と思っているあなたに、本書と特別付録CD-ROM(30日限定・工程管理ソフト)をおすすめします。

既に手遅れになってから仕事がくることもある

設計書もかけないPGは、どんなにコーディングがすごくても
アマチュアレベルだな
仕事上、設計書は相手との契約書だからな

大阪の堺筋にある株式会社●ィッツ。ここだけは就職やめとくべし。

Ｉ次長。こいつバカ。沸点30度くらいで、すぐ茹蛸みたいに切れる上に、
仕事もいい加減。自分を棚にあげて部下に八つ当たり。出向先の人も
やりにくそうだよ。自分もこいつとは仕事したくないｗ

設計書の承認印をぶち破って仕様変更を押し付けてくるのは日常茶飯事ってのはおいておいて。
まぁ、ちっこいプロジェクトならフットワーク考えると無駄が多いかもしれん。
が、大きいプロジェクトだと責任分解点になるから凄く重要だと思う。

ただ、設計書もどきを作ってる作業が一番つらいな。
これ仕様どおりじゃないよね・・ってのを線表どおり工程進めたいがためだけに作成する無意味さ。
嘘の仕様書の誤字脱字指摘されて、「修正します」って・・ムナシス

【IT】システム設計図の統一ガイドラインを発表…NTTデータなど開発会社9社［09/18］
http://news21.2ch.net/test/read.cgi/bizplus/1190124648/

設計書通りに作ったら動きません

内部仕様書に、せめて状態遷移表ぐらい無いと
ホワイトボックスのテスト項目が作りづらくてしょうがない

>>56
ソースもなしにホワイトボックスのテスト書けるのか！？

>>57
56の上司「書けるか、だと？ 書くんだ！お前の首の上に乗っかっているのは飾りか？」

>>58
ねつ造するくらいは出来るだけの能力は有していますが、意味が無いかと。

>>57
何が言いたいのか分からんが、お前のトコでは状態遷移表書いたらソースコード書かないのか？
なんで「ソースもなしに」とか出てくるのか意味分からん。

>>59
56の上司「意味？そんなものは上が考える事だ。お前は結果を残せ。」

実装後に書く設計書は書くだけ時間の無駄。コード見た方が早い。
実装前に客の承認を得る意味での設計書なら必要。
>>61
おれの今の上司がそんな感じ。
人の上に立つ立場なら部下の意見に耳を傾けるぐらいの度量は持って欲しいね。

>>62
実装前の客の承認を得る意味でない設計書はどうなんだ？

>>63
ケースによる。
必要なときに最低限必要なものだけ書けばよい。
形式的に毎回全部を書く必要は無い。

仕様確認のための設計書は書いたこと無いなぁ
ってゆーかそれならプログラマなおいらが書く時点で…

おいらが書くのは常に実装後だから
カスタマイズや保守、類似機能開発の為の仕様書だよ

うちのSEはプログラム組めないし仕様書かけないから
夢みたいなカスタマイズ受けてくるから
その指示で外注が直しちゃうと破綻すっから
日本語で読める現状ソースみたいな位置付けだ

>>65
一級建築士みたいにある程度資格あってもいいのにねぇ・・
実装はできないかもしれんが、ファンタジーな絵本が上がってくる率は低くなるかと。

日本のSEって存在すごくおもしろいんだな

自分の漫画描いたりするもんな

簡単にちゃちゃっと手を入れて作っちゃうのがいけない

簡単に出来るのね〜とか思われる

>>1
俺も激しくそう思うｗ
馬鹿に限って教科書通りの開発スタイルにこだわる。
そんな奴に限ってスキルが無い。

>>70
ドカタ乙

プログラマ崩れのSEもどきな俺はドキュメントは『メンテナンスの資料です』と嘯いてる。
クライアントの受けは悪いがな。

テスト中に見つけたバグを修正するのに、バグを出した理由から始まって、腐るほどのドキュメントを書かないと、修正できない。
・・・面倒くさすぎて、みんな、バグを隠すようになったよ！

構造化で作るなら、設計書なしでも大丈夫だが
オブジェクト指向で作った場合、設計書がないと
ソースが追うのが大変
（もちろん、オブジェクト指向で正しく作ってある場合で、オブジェクト指向もどきの構造化は別）
オブジェクトは一種のグローバル変数でポインター型だ
これは構造化の時も同じだが、ソースを読みにくくする最大の源因の一つ
そのオブジェクトがどのように、他のオブジェクトとどのように関係しているか
設計書が有った方が良い

>>74
スキルが低いだけだろーが。木瓜。

>>73
俺も結構隠蔽してるよ。
脅威のバグ発生率９９．９９％
テスト時にバグを見つけたらこっそり修正してからテストしなおして
るからねｗｗｗｗｗｗｗ

バグ発生率99.99%は脅威ですよね

>>75
>スキルが低いだけだろーが。木瓜。
オブジェクト指向知らないのか？
少なくとも一般レベルのスキルは持っているが、お前のスキルは？
（俺は、別スレッドで落ちたシステムモジュールを、マシン語レベルで解析して修正するぐらいなら出来るが）

>>77
バイナリ方面は何とかcoreファイル読める程度のスキルしか持ってないが、
仕様書無しなら俺は、構造化よりもオブジェクト指向のソースの方がシステムを俯瞰し易い。

>>74
>オブジェクトは一種のグローバル変数でポインター型だ
オブジェクト指向で正しく作ってある場合に当てはまらないよね？

俺はcaseツールでクラス図書いてスケルトン吐かせてるから、クラス図『だけ』はいつも最新だな。
ソースしかないなら規模にもよるがoopな言語は追いかけにくい。

>>77
赤の他人で悪いが、>>75はスキルの高い人間の書き方ではないなぁ。
人格レベルも。
スキル低いのはいいが、それを自覚していないのが痛いんだよな。
自分の書いたクソみたいなドキュメントは役に立たないんだろうが、
優秀な人の書いたドキュメントは、凄まじく助かるシロモノなんだが、
それが理解できていない。
底辺コーダーとはかくあるべき。

>>78
>バイナリ方面は何とかcoreファイル読める程度のスキルしか持ってないが、
「バイナリ方面」って何、バイナリを直接扱うのか？逆アセンブラじゃなくて？
「coreファイル」は何のために読むの？

OOもどきよりもOOの方が可読性が低いと主張する
輩の集まるスレはここですか？

>>82
＞「バイナリ方面」って何、バイナリを直接扱うのか？逆アセンブラじゃなくて？
>>77で「マシン語レベル」って書いてあるから、実行バイナリやらオブジェクトファイルやら
バイナリのまま解析したり編集したりするのかな、と。

＞「coreファイル」は何のために読むの？
coreファイルって、LINUXとかでセグメンテーションフォルトしたときに
メモリの内容をダンプしたファイルで、デバッグのために読むよ。
落ちた時のアドレス、コールスタックとか簡単に拾える。

まぁcoreファイルをgdbに食わす速い方が多いけどな・・・

>>77
>（俺は、別スレッドで落ちたシステムモジュールを、マシン語レベルで解析して修正するぐらいなら出来るが）

>>78
>バイナリ方面は何とかcoreファイル読める程度のスキルしか持ってないが

>>78は、ダンプファイルが読める程度、これはアセンブラが出来れば普通出来る
>>77は、マルチスレッドのデバッグだから、>>78より高度かな

>>78は、後出しなんだから、嘘でも少しは高い技術を書けるだろう？

よくわかんねぇけど、そこで嘘ついて高い技術書いて何になるんだ？

まぁ仕様書が皆無なら、構造化の方がというか機能分割されてる方が取っ掛かり易いだろ。
どんな機能があるかはシステムを動かしてみればはっきり分かるけど、
どんなオブジェクトがあるかは動き見ても想像までしか出来ないからな。

ある程度分かったあとならモジュール間の関係が薄いオブジェクト指向の方が詳細を理解するのは楽かね。

>>86
>よくわかんねぇけど、そこで嘘ついて高い技術書いて何になるんだ？
これは>>75で、
>スキルが低いだけだろーが。木瓜。
と書いてる本人が、その相手より、後出しでスキルの無い事を書いてたから
不思議に思っただけだ
（普通、スキルが無いとバカにしたんだから、スキルが有るように書くと思っただけ）

つーかさ、
一文だけでスキル判るって天才ってレベルじゃねーだろ・・・
この業界スキルあっても対人スキル持ってない奴なんて腐るほどいるだろ・・・

>>75と>>78は別人

なるほど！！分った。あんがと

俺は自分のチンコを30秒でイかせるくらいのスキルはある。

しょうがきせいの頃は10秒くらいでいってたな
今考えるとありえんわ

しょうがきせいの頃から白いもん出てた訳でもねえだろ。

確かに、おまいらには仕様書はいらないな
書いても、その紙を別の事に使うだろうしｗ

そもそも体裁だけ整えようとするから設計書の存在自体に疑問を感じるんだろ？
まあドキュメント自体、後回しかほったらかしにならざるを得ない状況じゃどうしょうもないかｗ

設計書とソースの修正だけなら問題ないけど、
障害表、障害報告書、修正前後の画面帳票等の出力結果、横展開確認書、
さらに確認会議、とか。
こういったことに無駄が多く、生産性がすばらしく落ちる。

>>96
そういうのに限って、設計はおろか
何のシステムかすらよく分かっていないような方にまで
提出しなきゃいけないんだよな…。

説明も一からだし
かなり噛み砕いた資料も添付せんといかんし…。

ホワイトボックステストって、コードから起こすだろ・・・

>>55
あるあるｗ

ISOなんて審査員が来たときだけ辻褄合わせしときゃいいんだよ
あんなんまともにできるかボケ

>>13
俺のすごいところは何万行のプログラムでも
一度もコンパイルすることなく一気に書き上げる。
しかも動作確認しないで納品する。

いちいち動作確認してから納品するやり方は素人

朝から90前のレスに・・・

小鳥が３歩歩くと忘れるのと同じで３行書くと
どんなものを作ろうとしてたか忘れる。仕様書は大事。
でも仕様書を何処にやったかもよく忘れる。

ていうか、仕様書がないとテストシナリオを書くという退屈極まりない仕事まで自分に回ってくる。
そういうのを他人に押し付けるために仕様書は必要。

設計書は抽象化という意味ではあって然るべきだとは思う
でもソースとの乖離が問題
プログラムに設計書まで含められるような手法があればいいんだけど

Windows Vista
http://recwav.dip.jp/M_RECWAV_Media.asp?Speech=1221925210420080108190059

亀レスだけど、オブジェクト指向を正しく適用したアプリは仕様書がないと読みづらいとか言ってたヤツは
オブジェクト指向がまるでわかってないかと。
責任の切り分け、インターフェイスの粒度の考慮、抽象化、適切な名前付け、広義のカプセル化、等を正しく行っていれば
仕様書なんてなくてもあまり問題ない。
単体テストコードもあればなお良い。



読み手がオブジェクト指向わかってなくても問題ないかどうかはわかんないけど。

>>106
マジな話、研修終わったばかりでしかも出来の悪い方の新卒にも理解できる
ものを求められたことがある。

全体が見えないんだよ全体が

>>106
分業ができないだろ、分業が。
独りで隅から隅まで面倒見る小規模アプリならんな戯言も吐けるが。
きつい納期で中規模以上のアプリを分割して仕上げるには、どこを誰がどの程度やるのかを決めなきゃならん。
そのために設計は必要。さもないと同じような機能の関数を重複して作ったり、など無駄が出る。

ケーキのサイズがわからんのに切り分ける事はでけんよ。

>>109
それ、全く別問題。
読みやすさに着目した話なんだから。

>>106
＞適切な名前付け
「適切」の意味が微妙だが、「何のクラスか(とかメソッドとか)を良く表した名前」ということなら、
そんな「適切な名前」は存在しない。
みんな(プロジェクトメンバの範囲でも)に「何のクラスなのか」が伝わるような名前なんて無い。
価値観も感性も人それぞれなのに、精々単語レベルの組み合わせでで誤解無く伝わるなんて言うのは、
他人の人生をバカにしてる。(言いすぎ？)


さておき。
オブジェクト指向やら構造化やらにかかわらず
個人的には要件仕様書ぐらい無いと手の付けようが無いねぇ。
ポロっとソースだけ渡されて「理解しろ」と言われても
そのプログラムが何のためのプログラムかぐらい知っておかないと、
読み辛くて仕方が無い。
贅沢を言わないから、開発の背景、目的とシステム構成図だけでも欲しい。
表紙も目次も要らない。
A4で2ページぐらいで良いから。
ホント・・・マジで・・・引継ぎぐらいちゃんとしてください・・・orz
前任者もう居ないから誰かに聞くことすら出来ネェヨ。
俺が今何の開発してるのか、誰か教えて・・・

>>111
> >>106
> ＞適切な名前付け
> 「適切」の意味が微妙だが、「何のクラスか(とかメソッドとか)を良く表した名前」ということなら、
> そんな「適切な名前」は存在しない。
> みんな(プロジェクトメンバの範囲でも)に「何のクラスなのか」が伝わるような名前なんて無い。
> 価値観も感性も人それぞれなのに、精々単語レベルの組み合わせでで誤解無く伝わるなんて言うのは、
> 他人の人生をバカにしてる。(言いすぎ？)

言いすぎ

>>111
何のために人間は脳味噌があるんだ？

思考ができない人間モドキでなければ、すぐピンとこない名前でも「説明してもらったり、
勉強して推測することで、名前が表す機能を理解する」という道があるだろ。

「適切な名前」は、その理解に必要な時間を短くできるといった程度のものでよいと思う。

「誤解なく伝わる名前」に多くを求めすぎ。
脳味噌をまったく使いたくないってことか？
そんな人間モドキは、引き篭もってるのがいいと思う。

>>113
＞説明してもらったり
説明のために他人の時間をいちいち使わないように仕様書があるんでしょうに、という話なんだが。
その場に説明できる人間が居るとも限らないし、推測だけでは誤解が生まれる可能性がそこそこにある。

俺自身は「誤解なく伝わる名前」に多くを求めてない。
だからこそ「ソースの理解のためには仕様書が重要なんじゃないの？」と思う。

最後まで言うと、>>106の言う「正しいオブジェクト指向」が使われていたとしても
仕様書が無かったら問題あるだろ、というのが俺の言いたかったことです。

言葉足らずですんまへん。

確かに、名前だけで意図を完璧に他者へと伝えることはできないけど、
名前とコードが組み合わさればどうだろうか？

もちろん、コードが汚ければ話にならないだろうが、
だからこそ、
＞ 責任の切り分け、インターフェイスの粒度の考慮、抽象化、適切な名前付け、広義のカプセル化
と、色々なものを挙げてある。

それと、今気づいたのだがもう一つこれに追加させてもらいたい。
それはクラスやメンバの概要を説明するコメント。
コード中のコメントは極力少ない方が良い (コメント書く代わりにリファクタリングを検討) が、
クラスやメンバの概要を説明するコメントは、あった方が良い。 (C#でいうとこのXMLコメント)
パラメータや戻り値の説明、メソッドを使用するための前提条件などもここに書く。

設計書なんて後から作るもんだよ





って言う人は大抵納期を守らない
機能の箇条書きだけじゃ設計書とは言わんよな
つか完成した状態が完成してみないと分からないので
手戻りはあるは、テストはほとんどされてないわでもう…
勘弁してくださいよ先輩

>>106
どんなに理想的なコードやコメントが組めても
仕様書はある方が絶対いいと思うぞ
というか最低でも業務分析フェーズで作ったものは残してくれと思う。

コードを見れば「その処理が何をやっているのか」はわかるが
「どうしてその処理が必要なのか」まではスグにはわからんよ。

ごめ、誤読した。
オブジェクト指向のコードって読みづらい・追いかけづらいから
仕様書を読ませろ、って話か。業務云々じゃなくて、
システムのアーキテクチャが理解できないってことか。

>>117
ズレてたらすまん。
業務分析フェーズって企画段階でしょ？
企画→システム化で差異がでない訳無いんだからいらなくね？
受注以降フィードバックする事は無い物だし、マの納品対象でもないと思うが・・・

>>119
すまん「業務分析フェーズ」って言葉は無視してくれ。
俺が言いたかったこととは本質的には関係ない。

俺が今知りたいのは
「なんで休暇届出申請処理の“勤続年数”算出ロジックと、
貸付金申請処理の“勤続年数”算出ロジックが微妙にちがうのか」
なんだ。

ロジックを見れば、
休暇側が「申請日当日 - 入社年月日」、
貸付金側が「申請日当日の属する月の月末日 - 入社年月日-1」
になってるのは分かる。どんな処理をしてるのかはわかるんだ。

でも「なんで月末なのか」とか「なんで入社年月日から1引くのか」を
説明した文書が無いんよ。それを現場で唯一知ってたSEは大昔に辞めてて
連絡もつかないんで、結局クライアントに問合わせ中なんだが、
ドキュメントが残ってればなぁ、って思いながら書いたのが>>117だ。
こんなんだから仕様変更がし辛くてしょうがない。

それはコメントに書くべきことで、外設や内説に書くのはやりすぎ。
単にソースコードレビューやってなかったツケだな。

設計書書いたら後はコーダー君がやってくれる。設計書たくさん書いたから品質も最高だ！（妄想）
↓
保守や改修でスパゲティを眺めて担当者涙目。

古今東西よくある話。設計書がいかに無意味かよくわかる。

OOPだー、とかほざいてクラスが増えすぎ関連性爆発に陥ってるプロジェクトも多いな。
デザパタも知らずにアーキテクチャアーキテクチャ吠えてる似非SEが多いとこうなる。
簡素で信頼できるブロックが必要なのに、水気が多すぎるうどん粉を捏ね回してるタイプだな。

>>120
その例なら要件定義フェーズの成果物でマの納品対象だと思う。
開発時の要件追加・修正がフィードバックされてないのは良くある話（単に要件定義が適当だって話っぽいが・・・）

クライアントに問い合わせ出来るだけいいよ。
世の中には要件定義書も何も残ってなくて、生ゴミ（画面足らず・一部ソース無し）しかない場合だってあるんだ。
その上、アホPM（要件非認識）が対面気にして要件再確認許可しない事があるんだから・・・

>>115
中身まで読まないといけないようなら、やっぱりモジュールの一覧性悪いよ。

一通りソースに目を通しておおよそのモジュールの役割を理解しないと
システムの概要が掴めないんで、ボトムアップでしかソースが読めない。
規模にもよるだろうけど、ある既存のソースの部分を読むときには
システムにおいてどういう位置づけのモジュールなのか分かってる方が
理解し易いと思ってる。
(ここで「ボトムアップのが読み易い」という人なら、まぁ平行線だな)
ので、要件仕様書とシステム設計仕様書、もうちょい言えばクラス図ぐらいまであれば
引継ぎに掛かる時間はグッと減るはず。(まぁ仕様書の出来にもよるんだろうけど)

詳細設計レベルの話(メソッドの使い方だの)はコメントで良いと思う。
個人的には規模がデカくなるといちいちgrepすんのもしんどいから、
最初にDoxygen辺りでチョロっと一覧だけ作ることが多いけど、
詳細設計仕様書っつーほどのモンは要らないかな。

>>121
> それはコメントに書くべきことで、外設や内説に書くのはやりすぎ。
> 単にソースコードレビューやってなかったツケだな。

金銭に関わる仕様なんだから、要求仕様書に書かれてしかるべき。

>>121
> それはコメントに書くべきことで、外設や内説に書くのはやりすぎ。
それって、アジャイル開発が念頭にある？
ウォーターフォールでやってきた俺にはピンとこない話なんだが。

>>124
ごめ、「業務分析フェーズ」じゃなかったか。

> アホPM（要件非認識）が対面気にして要件再確認許可しない
似たようなことは遭遇したな。「もうン年以上前の話だし、当事者も異動して
当時の経緯聞いても正確なことは分らんだろ」と言われたことはある。それでも
一応聞くだけ聞いてみたけどね・・・

>>126
＞金銭に関わる仕様なんだから、要求仕様書に書かれてしかるべき。
金銭に関わる仕様だからっていうか、
システムを使用する業務の知識だからじゃないか？

本意は同じ気もするが。

書き方にもよるだろうけど、改修・運用保守時に最低限必要なDocumentって何よ？

>>129
契約書。
その仕事、ほんとにやるの？って。

ちゃんとした設計書書かされても何故か改造や拡張の仕事の時には
元の設計書をもらえない

門倉貴史「ワーキングプアは自己責任か」(大和書房)という本によると、こうだ。
「仮に、国内企業が退職する団塊世代の人たちに『継続雇用制度』を導入して(中略)団塊世代を非正規雇用として採用したほうがコスト的に圧倒的に有利になる」(p.157)

俺が爆笑したのはその直後の文。
「筆者の試算では、20〜24歳と60〜64歳の労働生産性には、大きな差がみられず、むしろ60〜64歳のほうが20〜24歳の労働者よりも平均的な労働生産性が若干高いことが観察された(0.63%程度の差)。」(p.157〜158)

さすが団塊は神世代だ、20〜24歳よりも何と0.63%も労働生産性が高いと認定されるなんて。

お前らすごいな
俺、小規模から中規模のプロジェクトしかやったことしかないけど外部設計書、テスト指示書以外書いたことないぞ
小規模なら外部設計書しか書かないなんて普通かな


まあ一人でしか開発したことないからかもしれんが

他人の作ったものをいじるとき
設計書はテストケースの網羅性を高めるために使う
でも結局はソースを読むのが一番確実なんだよな

自分でアルゴルを考えてプログラミングするなら設計書なくてもいいんだけど、
他部署の人から、設計書なしにテストプログラムだけ渡されて
これを実装してとか言われて困ってます。

しかも、テストプログラムがバグだらけなんですが・・・。　せめて少しはデバッグしてくださいよ。
バグのままく見込んだらおれが怒られるし・・・

日本人の大卒はおそらく
先見性・論理性・計画性にかけて飛び抜けた劣等人種
頭脳内で設計を組み立てる能力が無いのに
より具体的な設計書を作るなんで無駄無駄

物を作ろうとしない奴に何やらせても無駄

オレがソフトウェア開発プロジェクトを進めるうえで
必要不可欠だと感じたドキュメントはこのくらいだった。
・要件定義書（ここでDFD、E-R図も作成する）
・作業分割図（これができない＝デスマ）
・ディレクトリ/ファイル一覧（どんなファイルを作ったか網羅する）
・スキルリスト（実装技術と書いた経験がある文書、業務経験の3つが知りたい）
・コーディングルール（命名規則、使用禁止関数、コメントのルールなど）
・ユーザ向けマニュアル（PC使えない人でも読めるもの）

逆に「ここまで文書化？」と思ったのは次のようなもの。
失くすのはどうかと思うが、もうちょいシンプルにしたい。
お客さんが欲しがるなら仕方ないが、読んでくれないならやめよう。
・基本設計書（どうせ後で修正する）
・詳細設計書（ソースコード読めば分かる）
・運用計画書（GUIの管理用ツール触れば分かる情報が多い）
・画面設計書（画面みれば分かる。それよりユーザI/Fとマニュアル作りこみたい）

要するに、成果物みれば分かることの文書化に反対。修正するとムダになる。
早めに何ができるかユーザに理解させ、とっとと作ってレビューしたい。
開発メンバにできる事を把握して、納期までに何が作れるか見積もりたい。
柔軟性がないプロジェクトはメンバーの退職に繋がる。

>>138
ホントにリーダ以上でやった事あんのか？
金取れんの要件定義書、ユーザ向けマニュアルだけだぞ？

まぁ、内容見る限り自社サービス系企業のPGか・・・

>>139
ユーザーから金取れないから資料作らない
→後でですまですね。

開発が効率よく進む為には、ユーザーとは無関係にある程度の内部資料は必要

>>140
だからリーダ以上やってないのに知ったかぶるなよｗ

>>141
ユーザーから金を貰うというか、

効率よくスケジュール内に仕事が終わるために、
資料を作る方が安上がりになるから作る訳だが。

こんなに仕事したら体壊すよ。
都内のPG/SEはハードすぎる。

>>142
仕方ねぇな・・・

非納品ドキュメントのコストをどこから捻出するかって話だよ。
元々非納品のドキュメントを作るなといってる訳じゃないし、当然必要な物もある。
138はそのドキュメントコストを絞ってるんだから、設計？実装？テスト？リスク？
ドキュメントコストはドキュメントで一括りで管理すべき。

設計や実装にドキュメントコストが含まれてるなら問題ないが、そんな見積り方法無いだろ？
まぁ、そんな温い見積りが通る企業かも知れんがなｗ

>>144
納品物に含まれてないからと言う理由で、中間作成物としてのドキュメントを作らないなんて、その場のノリで作ると噂のゲーム制作の現場でさえありえないwww
だが、毎回デスマーチ状態の携帯開発の現場では常識のようだった。

日本語不自由な奴しかいねーのかよ

マ板だからな
提案、見積もりからやったことあるやつは少なく、
やったつもりになってる奴はものすごく多い、
って事だろう

保守も含めてトータルで考えると、生産性は落ちてない気がする。あがってもいないけどｗ

>>148
ドキュメントの無いコードのメンテナンスの効率の低さは異常。

あと、エミュレータの無い組み込み系のメンテナンスも効率の悪さは異常。

ついでに、再現性の超低い不具合の改修効率の悪さも異常。

新規開発で汚いソースだけ残してドキュメントを残さずトンズラこく
連中ってプロとしての自覚あるのか？

>>150
仕様です。

>>150
特に偽装派遣はその場凌ぎしか考えて無い奴ばっかり。
スケルトンに1行コメントで実装方針記述して渡したのに1行コメント全削除＆スパゲッティ・・・
マルチスレッドで動かない実装だったし、退場頂いて別な人に作り直してもらったよ。

>>152
>スケルトンに1行コメントで実装方針記述して渡した

それは、指示の仕方を間違ってはいまいか？

>>153
どう間違ってんの？

>>154
ソースのコメントで作業指示www　おまい最低だなwww
でもって消されたとか、当たり前だろwww　狂ってるwww

ちゃんと指示書起こせよwww

>>155
詳細設計書＋指示書＋1行コメントなんだけど？
何が最低なの？どう間違ってんの？

>>156
君の情報量の少なさが原因だと言う事に、今新たに気付かされたよ。
>>152 のどこをどう読んでも、設計書や指示書の類の話は出てないからね。

ま、実際そうだったんだろ？　後付けでナニを弁解しても遅いよ。
指示書や設計書があれば、そのように実装されないという事はまず無い。

>>157
設計書＋指示書は当たり前だから省いただけなんだけどさ。
まぁ、ここで理解されても意味無いし、どーでもいいやｗ

>>158
スレタイ嫁　説得力無しw

その設計書自体が
・スパゲッティ
・マルチスレッドで動かない実装
という可能性もある訳だが。

その１行コメントに、「エラーが起きたら最初に戻る」とか書いてあれば、
実装すればgotoとかになる訳だし。

>>160
設計書にそう書いてあれば、何も問題無いんじゃね？

じゃぁお前は先生が死ねといったら死ぬんだな？

夏休み？

そう
明後日から夏休み兼秋休み兼冬休み兼春休みだ。

うちの現場さ、書けない組めない奴が上流やってんの。
もうね、設計書はもちろん、フローもテストケースも何も書けない。
人に見せるための書類が全く書けない。
でさ、何が出来るのかっていうとお客さんと話して、口頭レベルで下に伝えるだけ。
本当にそれしか出来ない。
こんなのが上やってるというだけでトップレベルの単価貰ってたりするんだから
若くて出来る人はみんな嫌になって引き上げちゃうのね。
本人は気付いていないんだろうけど、皆言ってるよ。あいつとは関わりたくないって。
シ○ポーのいしざ○！おまえのことだ！！

何度も何度も何度も既出だろうが、
プログラムの世界で言う「上流」という名目は、一般的に使われる意味での「階級」という意味は持ち合わせていない。
工程を川の流れに例えて、上流→下流と表しているだけ。

どこかのバカはそれに気付かず、上流工程の方が下流工程より偉いとか思っている。

書けない奴が上流ってあり得るの？

>>150
納品物リストにドキュメントは含まれておりませんでしたが？

>>168
それはタイトルだけそれっぽい名前が付いてて申し訳程度に書かれた中身スッカラカンの
PowerPointやExcelのファイルのことを言ってるのか？

ソースファイルのコメントを抽出するツールで作ったそれの事です。

>>167
コードが書けないSEもいたよ。

>>171
×コードが
○ドキュメントもコードも

バランスのいいやつが少ないんだよね。
コード書きは優秀なんだけど、ドキュメントになると、そもそも日本語が・・・ってなくらい。

VB.NETでオブジェクト指向で作ったのに、関数仕様書書かされたことあるなあ。
ISOがどーたらこーたらで。

途方にくれたもんだｗ

>>132
んなもん、経験値が違うんだから
あったりめーだろうが。
それより若いのにもっと経験値をつませろってことよ。

設計書作らないで脅迫されるままに１０万行以上打ち込んだら
最初の頃打ち込んだ内容を完璧に忘れて

数ヶ月前の自分に恨み言を言ってる

そんな俺が来ましたよ。

ITコンサルタントになるにはプログラミングの他に何を学べばいいんですか？

>>177
なんでこんな過疎スレで釣りはじめてんの？

10社で作って、基本設計書のフォーマットが微妙にバラバラだったのが笑った
後になって、揃えろとか言い出して、みんなで全修正。
先にきっちり決めなきゃ、そりゃどんどんずれて行く

それで終電でサビ残。
誰もが知ってる会社名なのにｗｗ
管理が専門なのに糞すぎる

>>179
SIなんてそんなもんだ

悪い仕事に当たると無から有を作る、原理的に不可能な事をする
連続だから嫌だ。上がプラン無しだからな。しかもやり方まで強制してくる。
「そのやり方では不可能」という意見は自動的に無視されて生産性の悪さ
だけでプログラマを叩く。
いよいよ徹夜が続くと「今更言っても仕方が無い。」の一点張り。

Nで始まってDで終わる4文字のSIreが作った
大規模プロジェクトの仕様書のフォーマットに
一目で分かる誤植やらありえない日本語遣いがあって、
これが2年ぐらい放置されてるんだけど、なんなんだろう

>>182
書類は中身じゃなく、あるかどうかで判断される。

>182
NTTデ○タ？

一機能数百枚のテスト仕様書のチェックやらされた
中国人が書いてたから俺のするのは日本語の間違いと体裁のチェックをするだけで
俺たち以外にもドキュメントの品質管理がたくさんいた。
どうみてもあんな量まともに書いてないと思うし、誰も読まないと思うし、アホかと思った。

テスト仕様書はね〜
正直力入れるところじゃないんだよね。
一度しか読まれないし。

全くないってのはウンコプロジェクト。
ないよりはあった方がいいよ。

何年も前に作られて動いてるプログラムのソースを読んで要件定義書を書けと言われた。
なにか良いコツ、良い参考書があれば教えてください。

えっ

とりあえずまずは全体を把握する。
パッケージ構成、フォルダ構成から、そのフォルダごとの機能を推測する。
あと、データベースの構成も押さえる。

あとは>191が教えてくれる

とりあえず何をしているプログラムなのか
把握しなきゃならんと思うので、
Wikiにソースファイル名でページ作って
ガンガン内容書いてけ。Wikiじゃなくてもいい。

要件定義って、むしろソフトを弄って、何ができるか書いたほうがいいんじゃね？
ソースからなんて子細すぎて要件定義じゃねえだろ。

結局のところ「設計書を作れ」と言われて作ってるわけで、上司としては作らせておけば引継ぎの指示が出しやすい。
「仕様書読んどけ。設計書が解りづらい？作った奴はクビだ」という指示が出せる。
少なくとも何も無いよりはマシな状態が作り出せる。

言うまでも無いが、上司は設計書を見る気はサラサラ無い。↑の状況が欲しいだけなのさ。

↑が言うところの困った上司ってどこにでもいるなｗｗｗ

え？要件定義書からなんで設計書になるの？
>>192以外に考えられん。

ソースコードで表現できることはドキュメントにしない。ソースコードでは表現できないことをドキュメントにする

ドキュメントにはソースコードでは絶対に表現できないことを書く。
分析ではユースケース、要求仕様、
設計では期待される入力値、出力値、副作用

あとはソースコードで表現しにくいこともドキュメントにしておく
クラス図、非同期のシーケンス図、データフロー図(OOと相性悪いので自分用だけど)等


ソースコードで表現できること(フローチャート、ステップ単位の処理の詳細等)の設計は
ビルド、テスト無しでソースコード書いてレビューするのが一番速い。


ということを会社で言いたいが言えない今日この頃。

ちくちく詳細書いてる位だったらコード書くわなぁw
つーか書類書類言ってねーで本来の仕事させてくれよと、プログラムができてなんぼだろとw

詳細設計なんか書かされるのは、プログラマとして信頼されてない証拠

机上でロジック組み立てさせてレビューしないと、いきなりコード書かせても
手戻りばかりでしょ、おまえらなんて

詳細設計作らないとか、引継ぎどうすんだよって話。
フローチャートを描く必要は感じられないが、
システム側の仕様は決めておく必要あるだろう。

別に詳細設計だけを書くんじゃなくて、
先にコード書いてしまってもいいけどね。

>>199
各関数の入出力+副作用まで書いておけば十分じゃね？

後は全体の大まかな設計と。

>>198
それステップ単位のドキュメントじゃなくてコードレビューでいいと思うんだ。ビルド、テストしなければドキュメント書くより作るのも直すのも早いし。

コードレビューして相手が理解できるまでコメント入れれば後での保守も問題無い気と思う。

だいたいもっと酷いコード散々見てきただろーが。

状態遷移図は必要だな。
設計しないできちんとできるのはちっちゃなプログラムだけだろうｗ

>> 201
状態遷移図は確かに必要だね。
それはソースコードでは表現しにくいことだから。

でもこのスレで問題になっているのはコードレベルのドキュメントじゃないか?
そして状態遷移図もクラス図もまともに無いとか。

>状態遷移図
いまいち何を書いていいのかさっぱりわかんね

>> 203
永続的に稼働するようなシステム(サーバーとか)や割り込みが入る組み込みシステムだと
状態変数を持ってその値に応じて制御が変わるので必要性がわかると思う。

全てのシステムに必要なものでもないね。状態持たなければその方が良い設計であり理想的なわけだし。

詳細の仕様書を作る時間の見積もりだけは見積もれない
すっげー時間かかる
作る時間の１０倍以上は余裕でかかる自信がある

だから書けって言われたもん以外は自分からは絶対書かないようにしてる
これ、マジで無駄だわ
めっちゃ詳細まで書く時間まで見積もってマジでこんなもん作ってほしいのか？
同じ規模のアプリが８〜９本は作れるぞマジで

担当者によってショートカットやタブの動作までぎっちり書かせないと気がすまないキチガイにあたると最悪
プロジェクト終わってからしつこく電話かけてきてマジでウゼェ
詳細仕様書書けって言ったら時間で給料もらうか別料金にしてくれって思う

>>205
本来は、納入仕様として取り決める必要がある部分なのに、
ＩＴ系はその辺いい加減だからねぇ。

でもこんなもんマジで書くのを強制されるなら
もうこの仕事は金にならないな
ホントにこの辺はしっかり金もらっていかないとダメな部分だと思う

>>200
関数のドキュメントはソースコードでいいだろう。
Javadocやらいろいろドキュメント化するツールがあるからそれでいい。
関数の設計は設計段階にやることではない。
ソース書いた後に自動出力でOK。

というか、全体の大まかな設計だけでOK。
あと項目レベルで外部とのインタフェースあるならそのドキュメント。
特殊仕様があるならそのメカニズムを説明するドキュメント。

ソースが仕様書であり設計書
今回ドキュメント書きまくってそこに落ち着いた

おまいらがこれまで経験したなかで、一番仕事がやりやすかった仕様設計ドキュメントってどんなの？ 量や内容といった点で。

上流、下流じゃなくて
設計、製造だろ？

機械なんかは、図面書く奴と、材料集めて削って組み立てる奴は
まったく別だろ？　町工場なんかは兼ねてる場合もあるにはあるが。

あと、設計書にフローチャートは無用。　その作成は製造の仕事。
設計で大事なのは、モジュール分割と、モジュール間のインターフェース仕様だな。

小規模なソフトには、それで十分。
規模が大きくなるほど、ＵＭＬなどを駆使して、十分な設計が必要だろ。
常識だがな。

UMLってわかりやすいんだけど、仕様に依っては表現できないことがあるよな

プログラムではめちゃくちゃミクロな内容で関連ができてしまうのに
上から眺めるとそういう部分が見えない場合なんてしょっちゅうだな

このスレ、たまに偉そうに語り出す奴がいておもしろいなｗ

>>213 それは分析が甘いから。　グローバル変数いっぱい使って値を受け渡すとか
　　　あちこちでＤＢを書き換えているとか、あちこちで別個に１つのＩ／Ｏに
　　　アクセスしてるとか．．そういう場合だろ？

　　　たとえば、１つのＩ／Ｏアクセスは１つのドライバモジュールを介して
　　　行わせるだけでも、絡み合いが少なくなるだろ？

　　　オブジェクト指向の発想を設計に取り入れれば、モジュール間の絡みは少なくなる。
　　　処理をほぼ丸投げできるモジュールの集まりで構成するのが、ソフト設計の極意だろ？　　　

仕様とロジック間のＩ／Ｏさえ決めれば設計が手抜きでも充分いける

逆に仕様とロジック間のＩ／Ｏが曖昧のまま設計すると後でちぐはぐなモンが出来上がる

仕様とロジック間のアイオー。
それは設計とは言わないのか？

形式手法とかいう
プログラムだか仕様だか設計だがよく分からないものを導入しようとしている
俺の会社の役員に何か言ってくれｗ

こんなのを仕様書にしたら、仕様書を作る段階で
設計書がいるよｗ

UMLがいらないとか言ってるやつらって
プログラマとしてどの程度のレベルなの？

実際の開発ではumlに書けるようなとこは問題にならないのでなんとも

>>219
UML必須の開発現場なんて行ったこと無い。
クラス図だけありゃ十分

仕様書のレベルが低いから仕方ない。

ソースコードが一番詳細な仕様書なのに、
ソースコードのチェックは全く入らない俺の会社。

偉そうに語るだけに、いいコードちゃんと書いてるんだろうな

>>185
そんなんで工数かけてもオフショア利潤まだ残ってんだろうな・・・

未だに、誰が見ても同じコードが書けるような
詳細設計書がベストだと抜かす奴がいるけど
なんで、コード書いてトライ＆エラー繰り返すより
excel上でコピペしたり改ページ気にしながら
UMLとかこねくり回すのが優れていると考えちゃうんだろうね。

だいたい誰が見ても同じコードが書ける設計書なんて
未だ見たことないし。

まず使用するフレームワークのマニュアルを詳細設計書に添付する作業から始まる

>>225
そのままコンパイルできそうな詳細設計書を見たよｗ

>>227
ifとかforが書いてあるのなら
俺も見たことあるぜ

コードレベルの詳細設計所って、最初の開発終わって年月がたつと
修正なんかが抜け落ちまくりで、最初はこう作ろうと思ってたって
だけの書類になってることが多いやね

設計書でも、
・自分の頭の中を整理するため
・他のメンバーと考えを共有するために
作成するものなら、必要だし、また自然に作られるものだと思うが、

納品物のために作る設計書はマジで不要だと思う。

>>229 でもそれを出せという客が多い。
プロマネは金と成果はもっていきながら、俺が全部かいて全部怒られる。

納品の為につくる詳細設計書だと、
コード買いてからの方が書きやすいよね

書く前だと、どうコーディングしてもいいように
あいまいな表現をするよう気をつかわなきゃいけないし

着手後の細かい仕様変更や不具合の修正分が
盛り込まれないまま提出する事も時々あるなぁ

仕様書設計書、自分のいい加減な仕事を否定させないために作るな。
そういわれて作った代物

案の定

あっはっはw

このスレで詳細設計は必要ないと言う奴は、こんな感じだろ
A「詳細設計は書かないの？」
B「詳細設計？、そんな物書いている暇があるならコーディングした方が早いだろ」
A「でも、オブジェクト指向で作る時は、詳細設計した方が良いよね」
B「オブジェクト指向なんて分からん！！、俺はPOA作るから良いんだ」
A「．．．（たしかに、POAなら詳細設計は、あまり必要じゃないけど｝」
A「でもオブジェクト指向覚えたら、改造やメンテが楽になるよ」
B「アホか？、楽にしてどうする、工数が減らされて俺みたいな使えない奴から切られるだろう」
A「確かにそうだけど．．．」

>>234
古くさい言語で古くさい開発スタイルが好きな人間ほど
詳細設計が好きだから、それはない

でも自分でも作るもんがわかってねー奴とかには書かせたほうがいい＞詳細設計書
元ＰＧのＳＥとかだったら結構安心できるけど
元素人のＳＥはダメだ
まったくダメ
金のある会社でも元素人のＳＥとか育ててるけど全く意味がわからん
はじめの一歩から踏み外してる奴はどうやっても使えないよね
いまの外勤先にはいないけど前いたところは酷かった

ってそれじゃ詳細設計書なんて書いてもしょーがーねーじゃんｗ
ってそうなんだけどさｗ書かせないと自分がした発言すら忘れるからな

>>234
> A「でも、オブジェクト指向で作る時は、詳細設計した方が良いよね」

この「良い」に疑問の余地は無いのかね？

>>237
>この「良い」に疑問の余地は無いのかね？
疑問の余地など１�_もないわｗ

オブジェクト指向は詳細設計が必ず必要
詳細設計”書”はケースバイケースだなｗ

詳細設計が必要ないほど小規模は開発は
オブジェクト指向で作る必要なし
だからオブジェクト指向は必ず詳細設計が必要だなｗ

>>238
お前のレスの１行１行にはいちいち根拠がまったくないな
必要とか断定口調の割りにはそれを裏付けるような内容は書いてないし・・・

>>239
心配するな、始めからアホには理解できないと分かっているｗ

だいたい、説明しないと分からん奴は、説明しても分からんからｗ

必要性が分かるような技術力は、自分で身に付けないとなｗ

>>240
それって後で困るぞ
言っとくけどこの業界な
アフォが学会で延命するためにすげー無駄な技術で溢れてるから
自分で採用する技術の良し悪しも判断できない人間がくるとまったく無駄な人生費やして終わるよ

オブジェクト指向も実はそのひとつで
これで生産性が上がるって説明できる人間は本当にいないから

業界全員で騙されちゃった例
根拠のない技術って怖いよ
クラウドもそうだけどこういうのバズワードっていうんだぜ

>>241
じゃあ「オブジェクト指向を撤廃することで生産性が上がる」という事を説明してください。

「馬鹿にはわからない理屈なんです＞＜」
っていう裸の王様ごっこか？

>>242
だれもそんな話してない。

「オブジェクト指向で作る」ことと「詳細設計した方が良い」ことのつながりが
不明だろうって話。

>>243
自分の書いたレスをちゃんと読み返してくれよ。
自分は悪くないみたいなつまらない自己弁護はしないで、発言を見直してくれよ。

>>238の主張は「オブジェクト指向は必ず詳細設計が必要」だから、
「詳細設計した方が良い」というのは議論していない事のように読める。

>>242の発言は「詳細設計しないほうが良い」と言っているようには読み取れない。
「オブジェクト指向」を否定しているように読める。
「オブジェクト指向は無駄な技術」だから「後で困る」と言っているように読める。
なぜ無駄なのか、なぜ後で困るのか、そこんとこを説明してくれ。

>>244
ごめんよ。

> B「詳細設計？、そんな物書いている暇があるならコーディングした方が早いだろ」
> A「でも、オブジェクト指向で作る時は、詳細設計した方が良いよね」

これ読んだとき、詳細設計するかどうかと、それを文書として書くかどうかを
ごっちゃにしてた。

Bは詳細設計をコードと別の文書として書く必要は無いといってるのに、
それを「詳細設計しない」と思い込んだAが変な反論してるんだな。
で、つられてBも変な方向に反論してる、と。まともな会話になってないね。

っていうか、「詳細設計」ってのが何なのかわかんなくなった。
コーディングしてれば少なからず脳内で「設計」はしてるよね？それは「詳細設計」じゃないの？

このスレの>>1自体が「まともな会話になってない」と、俺は思う。
「設計とはなんぞや」というのが誰も理解できてないな。

「コーディングすること」と「設計すること」を一致させるということは、
大工が設計図無しに家を作って「設計しながら作った」と主張する事に等しい。

・設計書を書かないで建築すると建築物の品質はどうなるか
・建築途中もしくは改築時に大工が変わったらどうなるか
・一生住む家と1日しか住まない家では設計の価値は変わるか

を考えると、そもそもどれも生産性とは関係ない。
「設計書を書くこと」と「生産性が落ちること」のつながりが不明だと思うのだが。

ちなみに、実装に関係ない書類を作ると実装が遅れというのは当然だぞ。

>>246
大工とプログラマを同列に扱える理由は？

>>246
"What Is Software Design?" By Jack W. Reeves
http://www.developerdotstar.com/mag/articles/reeves_design.html
・・・ありゃ？ひとつだけあった邦訳が 404 になっちゃってるね。

ソフトウェア開発において、大工の立場にいるのはコンパイラであり、大工が見る
設計図にあたるものはソースコードである、という話。

つまりソースコードを書くための設計書を書くということは、大工のたとえで言うと
設計図を書く前に設計図を書くための別の手順書を書くという、明らかに無駄な
行為にあたるということ。

こっちが真実でしょ。

コンピュータ視点すぎて参考にならん

>>249
コンピュータソフトウェアの開発してるんじゃないの？
もしかして本職の大工さん？板違いですよ。

>>246
受け売り過ぎて、しかも極端な喩えすぎて話にならんわ。
自分の言葉でしゃべれ。

オブジェクト指向は何で詳細設計が必要か？　俺の主観で回答するな〜
前提条件として小規模開発は除くから、あと、詳細設計＝実装レベル設計と考える

まず、基本設計（概念設計）は構造化、オブジェクト指向ともに必要
（まさかこれも必要ないと言う奴は、さすがにいないだろうな？）

本題の詳細設計は、構造化の詳細設計はアルゴリズムがメインだが
アルゴリズムは、実際にコーディングして動かさないと分からない事が多い物、だからコーディング前の必要性を感じられない

次に、オブジェクト指向の詳細設計は、クラス設計・クラス/オブジェクト間連携・メソッド振る舞いなど
アルゴリズム以外の設計がメインになる、そしてこれらの設計は、基本設計より難しい
これを、いきなり作り始めるのは、天才かオブジェクト指向で作っていないかのどっちかだ

オブジェクト指向で作っているかの見極めは難しいが、絶対違うのは
・クラス数＝オブジェクト数（これは、構造化だなｗ）
・クラス数が、１０個未満
・オブジェクト数が、１０００個未満（オブジェクト指向は”オブジェクト”指向だからなｗ）
まっ、これをクリアしも違う場合もあるが、どうだ、身に覚えがないかｗ

>>248
>ソフトウェア開発において、大工の立場にいるのはコンパイラであり、大工が見る
>設計図にあたるものはソースコードである、という話。

どこにそんなこと書いてる？引用してくれ。

それと、ソースコードが設計図であるとも書かれてない気がする。
> If source code is a software design, then actually building software is done by compilers and linkers.
> We often refer to the process of compiling and linking a complete software system as "doing a build".

> A program listing is a document that represents a software design. Compilers and linkers actually build
> software designs.
あたりか。

またリーブズ厨か。やれやれ。

こうも書いてるね。
> There are other design activities?call them top level design, module design, structural design,
> architectural design, or whatever. A good software design process recognizes this and deliberately
> includes the steps.

> All design activities interact. A good software design process recognizes this and allows the design
> to change, sometimes radically, as various design steps reveal the need.

>>254
最早、信者の域に達している。
だから自分の言葉で説明できない。

大工の立場にいるのがコンパイラっ考えがまずおかしいだろって事

大工の喩えは嫌いみたいだからもう忘れてくれ。

「コーディングすること」と「設計すること」が、
生産性と関係するかを考えると、そもそもどれも生産性とは関係ない。

・設計書を書かないでコーディングすると、
　（設計書を書いてからコーディングした場合と比べて）ソフトウェアの品質はどうなるか
・開発途中もしくは保守フェーズに開発者が変わったらどうなるか
・一生使うシステムと1日しか使わないシステムでは設計の価値は変わるか

「設計書を書くこと」と「生産性が落ちること」の因果関係が不明だと思うのだが。

>>248
個人的には、ソースコードに詳細設計を含めることは出来る（ので基本賛成だ）が、
ソースコード＝詳細設計である、というのは真実ではないと思う。
理由は、それだと「リファクタリング」という概念が説明できないから。

>>252
前提を足したのはどうして？

ソースコードを書かずして詳細設計ができたと言われても、まったく信用できないね。
ソースコードは詳細設計を行い、その正しさを確かめるのに必要なもの。
ついでにソースコード中のコメントとして文書を書きこんでしまうのが楽チン。 Javadoc とかね。

最初に設計書なんか書いても、偉そうにふんぞりかえってる上司がダメ出しするし
出さなきゃ出さないで責任とらされるし、正直ウンザリだね。

設計書に書かなければならないことをまとめよう。

CSVファイルで、数値が入っているべき所に
なぜか文字が入ってきた場合の処理は
設計書に書くべきか否か。

ドキュメントは書いたほうがいいと
ジョエル・スポルスキーも言っている。

問題は設計書でプログラムを書こうとする場合。
日本語でプログラムするくらいなら
プログラム言語でプログラムしろよｗ

プログラムはひとつの切り口しか持てないけど
ドキュメントなら色々な側面から問題の解決方法を記述できる。
これは大きいんじゃないか。

問題の解決･･･それは大きなメリットだ

でもそれは設計書とは呼ばれていない、多分

設計者とコード書く人間が別とかいうこともままあるわけで、
そういう時のための設計書だ、という主張には一理あると思うが
設計書があれば意図が正しく伝わるかと言うと疑問

お前の設計書がクソなのだ、と言われれば自信を持った反論は出来ない

>>258
おいおい、ちゃんとした日本語で書いてくれよ。
自分が書いたのを10回読み返してから書き込みボタンを押そうぜ。
内容めちゃくちゃだぞ。支離滅裂。

責任者がとにかく嫌がらせのようにダメ出しをする場合
レビューって終わらないよな。
何度か試みたけど毎回喧嘩になるんで、もう勝手に作ってる。

設計書を作ることを全力で阻止してるチリチリ頭のバカに暴言はかれまくり
第三者のいる展示会とかでやるか普通

コードレビューが意味あるものかどうかをチェックする方法。
以下のコードを故意に入れたものをレビューにかけて、検出されるかどうかチェックする。
・境界値条件をわざと間違えておく
・メモリを破壊するコードを書く
・リソースがリークするコードを書く
・その他セキュリティリスクの要因となるコードを入れておく

はい、検出できませんでしたねー無駄だから削減！
てな事にはならないんじゃないか

蓮舫がいれば話は別

顔が柴田で性格が蓮舫とかならよくいるだろ

コードレビューがお勉強会になる現実
んな屑みたいな書き方するなとか
んなコードじゃ保守できないからやめろとか
コーダの質が悪すぎる

コーダーのレビューなんかしなくていいよ
チェックしてまずいところがあったら、問答無用で直せ

プリプロセッサを3段入れ子にする奴ってどう思う？
しかもその有効範囲がすげー長いんだ。
100行以上を囲ってたりする。

インデントいれたら「余計なことすんなバカ」といわれた。
しにたお。

>>274
ソース見てないから何とも言えないが、１００行以上は長すぎと思う

>インデントいれたら「余計なことすんなバカ」といわれた。
>しにたお。
これは当然、人のソースを勝手に変更する方がお前が悪い
変更するなら、了承を得ないと

人のソースを修正する奴は何を考えているんだ？
自分が正しいと思っている奴に限って、とんでもない大馬鹿野郎だったりするよな
そのくせ自分の事を天才プログラマーだとか言う、本当に駄目な奴が多い

出来る人は、本人に修正させて納得出来る理由も教えてくれる人が多い

>>276
面倒臭いだろ

>>277
それも、不思議だよな、よっぱど火を噴いているプロジェクトじゃない限り
出来る人間は、人より多い仕事をさせらているのに、余裕があるんだよな
出来ない人間は、説明の無しに人のソースを修正して、余計な仕事を増やす
本当に、知ったかは氏んでくれと思うよ

自分が書いたクソコードが修正されたのがよっぽど悔しかったんだねｗ

事情を説明するのも面倒なんだが、そもそも第三者に読まれることを
考えてないコードって酷いんじゃないか。

>>279
自分の事を天才とかピカソだと思っているだろうｗ
理解出来ないソースはクソコードか単純でいいなｗ

お前レベルの人間に、再帰のソースを見せるとまったく理解できなくて嫌になるよ
ループで出来るだろうとか言い始める、本当に馬鹿は自分のレベルを知らんな〜ｗ
はいはい、アンタは天才ですよｗ　頑張れよ、天才ｗ

>>280
>事情を説明するのも面倒なんだが、そもそも第三者に読まれることを
>考えてないコードって酷いんじゃないか。
第三者（アホ）に合わせたソースを書けと言うのかｗ
自分は頑張らんのか？　まっ天才だから頑張らんでもいいのかｗ

何コイツーｗ顔真っ赤なんですけどｗｗｗ

いくら「コードがドキュメントだ」といってもそこには限界があります。
というのも，ソースコードやテストコードでは「What（何を）」や「How（どうやって）」を表現することはできますが，「Why（なぜ）」「Why not（なぜXXでないのか）」は書けません。
結果をコードで表現しているのですから，当然です。
コードのWhy，Why notは，ソースコードのコメント等に書かれるべきです。

コード以外のドキュメントでも「なぜ」「なぜXXでないのか」を書くことは重要です。
直接話のできないドキュメントの読み手に意図を伝えることができるからです。

>>282
そんなんだから、「余計なことすんなバカ」と言われるんだよｗ

だいたい２ちゃんにしか、愚痴をこぼせない奴ってｗ
その性格だと職場の人間に相手にされていないだろう、いつも自分勝手にやっているから
だから、相手も「余計なことすんなバカ」と切れたんじゃないのかｗ

>>283
意味分からん、誰も基本設計をしないとは言ってないだろうｗ

何かカチンと来たらしい

お前等疲れてるなぁ

>>285
>何かカチンと来たらしい
絶対職場に一人はいるよな、こんな奴
みんな、お前に怒っているのに、それが分からんアホが

>インデントいれたら「余計なことすんなバカ」といわれた。
まさか、インデントをTABで入れてないよな？　
たまにいるんだよなTABで入れる馬鹿が、お前もそっちか？
まっ、職場で「バカ」呼ばわりされている時点で終わっているがｗ

>>281
>ループで出来るだろうとか言い始める
末尾再帰ならそのまま、そうでなければコンテキストを保存すれば
ループに置換可能ですね。

よほどの理由が無い限りインデントはtabだけども
何がバカなのかすらわからんわ俺

放っといてやれ。
スタイルに食いつくのは素人の最終手段だ。

スペース教信者か
哀れ

どっちでもいいだろ

語尾に罵詈雑言付けないと意見を補強できない人って
可哀想ですね。

>>289,291
ソースは他人も見るものだが、分かっていないのか？
「ソースは自分さえ分かれば良い、人のソースも自分が分かるように勝手に修正する」か
本当に駄目な技術者だな

普通の技術者は、相手のタブ設定や使用するツールに関係なく
正しく読める為に、スペースを使うのが常識なんだが
新人教育でも習う基礎だぞ、お前は転職組みが？　それとも教育もない中小企業か？
まっ、職場で『バカ』と呼ばれるだけはあるなｗ

> スペースを使うのが常識

はぁ？
聞いたことねえよ

コーディングルールにあわせるのが常識だろ

相手が自分より下だと思い込んでいちいちそれを書かないと納得できないって人間終わってるな

こいつ他のスレで青山とか騒いでたジジイじゃないか？

オブジェクト指向すら理解できず火病ってたあのアホの子か

ところでtabの設定が変わったら可読性が落ちるインデントって何？
普通の技術者ならtabの設定が2だろうが8だろうが関係なく読める程度にしか使わんだろJK
コードにAAでも書いてるのか？

>>294
>はぁ？
>聞いたことねえよ
それは、お前が皆から相手にされていなからだろ

>コーディングルールにあわせるのが常識だろ
お前のところでは、字下げはタブでやれと書いてあるのか？
普通は、２桁づつ字下げするとか、空白４文字字下げするとか書いてあるが
もう一度ちゃんと読んでみたらどうだ、お前、本当に使えない技術者だな(･･;)

普通、タブかスペースか書いてあるよ。
どちらの場合も何文字でインデントするか書いてある。
普通はEclipseのオートフォーマッタ任せでいいでしょ。

よく分かってなかった俺だが要するにアレだな
統一、徹底されていればいいって事か

そうそう。
本当はタブ使ったほうが整然としてるけど、
見た目考えるとスペースだね。
それだけの話。

>統一、徹底されていればいいって事か
納品する客にも徹底させるのか？　無理だろうｗ

>299
井の中の蛙だって自己紹介しなくていいよ？

つかいちいちインデント如きで拘らねえよ
並のエディタなら変換機能持ってるしIDEならなおさら
万が一気に入らなくても変換してコミットすりゃいいんだから

設計書きちんと作って外注にでも出した方がいい仕事で
設計書作りを全力で妨害してるおっさん

何考えてるのかわからない。

>>304
>並のエディタなら変換機能持ってるしIDEならなおさら
>万が一気に入らなくても変換してコミットすりゃいいんだから
コーディングルールの意味は？　始めからルールどうりに書けばいいだろう

お前は「万が一」の意味がわからんのか。

※どうり【どおりの誤り】

こんな奴にコーディングルール云々言われても…

>>300
>普通、タブかスペースか書いてあるよ。
本当に書いてあるのか？　嘘だろうｗ

>>307
>お前は「万が一」の意味がわからんのか。
その為のルールだが、本当に駄目だなｗ

>>308
>こんな奴にコーディングルール云々言われても…
別に俺はコーディングルールを書いてもいない
それにコーディングルールと言い出したのは、そっちだが(>>294)
それが、分が悪くなると、これだ．．．　本当に駄目だなｗ

>>309
おまいはいちいちペタペタスペース叩くことを推奨してるの？
救いがたいね。

>>310
>おまいはいちいちペタペタスペース叩くことを推奨してるの？

>>294 >コーディングルールにあわせるのが常識だろ
>>280 >そもそも第三者に読まれることを考えてないコードって酷いんじゃないか。
次から次へと主張を変えるなｗ

しかし、技術者がキーボードを叩くのを、めんどくさがってどうする、本当に駄目だな(･･;)

>>311
駄目な技術者はおまいだろう。
そのスペースを叩く無駄な時間で何行コードが書けるか考えたことあるの？
真っ当な技術者ならタイプ数は出来るだけ減らして
コミットするときに変換かけるようなフックスクリプト噛ませるよ。

>>312
>コミットするときに変換かけるようなフックスクリプト噛ませるよ。
なんだ、結局タブじゃなくスペースだと認めたなｗ

つまり、人のソースを勝手に修正し、コーディングルールにも合っていなかった
それで、「インデントいれたら「余計なことすんなバカ」といわれた。」となった
本当に駄目だなｗ　真っ当な技術者じゃなく普通の技術者でもそんな事しないぞｗ

>>304は、書くときはTAB、コミットするときはスペースだと言っているが
それについたレス>>306は、書くときにスペースで書けと言っている。

そこでスペースで書くことを推奨しているのか尋ねたのだが>>310
どうやら本当に推奨しているようだ。>>311

だから救いがたい。

>>313こんなことしか言えない憐れなおっさん。

それで、仕事は見つかったのか？
オブジェクト指向が判らないおっさん。

可読性のためにスペースで保存することと
スペース連打とにどんな相関があるの？

とか書いているうちに314が書いてくれてたのでアホの相手はまかせる

> 別に俺はコーディングルールを書いてもいない

わかったわかった

こんな奴にルールを守って書けとか言われても…

に訂正してやるよ
納得したかい？

ドキュメントだから文系が集まってんのか？
過疎スレとはいえ関係ないどうでもいい事で消費すんな

>>314,316
だから、タブじゃなくスペースだと認めるんだな
>>300 >普通、タブかスペースか書いてあるよ。
これは、嘘だと認めるんだな、
なんだったんだ最初の方の書き込みは、嘘まで付いて本当に駄目な人間だなｗ
しかも、自分の間違いが分かると今度はコミットの時の話に変えるか、職場でもそうなのか？
言い訳ばかり上手いのか？　いるよなそんな技術者ｗ　あれは一種の才能だなｗ

しかし、>スペース連打とにどんな相関があるの？
スペース連打ってｗ、根本的に間違っているだろう
そんなに連打するほど、ネストさせてどうする、どんなソースを書いているんだｗ
書けば書くほど駄目さ加減が分かるなｗ

>>317
>こんな奴にルールを守って書けとか言われても…
>に訂正してやるよ
>納得したかい？
お前は馬鹿か？　俺からコーディングルールに合わせろといったか？

まあ、開発で使うエディタで保存時にタブをスペースに置換してくれる機能が
無いのがまれだから、インデントはタブで入れて保存時にスペースに置き換える
ようにしてるな。 コーディングルールもそんな感じにしたし。

タブじゃなくてペチペチスペース打つ頭の悪いやつがいるなんて想定外だな。

このひとの頭おかしくね？
コーディングルールでスペースが指定されていたらという前提で話が進んでるのに
コーディングルールにタブと記載されているのはウソなんだな？ウソなんだな？
って意味不明なこと言い出すんだ？
しかも何故そこに執着する？

つかルール通りに書けってお前が言ってるじゃん
記憶力ねーのか？

？？？？

2回押下でも連打だろう？JK

「一段インデント」を TAB キーに割り当てて、そのとき実際に挿入されるタブ文字なり
半角スペースなりおよびその数はエディタがよきにはからってくれるように設定しておく、
ってのが常識。

あれ？今時、自動インデントじゃない環境w

>>321
＞コーディングルールでスペースが指定されていたらという前提で話が進んでるのに

いや、コミット時に変換すれば別にどっちでもいい話なんだよ。

なんだこの伸び…>>290 をもう一回繰り返そうか？

どうでもいい、カスがわめくスレなんぞ要らん。落とせ。

ワハハハ、お前ら哀れすぎるぞｗ
>>289
>よほどの理由が無い限りインデントはtabだけども
>何がバカなのかすらわからんわ俺
>>290
>放っといてやれ。
>スタイルに食いつくのは素人の最終手段だ。
>>291
>スペース教信者か
>哀れ
>どっちでもいいだろ

最初はタブで良いと書いておきながら、自分が無知だと気が付くと、今度は

>>294
>はぁ？
>聞いたことねえよ
>コーディングルールにあわせるのが常識だろ
と言い始めるが、コーディングルールにタブと書いてあるのかと、詰められると

>>300
>普通、タブかスペースか書いてあるよ。
と嘘を書き、また自分の無知がばれたから、こんどは

>>312
>真っ当な技術者ならタイプ数は出来るだけ減らして
>コミットするときに変換かけるようなフックスクリプト噛ませるよ。
必死にコミット時に出来るといい始める、
どうだ、自分の無知が恥ずかしいだろうｗ

お前の書き込みの方が恥ずかしい

・相手が同一人物である証明
・相手が無知である証明
が全くされてないな
よってキミがキミの仮想敵よりアホってことが証明されてしまいました
ｶﾜｲｿ(´･ω･`)ｽ

>>330
お前は本当にアホか？
>>・相手が同一人物である証明
お前らが同一人物じゃない証明をだせ、こっちは一人で相手しているんだ

>・相手が無知である証明
本当に馬鹿だなｗ　馬鹿に、あなたはこんなに馬鹿なんですよと証明して納得するか
「相手（お前）は馬鹿なんだぞ、常識的に考えろ」と、馬鹿に言ってみるｗ

>>329
>お前の書き込みの方が恥ずかしい
で？　何処が恥ずかしい”証明”してくれｗ

>>331
それで？
青山のおっさんはいつまでこのスレに居座るつもりだ？

見直したら愚痴＆キチスレだな、何でこんなのログ残してたんだろう

> で？　何処が恥ずかしい”証明”してくれｗ

自らのまぬけさにようやく気がついて顔真っ赤になっちゃいましたか？
日本語書けよ

>自らのまぬけさにようやく気がついて顔真っ赤になっちゃいましたか？
"真っ赤になっちゃいましたか？"なんで赤ちゃん言葉？
ちょっとキモいなマジで

ボクは、キモくないでちゅうｗ

お前自分がキモくないと思ってたのか？
自覚した方がいいぞ

赤ちゃん言葉って、ほんと糞スレだな

インデントがタブだとカーソルで移動するとき無駄に時間かかるから嫌だ

はぁ？

まちがい
インデントがタブでないと

>>339
HOME 一発とか Ctrl+カーソル とか、タブでもスペースでも関係ない操作が
いろいろあるし、そっちのほうが速い。

キーボードを休みなしにカタカタやってる奴って、大抵 >>339 みたいな奴だよな。

赤ちゃんプレーのスレがあると聞いて飛んできました、ここですか？

いいえ、アホなオッサンを虐めて遊ぶスレでちゅう。

真面目かｗ

設計書の話はどこに言った?

なんか書こうと思ったけど>>20が全部言ってくれてた。
>>24と酒飲みに行きたい。

>設計書なんかで妄想してるより何倍も多くのことが分かるっての。
ただし行き先すら分かっていない場合は、時間の無駄
"方向"決めや、大まかな"手段"ぐらいは設計する
で実装とテストして分かった問題によっては設計を見直し、の繰り返しだな
その方が早く終る

>で、実装とテストが終わったあとに
>改めて補足のドキュメントまとめた方が明らかにソースと食い違いのないものができる。。
こっちは同意だが

仕様書について、実装の方法とか何だかんだでケチつけてこなきゃ書くけどさ

気に入らないだの何だのと
中途半端に解ってる奴が茶々いれるから書き終わらないんだよ。
非建設的な上司がいると文書作成で1ヶ月潰れるとかザラだから書きたくない。

これは俺の会社の構造的欠陥だけど。

>>350
どこもそうだな
はじめに方針をいってくれりゃいいけど
大抵は出来上がったものをみてそれに文句いうだけだしね
だったらこっちが全部書いてしまう前に数ページ書いたらまずレビューしてくれと
それでフォーマットがある程度決まってから作りたいけど
そんな時間とってくれないよね
はじめに全部作らせて後からアレが足りないこれが足りないって結局書き終わる頃には
２〜３ヶ月は経ってるしそのお金全部こっちもちとかもうね
開発にドキュメント書く時間も含めて請求すると２〜３倍にはなるよね
どうせ金だしゃしねぇんだから本当に書きたくない

>>351
>はじめに方針をいってくれりゃいいけど
>大抵は出来上がったものをみてそれに文句いうだけだしね
あるあるｗ
嫌がらせ目的だとしか思えないんだよな
まぁ嫌がらせなんだろうけど

句読点打てよ、キチガイ。

>>353みたいなことと仕様じゃなく実装について
言って来る客との仕様書レビューを見た。
諸外国との競争に日本が負ける理由がよくわかった。

「みたいなこと」が何か知らんが、
句読点がないことと同レベルな仕様書かよ。
日本の足をあんまり引っ張るなよ。

>>355
意味がわからない
何がレスの主旨なの？

まともな仕様書書けってことだろ。

>>357
はぁ？どこが？
句読点が一番大事なの？
馬鹿なの？死ぬの？

これだから、卒論も書いてない高卒は・・・

>>355
>日本の足をあんまり引っ張るなよ。
まったく、在日は迷惑よね。

> ・・・

句読点が云々論文が云々言うなら三点リーダー使うだろJK

他人がまともな文章を書けないのと、自分がまともな文章を書けないのには関連性は無いよね。
どんなにおかしい日本語で指摘されても、自分の文章は正しくならないよ。

>>362
何が言いたいのかさっぱりわからない
上段の文章と下段の文章の関連を教えてくれない？

変な日本語で指摘されて、それが変だと指摘しても自分の文章のおかしさは変わらないってことでしょ。
つーか、正しい日本語で仕様書を書きましょうって言ってるだけなのに、何で抵抗するのかなぁ。

少なくとも社内内輪向けの設計書は、出来を罵倒するんじゃなくて
足りない部分を明確に指摘してほしい。

社外向けに納品する書類が出来ないのはアホ上司のせいなんだが
お前印鑑おさねーだろ。だから俺も出さない。会社がどうなろうとしらん

>>364
はぁ？意味がわからない
他人の文章は関係ないんでしょ？
変な日本語で指摘されようが、なんだろうが関係ないじゃない

上の段の文章は他人の文章と自分の文章に関連性がないことを主張しているにも
関わらず下の段の文章はおかしい日本語で指摘されたからわからない
ってとれるじゃんここが意味がわからない
上の段で関係ないって言ってるのに下の段では正しい日本語で指摘されたら効果があるみたいに読めるじゃん
だから変なパラドックス入った文章だな

って思いました○

お前は中卒か

他人が人を殺したからといって、自分の殺人は正当化できないってことだよ

>>365
客との仕様書レビューの話だよ。
客が正しくない日本語に文句つけるようだったら、正しい日本語で書けば良いだけの話だ。
ぐじぐじ言う意味がわからない。

機能の分割と再利用をきちんと理解して仕様を起こし始める人がもう少しいてくれれば…
正直詳細設計に入る前の仕様がボロボロすぎて詳細設計を書けるレベルじゃないから
先にコーディングして動作確認してからじゃないとドキュメント起こせないような状況になるんじゃないかと思う

もちろん、コーダーやもっと上流が具体的にどういった実装が現実的かを
ある程度想定できるスキルくらいは最低限もってるってのが前提になるけど

プログラマとして無能な人々が書いた仕様書・設計書

コーディングスキルがあっても、文章書く能力がない人もいるっちゃいるけど、
そんなの気にならないほどに、どちらのスキルも足りてない奴が多すぎる
自分も、人のこと言えるくらいのスキルがあるとは思ってないけど、
第三者が、それを見てどう捉えるだろうか、っていう感じで見直しすらかけれない奴が多いよう

複数の意味が読み取れたりしない、なにを作りたいのかが漏れなく明確にされた
上流のほうのドキュメントとか見ながら、あとで詳細設計を作るためのJavadocみたいなコメントと
テスト用のクラス起こして、TDD(なんか響きがかっこいいぜ！)で少しずつ
リファクタリングちまちま繰り返して洗練されたコード()を作るような
地味っぽい作業を黙々とやれる環境が欲しい

贅沢がダメならせめて中国韓国語が耳に入ってこない環境がほしい…

>>372の後半みたいなことはよく考える。
アメリカの開発者向けのプロダクト作ってるところに行こう

インドか

組み込み屋だけど、要件定義を誰も作らずに
勝手に「もうそろそろファームできてるよな」とかざけんなよ。
だから顧客から馬鹿にされんだよ

と愚痴ってみる。

古いとこほど勉強しないしなーなー体質が多い

組み込みだといわゆる流行りの勉強じゃあ役に立たないし
ノウハウの積み上げ部分が大だから
他所に仕事を取られる事態もほとんどないっつうんで
気楽にやってんだろう

その分、新人は辛いだろうが

発想の問題だけど、
高級言語自体が設計書とも言えるしなぁ。

最終成果物は、マシン語（アセンブラ？）なワケだし。

そう考えれば、高級言語でのプログラムを目的とした詳細設計書は不要

んなわけないだろアホう

効率化のアイデア出してよ、って言われるんだけどさ、

大量のドキュメント作成させた上、その作成枚数のカウントやら、
細かい作業項目に分けての工数の集計やら、
その数字から弾き出された数値が目標に届かないからといって、
つじつま合わせの再計算や書類の捏造をする、その手間がなければ効率化なんぞ即可能だっつうの！

と叫んでやりたいｗ
怖くて口には出せないけどｗ

怖くて、じゃなくて、説得するスキルが無くてだろ。
言い訳すんな。

まぁそうだな
多くの無駄の発生源は取り仕切る奴の無能が起因してるし
そういうとこには使えないやつがあつまってスパイラル

設計書を書こうとしたら、全力で妨害された。
CASEツール安いの使ってると、やっぱり全力で妨害する。

底辺高卒PGは執念深いわ。

そんなのと仕事する環境もどうかと思うぜよ

頭の悪い仕様メンバーが意味のない設計書を書いては直し繰り返してるせいで
10でおわる仕事が20にも30にもなる感じで、いろいろ生産性落ちてるきがしてくる
設計を作ることが原因じゃなくて、作ってる奴のせいで生産性がおちるんじゃないか…ｗ

>>383
スキルの有無だけでいったら独学でやってるほうが、
クセのなさなら素人のほうがいいってだけで
高卒より高学歴だからマとして使えるってことはない気がする
まぁ高卒でいいやって思う程度の奴って時点で既に補正かかってるとは思うけど

それはさておき、具体的にどういう妨害なのかきになる

まずはサポタージュ。手が足りないので一部分担を頼んだ。
3ヶ月間資料を読んでキングファイルに収めただけだった。

機材が無いからできないというので、機材を無理して手配した。
少し触って箱に収めて眺めやがった。

火を吹いた。

完全無視で自分の保守作業始めやがった。
組み込みなんで機材があるんだが、これが五月蝿い。
何かと理由をつけて大音響で動作させやがる。

話もできないような騒音の中でプログラム組めるかよ。
いくら底辺でも苦行過ぎる。

メーカーの受託仕事はここ数年で特に酷くなった。
管理資料を山ほど作らされ、少しでも遅れるとその対策やら何やらの資料を作らされ、終盤になればソースの行数を報告させられ、何に使うのかと思ったらそれを根拠にテストケース数とバグ発生率の目標値を指定してきやがる。
いまどき作りながらテストしているわけで、太古のパンチカードでやってた時代のように大量のバグなど出ないんだが、まったく分かってくれない。
そもそも、言ってくるメーカーSEさん自身実装経験ゼロで、ソースは読めないし実行環境の設定や調整もできないし。

>>387
テストがコーディングの延長線上にあると思ってる事自体がそもそも間違い。
納品先にとってはコード自体もブラックボックスで、完全に統計的手法で品質管理するのが普通。

完全分業が必ずしも効率がいいとは限らない。

>>387みたいなことは俺も思うなぁ。確かに>>388の言うように
統計的手法による品質管理が必要だというのは頭では分かるんだけど。だけど。だけどさ。

ウチの場合、報告した数値の分析結果がこっち（現場）にフィードバックされてないから、
こっちは「数値を報告するだけ」「上から指示が降ってくるだけ」って感じで、
あれこれ数値を報告することに何の意味があるのか実感できないんだよなぁ。
おまけに年々報告を求められる項目も増えてくるし、報告書を書く工数をもらえないし……

複数のExcelシートからあれこれ数値を転記してマクロで計算させる単純作業を
改修した機能の数の分だけやってると、最後の方は気が滅入ってくるよ……

統計的手法って本当に有効なんだろうか。
大きなプロジェクトでいくつもチームが分かれている場合、xUnitを使うチームとそうでないチームで、
いわゆる「テスト工程」でのバグ密度が全然違うと思うんだが。
収束曲線も違うと思う。

半端な知識しかない連中が、新しいことを覚えようともせず、
今ある腐った知識と妄想だけで、腐った資料を作り腐った仕様書を書き
ろくなスキルもないコーダーが、行間を勝手に見繕って実装するから、あっちでもそっちでもひどいことになる

今日は、詳細(プログラム)設計を先に書いてあって(でもその内容じゃ実装する情報が全く足りてないんだけどな！)
いま実装してるらしい機能の基本設計を、その詳細にあわせて修正するような指示が出た
そのほぼ仕様が決まりレビュー前で、既に先行で実装も始まってるらしい詳細設計書をみてまず唖然
実現方法が複数パターンあるし、必要な機能についての説明も足りてない。余計な情報だけが大量にある
とりあえず基本設計書という名前の方眼紙Excelシートに書かれている、一行ごとにセルをまたいだ文章を日本語に修正し、
実装とかなり異なったオブジェクトと結合セルの入り乱れた図を修正する
このプロジェクトでもやっぱり設計書って文書ではないようだ

一通り終わり、詳細を何度見返しても、どのような実装をすることを想定して設計したかを憶測するしかないレベルの
詳細設計を記述した前任に確認して、処理内容を確認しようと話を聞いて、まずその知識のなさに驚愕
実現不可能な方法で動作させることを想定して設計書を書いてやがる！
設計書の修正の合間に、その間違った知識の修正まで行うハメになる
どうやら、こうなったらいいなぁ的な妄想を書いて実装で何とかしてくれるだろう、程度の意識で書いていたようだ
なんで内部レビュー通ってんだよ、っていうか管理者はなにしてんだよ！

こんな連中ばかりのプロジェクト、今日も当たり前のように定時すぎてからも仕事してるし
その日クリアする予定の仕事とかもまったく考えず、ただケツまでに終わらせるってだけの
漠然としたスケジュールを当たり前のように受け入れて、日々だらだら仕事し続けてる

なんだかなーっておもっちゃうよ！こんな状態で進めっからまたケツでデスマるんだろうに…

設計書を作るせいで生産性が落ちるというより、
能力が足りてないのにできないことを現状のままで無理やりやるから
つもり積もって生産性が落ちることになってんだと思う

ExcelやWordの使い方やら、もっというとエディタとかマクロとか画像の切り貼りとか
ちょっとした資料を作るときのチェック観点とか、必要な情報と不要な情報の判断だとか
設計書なりを作るときに役に立つような知識を新たに見つけ身に着けようと
勉強なんかをするわけでもなく、今ある足りない知識やスキルを無理やり動員して
質を落として難解にしてでも無理に実現しようとするから、余計な手間がかかり、
複雑で修正しづらくなり、そういうのが生産性にも影響でてくるんじゃないの

芸術とかスポーツとか実際に物理的に何かを作るような、スキルがないと絶対にできないようなものだと
勉強して練習して、みたいなことが必要なのは理解できるだろうけど、
この業界、とりあえずパソコンが触れればあとは適当に糞みたいな資料を量産してても
確認する側も糞だったりするので、なーなーでOKとされてしまうから、良くしようって意識が伸びないんだよね
できるひととできない人の差が激しすぎるのに、当たり前になっちゃってる

最近もなぁ「Webの画面設計は俺に任せろ」とか言って出てきた仕様書に、しっかりコンボボックス
（入力可能なリスト）が使われていたのには参ったよ。

できること、できないこと、注意しなければならないこと、リスクの度合い、等々をまったく考慮せず
要件定義書の焼き直しのような文章を指して「これが設計書だ」とのたまう輩が多くなった。
実装技術を学ぼうとせず、表面的な部分だけに力を注いで完成したシステムが、結果ザルセキュリティ
だったり、簡単にデッドロックが起きたりする。

さらにそういう設計者はソースは読めないし、開発ツールも使えないし、自力じゃ何もできないので
問題が何かは理解できても、原因究明は他人に頼るしかない。
使えないPG連中と一緒に連日遅くまで侃々諤々やってるのが見てて笑える。

開発工程を一切勉強しないやつが機能仕様を書いてる現実
そりゃ生産性とか度外視してないと無理だろ

顧客のレビュー担当はフォントサイズやレイアウトについての批判についてはノリノリなのに
いざ機能のはなしになると、「あー、うん？そうそうそんな感じで。テキトーにやっといてよ」

結局実装が始まってからやっぱりここはこの方が、とか、そんな実装は土台の仕様的に無理だ、とか
後から後から変更がはいって、書類の整理だけで無駄に無駄に時間が費やされていく

>>394
> 最近もなぁ「Webの画面設計は俺に任せろ」とか言って出てきた仕様書に、しっかりコンボボックス
> （入力可能なリスト）が使われていたのには参ったよ。

できるよ。Gmailで使われてる。
まぁ通常のコンボボックスとは少し違うけど。

できなくはないけど、標準パーツを使うとか、Javascriptの使用制限が多い環境じゃ無理だわな
業務系Webシステムなんかでよく出てきたりするのに
クライアントサイドのJavascriptはサーバサイドメインの言語より理解度が低い奴が多いせいか、
なにかと理由をつけて使わないような制限をつけてることも多いし
ブラウザの仕様だとかHTTPの仕様だとかそういうのを理解してないで妄想仕様を立てるやつがいることは事実
結局実装段階になってあれやこれやとできないことがわかって、そっから仕様リセットする

PCで実行するなら、Javascript必須でOK

作って直してするようなのが多いから最初に設計で決めてしまいたい
しかし大半の設計レベル担当は無能だから、必要な情報が何かを理解できない

作る側が検討して１回修正案を上に投げるような時間が必要だよな
向こうのどうしても押さえておきたい点とか見えないと修正するにもできないしな

ASP.NETでつくれよ

設計書でさえ、プログラムだろ。
いや、設計書こそ、プログラムであるべきなんだよ。

日本語で言い直します。
設計書でさえ、予定なんだよ。
いや、設計書こそ、予定であるべきなんだよ。

一人で最初から最後まで設計が必要な位のプログラムを作るっていうのをやった事がない奴が混乱する
設計書のダメなところとか、本当に自分がそこをダメだと自信もってるならしっかり口で言えばいいのでは
自分の考えがあってるかどうかすらわからないから下手なこといって責任もとりたくないっていうので2chで愚痴たれるしかないゴミグラマの現実

プログラマーはゴミみたいなもんだからな

っていうか考慮が足りない馬鹿が適当にわからないとこを妄想で埋めたり、
埋めるとこにすらたどり着けずわかってないことに気づかないまま仕様書作って
それをレビューする側も馬鹿で肝心なところを一切理解しきれないから、
糞な仕様書ができあがって、こんなもの役に立たないってなる
実装までわかってるなら、あとはコード書く前にどうするかを決めないといけない事柄を
客に提示して、決めたことを記録しておくためにも仕様書は必要

設計段階を必要としないのは、アバウトなところ意外は全部投げっぱなしで
コーダーが好き勝手に作っていいものだけ

全体を理解してないと上から下に落としていけないのに、
上も下も理解せずに仕事に投げ込まれる使い捨てだらけのこの業界
自分からは学ぶつもりもない奴が大半だから、どこもすぐデスマるんだよな
土方と同じ扱いなのに、土方とちがって明らかな向き不向きが表に出にくいから余慶に厄介

>>404
文章は細かくきざんだほうがいいよ。
内容に関しては同意。

>>404 仕様書を理解しようとしない上司・同僚にも重大な責任がある。

同じように、お前さんの同僚がかかえてる仕事について、お前も責任をとってるか？

自分ができてないのに、他人には厳しいことを言うのはよくないな。
先ず、実らずとも自分から理想を実践してみろ

見苦しいほどの愚痴で非常に申し訳ないんだけど

>>406
ここんとこずっと、すでに端のほう燃え尽きてるような火事場に
火消しとして投入されるって感じなんだよね
スタートからやってたら、流石にこんな状態になる前になんかしらやるよ…

なんつーか、毎日毎日アホみたいな仕事で残業してんのよ。
Excel仕様書()笑のレイアウト修正とか、実装終わってからの仕様検討やその反映とか。

俺みたいな1年弱のようなやつでも、ざっと見ただけで気づけるような、
あからさまな仕様不備や、検討漏れが腐るほどあるなんてのは当たり前だし、
仕様書が読めないのでソースをみてみたら、仕様書とやってることが全く違ってたりなんてのもザラ。
不備を指摘してから、なんか仕様検討が始まったりとか、そういう感じのレベル

仕様書のレイアウトの直し()ｗしてて、どう考えても先に決めれる内容で、
決まってないと、実装で困るだろって事がいっぱいあるので、前担当に確認してみたら
自由にコードが書けなくなるような仕様書にしたくない()だの、
とりあえず思いつくままに書いておいて、レビューで指摘されたら直すような手順になってるだの…。
俺鈍いから気づけなかっただけで、今思うとここは笑うとこだったのかもしれないケド

基本設計や用件定義の不足があるのは、一応理解してたみたいなんだけど、
足りないなら、QAなりで確実に潰しておかないと、後で絶対に問題が出るのは明白なのに、
今ある情報だけでゴリ押ししては、毎日毎日無駄な修正におわれ
残業休出当たり前のデスマーチを作り出してるのよね…
リーダーは用件定義に問題があったせいだ、PMクラスがいないことが問題だって文句言うだけ、
会社の体制が腐ってるのはわかるけど、自分も火種のひとつだって気づいてないみたいｗ

手の打ち用がまったくなくて、このままじゃ俺の寿命がストレスでマッハ

末端として終わらないプロジェクトの一員となるか、自ら手を挙げてホースを持つ係になるか。
どちらにしても苦痛だけど、後者は自分で道を変えられる可能性がある。

生活残業のための生活の知恵ってやつじゃないの？わざと作業量を増やしてるようにしか見えん。

残業代が出るとこならなｗ

>>408
前者は火に油を注ぐことが仕事だけど（残業代的意味で）
後者は数字を求められる

どっちが楽かって・・・言うまでもないなｗ

>>411
しかし自分でホース持たないと毎日徹夜や終電帰りを強要されて死ぬ可能性もあるという

>>412
疲れたら休めばいい
自宅までくることはないだろ
来たらきたで警察に突き出すチャンス

>>413
民事不介入

>>414
不法侵入してきたら刑事

a

設計書すらろくに起こせないヤツの書いたコードはさらに生産性を落とすんだって
最近また思い知らされたわ

良くできてる設計書があると
検査項目書も作りやすいってのもあるな

HTMLファイルが設計図なWebアプリケーション開発プロジェクトの経験ならあるよ。
不思議と手戻りなかった。

そんなに設計書が多いのですか？
俺は部外者だから知らないのだがｗ

設計書が無くて、何を元に試験仕様書を作ればいいんだ？

ソース？

仕様書。
単体テストとかを他人が作るなら設計書がいるだろうけど。

数人月ぐらいの開発なら、詳細設計は無くてもいいかなと思わなくもない

きちんとドキュメントコメントを修正したり、
ちゃんとした実装がされているのであれば、
コードから作成できる資料で事足りるとは思う
実装経験が浅いうちに、実装よかさきに詳細設計、プログラム設計の
ドキュメントを書こうとしても、あんまり意味がないことが多いしな

コードつくらせる前に、そのコードを外部から使うための
取り扱い説明書を先に書かせてるし、自分達でもそうする

使う側のシチュエーションで検討して使い勝手悪けりゃ書き直し

UIとかハードの設計まで拡張できる

個人的に設計書には
設計思想が一番欲しかったりするが
自分もうまく残せていなかったり

設計思想をうまく残す方法ってないものかねえ

>>427
そういうのは外部仕様書に書くもんだろ

>>428
なぜこのアーキテクチャになっているとか
このようにインターフェースが切られている理由とか
なんでこのパッケージ構成とかこのクラス構成にしているとかの話よ

普通は外部仕様書に書くものなの？
場所はともかく
設計の結果ではなくて、いきさつとかを残すのって難しくない？

書けばいいじゃないか。
体裁に拘ってないで。

>>429
いきさつとは、なぜその方式を選んだのかという理由のことだよね？

自分の場合はDDN(Design Decision Note)という定型文書を使っている。
与えられた課題/問題に対して複数(3つ以上)の解決案を示し、
それぞれについて複数の切り口で評価し、結論とその理由を簡潔に書く。

BNFで書くと、こんな感じ
　<DDN> ::= <題目> <要旨> <提案>.... <結論> <理由>
　<提案> ::= <提案名> <視点>....
　<視点> ::= <視点名> <評価> <本文>
　<評価> ::= "○" | "△" | "×"　　/* 良/可/否でもよい */
ここで、<題目>、<提案名>、<視点名>、<結論>は一行のテキストであり、
<要旨> <理由> <本文>は単一のパラグラフ(複数行テキスト)である。
実際の文書では、<提案>を横軸に<視点>を縦軸とする表として書く。

昔はこれを印刷してA4用紙1ページにまとめていたけど、今は制約を外してる。
たとえばこれをXML化するのも面白いと思うけど、今はWordで手書き。
こうしたDDNは、仕様書/設計書に「付録」として添付する。

>>431
DDNって初めて聞いた。

そもそも選択する過程で選択肢と評価視点のマトリクス作って評価して、
それをそのまま文書化してるイメージってとこかしら。

事前にかっちり決めるものに対してはドキュメント作成コストに無駄がなくて良さそうね。

>>432
>DDNって初めて聞いた。

DDNは、あるメーカーで派遣として仕事をしていた時に学んだ。
その派遣先部署の主任さん(H氏)が考案したものらしく、
そのメーカーの公式文書フォーマットではないし
結局はその部署でしか見かけなかったから、
世の中で広く知られているものじゃない。

>そもそも選択する過程で選択肢と評価視点のマトリクス作って評価して、
>それをそのまま文書化してるイメージってとこかしら。

うん、そのとおり。
そうしたマトリクス化した比較表を書いたり、あるいは
検討課題を箇条書きにして書き出すといったことは、
ごくありふれた事だと思う。
DDNは、それらを半定型化(semi-formalizm)したもの。

>>431を見ればわかるように、形式としては難しいものではないから、
自由な発想で自分に(or 自分達に)合うように改変して使えばいいと思う。
たとえば、評価視点の見出し(視点名)が具体的であれば、
その本文を省略して単なるマルバツ表にしてもいいし、あるいは
本文はテキストとなっているけど、そこに絵(イメージ図)を貼付けた方が
他の人にとって理解しやすいだろう。

定型化はしてないしちゃんと文書化もしてなかったけど、
選択肢をあげて評価をして伝えるってのは、確かにちょいちょいやるな

http://awabi.2ch.net/test/read.cgi/poverty/1327050821/3

>>431
ちょっと想像するだけで、駄目駄目なやり方だとわかるわ

x

設計書を作れない奴のせいで生産性落ちるほうが多いな

設計作業とはコーディングのこと
製造作業とはコンパイルのこと

XPの考え方はとうとう普及しなかったな

プログラム設計はコーディングだと思うんだが、これを理解できない層が絶対いるんだよなぁ。

頭の中で設計したものを製造（コードを書く）んじゃないの？

頭の中で設計して、設計と意図を仕様書に出力するか、コードに出力するかの違いだね。

コードに出力した場合はその後に関わるプログラマのレベルによって読み取れない可能性があるのと、プログラム読めない人にはわからないのが問題だね。

一定のレベルのプログラマを常に確保出来る組織で、かつオナニーなコーディングをするやつがいなければ、仕様書は要らないかもね。

>>441
> 頭の中で設計したものを製造（コードを書く）んじゃないの？

その「コードを書く」の意味は
完全にタイプのみのことを言ってるだろ？

頭の中に見えない、コード印刷物があって
その印刷物をタイプしてるようなもの。


コード印刷物がない状態で
頭の中でコードを考えているのなら
それは設計なんだよな。

>>442
一人で作ってるのじゃなきゃ、仕様書はいるだろｗ
仕様書は最終的にどんな機能を持っているかという目標。
その目標がなければ、他の人が思っていたものと違うものが出来るだろ。

目標を達成するために必要なのが設計。
コード＝頭の中で考えた設計を書いたもの。
だからコードを見れば設計は分かる。

ただ何の手がかりもなく読むのは大変だから
設計概要はあったほうがいい。

>>443
どういう反応なのか理解できないけど、俺の言いたいのは、設計と製造にわけるとするなら
コーディングが製造じゃないのってこと。

>>444
話の流れから、プログラムの設計レベルの仕様書だと思ったのだけど。

機能仕様はもちろん必要だよ。
システム設計ができていて、インプット、アウトプットが明確になっていれば、詳細設計は骨だけできてれば細かい仕様決めなくても実装は進められると思うよ。
詳細設計を細部まで1人がやる場合、その人が頭の中で細部まですべての設計を終わらせてから仕様書に出力する必要が出てしまって、余計手間がかかってしまう。
レベルが低いプログラマの育成には使えるけど、同じレベルのプログラマで仕事する場合には足かせにしかならない。

コードを読めばわかるのは多くの場合自分が書いたから解るか、自分に近い思考をする人間が書いたから解るか、解ったつもりになってるかだよ。
一から考える方が楽だからスクラッチする奴は傲慢になりがちだが、一度離陸してしまった思考に追いつくのは大変だよ。

だから、同じレベルのプログラマを継続的確保できる環境でないと辛いって話。

話が少しかみ合ってない気がするけど、大丈夫かな？

コンパイル不要な言語は、製造できません。

>>441
頭の中で設計して、それを仕様書にして、コードに書いて、コンパイルして、動かしてみて、
動かして見せて、これらすべてが設計を洗練させるのに利用可能な工程。
ソフトウェアはとんでもなく複雑なので、これらを含めて利用可能なすべての手段を総動員して
設計を洗練させなければいけないし、それでもまだバグ（コレジャナイ感含む）は残る。

> コードに書いて、コンパイルして、動かしてみて
いやだから、これ製造工程だろって話なわけで。

>>449
例えばソフトウェア以外の製品についての試作品・試作機を作る工程を製造と言うなら
そうなのかもしれないけど、一般的にそういうのも製造って言うのか？

まぁそいつらが製造かどうかよりも、それらの工程が設計にフィードバックされるべきという点
のほうが大事だな。

なんで俺に絡んでくるのか知らんけど、

>>349
> 設計作業とはコーディングのこと
> 製造作業とはコンパイルのこと
を見て、設計と製造をわｋるなら、コーディングは製造だよねって話なんだけど。

付け加えるなら、別に俺は設計作業と製造作業の定義をはっきりさせたいわけじゃなくて、
(設計作業, 製造作業)という分類があったとして、(コーディング, コンパイル)という作業を振り分けるなら、
コーディングは設計作業じゃなくて、製造作業じゃね？ってこと。

「コンパイルが製造工程です」って言いたがるアホが多いのよ。
だったら、LLは製造できないじゃんｗ

「コンパイルが製造工程です」って言い始めた奴、誰？

設計と製造とかいう、ソフトウェアになじみのない分類にするからいけない。
ふつーは、設計と実装にわけるものだよ。

>>452
例えば、コーディング時に発覚した事実（欠陥）によって設計を修正することは認めないと言うのか？

これ以上話しても言葉遊びと揚げ足取りにしかならない予感。

どう作るかを決めたのが設計で、どう作るかを頭から出したのが仕様書で、それをコードに起こした(実装した)のがプログラム。
実装中の修正も、不具合に対するデバッグも、作りを変えているのであれば再設計。

>>454
ケント・ベック

製造ってのは同じ物を何度も作る行為。

プログラマがやってるのは製造ではなく試作。
試作ってのはまさに設計段階の行為。

実装は、設計の一種なんだよな。

つまり、ウォータフォールでスケジュールを作るときなどに良く登場する
・設計工程
・実装工程
・テスト工程
という分類を認めないとよろしいか？

>>461
違うと思う。
設計と実装を同時にやってたり、実装とテストを同時にやってたり、工程を状態遷移で行き来してるんだと思う。

>>462
そんなこたぁどうでもいいんだよ。
「工程」に分けたら「実装工程」なんて無いということなのという質問なんだが。

>>461
それぞれこういうことじゃないかな？
・仕様書を書いてみて設計を確認・調整する工程
・実装してみて設計を確認・調整する工程
・動かしてみて設計を確認・調整する工程

>>464
馬鹿なの？
>>463が読めないの？

いつまで設計やってんだよwww

>>465
ごめん何が聞きたいのかわかんない。

>>461 の分類を認める場合と認めない場合と、
あるいは >>463 のいう「実装工程」があるとする場合と無いとする場合とで、
何が違うことを確認したいの？

>>467
悪い。ちょいいらついてた。

>>439のようなこという奴がたまにいて、なおかつこのスレの最近の流れでは、コーディングも
設計だよ的なことになってるんだが、じゃぁ君たちは

ウォータフォールでスケジュールを作るときなどに良く登場する
・設計工程
・実装工程
・テスト工程
という分類を認めないの？認めないならどういう工程にするの？認めるなら実装工程では何をするの？
って聞きたいんだよ。

コーディングが設計を洗練させるとかどうでもいいのよ。つか、俺ほぼTDDで実装してるし。

下手に単純化しようとするから混乱するんじゃないの。
工程分けなんて好きにすればいいけど、単一作業しかしない時間が連続的にあるかと言うと実際にはあり得ないだろ。
出なきゃ世の中バラ色になってる。

>>468
あと、工程はともかく、実装はコードを書く事だと思うよ。

>>468
設計工程の後の実装工程やテスト工程で設計変更を認めないという、
真にウォーターフォール型の制約を意図して分類されているのならそういった制約は
無いほうが良いと説明する。その時に出てくるのが >>439 みたいな話。

そういう制約無しで、この時期にはこういう作業をやってるよね、っていうスケジュール上の
目安として工程分けされてるだけなら問題ないし、たぶん今はそっちのほうが多いだろう。

混乱なんかしてないし、百も承知な事を手を変え品を変え何度も何度も聞かされる苦痛。

コーディングって実装工程だよねというと、いやいや、コーディングは設計だよとか言う奴は
何考えてるのってことなんだが、どうしてわかってくれないのか。

そして、コンパイルこそが製造といえるもので有り、それ以外は全て設計、とか、
ソフトウェア開発では製造は一瞬で終わる！！！とか力説する馬鹿が出る始末。

え？製造はコンパイルで、それ以外は全部設計であってるだろ

よーしみんな

設計、実装、製造の言葉の定義からやりなおしだ

設計・大林組
実装・日建設計
製造・銭形組
現場・お前ら

言葉の定義の話になるとスレが伸びるなｗ

いわゆる設計工程で本当に設計書作るか設計書という名の
客へのプレゼン資料を作るかで後の工程やる人の感覚は違うだろう
詳細設計から単体テストまでを一まとめで実装工程とするのが無難だと思うけどね
実際は詳細設計とコーディングと単体テストは分けてスケジュール引くけど
製造って言葉はコーディングカード時代の名残と思って深く考えないほうがいい

ソフトウェア開発は建築とは別物だって言われて、もう30年以上経つのに
未だに建築になぞらえた、設計過程、製造過程が存在すると思ってるアホが大勢いる

現実的に考えたら設計からコード書いてるわｗ
ある程度動作確認したり調査したりしないと確実に出来る保障がないケースや
コーディングとテストの繰り返しで最適な処理考えたりもするしな
このあたりの工程を分ける意味はほんとないと思う
管理側の都合でしかない

>>479
いるいるｗｗｗｗ
そんなに土方根性が染み付いてるのかよって感じ

>>480
そして
スパゲティコード
デスマの典型例ですね

いいえ

設計出来ないから
行きあたりばったりのタッチアンドゴー繰り返してるんでしょう
その方が工数取れるしデスマになれば残業代増えてウハウハだし
いや設計できないんじゃなくて真面目に設計したくないんですよね
残業代おいしいれす

脳のメモリに限界があるから、一度アウトプットしてから検討してるんだろう。
リファクタリングってのはそういう物だろ。

そう。何も考えずに単純作業で作れるなら、
それは製造でいいけど、

考えて試行錯誤してるなら、それは設計なんだよ。

>>484
> 設計出来ないから
> 行きあたりばったりのタッチアンドゴー繰り返してるんでしょう

コードを書く作業＝製造なんて考えてるところが
そんなことを言い出すと、
設計したくても出来ないからね。

設計のためにコードを書かないといけないのに、
設計しだすと、なんで製造してるんだ！ってわけの
わからないことを言い出す。

んで、渋々従って、コードを書かないで頭の中で
クラスの関連とか使うライブラリや関数とか考えるだけだから
動作確証が得られた設計が作れない。

プログラマにとって、プログラミング言語でコーディングするのは
建築技師がCADで設計するのと同じ感覚
システムの構造を考えたら、頭の中に直接プログラミング言語の構造で浮かんでくる

逆に日本語やら図やらで整理しないと全体像がイメージできないって人間は
プログラマに向いてないから、早めに転職を考えた方がいい

>>488
プログラマに限らずもの作る仕事に向いてない

>>488>>489
多分、お前らには向いてない

>>487
そうそう、そんな感じ
想定上うまくいくだろう仕組みはできてるけど、コーディングしてるうちにロジックの不備とか見つかったりするしな
プログラム設計をコード外に出さないといけない仕組みを求めるところは総じて糞
リファクタリングの度にドキュメント修正とかになるから、だれもリファクタリングしなくなって
すぐに糞コードがあふれかえる、なんてプロジェクトも結構あったりする

>>488
言い得てると思うわ
コードが一番明確な説明なんだけど、それじゃ理解できない層が別のフォーマットを求めたりするしな
この業界ピンキリ激しくて、下は本当の意味での土方と勘違いしてる節があるよなぁｗ

抽象化できない奴は死んだ方がいい。
コードの規模が大きくなると破綻するから。

CADで設計しないで
いきなりセメント流して基礎作り始めるようなもんだな
途中で柱ぶっ壊してまた作りなおしとか
真面目に作ると残業代貰えないからな

ハードも複雑高度化してるのに
日本はいまだハード偏重でソフトウェア軽視してるしな
ハードの仕組み知らないPGとかドライバ書けないハード屋とか
さっさと樹海に投げ捨てろ
中国やインドにももう追い抜かれるわ
トラ技とかインターフェースとかで記事書いてる奴
脳みそ昭和の真空管で止まってんだろ

だってソフトなんてkeygen + ソフト名あたりでググったらタダで落とせる程度のもんだし

>>493
確実に動く設計書を書けって言われたら、
まずコーディングして、動作試験まで行った後で設計書を起こすしかないだろう。

世の中の製造業における「設計」とは、図面を起こしたり、CADデータを作成することで
「製造」とは、設計したものを寸分たがわず形にしていく作業のこと

しかしソフトウェア開発における「設計」とは、プログラマの誰もが目安程度でしかないことを分かっており
「製造」というコーディング作業で詳細な構造を初めて考える

これだけ質の違うものなのに、未だにソフトウェアは工業の延長の考え方でどうにかしようと思われてる

工業より、文芸に近いよな。　製作ではなく編集に近い感じ。

「設計」つったって、システムデザインとソフトウェアデザインは違うだろ。

出版業界では、製造は印刷であり一瞬で終わる。
作者が執筆するのは設計。
へんだよこれ。

この業界、上下で分ける意味ないしね
上もできれば下もできるし、下もできれば上もできる
なんか無駄なことしてる予感

実際は、上やってるやつは実際は上も下も殆どできない、
客とよしなによしなに言い合うだけが仕事
下に居る奴は鎖のつやを自慢してる

こういうのが8割くらい

日本語おかしくなった俺ももうだめだ／^o^＼

ソフトを工業化しようとしてる奴は根本的に勘違いしてる。
ソフト産業は第三次産業、サービス業。
第二次産業の理論を当てはめること自体間違ってる。
工業に農業的手法を導入しようとするぐらい狂ってるのに気づいてない。

そんなにサービス業になりたいなら
法体系も合わせないとな笑
今まで好き勝手やって４０万５０万貰ってたのがサビ残込上限２０万になるけど
それでもいいなら第三次産業に鞍替えしないと笑
経営層はコストカットできて大喜びだな

> 今まで好き勝手やって４０万５０万貰ってたのがサビ残込上限２０万になるけど

その根拠は？

でもSEプログラマは研究職扱いw

まぁ大半の社蓄は会社にサービスしてるし、サービスをしてるという意味では間違ってはないとも言える。

じゃあ上司はサービスキラーか

>>4

このスレ初めて来ましたが、2012年現在も普通に存在しています。

>>488
すげえ
確かにそのわけ方で、俺のまわりのできる人できない人を分けられる

基本設計書だけは必要だよ
客から言われなくても俺はいつも自主的に書く
何か仕様でもめたり調整が必要なときにとても役に立つ
長い仕事だと途中で内容を忘れてしまったときも復習できる
詳細はいらないけど基本設計書は必要

それは設計書ではなく要求仕様

それをふつうは「要件定義書」と呼ぶ

要件定義、要求仕様はもう一段手前だから全然別の話だと思うけど。

書き残して合意取るべきは機能仕様、外部仕様、性能要求とかだと思うんだけど。
要は、客の見に見えるところだけはどう取り決めたか残しておかないと、「イメージと違う！」って客がごね始めるから。
中身はうまいことやってくれるなら仕様書なくても問題ないと思うけど。

> 書き残して合意取るべきは機能仕様、外部仕様、性能要求とかだと思うんだけど。
それを、要件定義・要求仕様と呼ぶのでは？

俺々定義用語を使っている間は議論にならんよ。

システム要求仕様書の書き方
IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specificationより
http://www.metabolics.co.jp/SoftwareProcess/SRS.html

>>515
基本設計の段階でそんなにガッチリ客と合意取られると
後の工程もそれにガッチリ縛られてやりづらい
特に有りがちなのはエラーメッセージを柔軟に出すのを禁止されて
何かあったときに障害原因の特定が困難な仕様を強制されるとか
あと客に設計書出して合意取っても後から客の客の客がゴネ出すとかね
本来ならこのケースでも設計書が活きるはずだが政治力で負ける

>>515が正しいやり方と思うけど場所が変わればだよ

>>517
まぁ、ガチガチにしちゃうときついけど、その辺は少し抽象化しておけばうまくいかないかね？
規模大きくなって手戻り許されないと厳しいかもしれないけど…

詳細設計はプログラマーのために書くんだよね？
Web系やってるんだが、プログラマーの質に差がありすぎて
If文単位までプログラム設計書作ってあげないと作れないやつとか来るぞ

プログラムを書いたことがないベテランプログラマ()とかよく来るし普通だろ

>>519
詳細設計というのはプログラマーがプログラムを自分で作るために
あらかじめ構想を練って整理するために作る
または自分がいなくなった後の引継ぎを簡単にするため
みんながみんな頭がよくて記憶力がいいわけでもないしね

作図にいいツールないかねえ
Visioもなんかいまいちなんだよなあ
Excelかぱわぽでフローチャート書いてるやついるしおめでてえなと

Wordで書くよりいいだろ
フローを一部でも修正しようとすると図全体がガクガクになる

図にしても文書にしても、たいして意味のあるドキュメントってないよな

うちが底辺だからってのもあるけど、まずきちんと更新されてる保障がなさ過ぎて
結局実装が全てっていう暗黙の前提がどこにでも蔓延してる現状、無駄になることが多い
自分ひとりがどれだけちゃんとがんばってやっても、周りが糞だと全てが無駄になるし…

んで結局、設計書は外枠決める前に軽く流れだけかいといて、実装とテストが一通り落ち着いてから
コード内の意図やら流れの詳細なんかを書き出していく、みたいな作業になる
大抵そういうのはコメントとかでも注記するようしてるから、完全に二重管理の情報

今後修正する人が楽に、っていう建前も、実装と差異がない保障なんてなく、いい加減なことが多くて
さして信用ならんから、結局実装みて判断することがメインになってしまう
結果、設計書の有無がコーディングのしやすさに繋がることはない

ドキュメントの類を全く作らないのは流石にないけど、
昨今の詳細設計とかのレベルで作られるドキュメントは大半はゴミだと感じてしまう
フローチャート()とか言い出すところもまだ結構あるしな

ああ、>>522 のフローチャート云々に反応して悪く言おうってわけじゃなく、ただの愚痴な

なんにせよ、フローチャートなんて物を作る上で全く意味ないから適当なもんでいいと思う
ロジック見て判断できないようなスパゲッティコードを作るわけじゃないだろうし、
コード読める人なら処理の流れなんて頭の中で十分組み立てられるしな

昔は一本道の処理が多くて、ああでもしないと読み解くの大変だったんだろうなとは思うけど、
最近の言語使ってる限り、一メソッドのサイズは大したことないレベルに収めれるわけだし、簡単に把握できる
それ見て判断するのは苦手だけど、フローチャートがあったら仕事が捗る、なんて人が居る分けない
まぁ糞コーダーが居たら破綻する話ではあるけど、糞コーダーの資料が完璧なわけないしなｗ

コードを見ない人に説明するには必要だとは思うけれど、
そもそもコード見ない人に内部ロジックなんて説明する必要ないと思うしなー
コード見れない人が考え付く程度の最低限の考慮くらいは、よほど馬鹿コーダーじゃない限りできるわけだし
初心者に指摘するならフロー書かせるよりコードレビューしてあげたほうがいい

一番大外のフローチャートは書くだろ
そこだけは、仕様書書いてるうちにどうしても必要になってくる

実際のコードをフローチャートに変換したら、
コードの10倍ぐらいの量になりそうだよねｗ

>>526
一番大外は、だいたい状態遷移図とかシーケンス図とかにしてるな。
フローチャートで描けないことも無いけど。

Excelやワードでフローチャートなんて描いてたら
修正するたびにレイアウトにすげー無駄な時間使いそうだな

更新するのがためらわれるようになるよ
四角+透明テキストボックス+線になってんだもん

◇ ← フローチャートの一番ダメなのはこの形。

文字が入りきれません。

>>529
無駄だなーと思いながら、昨日から今日にかけて、エクセル使って１０００行分くらいは
フローチャート書いた。明日の朝までにあと数百行分書かないといけない。
無駄なことをするのも仕事のうちと割り切ってやるしか無いんだが、
こんな無駄なことをさせておきながら、工期縮めろだとかスケジュールより遅れてるとか
文句言われるのはむかつく。

ぶっちゃけ最初に書くのはまだ自由にやれる分マシ
ただし保守でブチ切れる
負の遺産にしかならないもの作るとかほんと日本のこの業界は世界に負けるべくして負けてるよなーって感じちゃう

前の現場がプログラマにプログラミングさせるな、の現場だった。
詳細設計書はまんまプログラムだと。
プログラマはそれみてプログラムを書き写すだけだと…

設計者群の中でプログラムに入るのは自分だけ。

理想は分かる。ドキュメントが大事なのは分かる。
ただそんな理想は納期に余裕があり、最初の設計が完璧で、かなり力のあるSEでなおかつ全員がプログラミングできなくてはならない。
理想なんだよ。

納期やばい場合はんなこと言ってられん。
実際はプログラミングに入って変わるプログラミング的な仕様変更とかあるしだな。

詳細設計書とプログラムの二重管理しんどすぎ。
納期かつかつなら、プログラム少々変えても変更しなくていい作りにしないと。

あと、余りにも細かく書きすぎる詳細設計書って、
後からみたら何がしたいのか意味が不明。

そんで設計書とかあっても、実際メンテの仕事で設計書が役立ったことって少ないしな…
やっぱソースが設計書になるとこあるよ。
理想を言えばそんなんダメ。
だが1番は納期に正しいプログラムを納品することなわけだよ。
もちろん、成果物としての詳細設計書はいるが。

ほんとあのプロジェクトは無茶苦茶だった。
プログラミングできないSEがこぞってひどすぎた。

>>512

設計者側からしてもそのほうが楽だし、
開発する側からしても、いつも詳細設計書もらっても書き損じとか
つじつまあわずとか、ミスが多すぎて
結局自分で基本設計とか要件定義書とか見て、誤りみつけてまとめてSEに報告し、
詳細設計書を変更。
そんな風にしながらプログラム作って行くよな…

設計も開発も出来ると、なんか色々見えるからしんどい。
作ってポイ、なんてできんし。

>>488
プログラマにとって細かく書きすぎて
なにがしたいかよくわからない詳細設計書なんかみても組み辛い

結果どうしたいのか、
どのクラスを使ってどのメソッド呼ぶのか
みたいなことだけまとめて書いてあるとありがたいし、
修正もいらない。

クソみたいな設計者が書いた
そいつのクソソースみたいな詳細設計書もらった時は苛立ちが隠せなかった。
なんでこんなことしてんの？っていう。
プログラムできないヤツが作る本当の詳細設計書はカス。

>>534
そんなものは理想じゃなく、ありえない幻想
本当に必要なものが誰も判ってないからそんなことになる

>>537
とにかく設計者史上主義な現場だった。
実際組むC♯できるのは自分だけ。

組織が巨大だからこちらの声は届かず、流されるまま…
いま思えばもっとアピールすればよかったよ。
ドキュメントを軽視したら、
それはプログラマだからよ、みたいに言われた。
プログラマはコーディングするだけの人。らしいけどさ…そんなん理想だっつーの。
実際は組みながら色んなことでてきますやん、ていう。

時間の無駄みたいな仕事だな…

そう、ドキュメントとコードの無駄な二重管理
これが一番厄介だわな

無駄なのかな?考えてほしい
メカだって電気だって図面作らずに現物あるからええやんなんていうエンジニアはいない
現物を修正したら必ず図面も直す
図面の作成には大いに時間かけてるよ。まぁ試作・量産は別の人がやるんだけどな
ソフトのエンジニアはそれをしないのか?前時代的な職人稼業だから?
根本的な問題は設計と実装作業が分離されていないことだろう

> 根本的な問題は設計と実装作業が分離されていないことだろう
問題ではないよ。利点も多いし。そのうえで、
設計と実装が分離されていない場合に、ソースコードと同レベルのフローチャートを
「メカや電気はそうやってたから」という理由で書くことに意味があるのかどうかを
問いなおしたほうがいい。

図やフローチャートなんかはコードから生成してくれるツールは昔から存在
する、昔は高かったけど今だとオープンソースのそれなりものがあったりする。
ただ、そういうのと折り合いが付けれない体制だったり、開発プロセスだったり
することが多いのが問題なんだな。

>>541
ソフトにおいて設計書は目次、コードは本文
ソフトがなぜソフトと呼ばれ
ハードがなぜハードと呼ばれるか
考えてみ

>>544
そういう理屈が成り立つんだったらガンガン「本文」変更してokっすかあ?
楽勝っすよねえ本文変えるだけなんでえ
ソフト変更おいしいっすwwwwwハード変更難しいんでソフト屋で対応オナシャスwwwwwwwwwww
本文変更は本文書く人のマターなんでwwwwwwよろしくwwwwwww

>>545
小説だって話の流れ無視してプロット変更すること出来ないよね。
そんなことしたら全体が破綻してしまう。
素人臭い事言ってファビョるのやめなさいよ。

本文にちょこっと入れるだけでしょwwwww簡単じゃんwwwww
やってよwwwwwwww

>>547
何がそんなに癇に障ったの？

>>545
あぁ、いいよ。
その代わり、俺たちが変更した本文を書き写す作業よろしく。

客から身を守るために設計書を作るのもひとつの意味だけど
それって契約上の話だし、開発の話じゃないし。
だいたい、そんな敵と味方を分けるような仕事のやり方、あんまりしたくないよね。

情報工学の素人が「あんなこといいな、できたらいいな」って書いたアイディア帳が何故か設計書と呼ばれている

>>550
わかるわ、すごく。
内部で言った言わんやの話でもめる時点でクソプロジェクト確定。
身を守るのも大事だけど皆で同じ方向向いて頑張ろうよっていう…
泥臭いけど1番の近道を皆で模索できるプロジェクトがいい

責任逃れのために無駄なもんをつくる業界とかそのうち爆死するだけだしな
品質やコストを考えて、本当に必要とするものが何かってとこが重要なのに、
古い既存はこうだったから抜け出せない老害と、それに従うだけで考えないごみくずが蔓延ってるからなー

そして、開発者はデスマの日々でストレス上昇モラル低下体調不良で、いいものを作るなんて意識は消え去り
客は遅れまくる作業と、毎日発生する問題に怒りを覚え
実際使うことになるユーザは、質の低いバギーな使いにくいシステムにストレスを溜め
会社は赤字出すわ信頼を失うわで、スネークホルダーはみんな不幸になるんだ

仕様ドキュメントちゃんと作らないからや

>>555
それを詳細に書くとだんだん実装に近くなってくるんだよね
何をやりたいかと、どうやってやるかが
いつの間にか摩り替わってるんだよ。

そして、どうやってやるかは時代によって変わるので、客としては残す意味が無い。
開発が回るなら、無くても良い。

回るならな

回してるけどな

そしてグタグダになってから
ソースの品質が悪いのはドキュメントの品質が悪いから
とか言うのがお約束じゃないのか

ソースが悪いのをドキュメントのせいにする奴は
そもそもこんなこと言わない
用意してもらわないと何も出来ないお客根性が染み付いたコーダーだからだ。

最 後 は 精 神 論

>>562
お前は何が不満なんだ

>>561
じゃあ全部やっといて
お前のソースなんてよめねえから

>>564
いいけどじゃあ君いらないよね

>>565
人のことはいいからさっさとやれよks
全部やれよバカ

>>566
お客に言ってお前切ってもらうからな
お疲れｗ

まあ実際問題、お客に近い立場で話できる人は必要だよ。
SEでもPGでも関係なく、足らない部分は身につけないといけない。
お互い苦手分野を補い合うことは必要だけど
職域に拘ってたら良い仕事できんよ。

>>567
お前が作ったバグだらけの製品でお前の首が飛ぶのが先だよｗｗｗｗ

>>569
お前のボリュームばかりあって内容スカスカの設計書を元に
ハナタレコーダーが作業して
頑張って頑張ってデバッグしてようやく作った製品と比べるつもりか？

>>570
全部やりきってから言ってもらっていいすか

>>571
ごめんね、やりきるどころか運営にも足突っ込んでてごめんね

早く宣言通りやりきってもらっていいすか
お前のマターなんで

馬鹿ガキがちちくり合うようなスレじゃないから他所でやれよ。

きちんと設計書を書いた方がトンズラしやすいど。
立つ鳥あとを濁さず。

出来るやつが手がけてた仕事なら、ドキュメントなくてもまぁ何とかならんこともない
でも、ドキュメントの類ろくなの残せない人は、ほぼ9割以上の確率で成果物のほうも濁ってたりする

そりゃスーパーマンみたいなやつでも無い限り、ソースだけ書くよりも
ドキュメント書いて構造やら整理してからソース書いた方が品質もあがるさね

外部設計書はいるけど、ほかはredmimeやtracでいい

つか紙に出すのはおかしい
wikiにして検索できるようにしとけ

印字した仕様書って、客はあとで読んだりすんのかな
A4ファイルなん十冊って量だし、証拠的な意味で紙にしたがんのかね

普通読まずに電話で問い合わせだろ
こっちからすれば書いてあることいちいち聞いてくるなよって感じだが

>>579
キングファイルで何冊もになるような資料だと、電子ファイルでも案外見づらい、
見つけづらいことが多いから、紙であればそれなりに役に立つ。問題は印刷
された紙がメンテされてないことがよくあることかな。

結果をまとめた資料を保守したいのか
ソースを保守したいのか

資料直したら、自動的にソースコード修正してくれるのかね？

仕様書のとあるAPIを検索したら見つからない。
部分一致で探したら引っかかったのでよく見ると、
ソースコードの方だけtypoしてやがったw

ヘタッピが作るとファイル分割する時点でワケワカが始まってんじゃないの？

>>579
IPAの仕事は仕様書の重量で金額が決まるって聞きましたが。

上司が詳細設計は誰がみても同じコードが書けるように書かれたコードの日本語訳であるというのだがコレっておかしいよね？

>>586
その上司の言葉を一字一句間違えずに書き写したとすれば、自己再帰だからおかしい
論理的に正しい文章へ書き直すと、
「詳細設計は誰がみても同じコードが書けるように書かれた日本語である」となる
で、この解釈は世間一般の「たてまえ」として通用しているが、
いわゆる理想論であり、「本音(=現実)」としては空理空論でしかない

誰がみても上司がバーコード

コードを読めない人たちが結果を見るのに必要なのでは
（実は誰でもできる虎の巻が欲しいだけ）

書く技術よりは、要求に対する読解力とコードに対する読解力が必要
動かすって意味では環境、言語によって違うからね

コードの説明書()のドキュメントなんて2重管理、うまくいくわけもないの、いい加減理解すべき
スキルのない技術者にスキルのいる仕事をさせること自体が無理

つか、誰が見ても読み解けるコード、誰が修正しても容易にテストできる開発環境が最善であって
そこに一定以上に冗長なドキュメントの入り込む余地なんてねーよ

趣味で記載レベル変えたり、文言変えたり、改行変えたり
言い回し変えたり、漢字だったり平仮名だったり、図いれたり入れなかったり
全角絵数字記号だったり半角だったりオブフェクトだったり表だったり
こういうのを修正指摘に並べてくる確認者が３人いて
３人同時に承認を得なければ完成にならない
誰か一人が指摘すると振り出しに戻り、修正後また最初から確認者を通す

こんなことしているから、いつまで経っても終わらないんだよ
何度も修正しているうちに誰かの指摘対応で修正した部分に対し
別の誰かが指摘し始める

誰かドキュメントチェックのプラグラムを開発しろよ
そして、この確認者３人をクビにしろ
これだけで、無駄な時間と労働力と人件費が浮くわ

そういう人は技術的なことはわからないけど会社や部署での立場上、何か指摘しなくちゃいけないんだと思う。（本人もくだらないと思いながら）
指摘０件で仕様書や設計書の承認を上司に求めると、上司が彼を怒るから、無理やりにでも指摘事項見つける。その結果、技術的なこと以外のくだらない指摘となる。
本人もくだらないと思ってるしできればやりたくないと思ってるはず。

承認とってなくていいから、設計書は書け。

それはお前を救うから

設計書いるのはわかるんだけど、前やったプロジェクトが炎上してたのって
絶対1ヶ月半遅れて完成した、指導しないとどう読めばいいのか理解できないExcel方眼紙製の設計書作ってたせいなんだよな
設計書意味わかんないから、最終的にはみんな設計者と直接やり取りしてたし、もっと簡潔に仕様を書き残せないものだろうか

>>594
フォーマル

>>594 実装する前に仕様書に書く。

これしかないと10年働いて実感した。

納品時に文書がある。なんと心強いことか。

>>1
保険書を作ってるのだよ
責任のな

設計書の内容に関しては担当者が書いたものが、
そのまま残る訳ではないからね
上流工程ほど確認者がたくさんいる

どちらかと言えばレビューする側の人たちが記載内容と記載レベルに指摘を出すから、
そこで全てが変わる。>>591みたいなことをされたら、
中身はめちゃくちゃになって意味不明なものになるかもね

担当者が細かく記載している内容をレビューした人が、
色々削って意味不明な文章にすることはよくある

主に文章の主語を削り取ったり、「※」記載の注意書きや例外部分を削ったり、
未確定な部分や検討が必要な部分を削除したりして
文章の見た目を格好よくするんだよね。もちろん担当者が記述した文言も変更されるから
出来上がった設計書で担当者の思考を読み取るのは無理だと思う

結果的には削ってはダメな部分を削除すると
読む人によって解釈が違う文章や、アバウトすぎて理解不能なものになるわけ
つまり担当者ではなくてレビューする人に問題がある

「コードから自動で、中身を解析した設計書を吐き出すツール」が
あれば良いと、どれほど思ったことか。

いるんだよな。やたら設計書にうるさい上司
もってくと何度もやり直し
あんなもんやり方次第だからいくらでもいちゃもんつけられる
低学歴上司に多いね

遅延なし、極端な残業休出なし、黒字、稼働直後に致命的な障害なしな成功プロジェクトって
どんな設計書つくってんのかな

作ってないから。
時間が有限なら無駄な仕事したほうが
負ける。

仕様書が無いプロジェクトでは、全ての責任を請け負う俺が仕様書だと言う奴が必ずいる。
責任持ちたくないサラリーマンだけのプロジェクトなら仕様書は作っておけ。

あ、設計書の話だったな。
まあ、おんなじ話だ。

そういう奴の責任のとり方って、
「私が責任をもって『コイツに修正させます』」
とかだったりするよね。
もう『コイツ』になるのはゴメンだ!w

下流工程では、火噴きまくって「何故こんなになるまで放っておいたんだーーー！！！」
「寝る間を惜しんでコーディング、テストしろ！！」
「ホテル代出すから、終電なくなっても大丈夫だろ！？」みたいになっているけど

上流工程だとスケジュール遅延してものんびり、
ユーザー言い包めて、ああでもない、こうでもない、延長延長工数足りない金払え
無駄な討論・議論に時間使ってゴミドキュメント大量生産
これが理想の設計書だ！！いやいやこっちの方が理想の設計書！！ならもっと理想の設計書を作成する
急にやっぱりいらねーやーとか言い出して全部廃棄
結果、役に立ちそうな資料は何もない

これで下流工程より全然単価が高いんだから、本当IT業界は凄いわ
上流工程専門のクズ共・詐欺師が湧くのも頷ける
こいつら間違いなく機能実装にはいなくなっているからな

>>606
下流なんて端から「時間」しか買われてないんだよ

うちのじっちゃんが、パソコン使う仕事は全部怪しい仕事だ！つってた

前いたところは本当酷かったなあ。
役職者が思い思いの「美しい設計書」に拘っていて様式が統一されてない。
社内公式の記述は守っているようで皆守ってない。
各自が各自の部下に俺流の美しい設計書を刷り込んだうえ、
レビューになると相手の部下の書き方に難癖つけて潰しにかかる。
お前ら上同士で意見すり合わせろよ、って話は何度もでたが絶対にやろうとしない。

自分の書き方と違う＝間違っている、理解してないと解釈して激しく罵られ、
何度も何度もレビューにかける。そのうち面倒くさくなった頃もういいやで通る。
いろんな意見取り入れ過ぎてゴミ度がアップしただけの設計書が後に残る。

詳細設計なんて一度つくればトラブル改修まで見向きもされないゴミ一つつくるのに何日こねくり回せば気が済むのだろう。
そして自分達で進捗止めてまで設計書に拘ってたにも関わらず遅いのは部下が無能な所為ですと口を揃えて抜かす馬鹿ども。
しまいには（）の半角と全角が違う、気に入らないとか句読点が俺の好みじゃない、とか
仕様の本筋と全く関係無い所でいちゃもんつけた挙句、
あいつは仕様を何一つ理解してないとかいいだしたので辞めた。

句読点の使い方でSEの実力測れるとかどんなスペシャリストだよ(´・ω・｀)

しかもトラブル起きそうな案件のドキュメントには自分の名前残したくないものだから
勝手に人の名前を使う。
これも何度いっても止めないし知らん顔して使ってる。

それで間違えてないならまだしも仕様間違えてるからね。
美しい設計書とやらに拘って中身スッカスカですからね。
大体が才能誇ってるだけのコミュ障の分際で客とろくに話もせんと思い込みで仕様書書いてるからそんなんなるんだよ、の繰り返し。
どうかんがえても客と会話してないのが原因なのにそれは認めない。
アホかと。

設計書は設計者のスキルチェックも兼ねてるんだと思うがな
読解困難な設計書書く奴なんて高確率でスパゲッティコーダーなんだから爆弾仕込まれる前に隔離できる

まぁそれ抜きでも設計書は共通認識を得るために使うもの
極端な話、一人でシステム作るんなら設計書作るのなんて時間の無駄でしかない
だけど100人規模のプロジェクトで同じ事やってみろよ
100人全員自分好みのソースを書くわけだがそれを全部ご丁寧に読むのかよっていう
さらにバグや根本的な仕様の抜けの存在を認識できなくなるリスクも増えるわけだ

日本語ドキュメント100ページは30分もあれば全て読み終わるが
一つ一つ書き方が異なる500〜1000行のソースコード×100個読み解くのに何時間かかるんだよっていう

>>611
100人規模で実装を全く考えていない設計書の時点でスパゲッティーで
実装段階は各自好き勝手なカウボーイコーディングなんてのは

この業界では日常茶飯事ですよwww

設計書さえ作っておけばダイジョブダー教はもうおなかいっぱい。

アジャイル？
プロトタイピング？

あー開発部隊もカプセル化すれば良いのか

もしも実装方法を限定せず仕様定義されていたなら理想的な設計書であり、
そして仕様から実装を設計するのはプログラマの責務だ

wwwの意味はプロジェクト内で>>612が主導権を握れないことに
対する不満や苛立ちの現れだと思われるけど、
それは単にプロジェクトが要求するプログラマの能力レベルに
>>612が達していないことが原因だと思われる
他の連中は与えられた設計書からすいすいと実装コードを仕上げていくのに、
自分だけは「実装が全く考えられない」からコード設計が遅れてしまう
それが>>612にとっては日常茶飯事なんだろね

業務知識的なものはやっぱドキュメント省略しちゃいかんわ
無いと後から他人が見て何をどうしたくて実装してるのかわからん

それはわかるんだけど>>616みたいな原理主義派がおるとめんどくさいことになるんだよね。

それはコメントとしてソースコードに書くべきことだよ。

>>616
そりゃ、ちゃんとした実装アーキティクトが居ればの話だよ
一見仕様通りには動いてはいるが潜在バグだらけで
少しイレギュラーな処理をされるととたんにダウンする

>>620
>そりゃ、ちゃんとした実装アーキティクトが居ればの話だよ

もちろんそうだね、だから>>616の冒頭で「もしも」と書いた
ただし、それを指摘して的確に弁明/反論できず
>>618 みたいな愚痴しか書けないってことは、
>>620 の推測が図星だったのではないかと思われ

憶測で物言ってドヤァとかやめてくれよ。
仕事でもそれやってんのか？

>>621
実装方法を限定しない仕様書って何だ?
画面レイアウトやテーブルレイアウトがある時点で実装方法が限定されるんだが。

うむ。なので画面レイアウトやテーブルレイアウトにかんして
これじゃ、使い勝手が悪いだとかこれじゃパフォーマンスが出ないと
プログラマから突っ返されることがあるんだよな。

>>622
何も知らない客に絵に書いた餅を食わせるコンサル業なんだろ
コンサルの餅なんて食えないから実装段階で１から設計し直しが殆ど

>>624
ダメじゃんw

>>624
>これじゃ、使い勝手が悪いだとかこれじゃパフォーマンスが出ないと
>プログラマから突っ返されることがあるんだよな

自分に火の粉が降って来なけりゃそのまま実装する

>うむ。なので画面レイアウトやテーブルレイアウトにかんして
>これじゃ、使い勝手が悪いだとかこれじゃパフォーマンスが出ないと
>プログラマから突っ返されることがあるんだよな。

使い勝手はユーザの問題ね。プログラマは知らない
パフォーマンスについてもユーザが判断する。処理速度が遅い！　というやつ

>>623
まず最初に対象文書を機能設計書に限定すると、
開発しようとするシステムをブラック・ボックスと見立て、
それと外部との間のインターフェイス仕様を定義した文書を指す

[画面レイアウトについて]
・たとえば画面レイアウトはユーザとのインターフェイス仕様だから、
　それを忠実に実装するのがプログラマの責務になる
・ユーザ視点による操作性、いわゆる使い勝手に問題があると
　判断したなら、それは仕様の問題だから機能設計担当へ申告する
・同様に仕様に論理的な矛盾があるケース、たとえばボタンAを押下したら
　メッセージXを出力するという振る舞い仕様があるのに
　そのXが定義されていないケースもまた仕様の問題(明らかなバグ)だから、
　機能設計担当へ申告する
・他に帳票レイアウトや通信メッセージ形式、ファイル交換形式などの
　外部インターフェイス仕様に関して、考え方は同じ

[(データベースの)テーブルレイアウトについて]
・テーブルレイアウトに関しては、ビジネスの静的な論理構造や
　ルールをコンピュータ上で表現できるモデルとして定義したものであり、
　開発システムの内部仕様ではあるけれど、考え方は上記と同じ

要するに、機能設計書で定義された仕様に問題点や不明点があるなら、
それらを申告するなり質問するのもプログラマの仕事の一部である
で、もしもプログラマが的確に問題を指摘できて、それら指摘の多発が
プロジェクト炎上/崩壊を起こしたのなら、それは機能設計に原因がある
それに対して、不具合の指摘や不明点の質問もできず、実装工程が
ずるずる遅延していくのなら、その原因はプログラマの能力不足と見なされる

>>629
言ってることは、ヘボSEの尻拭いってやつだなｗ

技術力 が　SE　<　プログラマ

という方程式があってこそなり立つ話だ。

俺から見れば、ここで実装方法について、何が問題となっているかわからない

昨日俺はねーちゃんにキスをしようとした。そしたら、ダメというんだな。
おれは、分かったと、いって力を抜いた。
すると、相手も力を抜いた。おれは、それからねーちゃんの乳首までキスができた。
何が問題だったのか分からない

>[画面レイアウトについて]

パフォーマンスが出なかったら、どう解決するの？
ユーザは、実験室で動くよなもんじゃダメだ、といってくるよ

やってみなければわからないことはやらないとわからない。
やってみて、問題があればすぐに修正しなければいけない。
そこで必要なのは開発速度。技術力。

一方、開発できない、技術もあげられない奴は、
あーだこーだいって、やらなければわからないことを
やらずに済ませようとする。

>>629
仕様に明らかな矛盾点が無い限りそのまま作る
自分の担当以外の機能と矛盾点があって気づいていたとしても無視する
処理速度的に破綻するのが分かって居ても無視してそのまま実装

これがプロのプログラマーと言うもの

>>625
それ自社の製品や体制をなんにもわかってないで客先で大口叩いて
糞仕事持ち帰ってくる無能営業あるあるだわ

>>628
それはプログラマが知らないじゃなくて設計者が無頓着なだけでね。
気付いたなら申告しないと糞が蔓延る。

前いたところじゃボクの設計は完璧だからそんなのありえない。
って強弁されてそのまま実装したらパフォーマンス悪過ぎて後々まで
クレームつく原因になった事もあったけど。

>>635
味噌でも糞でも仕事を取ってくる営業は良い営業。

技術力が無い無能なSEほど変にプライドが高く他人の意見を聞かない。
それ以前にそういうヤツの設計は糞過ぎて指摘する気にもならん。

>やってみて、問題があればすぐに修正しなければいけない。
>そこで必要なのは開発速度。技術力。一方、開発できない、技術もあげられない奴は、
>あーだこーだいって、やらなければわからないことを

アマチュアならそうかもね。
プロはちがう、わからないことはやらない。
プログラマというのは職業柄見通しということが発達している
一般人より、先を見るという習性がつよい。
プログラマは、やってみなければ分からない、ということはやらない。
ほぼできるだろう、ぐらいならばやる。

なんか、プロのフリしてる素人がいるなｗ
>>637とか。

>>638
やってみなきゃ分からないことはやってみるね
ま、やってみる前に出来そうか出来なそうかくらいの想像は付くが

やってみなきゃっていうのは、パフォーマンスの話だよ。
開発時にどう頑張っても実際と同じサーバーとユーザー数で
やれるわけがないし、第一ユーザー数なんてのは変わるもの。
100%同じ状況は作れない。

スペックが足りなかったら困ると恐れるあまり
無駄にオーバースペックなマシンを用意することも
かける必要のない費用をかけたという意味で、失敗だしな。

こんなのやって問題が起きてから対処するしか無い。
その時、対処のスピードが重要になる。
ようするに技術力だよ。

こればっかりは、物を作れないやつには対応できない。

>>640
性能設計(性能予測とか性能見積ともいう)は、
最も本質的な技術力を試される部分だね
だから一般に性能設計は、
(機能設計工程より前の)基本設計の要素に位置付けられる

見積はあくまで見積でしか無いからな。
やってみなきゃわからないから見積もりという。

>やってみなきゃ分からないことはやってみる

金ハチ先生の学園ドラマのような、臭いセリフが現実にあると思ってのか？

別に臭くないし、現実にあるだろ。

>やってみなきゃわからないから見積もりという。

おまえ、素人まるだし。見積もりは金額提示のことだよ

今金額の話はしていません。
性能見積もりってしっかり>>641にかいてあるだろうが。

>>641
技術の無い連中が基本設計やってるもんだから後工程だとどうにもならん
その場合はパフォーマンス爆弾埋まってても見て見ぬ振り

>技術の無い連中が基本設計やってるもんだから後工程だとどうにもならん
>その場合はパフォーマンス爆弾埋まってても見て見ぬ振り

設計段階で、やってみなきゃ分からないことはやってみる とやられたらたまらん
だから、ぼくちゃん(設計者）に、ああしろこうしろ、とこちらから言ってやるわけ。
ぼくちゃんはこちらのいいなりだよ。物事を成就するすべを知っているから
そして完成にむすびつく

>>648
そんな可愛げのあるぼくちゃんだと助けてやらないでもないが
スキル無いのに上から目線のぼくちゃんだと超ビジネスライクにお付き合いw

大抵のぼくちゃんは設計できない癖に実装する人間よりエライとか思ってるからなあ。
そんなんとはビジネスライクにしか付き合えませんよ。

>>650
地雷埋まってても自分が踏まない限りは放置ですw

プログラムの設計書なんかいらない。

プログラムのドキュメントがいるんだよ！


使い方わかんねえ…（泣

>>652
まずは doxygen を試すとか....

>>653
doxygenが操作マニュアル出力してくれるんか？

設計書は必要ないけど設計は必要。
アジャイルでも綿密な計画は必要。
当たり前に見えて誤解してる人が居ると思う。

>>655
そういった誤解をしている人も「一部には」いると思う
ただし、このスレにおける議論の対象は、それらを理解し、
現実には設計や計画を文書化する人/しない人がいるという事実を認めた上で
「そもそも生産性という観点で文書化は必要なの？/不要なものなの？」
だと考える

なお、本人は設計や計画をしているつもりだけれど
それを「文書化できない(=文書として表現できない)」という
文書化能力の欠けたも人も一部にはいるが、それも除外する

設計は設計書からではなくソースコードから
読み取ることもできるしね。

もちろんソースコードだけから全てを読み解くのは難しいかもしれない。
でもソースコードから読み解けるようなものは省けば、設計書として
別に用意するものは限りなく少ないのではないか？

ソースコードからじゃ
どれが仕様でどれがバグかわかんないだろ！

>>658
それは仕様書でも同じ。

仕様書と実際の動作が食い違っていたら
仕様書のほうが間違い（古い）って
言われることのほうが多いよｗ

動作の方が間違いって認めたら厄介な事になるからねえ・・・
大概は仕様ですって突っぱねるしかない。

データベース定義書すらないとか勘弁してください

定義書ないと意味わからないDBは糞

ddlにコメントいれとけば十分。

おまえらこれみてどう思う？
http://www.nicovideo.jp/watch/sm8630663

俺の作った糞設計書
↓
名もなき職人プログラマの神実装

クソ設計渡されるぐらなら要求定義書だけくれ

糞に限って美しい設計書とかいっちゃうのが現実

>おまえらこれみてどう思う？

多分、画像を沢山用意して切り替えているとおもう

動画(人が演じる）を作って、それから影絵にしている

画像は多分、手作業が入っている

自分が言いたかったのは、こういう指示書でも実装する人（制作）の
レベルが高いとここまですごい作品が仕上がるのかという驚き・・

　どうしてこうなった

ではなく

　どうしてこうしていただいた
　何がおこった

などのタグで皆が驚いているのがわかる。

誰か作って（絵コンテならぬ字コンテ）
http://www.nicovideo.jp/watch/nm3601701

↓

神職人がこの糞指示書を元に神動画　再生1800万回
http://www.nicovideo.jp/watch/sm8628149


■おまけ　2chバージョン
http://www.nicovideo.jp/watch/sm18604952

>自分が言いたかったのは、こういう指示書でも実装する人（制作）の
>レベルが高いとここまですごい作品が仕上がるのかという驚き・・

プログラミングの世界と関係ないよ。映画製作だな

設計で、クラス図といのがあるが
ネットで紹介されていたのが、ユースケース図みたいなのだった。
学生のデータがA->BとなってAのクラスからBのクラスへ渡されるとなるのだが

クラスについては、もう少し大きい世界でのべてほしい
クラスについてならデータ処理とか画面表示とか、そのクラスがあるというふうにのべたほうがいい

設計書というのは自分を守るためのものだ。
若くて未熟な組織ではそうはならない場合もあるだろうが、
ある程度成熟した企業では間違いなくそうなる。

設計書は要らんが設計工数は要る

成果物がないのにどうやってその設計工数の費用を請求するの？

こまったね

>>673-674
謎が解けたな！

受注系SEは、
スキルや残業が上昇するほど
ギャラや期間が下降するから
遅く作る努力をすべき

衝撃の真実を教えようか？
受注は早く作ろうが遅く作ろうが金額は決まってて
きみがやってるのは「派遣労働」っていうんだ

知ってた

ﾜﾛﾀw

>>678
金額高くするためじゃんw

ならないよ。

派遣は「時間あたりいくら」で金額が決まるからな
まさに >>678 にとっては衝撃の真実(>>678)だったかもしれんw

アンカ間違えた、１つめのアンカは>>677に訂正

言いたいことはよくわからんが、なんとなく要領がわるそうなのだけは伝わった

>>677
自己見積しないと損

仕事でもそんなことやってるんだろう

遅く作ったほうが儲かる
これ日本の業界がかかえる基本的な問題

>>688
早く完成させた人に報酬を与えないのはなんでかっていうとね、
そんなことしたら言われたことしかやんなくなって、
調査検証、プロジェクト内での連携、提供資料などにかける時間が疎かになって、
品質ボロボロに手抜きした人が得になるから逆に厄介なんだわ。

>>689
違う
使い捨てのため

いくら買った道具が便利だからってご褒美あげようなんておもわんだろ。
精々壊れたら同じメーカーの買おうかなって思うだけだわ。

>>690
客は使い捨てることを目的としてきみを雇ってるんかい？
だったらきみは、持っておくよりも使い捨てた方がコストパフォーマンスがいい存在ってだけだ。

でも現実的には使い捨てだぜ？
特にプラットフォームに依存する人は。

だから現実的に、持っておくよりも使い捨てた方がコストパフォーマンスがいい存在なんだろ

さも自分はそうじゃないといってもらいたそうだねチミ

いや単純に>>677のマルチ荒らしからずっとこの流れが続いてる意味がわからんのだが
何を主張してるのかさっぱり要領を得ないし

意味が解らんのにレスしてんのか。頭大丈夫か？

そいういう小学生みたいな返しはいいから、もういい加減帰れ
そりゃ使い捨てられるわ

もう>>677いないかもしれないのに誰と戦ってるんだこいつ
使い捨てられるのがそんなに恐いのか

スレチ

>>696
儲からないから
迷惑なだけでは？

>>692
私は、経営者だけど、
使い捨て業務は派遣にやらせてます。

>>1
裁判で言った言わないのための担保だってまだわからんか？

>>1
生産性というより、万が一税務署から手入が入った場合に
目に見える資料として必要なんだよ

結局実務上何の役にも立たないが会社としては必要ってだけか

上位の設計書は必要だけどね。
ＷＨＡＴやＷＨＹについて何も情報が残されてないとメンテしようがないから。

ただコーディングレベルの設計書は不要かな。実状みんなプログラム言語で設計、実装、テストした後、
納品前の最後のデコレーションとして、お絵かきしたプログラム仕様書を付けることが多い。
体裁だけあればお役人の口を封じることができる包装紙のようなものだ。

仕様書ってのはＷＨＡＴ,ＷＨＹ,ＷＨＥＮをちゃんと書いててくれれば、他の開発者にとって意味はあるんだが、
しょうもないＨＯＷばかりだとかえって邪魔になる。(書いてありゃ読まざるを得ない場合があるので)

>>705
だけか・・じゃなくて
会社として必要ってことは大きいだろ

>仕様書ってのはＷＨＡＴ,ＷＨＹ,ＷＨＥＮをちゃんと書いててくれれば、他の開発者にとって意味はあるんだが、

紙じゃなく、動画ファイル作っておいてくれないかな。
ユーザのボタンそうさで、画面が変わる様子とか

言葉で説明できないのもあるし、
動作説明は実際に動いてるところを見せてもらうほうがよかったりして

>>708
なんで取扱説明書の事だと思った？
設計書スレなんだから設計書の話。
　ＷＨＡＴ：システムの中でS/Wの目的と役割は？どんな機能を実現すべきか？など
　ＷＨＹ　：なぜその設計にすべきだったか？仕様変更や機能追加の入った経緯は？など
　ＷＨＥＮ：変更を行った時系列、いつの時点のコードを流用したか？など
こういうコードに書いてない情報が必要。これが不明だとS/Wをメンテできなくなる。

それと取扱説明書の話なら紙もいるでしょう。
購入者全員が動画を閲覧できるメディアを持ってるとは限らないんだから。

>>706
そういうの未だに先につくらせてる所も多いけどね。
１処理1処理全て書かせて設計書の誤字脱字添削して
仕事した気になってる馬鹿から仕事取り上げてやりたかったわ。

>>707
会社にとってはな。

実は取扱説明書がUIの実装条件検討するのに一番いい書類だったりする。

そりゃ、UIをコーディングするだけのお仕事ならね。
もしくはUIだけ要件定義すればほぼ事足りる、ちょこっとしたPCのアプリケーションツールとかね。

>>714 UI軽視してクソソフト作ってる典型例だな

UIの検討と言ってるのにシステム全体にまで適用しようとしてるのは何で？

現場でもこうやって話しかみ合ってない光景よくめにするわ。

作成時限守るんじゃねぇよ
受注系SEは
早く作ると
早く切られる

>>707
馬鹿を相手にするな
会社は自分のために存在しなければならないというトンチンカンな思考の無職だから
好きなことやりたきゃ自分で起業すればいいだけなのに

取扱説明書まで出来てる段階でUIの検討って何？

>>719
こんなスレでも自演しないとやってけないのかお前は

>>720
後継機開発ではよくある。

>>721
お大事に。

スレチ

結局コードだから。