仕様書とか意味あるの？

特にプログラムの内容を文章にしてるものは腹が立ってしょうがない

つjavadoc
つdoxygen

〜終〜

意味がないわけがない。

わかるわー

○○仕様書
hogeフラグ ＝1 の場合 hage

とか書いてあるやつな
これが仕様書とかｗ意味ねええええええ
って思うわ

テストケースを考えるのも意味ない
適当にテストすればおｋ

>>4
だいたいそういう仕様書になる経緯は察しが付く。

（設計開始）
↓
↓
（仕様を日本語で説明）→設計書なり〜　　→→→　曖昧過ぎます。具体的に
↓
↓
○○テーブルの××コードの値が△△のものだけ抽出〜　　→→→　ああ具体的でいいですね
↓
↓
（以後無限ループ）

て、それって既に実装手順じゃん。
論理設計どこ逝った〜〜？？みたいなｗ

仕様書は成果物として必要だろ。誰も見ないかもしれんが・・・

なんでみんな詳細設計の話なんだろ

要求仕様書を書いたことないし見たこともないから、どんな設計をしてアウトプットすべきかを知らないので

仕様書は必要だと思う。
形として目に見えないものをつくるんだから、何を作ろうとしているのか、
作っているのかは明文化する必要はある。
でも、現状を見ると・・・orz

まぁ知らないのに書けって言われたら、言われたとおりに書くわな。で、>>6

要求仕様は、それが契約の前提になるべきはずで、
そもそもプロジェクトが始まる時点で存在しなきゃおかしい。
とっかかりの上流の時点でからして、おかしいんだな日本のやり方は。
そもそも無いっちゅうのは論外。

で、設計ってフェイズで出来上がってくるものは、全体として詳細設計レベル。
つまり、論理設計無しの状態で見切り発車してるのわけだな。
これが大きな問題なんだな。
クラス設計とかファサード設計が先にあるだけで、大分違ってくるんだけどな。

俺から言わせれば、優れた開発ツールが豊富な時代になってからは、
詳細設計なんてのは要らねえんだよ。
詳細設計無しでいきなり作り始めてオッケーだ。

エクセルはシステム製造用に作られたツールじゃねえし。効率悪いだけだろ。
説明資料を纏めたいときに適時使う程度で十分。
で、詳細設計レベルの仕様なんざ、動かしてる最中でもどんどん調整が入るんだよ。
その度に製造物と設計書両方直すという２重管理状態か？整合性は取れるのか？
んなのデスマ必至だっちゅうの。

つまり、詳細設計だけ作ってるようなプロジェクトは、
設計フェイズでなんら有効なものを作っていないのだと主張したい。

>>12
> 要求仕様は、それが契約の前提になるべきはずで、
> そもそもプロジェクトが始まる時点で存在しなきゃおかしい。
要求仕様書、あるいは要件定義書（英語ではSoftware requirements specification）は、
開発側が書く物ですよ？

要求仕様ってユーザ要件ってことでしょ。
でもそれは仕様書とは関係ないけど。

詳細設計書は誰が見ても同じように
実装できるレベルで書けってマジメな顔して
のたまう人がNTTデータに多くて参ってます。

NTTデータは低レベルな人を集めて人海戦術が基本方針だから仕方ない。

そこまで手取り足取りだと、ほとんど実装してるのと同じようなもんだ。
で、作業効率はというと、ワープロ作業でそれをやるので、実際の実装より効率が悪いときている。
だから当然、やたら設計工数が掛かり、実装期間が殆ど取れない
→安いPGの人海戦術にならざるをえない
というデスマ黄金パターンに嵌っているのだと、気づかないもんなのかねえPMとかはｗ

>>15
>実装できるレベルで書けってマジメな顔して
だったら実装して試験までしてしまった方が確実に良いじゃん。

一つ
日本語は狭量

一つ
日本語は寛容

結論
日本語は矛盾の宝庫

日本語の問題ってより、日本人の空気を読んでさえいれば上手く行く社会の風潮の問題だな。
会社自体がそういう組織だろう。
それをシステム開発に導入するから、矛盾の宝庫となる。

日本には、阿吽の呼吸仕様書という、立派な方式があるんだ！


で、コレって案の定、中国実装には通用しねえんだよなｗ
で、日中間のブリッジSEの需要があるわけだが、
ハッキリ言ってこの仕事はババだｗｗｗ

上は単なる通訳的な仕事としてしか見ていないので
（言葉の通訳じゃないよ。中国人は日本語を話す）
大した工数は与えてくれないが、実際には、設計の足りないところを
調査して補間していく作業のオンパレード。
割りに合わねえｗｗｗｗ

インド人は、中国人以上に論理に関しては厳格だよ。
Mr.スポックかと思うぐらい「貴方の言ってることは論理的ではありません」
ってすぐ言う。

まぁ一番、空気読まないのは他ならぬ「コンピュータ」なんだけどね。
派遣先の客先の団塊世代のエラいさんが「空気読め」だの「コミュ力」
だの要求するけど、一番コミュ力も無ければ、論理的思考力も無いのは
オマエだから。

>>15
実装できるレベルで書くのが当たり前だろ…。実装するレベルでは書かないが。
じゃないと個人の頭にしか仕様残らん。

>>23
この辺りは発言だけじゃどっちがまともか判断しづらいところだね

>>23
「実装できるレベルで書け」とは言って無くて、
「誰が見ても同じように実装できるレベルで書け」って言ってるんだよ。
誰が見ても同じように実装できるというのは、コードと一対一ってこと。
だから糞。

理想的なレベルを教えてください

>コードと一対一
だったらコード書けよ、って思うよな。

同じようにって全く同じコードを指してるわけじゃなくて
同じように動くってことだと思うけどな。

>>28
お前がどう思おうと関係ない。
NTTDの奴らは、現実にコードと一対一の仕様書を要求する。
「・・・を0でクリアする」
「・・・が・・・になるまで(1)から(5)を繰り返す」
「・・・に・・・を代入する」
「・・・の場合は・・・（メソッド名）を呼び出す」
みたいなのを要求される。

最悪だなｗｗｗ
まあ コメントから抽出すりゃいいだけか。
見ればわかることコメントに書きたくもないが…

もちろん、コーディング前に作成する仕様書ですよ。
仕様書レビューで承認もらわないと、コーディングもできません。
というか、>>29みたいな仕様書書く人と、それを受け取ってコードを書く人が
分かれてることも多いですね。

そんな事して金貰えるなんて羨ましい限りだな笑

天下のNTTさまですから。

まぁ自分への投資にならないから働きたくはないがな

>>29
もしかしてその仕様書
コンパイル通るんじゃね？

そもそもどうクラス分割するかとか、メソッドの粒度をどの程度にするかとか、
コーディング中に決まる物なのに。

限られた予算の枠組みで
良いものを作ろうという態度じゃないよなあ

バカは不満をのたまうだけでうごかねーからな
愚痴愚痴いっていないで現状打破をしないから３０できられるんだよ

>>29
日本語風プログラム言語を作った方が早くね?
は、とかなでしことか。

>>38
今まで少人数の仕事しかしてこなかったけど、大人数の中で仕事したら
そーいうアホが全体の1/4は居てびっくりした。

>>29
要求されてんならその通りの仕様書作れよ。バカじゃねぇの？
嫌ならさっさと辞めろよ。代わりはいくらでもいるんだからよ。

そういう一見わけのわからない要求も上には何か考えあってのことかもしれない
プログラマ「なんで？」っていう疑問をその場で質問しないで2chに愚痴として書くからゴミだ

そうだね。
実装ツールがどんどん進化するし、ソフトウェア開発手法もどんどん効率化しているのに、
仕様書を求める側がCOBOLの時代と全く変わってないんだよなｗ

優れた手法とツールで直接実装すれば１分で済む程度のモノを、
ワードとエクセル使って１時間掛けて効率悪く仕上げてるような、間抜けな設計手法。
それが自称IT国家日本の実態ｗ

なぜ そうなったかはどこにアウトプットされるん？

1分で実装できるモノを、何ヶ月も掛けて要件定義して、論理的欠陥だらけの
仕様書をワードとエクセルで「作文」してるからなぁ。そんなPJの提案を
パワポで落描きしてるだけのミカカDATA様が一番中抜きしてるのがムカツク。

まあ それは上がバカなだけで
いきなり実装すべきという根拠にはならんわな

そこでJavaDocですな。
他の言語でも似たようなのあるだろ。

現場を知らん上が考えるコスト削減プランなんて、
PGを中国でやれ…ぐらいだから、

誰でも１分で出来あがるPG　→　人件費の安い中国でPGしてコストダウン。。
誰でもPGできるレベルの詳細な設計書→人件費の掛かる日本で何ヶ月も掛けて作成。

で、当然赤出まくりという間抜けな結末。

誰でもPGできるレベルの詳細な設計書 ＝ 実装手順書

でしかないんだよ。
「何ヶ月も掛けて要件定義してた結果、論理的欠陥だらけ」
になってしまう元凶は、それに尽きるな。
実装手順だけで、論理的な設計は無理ってことだね。


設計書を書く目的も分かってないんだよな。

誰にでも製造できることと、誰が製造しても同じ振る舞いをすることは違う

重要なのは、成果物の振る舞いが普遍的に定義されていて、、かつ
全体が論理的に整合性の取れた設計書になっているかどうかであり、
実装手順の一意性などは、設計として何の意味も持たない。

一番やっちゃう駄目パターンは、テーブル設計を一番最初に時間を掛けて
一生懸命やっちまうことだな。DBを最初に決めるってのは、論理設計の段階で、
システムが使うグローバル変数を全部定義しちまおうって行為に等しい。
こんなことやってるプロジェクトは、えてしてその後作る設計書＝実装手順書。

運良く分かってる奴が入ってくると、ドメイン駆動の概念を持ち込んで改善しようとするだろうが、
先に仕事を終わらせたつもりでいるDBAとの間で何が起こるかは、
時間が無いので想像に任せるｗ

一番やっちゃう駄目パターンは、テーブル設計を曖昧にしたまま実装を
一生懸命やっちまうことだな。DBを最初に決めないってことは、ちょっとした
スキーマの変更が、ダイレクトに多くの既存コードに影響するってこった。

影響が大きすぎて、論理的におかしくても泣く泣く変更をあきらめるなんて
ことも出て来る始末。

それを変更しないがために、よりいっそうクライアントコードでデータの整合性を
保つコードを追加したりするはめになり、さらにスキーマの変更が不可能に
近づく。

＞スキーマの変更が、ダイレクトに多くの既存コードに影響する
単に作りが悪いだけだな。
そんな実装になるようじゃ、何やってもデスマの定番パターンだろう。

スキーマとコードは、限りなく疎結合にする。
ってのは、そうならないようにするための基本だな。
先に徹底しておくべきだったってだけの話。

要求定義書 => 子供が書いた絵がぱらぱらと並べられている。（パワポやワードが多い）
詳細設計所 => コード見たほうが早い。これ本当考え直さないとまずいと思う。
取り扱い説明書 => 画面のアクションポイントの説明がつらつらと

うーん、なんかなー新規作成者の癖とかそういうのを書いてくれるといいんだけどなあ。
全てパラメータの値を変更するだけでどうにでもなるように作ってあるのか
又は、糞コードすぎてどんどんコードが増加しまくるタイプなのか
作り直した方がメンテが楽になるケースもあるもんなあ。

>>62
つまり先にDBの構造を決定しても関係ないということですな。

>>52
アホなの？DBにアクセスするクラスは、どんな構造にしたって無くならないよ？
分厚いBC層を作ったって、スキーマの変更から逃れられるのはUI層だけで、
BC層の変更は避けられないよ？

そんな大規模な変更が発生しないように、最初にスキーマは良く検討しとく
必要があるよねってことなんだけど、そんなの必要ない、見切り発車でいいよって
言いたいのかな。

大規模プロジェクトになればなるほど、後からスキーマの変更をするのは
不可能になっていく。
逆に小さなプロジェクトなら、まぁいつでもスキーマの変更は可能だと言っても
過言ではない。

その程度の理解だから、ビジネスロジックがスキーマから切り離せないんだよ。

本来は、DBのFKなどのconstraintなどでデータ全体の一貫性を保てるのに、
構造上、そのような設定ができないスキーマだったら、一生懸命クライアント側で
保証しなくちゃならなくなる。

同じことは性能要件の検証を後回しにする場合にも言えて、「きれいな第三正規形、
俺天才」みたいなので結合テストまで完了してから、総合テストで性能上大いに
問題ありで、スキーマからコードから何から何まで見直しなんてアホなプロジェクト
いくつも見たよ。

>>56
スキーマでもビジネスロジックを表現するのを知らないの？

ひょっとして、JOINとか使わない派？

>>58
システムに「どう作んなきゃ動かない」なんてのは無いんだから、
好きなように作ってデスマやってろよ、お前だけはｗ

>>55
> DBにアクセスするクラスは、どんな構造にしたって無くならないよ？
そういう外部とのIFは一ヶ所に押し込めて、
DBがどう変わっても他のところには影響しないように作らない？

SEの仕事としては、それで正解だろう。
わざと改修に手の掛かるやり方で作っておいて、それを根拠に金を取る仕事ｗ
凝った作りしたって客は評価しないし、金儲けの種を逸しているだけｗｗ

凝ったつくりじゃないし自分が楽するためだろ

現実的には、凝った作りにするためには全社的なコンセンサスが必要で、
日本では色んな得意技術持った人の集合体の既得権益が
纏まり無く蠢いていて、そんな中では不可能に近いんだよな。

結局、家で趣味で作ってまで提案した挙句、
難癖付けられて潰されるのが現状なんだよなあ。

むしろ家で趣味で作ったプログラムの方が、会社で仕事で大人数で寄ってたかって
作ったシステム(笑)より出来が良くて短期間に出来上がることの方が多いな。

団塊世代の好きな馬鹿の一つ覚えの「人海戦術」だと、人数掻き集めた下請・外注
さんの教育・研修のコストと時間が馬鹿に成らない。この教育コスト・時間を無視して
人月計算されてモナー。

>>65
ところで、出来がいいってのの定義は？

>>12
> 要求仕様は、それが契約の前提になるべきはずで、
> そもそもプロジェクトが始まる時点で存在しなきゃおかしい。

いや、具体的には「要求をまとめたもの」ではあるが、それは契約の付帯資料として提出する義務のない
もの（≒契約内容ではあるが、それを確認するためのものではない）なので、ここは同意しかねる。


> クラス設計とかファサード設計が先にあるだけで、大分違ってくるんだけどな。

普通はINPUT/OUTPUTを要求仕様からまとめたものが基本設計フェーズとしてあるのでは。すべてのI/O
をこのタイミングでまとめておかねば、何を入力して「どう加工して」OUTするかの手順（＝詳細設計）は
書けぬ。


> 詳細設計無しでいきなり作り始めてオッケーだ。

人に迷惑をかけないように・・・。お前以外でもメンテしやすいものが書ければ君のとこではいいのかも
知れんが。


> で、詳細設計レベルの仕様なんざ、動かしてる最中でもどんどん調整が入るんだよ。
> その度に製造物と設計書両方直すという２重管理状態か？整合性は取れるのか？
> んなのデスマ必至だっちゅうの。

どんどん修正が入るって事は、その前の工程でちゃんと詰めて顧客に確認してないからであって、見当違い
だろう。

>>66
自己満足でしょ。どーみても。

>>67
そんなのんびりとした開発なんて今どきNTTデータくらいしかないよ。

>>69
はしょってもいいことないけどな。NTTデータでは仕事してないから君の話は分からんが。

開発ってのは、湖に浮かぶ白鳥のようなもんなんだよ。
優雅にのんびりと泳いでるように見えて、水面下では激しくバタ足してるからこそ進んで逝くのだ。

この場合、水面下が何に当たるかといえば、それは過去だ。
過去にどれだけのモノを作ったのかが重要ということだ。
毎回プロジェクトがはじまる度に、ゼロからのスタートをやってるようなとこは、
優雅といえる域には達することはありえない。

つまり、優雅なプロジェクト＝色んなモノの再利用性の高さの証明なのだよ。

過去に作ったバグを再利用しようとするから、余計に足を引っ張られるのだが。

なぜプロトタイピングするのか？
なぜXPなんてものが生まれたのか？

まともに開発しても前工程のものに修正が入るからだね。
成果物に修正が入らないって場合は
営業が顧客に圧力かけてるに過ぎない。

レビューのとき承認とって以降の仕様変更は金とるよ？とやるんだよ。
その意味でも仕様書は意味がある。
したにいる奴はその辺りのことがわかってない

ソースのレベルで再利用しようなんて発想自体が、設計レベルが低過ぎなんだよ。
より高度なモジュール化を果たした者のみが、再利用性の有用性を享受できる。
バグ入りとか論外ｗ

営業が顧客と一緒になってプログラマに圧力掛けて来るのだが…。orz

>承認とって
「確かに承認印は押したが、そんなつもりで押したのではない。想定外」
と双方一緒に成って、プログラマに皺寄せを押付けて来るのだが。

営業馬鹿じゃね
せめてSEが間に立って守れよ…

まあ 営業には次の案件とか含めて利益だせばいいから
製造側がつぶれてもいいんだろう。

やっぱ そのへんがうまいこと
コントロールできる優秀なSEは重要だな

板挟みで禿げること必死だが

(ヒト売り)営業は、常に顧客の味方w

プログラム仕様書のお手本みたいのはありませんか？
VCで作るアプリの仕様書なんですけど
どんな項目があればいいのやら

情報が少なすぎる

その会社の伝統、慣習が全てだから社内で探したほうがよい

最近できたばかりのソフト部門なので
まったく過去の実績が無いんですよ
だからいきなり作れって言われて困ってる
ソフトも別人（まったく交流なし）が作ったものなのに

知らんがな。


その人を雇えば良いじゃん。なぜ雇ってない別人の作った「モノ」
で金儲け？他人の褌で相撲？

>>80
この条件のときにこうやったらこうなる
ってのが書かれてるもの。

条件と動作が網羅されていれば問題ない。

>>85
それをどのように文章とか図を組み合わせて
どういう構成で書いてるのかがしりたいです
どこかにこれぞっていう例があればいいんですけど…

言語はなに？

DBありならとりあえずER図ぐらいはほしいか。

前も書いたが情報が少なすぎる

>>86
前工程の成果物ある？

>>87-89
vc++
dbなし、ファイルI/Oのみ
ソースだけ存在、資料まったくなし
ソースを読み取ってくださいとのこと
１プロセスアプリで画面が１０画面くらい
外部機器からデータもらって計算して表示って感じの監視ソフト
受け取ったデータはファイルに落とす
こんな感じのソフト

>>90
ここのダウンロードして見てみたら？
ttp://pocket9.net/pocketdoc_02.html

ところで、誰の為に、何の為に作るのか確認してる？
最低限求められているものだけ作るようにしないと切りないよ？

ER図なんて、結局はグローバル変数一覧とやってることは何ら変わらん。
そんなのが設計資料の中心として回ってたって、デスマは確実だろうし、
そんなのをお客様に設計資料として提出しちゃうセンスを疑うわ。

そりゃ永続領域が必要なプロジェクトでは、必須アイテムではあるが、
それをもって設計のコアとしてしまってるプロジェクトが多すぎる。

ER図やUMLは難しいことをやってると思わせるためのこけおどしだな。
昔は作った書類の厚さで評価されていたのと同じ。

RDB扱っててER図がグローバル変数一覧と変わらんとか…。

正規化できてないならいらないかも
知れない

UMLは必要なものだけ使えば役にたつぞ？
昔からあるやつに規約作ったようなの
ばかりだし。

確かに俺が関ったデスマ案件は、DB先行で、そっから仕様が派生して、
しまいにゃアクロバットなSQLが仕様書の原本と化してるようなとこばっかだったな。
んで追い討ちを掛けるように仕様変更の嵐地獄がやってきて、途方に暮れたけどなｗ

テーブルの作りで仕様に影響でるのは
設計が糞なだけ

>>97
しかも、基本設計の時点で固められていないと言うことは、
プロジェクトの誰も使えない子ばかりという罠。

論理設計≠テーブル仕様
が理解出来ない使えない子ばかりが設計してるから、
そんな糞設計にしかならないという罠。

>>99
ごめん、ちょっと訊いてもいいかい？

「論理設計≠テーブル仕様」と書いてるけど、そのテーブルの「仕様」にかかる
部分を教えてくれないか？

俺のイメージだと、基本設計の中に論理設計がある。つまりどのテーブルに
どんなデータを保持するべきなのかという事を設計することになる。なので、
俺の中では「＝」になるんだな。

基本設計は「INPUTデータ→機能→OUTPUTデータ」がすべて書かれてなけれ
ばならないというのが俺のスタンス。なので、ちょっと違うかな、と感じた。顧客に
説明するためにはそれでEnoughと思う。

だが君は「≠」なのでちょっと論理設計の意味するニュアンスが俺とはちがうんだ
と感じた。
後学のために、教えてください。

そこを理解できる人かどうかは、設計の上手い下手の分かれ目だな。
まさにキモの部分で、設計者として高い報酬を得る糧だろう。

仮にそれを数行で説明出来たとすると、
こんなとこに書いてみんなが上手い設計者として化けちまったら、
商売上がったりではないだろうかｗ

テーブルの設計って外部設計じゃなかったっけ？

> 基本設計は「INPUTデータ→機能→OUTPUTデータ」
その通りだけど、そこにテーブルは出てこないよね。

すまね。話の前提をば。

(1)要求仕様（設計）　→　(2)基本設計　→　(3)詳細設計　→　(4)プログラミング　→　(5)テスト　→　(6)リリース

大まかにこのような流れで話していて、(2)の中には「どういった機能を作るのか」ということをすべて網羅する
必要があり、これを基に(3)で「どのようにこれを実現するのか」ということを書いていく。
ということでよろしく頼む。

>>102
外部設計も論理設計も、俺の中では基本設計の範疇なんですわ。

>>103のいうとおり、単にINPUTとOUTPUTならばテーブルの概念ではなく「必要なデータ」が書かれてれば
顧客に説明するためにはそれでおｋです。テーブルの体をなさなくていい。

＃　上記は要求仕様の範疇だろ、という言い方もできるけど要求仕様がクローズアップするべきはそこでは
＃　ないからねぇ。顧客が欲しい機能の要約というかまとめだから。

で、それ（?機能）が全部書けたら、全部のINPUTとOUTPUTが出てきたことになる（なってないなら後で困る）。
ってことは、それらを統合してテーブル設計書が書けることになる。そこまでやって基本設計が完成する感じ。

顧客によってはテーブル設計書もレビューの対象になるよね。基本設計の工程かはそれぞれだが。

ということで、論理設計も外部設計も見せ方（使用目的）の違いであり俺の中では基本設計の範疇。基本設計
と言葉ではまとめてても、実際はいくつか束になる資料が出来上がるんだけども。

どうでしょ。

>>100
> 基本設計の中に論理設計がある。
これを言いたいんなら(その主張が正しいかどうかは別として)、
「＝」じゃなくて包含関係じゃないのか？

記号で書けば↓
論理設計 ⊂ 基本設計

>>105
よく分かんないけど、包含関係を問いたいわけじゃないよ。>>100では論理設計＝テーブル仕様書
・・・つまりどんなテーブルにどんな項目がどんな状態（属性）で保持されるのか書かれるもんだと
俺は思ってるんだが、「≠」ってなってたから訊いたんだよ。

「≠」なら、論理設計としてテーブルのなにを定義・設計するんだろう？

という部分が気になるわけです。

基本設計の中に論理設計があるっていう包含関係はステップ（段階）としてどこに位置しているか
って事で、>>100ではさほど重要でもないです。混乱させてしまって申し訳ない。

あ、そうか。書いてて思い直したんだが「論理設計はテーブル仕様だけじゃない」って
ことを言いたかったのかな？

それなら納得。たしかにテーブル設計だけが論理設計ではないってことで納得。

テーブルの物理設計は、文字通り物理設計だろｗ

>>108
テーブルの物理設計って、表領域なんかの話でしょ。それは次の段階では。

論理設計＝ビュー、物理設計＝テーブル、みたいな？ｗ

>>110
ま、そう捉えてればいいかもね

んなの、全くの論理設計レスよりは多少マシってぐらいのもんだろ

論理設計はあくまでも抽象的な設計であって、
テーブルの仕様には応答速度やストレージ容量に関する要件から、どのカラムのインデックスを作成するかまでなどの
具体的な要件が含まれてる気がする。

フローが書いてある詳細仕様なんかは要らんとは思う