5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

どちらの設計書が開発効率が高いだろうか?

1 :仕様書無しさん:2006/06/11(日) 21:05:39
PGにとって、次のどちらの仕様書(設計書)が開発効率が高い?

例1
◆CSVファイル取込処理
 (1)ファイル選択ダイアログを表示する。
 (2)ファイルが選択されたら処理を行う。
    ※エラーの場合はメッセージを表示する。
    「テキストファイルの読み込みに失敗しました。」
例2
◆CSVファイル取込処理
 (1)ファイル選択ダイアログを表示する。
   (共通関数:F_GetOpenFile)※関数の仕様については別紙参照。
 (2)関数の戻り値が正常(0)ならば処理を行う。
    関数の戻り値が異常(−1)ならばメッセージを表示する。
   (メッセージID:100「テキストファイルの読み込みに失敗しました。」)
    メッセージについては、共通メッセージ一覧を参照。
 (3)共通エラーチェックを行う。

例1と例2は共にCSV取込み処理について記述したものであるが、例2では、使用する関数名やメッセージIDが指定されている点で例1と異なる。さらに共通エラーチェックという妙な記述がある。
皆さんの意見を伺いたい。

2 :仕様書無しさん:2006/06/11(日) 21:45:51
余裕の2GET

3 :仕様書無しさん:2006/06/11(日) 22:24:05
ム板の話題だろ

4 :仕様書無しさん:2006/06/11(日) 22:31:39
VB.NETを選択する

5 :仕様書無しさん:2006/06/11(日) 22:36:40
とりあえずダブルコートと改行コードと
エスケープの扱いを書けと文句言い
その上で解析面倒、外部システムとの結合面倒なのを力説し
XMLに変更させる

以上

6 :仕様書無しさん:2006/06/11(日) 22:52:18
XML房は勘弁してくだちぃ

7 :仕様書無しさん:2006/06/11(日) 23:07:46
>>1
CSV の仕様も
取り込んだ内容をどこに保持するのかも
書かれていない。

結論: どちらも素人の書いたクソ。

8 :仕様書無しさん:2006/06/11(日) 23:35:15
ドキュメントとして残すべきはCSVファイル取込処理じゃなくてXXデータ取込処理なんじゃないか?
で、データ構造とかパーシステンスとか考慮のうえ記憶媒体をCSVファイル
にするかXMLにするかDBにするか決める、と。

9 :仕様書無しさん:2006/06/11(日) 23:53:05
共通エラーチェックってのが、例1では踏み込まれて無い内容なので、
比較することが出来ない。

入出力を意識して書いて欲しいよな。仕様書は。

どういうフォーマットの入力を受け付け(はじかなければいけない条件は何なのか)
どのような出力先(DBやファイルや画面)にどのように出力すればいいのか。

そうすりゃ、プログラマは間の処理を記述するのに集中できるってもんだ。

10 :仕様書無しさん:2006/06/12(月) 00:30:47
>>1みたいなドキュメントって、全然必要ない。
いつそのデータが欲しいのかとかデータ構造がどうなっているとか
ファイルフォーマットが破損していたときどういう後処理をしたいとか
そういう情報がわかれば>>1みたいなことは自動的に導き出されるから。
逆にそういう「何がやりたいか」みたいな情報が全く設計書に記述されて
ないからPGはSEに質問を投げまくることになる。

11 :仕様書無しさん:2006/06/12(月) 00:58:38
>1を見たときは「なんだこの糞スレwww」と思ったが
わりと良スレになりそうだな

12 :sage:2006/06/12(月) 07:04:03
例1
 担当者名 文字列型
 有効日付 日付型
例2
 担当者名 TextBox 文字列型(50)
有効日付 InputMan 日付型

例1と例2は、いずれもコントロールの説明であるが、例2は、コントロールの種類や長さまで指定されているケースである。
いったいどちらが開発効率は良いのだろうか?

13 :仕様書無しさん:2006/06/12(月) 08:55:51
例1は操作仕様書としてみれば及第点。
例2はそれにプログラム仕様書かデータ設計書にかかれるべきものの一部が載ってるメモ書き。

14 :仕様書無しさん:2006/06/12(月) 10:35:53
半角だけなのか
全角をゆるすのか
文字コードは何か

15 :仕様書無しさん:2006/06/12(月) 11:20:00
う〜ん、>>1は例2を見て「こんなコードに近い記述意味ねーよw」とか言って欲しかったのか?

16 :仕様書無しさん:2006/06/12(月) 12:43:51
PG仕様書ってSEが書くべきなの?

17 :仕様書無しさん:2006/06/12(月) 15:00:27
>>1
とりあえずこれだけでCSV取り込み処理をコーディングすることはできない。情報が少なすぎて。
んで、これらを「ダイアログ出して選択させる」とこまで、と考えるなら
事前のミーティングとか会社の状況によるんだろうね。
例2の「共通関数」ってのが会社として何回も実績のある関数なのか、
そのプロジェクトで初めて扱うものなのかによっても違うし。
個人的には(例2)の方がいいかな。

>>12
これ見ながらmaxLengthとか設定するんでしょ。んじゃ例2だなあ。
有効日付にInputMan使うとか、例2じゃなきゃわかんないし。


18 :仕様書無しさん:2006/06/12(月) 15:24:38
どっちもダメだけど
どっちか選べとしたら1だろ。

19 :仕様書無しさん:2006/06/13(火) 06:47:46
>>15
その通り。

別にコーダーを意識して書かれた設計書ではなく、発注したSIerの考えが古くさいだけ。
要は、ドキュメントとソースの体裁を完璧にしたいだけのようなのだ。
ユーザー要件は二の次にされている。

漏れは、ソースは書くものではなく描くものであると考えている。
しかし、漏れのリーダーは、他のプログラマに統一性のないコードを書かれるのを嫌っている。
SIerがうるさいからそうしているというわけ。

ソースを大事にするかユーザ要件を満たすかどっちが大事か分かるだろう。
今回のユーザ要件はきれいにソースを書くことなのか(爆)




20 :仕様書無しさん:2006/06/13(火) 06:58:59
汚いソースだと保守できなくなるだろ?

保守できなくて何がユーザーのためなんだよ


21 :仕様書無しさん:2006/06/13(火) 09:27:25
>漏れは、ソースは書くものではなく描くものであると考えている。
 ̄ ̄減点 100


22 :仕様書無しさん:2006/06/13(火) 10:20:42
>>19
今回の要件でなく、プロとしての要件
それができないなら単金下げられると考えろ

23 :仕様書無しさん:2006/06/13(火) 10:33:15
> しかし、漏れのリーダーは、他のプログラマに統一性のないコードを書かれるのを嫌っている。
そりゃある程度は仕方ないだろ。
共通ルーチンあるのにオウンコーディングされてたりしたら最悪。


24 :仕様書無しさん:2006/06/13(火) 13:54:14
>>19
言いたいことはわかる。
でもそれをするのはPGの仕事じゃなくてアーキテクトの仕事だと思う。


25 :仕様書無しさん:2006/06/13(火) 15:26:04
それよか要求仕様をかっちりしとけ

26 :仕様書無しさん:2006/06/13(火) 20:06:56
どちらもつまらない

27 :a:2006/06/13(火) 21:36:40
設計とコーディングの両方をやってるが、>>1なら絶対に例2のほう。
共通関数とはいえ、所詮はそのシステムでのローカルな共通関数であり、
どうしてもそれを使えというならきちんと目立つように書くべき。
できれば太字にしたり下線を引いたりして強調すること。

>>12のケースなら、例2をきちんと表にまとめて別シートで記載すべき
だな。。

28 :仕様書無しさん:2006/06/14(水) 02:06:59
例2の方がマシではあるが

>(共通関数:F_GetOpenFile)※関数の仕様については別紙参照。
関数名だしてるんだからワザワザ別紙参照とか注釈(゚听)イラネ

>   (メッセージID:100「テキストファイルの読み込みに失敗しました。」)
>    メッセージについては、共通メッセージ一覧を参照。
これもそう。メッセージIDだけでいいな。

> (3)共通エラーチェックを行う。
意味不明

29 :仕様書無しさん:2006/06/14(水) 02:44:54
思い出した。
昔、某Iのドキュメントがこんな感じでファイルフォーマットも何もまったく不明な状態で「見積もれ」って指示が来たので
「仕様の詰め」工数上乗せしたらおこられた(´・ω・`)

30 :仕様書無しさん:2006/06/14(水) 02:52:16
ソースが仕様書。一番確実・正確。

31 :仕様書無しさん:2006/06/14(水) 03:31:50
こんな馬鹿みたいなもんいちいち書くのって、
昔の底辺COBOLerレベルのクズPG寄せ集めのカスプロジェクトだろ。

例2がマシでさらに細かく書けとか言ってる奴らって、
コーディングを、日本語からプログラム言語への変換とか勘違いしてるアホだろ。
頭使うのがコーディングなんだよ。まさかそれで給料貰ってないよね?

だいたい、F_GetOpenFileって何だよこの関数名のセンスww

32 :仕様書無しさん:2006/06/14(水) 06:49:43
>>31
漏れは、「こんなプロジェクトぶっ壊して辞めるか」「仕方なく続けるか」の2択しかないわけで・・・

関数名のセンスの話だが、
例えば、Public Function だからって、PF_GetOpenFIleとかつけるのさ。漏れはキモイとは思いつつ、開発標準だってさ。
Public SubだからPS_SetEnabledとか

あと、ループカウンタにDim intLoop As Integer とか

この辺の事情はどうなんだろか?

33 :仕様書無しさん:2006/06/14(水) 09:48:11
>>31
意見書いてるのがコーディング側の人とは限らないぞ。たぶん逆。
>>32
微妙なルールだな。SubとFunctionなんて分ける必要あるのかとか・・・
目的があってこその分類・命名だと思うのだがその辺りがわからんないね。
個人的には、スコープを示すPrefixは使う。ローカル名には特にルールはない。
って感じかな。

34 :仕様書無しさん:2006/06/14(水) 10:52:19
>>31
本気でそう思ってるんなら、お前頭使う場所間違ってるよ。
共通関数を使うと決まっているプロジェクトで
処理一つ一つに「このコーディングに関する共通関数があるかもしれない」と
リストを探すのか?
そんな瑣末な決まりごとこそ無意識に書けるように仕様書に書いてあれば
開発効率は高まる。

どのメッセージIDを使うのかに頭使うより全体のロジックに頭使えよ。

35 :仕様書無しさん:2006/06/14(水) 11:09:26
>>34
そんなことしてるからエレベータが誤動作するんだよ

36 :仕様書無しさん:2006/06/14(水) 11:15:08
>>35
そんなことしててるからエレベータが誤動作する原因がわからないんだよ

37 :仕様書無しさん:2006/06/14(水) 12:51:52
>>34
そんなの頭使う内に入らん
そもそも仕様書じゃなくてコーディング規約作っただろうが
それを守れ

38 :仕様書無しさん:2006/06/14(水) 12:55:00
あのゲロみたいなハンガリアンの元締めMSですら、もう改心してるのに、
今更なにその名前規約。名前にそんなもんくっつけて何が楽しいの?

っていうか、「動詞動詞名詞」ってどこの言葉?

39 :仕様書無しさん:2006/06/14(水) 13:01:47
>>34
共通関数を探すのが、頭を使う、か。スゲェ頭だな。
そんな程度の頭だったら確かに使って貰ったら困るかも知れん。
あと、共通関数をどうするなんてのは、個別仕様じゃなくて、ルール。

40 :仕様書無しさん:2006/06/14(水) 13:35:09
>>37>>39
例えば>>1の言う共通関数が50個弱あって、
使用するメッセージがID250まで並んであったとする。

で、使う時どーすんの?「頭使う内入らん」ってことは事前に全部暗記してるの?
それとも探すのはルーチンワークだから手間を惜しまない、てこと?
コーディング規約の「メッセージID一覧」でも引きますか?w

どっちにしても開発効率が下がることには変わんねーよ。
そんなんだから「ドカタPG」って言われんだよww

41 :仕様書無しさん:2006/06/14(水) 13:44:48
>>40
微妙なところだね。
メッセージIDは仕様書に書いてあるとラクでいいと思うけど、
共通関数は事前に軽くチェックしてあればわざわざ書かなくても覚えてるかなぁ。

42 :仕様書無しさん:2006/06/14(水) 14:11:27
>>40
馬鹿かお前
その後の開発途中やメンテナンスで莫大なコストを払うこと考えたらその程度の開発効率の低下なんか微々たる物だろ
客は開発には金を払うけど、リリース段階のチューニングとかメンテナンスなんかにはあんまり金を出さないだろ
瑕疵担保責任もある以上、後工程が楽になる様にするのが当たり前

むしろそういうルール守れない奴は切り捨てる方向が正しい

ただメッセージはUI要件だからIDが仕様書に書いてあるのが望ましいな


43 :仕様書無しさん:2006/06/14(水) 14:50:39
IDなんてある程度ルール作って、共通のモノ以外、コーディングと共にExcel記入だろ。
仕様時点のIDだけなんて、糞使えないむかつくシステムまっしぐら

44 :仕様書無しさん:2006/06/14(水) 14:52:19
>>42
チューニングやメンテ、リファクタリングを楽にする、というのと
共通関数名を仕様書に書く書かないが全然繋がらないんだけど。
書かなかったらメンテがラクになるの?

共通関数を使うのがルールなんだから
仕様書に書いてあればPGがラク、書かなくて良ければSEがラクって話でしょ。
>>40はいちいち関数一覧を引きなおさなくても良いように
仕様書に書いてあるとラクって話をしてるわけで
書いてなければ共通関数を使わなくてもいい、とは一言も言ってないよ。
馬鹿?

45 :仕様書無しさん:2006/06/14(水) 14:54:27
>>41
仕様書に使用する関数を書くってのはレビュー時にも使うんだけどね。
「この処理は皆同じことしますよー」ってね。

関数書いてない=自力でコーディング
となっても文句は言えない。

>>40は「ソースさえあれば仕様書なんていらないYO!」っていう高校生

46 :仕様書無しさん:2006/06/14(水) 15:00:32
>>45
つまりおまいは仕様書に共通関数名は書いてあった方が望ましい、と思ってるんだよね。

じゃあちゃんとレス見直した方がいい。

文章も流れもちゃんと読まずに即書き込む。
そういう注意力のなさがバグを生む。

47 :41:2006/06/14(水) 15:05:03
ごめん、ちょっと整理したいんだけど、

>>1の仕様書が書かれる前に
メッセージID一覧とか言うやつと
使用共通関数一覧みたいなやつが
あらかじめコーディング規約にまとまっている、という前提の話なんだよね。コレ?

48 :仕様書無しさん:2006/06/14(水) 15:35:27
>>47
それは前提としてあるだろう。
もう1つ、登場人物を定義したほうがいい。

他人にコーディングさせるんであれば書ける情報はトコトン書くし、自分でやるなら多少の省略もありだろう。
仕様書を書くってのは下の担当者への意思伝達と上位担当者への内容確認と両方出来たほうがいいしな。

49 :仕様書無しさん:2006/06/14(水) 15:41:01
>>44
ちがうよ
>>40は煽りたいだけの馬鹿だよ

50 :仕様書無しさん:2006/06/14(水) 18:01:30
細かい仕様の必要性は、
どれだけPG達が馬鹿か×システム規模、に比例する。

本当に優秀なPG達による10数人月程度のシステムなら、
XPでほとんど仕様書無しで問題ない。

51 :仕様書無しさん:2006/06/14(水) 18:07:17
だな。
大規模システムを安物PGの人海戦術でどうにかしようってのは、
愚の骨頂


52 :仕様書無しさん:2006/06/14(水) 18:33:14
>>50
その考えがまさに開発効率を低めてるんだろうな。
「DB構成見て判断してよ」
「いつもみたいな感じで」
「質問あったらExcelにまとめて。後で聞いておくから」

挙句の果てに
「あぁ、、、そんなことも言ってたな、客。
でもなんとなくわかるっしょ」

53 :仕様書無しさん:2006/06/14(水) 19:46:02
>>50は、考えじゃなくて事実を言ってるだけだが。
馬鹿の集団なら細かい仕様書は重要。
天才数人のドリームチームなら不要。
比例って言葉が難しかったか?


54 :仕様書無しさん:2006/06/14(水) 19:51:32
>>53
>>53
>>53
>>53


55 :仕様書無しさん:2006/06/14(水) 20:00:17
>>53
お前の言う「PGの天才」ってのは、
斬新で効率的なロジックを書くことでも、
後々に資産に出来そうなライブラリやフレームワークを作ることでもなくて

顧客の要求を満足に文章化して設計できない馬鹿SEの心を読み取って
アーキテクトの経験のみで何とかしてやる心優しい人のことを言うのかw



56 :仕様書無しさん:2006/06/14(水) 20:10:02
天才なんだから両方できるに決まってんだろ。
どういう頭だったら、片方が出来たら片方が出来ないって発想になるんだろう。可哀想に。

57 :41:2006/06/14(水) 20:09:50
>>53みたいな反論する人って、スレタイの意味を理解してないんじゃないかな。
メッセージIDが指定されていなければ、一覧から使えそうなものを探す。
共通関数名が書いていなければ、独自にコーディングする前に
使える関数があるかどうかをチェックしてからコーディングする。

SEにしてみれば一覧に書いてあることからチェックして仕様書に書き込んでいくわけで。

要はその手間をSEとPGのどっちが持つか、っていうことで
PGが馬鹿だから詳しく書いてやらなきゃいけない、ということじゃないと思う。


58 :仕様書無しさん:2006/06/14(水) 20:16:53

漏れは >53 じゃないが SE なんて不要だと思う


59 :仕様書無しさん:2006/06/14(水) 20:18:01
えー、まとめます。

・SEは馬鹿で面倒くさがり
・PGが手間ひまかけて漁ってくれるなら何もしたくはない。
・天才はなんでも出来て当たり前。
・PGとはSEの面倒くささをどれだけ解消させられるかで馬鹿さ度合いが決まる。

これでよござんすか?>>53様に>>56様wwwwww

60 :仕様書無しさん:2006/06/14(水) 20:46:42
いや。
これを見てコーディングするPGの作業時間だけを考えれば
そりゃ例2の方が早いだろうけど、
この資料を書くヤツの作業も考えると、どっちも変わらないし、どっちも無駄。


61 :仕様書無しさん:2006/06/14(水) 21:36:42
底辺PGが一匹ファビョってるな
PGが天才ならSEは要らないし、SEが天才ならPGも要らない。
実際、組み込みでは天才でなくてもそうらしいし。

62 :仕様書無しさん:2006/06/14(水) 22:29:14
◆SEはいったいどこまで詳細に記述すればよいかを悩んでいる。

◆客と話はできるがVB.NETなどのIDEを理解していないなど様々なSEが寄り集まっていて、ルールを全体周知しても誤解(データベースの共通関数なのかVB.NETの共通関数なのかも区別できていない)されるなどまとまりがない。

◆せっかくのルールがあっても認識違いで設計書の記述がバラバラとなり、PGはやりにくさこの上ない。


63 :仕様書無しさん:2006/06/14(水) 22:32:47
そんな香具師はSEやるべきじゃないよ

64 :仕様書無しさん:2006/06/14(水) 23:24:41
うちはここまでプログラムに近いレベルのドキュメントはSEじゃなくてPGが書くよ。

65 :仕様書無しさん:2006/06/14(水) 23:29:02
>>1
> 仕様書(設計書)

今更だが、仕様書と設計書は別物だと言う事、分かってる?

66 :仕様書無しさん:2006/06/15(木) 05:36:11
>>64
すなわち必要のないドキュメントである。
もとシンプルな設計書があれば真のPGは実装できる。

ちなみにアメリカにはSEなんて言葉辞書に載っていないし・・・

新卒で即SEを騙ってる(騙らしてる)香具師らをどうにかしてほしい

67 :仕様書無しさん:2006/06/15(木) 10:16:55
>>66
だから実装できるかどうかとか、真のPGとかどーでもいいから。
「開発効率の高まる仕様書」について語れ。
SEの愚痴なら社長に言え。

68 :仕様書無しさん:2006/06/15(木) 11:00:36
SEとPGの人数を考えれば答えは自明。
SEとPGでどっちが細かいことをちゃんと考えられるか考えれば答えは自明。

しかし、PGが底辺の馬鹿PGなら、SEが手を掛けざるを得ない。

69 :仕様書無しさん:2006/06/15(木) 12:37:40
SEがこんなに細かく指示するくらいならもうコード書いた方が早いじゃん。

70 :仕様書無しさん:2006/06/15(木) 14:35:12
その通り。しかし底辺PGが…

71 :仕様書無しさん:2006/06/15(木) 23:05:22
レビューだとか打ち合わせだとか時間だけ食って、設計書の精度はいっこうに向上しない。

PGは要件仕様書さえあればコーディングできるはずだ。

SEは時間つぶしてるだけ



72 :仕様書無しさん:2006/06/16(金) 06:51:14
>>67
SES契約(偽装派遣)のため、うちの社長に発言権がありません。



73 :仕様書無しさん:2006/06/16(金) 07:00:37
>>67
開発効率の高まる仕様書

テーブルレイアウト
ファイルレイアウト
ユーザーインターフェース設計書
イベントハンドリング設計書

これをシンプルな書式で用意する。

74 :なぎさっち ◆Nagi/FmYMM :2006/06/16(金) 11:55:07
テーブルレイアウトはER図を包含してるのかな。ER図欲しい....。

75 :仕様書無しさん:2006/06/16(金) 14:43:03
>>69
この共通関数を使おう、とか
メッセージID:70は「使用回数は必ず入力してください」なのでそれを使ってくれ、
ってのは「コーディングした方が早いくらい細かい指示」なの?

俺は書く側も作る側もやるんだけど、
書く時はこういう「決まりごと」的なものはなるべく細かく書くけどな。
PGが考えるのはどうすればデータを安全に効率よく遷移させるかっていう
アーキテクト部分じゃないかな。俺はそこは全面的にPGにまかせる。


76 :仕様書無しさん:2006/06/16(金) 15:34:56
アーキテクト部分…

ルールや規約を細かくするのと、仕様を細かくするのは別の話。
SEの足りない考えで細かく仕様を指定されたら、効率や改善の邪魔

77 :仕様書無しさん:2006/06/16(金) 15:45:38
>>76
>>1はどうみても「ルールや規約」の範疇じゃん。
読解力ないな。

で、「SEは俺より考えが足りない」っていう根拠のない自信はどこからくるの?
SEじゃなくてチーム組んでる他のPGが考えた仕様なら納得いくの?

もしかして「お前らは勝手にやれ。俺は俺の考えで組む」っていうタイプ?

78 :仕様書無しさん:2006/06/16(金) 17:04:18
読解力ないのか?
>>1は規約を個々の仕様に書いてるんだがね

79 :仕様書無しさん:2006/06/16(金) 17:47:47
読解力ないのか?
規約を個々の仕様に書くことは「細かく仕様を指定する」とは言わん。

80 :仕様書無しさん:2006/06/16(金) 18:03:21
読解力ないのか?
規約と、規約の適用は違う。

81 :仕様書無しさん:2006/06/16(金) 18:07:00
読解力ないのか?
自分で考えた規約を自分が使って欲しい所に適用する旨書き込むことは
「細かく仕様を指定する」とはまったく別次元の話。

82 :仕様書無しさん:2006/06/16(金) 18:08:44
遊んでるところ横レススマソ。
>>80
お前の会社のSEは規約を作っておいて、どう使うかはほったらかしなの?


83 :仕様書無しさん:2006/06/16(金) 18:11:05
・テーブルレイアウト
・ファイルレイアウト
・ユーザーインターフェース設計書
きちんと書けていれば楽になる・・ってそれが普通か。

システムの基本要求すら実現できないいい加減な仕様書を渡され、
作り始めても当然進まず、設計者の隣にうんこ座りで
ヒアリングして自分で仕様書を完成させないといけない。
そんな環境にいる自分はやはり底辺でしょうか。


84 :仕様書無しさん:2006/06/16(金) 18:19:42
>>82
どういう場合に何をどう使うかまで決めておけば、
仕様書全部に同じものをコピペしなくてもいいじゃんって話だろ。

85 :仕様書無しさん:2006/06/16(金) 20:05:48
ならば、コーディング規約の適用についても、
それぞれの項目について使って欲しい場所で仕様書に全て書き込みたまえ。

86 :仕様書無しさん:2006/06/16(金) 20:26:03
>>85
そんなの事前に打ち合わせろ
一般化するな

87 :仕様書無しさん:2006/06/16(金) 20:53:44
ならば、自分で考えた規約なんて事前に打ち合わせろ
特別扱いするな。

88 :仕様書無しさん:2006/06/16(金) 23:16:27
標準に則さない間違いだらけの設計書をもらったが、システムとして成り立つように翻訳して実装することは可能な訳さ。

でもね、開発リーダー(開発標準を決めた張本人)が、うるさいわけ。

間違いに気づいたらSEにボトムアップしろと。

間違い大杉で、設計書を作らせるのに手間がかかり、実装する暇がない訳さ。

開発リーダーもSEも何様のつもりなんだか。

89 :仕様書無しさん:2006/06/17(土) 02:07:52
設計書はwhatを書くところで、ソースはhowを書くところ。

90 :仕様書無しさん:2006/06/17(土) 08:40:32
>>89
しかしながら、whatとhowを両方書いていて、
しかもhowが間違っている上に、リーダーはいったんその通り作れだの、逐一ボトムアップしろだの、うるさい。

設計書以外に開発標準書という妙なドキュメントにもhowがあり、リーダーが作ったテンプレート(これを原則使え客がうるさいから)にもhowがあるわけさ。

何を正として作業を進めてもやはりシステムは完成しない。

それならプログラマがシステムを構築するべく、道を切り開いていかねばならない。底辺PGは辛いのだ。



91 :仕様書無しさん:2006/06/17(土) 09:30:32
バカが沸いてるな

間違ってたら指摘する修正するのは当たり前のことだ。


92 :仕様書無しさん:2006/06/17(土) 09:47:01
>>91
SEがバカだから間違うわけで・・・
PGにしてみれば、「バカなSEがいてお気の毒ですね」といわれてしまえば、もう手の打ち所がないわけである。

開発効率を下げているのは、「開発効率をあげるために開発標準とテンプレートを作った」とほざく、リーダーとボトルネックSEどもなのさ。

93 :仕様書無しさん:2006/06/17(土) 09:49:01
その糞リーダーは「人間に完璧なヤシはいないので、70%もできれば上等」だとほざいているが、実情は30%もできていないかもな

94 :仕様書無しさん:2006/06/17(土) 12:07:23
設計書を貰ってきたけど
I/F仕様無し、データ仕様無し、U/I仕様無し・・・・・・
どこが詳細設計なんだ・・・・・
これ、要件定義しかしてないぞ

モジュール構成とテーブルレイアウトは月曜提出だってさ_| ̄|○
ER図起こさないと・・・・
ってこれPGの仕事なのか?

95 :仕様書無しさん:2006/06/17(土) 12:10:39
>>94
SEって、スケジュール管理表とにらめっこしてるだけのヤシいるよな

あぁいうヤシは逝ってよし

96 :仕様書無しさん:2006/06/17(土) 23:53:49
>>94 >>95
今の現場でも似たようなもんだ。
SE様、設計どころか要件定義もしない。
PGの進捗管理だけがお仕事らしい。

去年の現場のSEさんは優秀だったんだけどなぁ・・・

97 :仕様書無しさん:2006/06/18(日) 06:57:58
まあ、完成しないプロジェクトだから、テキトウに残業してもらう物もらってればいいだろ。

98 :仕様書無しさん:2006/06/18(日) 09:40:12
SES契約(偽装請負)なので、完成するまで付き合わされる。

漏れはむしろ、他のPGよりも中途半端にまともな人間と評価されているため、えらく持ち上げられ、おだてられて、コーディングマシーンと化しているのである。

漏れは残業は嫌いで、朝一番(8時半過ぎ)に出社して21時までに帰ることを目標としてコンスタントにがんばっているのであるが、同じプロジェクトの馬鹿ばっかが残業しているので先に帰るのになぜかしら抵抗を感じるのであった。


99 :仕様書無しさん:2006/06/18(日) 10:25:45
>>98
立派に残業中毒なのに、なんで残業してないとか言うのかな?

100 :仕様書無しさん:2006/06/18(日) 10:31:17
>>99
同じSES契約(すでに長期)のヤシで開発寒リーダーのヤシがしょっちゅう深夜残業(マン喫やオフィスで夜を明かしている)や休日出勤してることから(そいつものすごいど阿呆なんだけどね)

漏れの残業は残業と思ってもらえていない。

あげくの果てに土曜日出てくれるかとかいわれそうな雰囲気だ。

ちなみに漏れは、今のプロジェクト以外に別のプロジェクトのプログラム保守(最終試験中)を平行で行っているのだ。

101 :仕様書無しさん:2006/06/20(火) 06:39:24
詳しく書かれていると思いきや・・・

例えば、「納品完了伝票の場合編集不可とする」だけ書いている場合がある。

これだけでは、不足である。「発注テーブルの納品完了フラグが納品完了となっている場合」とせめて記述してほしいものである。

こんな記述が抜けていて、後は中途半端にプログラム設計書に近い書き方になっている。

記述量は多いが、情報量は少ない設計書ってどやねん!?

102 :仕様書無しさん:2006/06/20(火) 10:44:39
つうか設計書に詳細落とす前に業務の状態を分析した用語辞書やコード定義などを作っておけば
「納品完了伝票」とは何?とが「納品完了伝票が編集不可状態になる」とはどういう事かが決められる。

ようするに業務の分析と用語の定義とがしっかりして無いだけだろ
曖昧な言葉で曖昧に仕様書・設計書を書くから問題がある

それを設計書にいちいち書く必要があるかどうかは別問題

ちなみに用語辞書やコード定義があるのに>>101の様に言うならばそいつはコーダ

103 :仕様書無しさん:2006/06/20(火) 17:11:24
>>102
でもさ、スレタイにある開発効率っていう点で考えれば

>それを設計書にいちいち書く必要があるかどうかは別問題

まさにこの問題についてじゃないの?

「納品完了伝票とはどういう状態のレコードを指すか」というのは
打ち合わせや事前ミーティングでなんとなくわかってたり
DB設計書のテーブル構成のフィールドに「納品完了フラグ」ってあれば
「ああ、これが1なら納品完了なんだ」ってのはわかる。

で、「納品完了伝票の場合編集不可とする」と書いてあった場合。
「納品完了伝票って何よ?」とDB設計書を漁るより、一言
。「発注テーブルの納品完了フラグが納品完了となっている場合」の方が
効率はいいわけで。

さらに言うと「編集不可」ってのはレコードが呼び出せない状態を言うのか、
表示はするが中の値を変えることは出来ないという意味なのか、とか。

こういう細かいところを一回一回SEに電話したり他の資料で調べたりするのは
PGの当然の義務なのか、それとも無駄な作業に入るのか。


104 :仕様書無しさん:2006/06/20(火) 18:41:41
コーディングだけが開発ですか?って事だよ
その手の事を詳細に書くときに発生する矛盾が残るよりも
1つの事象は1つの箇所に書き留める様にすれば、矛盾が起きた場合のリスクが軽減できる


105 :仕様書無しさん:2006/06/20(火) 19:13:11
>>104
個人的に思うのはね、
PGの仕事っていうかキモの部分っていうのは
仕様書を見て、同じプロジェクト内の他の仕様書と合わせて

どういう風にクラスを切っていこうか、とか
ここはインターフェースにするべき、いや抽象クラスにするべき、とか
最終的にどのタイミングでDBに詰めて永続化させるか、とか
ここでトランザクションをかけたら負荷的にどうだろう、とか

そういう技術的な実現方法を考えることだと思うんだよね。
演出家(SE)に対する撮影部(PG)みたいな。

そうすると演出意図(設計意図)を理解するのに台本(仕様書)の他に
配役表(DB構成図)やスケジュール表(コーディング規約)を読み直さないといけない、
ってのは
ドキュメントとしてはまとまってていいと思うんだけど
開発効率としてはどうなんだろうな、と思うわけです。

106 :仕様書無しさん:2006/06/20(火) 19:29:58
>>105
この女優は右斜め45度以外の角度は撮ってはいけない。
この男優は横から撮ると肉のだぶ付きが見えるため撮ってはいけない。
この建物は撮影許可とっていないから枠に入れてはいけない。

色々と制限事項はあるよね。これを台本に書いておくべきだと

ある日男優が病気で急遽出演できなくなり整合性を撮るために一部取り直しする事が決定した
こいつは真正面から撮ると蛙みたいに見えるので常に斜め30度の角度から撮らなくちゃいけない

こういう状況で、お前さんは台本が全て書き直されるのを待つのが効率が良いと言うのだな




107 :仕様書無しさん:2006/06/20(火) 19:49:20
>>106
女優や俳優の角度(取り扱い商品の表示制限)ってのは絵コンテで
事前に詳細に説明するべき所だし、
撮影許可(ライセンス)があるかどうかはさらにその前段階の話でしょ。
ロケハン(使用ツール策定)の段階で判断するもの。

音楽番組でアーティストが病気で急遽他のアーティストに代わったら
演出台本が書き直しになるのは、至極当然のことじゃない。

書いてる時間がなければカメリハの段階で口頭指示が出て、
みんな自分の台本にそれを書き込むよ。

急な制限事項の変更で仕様を書き直してる暇がなければ
緊急ミーティング開いて、今までの仕様書にPGが新たに書き込んだりするじゃん。

つまりさ、SEが「こんな感じになるのが理想」って部分が
PGが頭搾って考えるところでさ、
「こうして欲しい」ってものが明確にある部分は
仕様書に詳細に書いてあった方がPGとしては効率がいいと思うんだよね。
それがSEにとって2度手間になっている場合、
SEとPG、どっちが手間をかけるか、という話だと思う。




108 :仕様書無しさん:2006/06/20(火) 20:26:23
プログラムは構造化したがるくせに、設計書は構造化すると開発効率が落ちるのか?



109 :仕様書無しさん:2006/06/20(火) 21:12:12
>>108
構造化されたプログラムなら、呼び出し元に関数名を書かなければ呼び出せない。
>>1では関数名を書いてるのは例2.
例1はいわばアスペクト志向だな。

110 :仕様書無しさん:2006/06/21(水) 00:11:57
オレは設計書を書くときは
「誰が見ても誤解しない仕様をかく」ようにしてるが・・・・
いきなり「これ中国に出すから」とかいわれると・・・・ヴぁー

111 :仕様書無しさん:2006/06/21(水) 00:46:46
アジャイル開発ならそんな設計書自体いらないみたいよ。

112 :仕様書無しさん:2006/06/21(水) 00:52:11
>>111
そのかわり、触って試せる動く仕様書が必要だけどね。

113 :仕様書無しさん:2006/06/21(水) 00:59:56
オレ文章書くのが苦手だから、そっちの方がいいな。

114 :仕様書無しさん:2006/06/21(水) 15:48:19
>>111
あれは一人でやるにはいいが、ある程度の人数になると負のスパイラルに陥るぞ。
デスマが好きならお勧め。

36 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)