07/03/23 23:46:11
少しでも気を引きたい
純情な乙女心
51:仕様書無しさん
07/03/24 00:15:54
>>50
ﾜﾛｽ
52:仕様書無しさん
07/03/24 06:12:41
開発する時の複雑さを表しているとは思えないが、
メンテする時の複雑さとは関係が有ると思うな。
特に、ドキュメントが無いときには。
ところで、ファンクションポイントって、本当に使っているところあるの？
53:仕様書無しさん
07/03/24 11:08:46
っていうか、「ファンクションポイント」でググってみると
結構な数の HP が引っかかる癖に、
不思議なことに、そのどのページもが
肝心の「具体的な計測方法・測定例」を記述していないんですが・・・
「日本ファンクションポイントユーザ会」なんていう
ご大層な名前のページですら同様の状況だし。
もしかしてこれ、「鮫島事件」みたいなものなの？
54:仕様書無しさん
07/03/26 09:49:39
書籍でてるよ。
そもそもFPの計測まではまあ出来る。
ただ、それと工数との紐付けが、各企業なりで蓄積・評価するノウハウになるから、結局即使えるわけじゃない。
規模を測るには、FPとかオブジェクトP法とかがステップより合ってる。
ステップなんぞ、過去の遺物。技術者が限定されていて、言語が少なかった時代なら、スキルも記述形式も均一だから出来たこと。
55:仕様書無しさん
07/06/27 16:29:22
俺、リーマン時代からフリーの今まで、コード行数の統計取ってるけど
（もちろん見積りのデータになどしない）
コードを誠実に書いて、シェイプアップもちゃんとやって、なら工数や複雑さの指標としては
有効だと思うけどなあ。客先からはＸＸさんの作るコードは小さいがそのつもりで他所に出すと
エラくでかいのが出てくるとか言われる。実際石のダウングレードこちらから提案とかもあった。
56:仕様書無しさん
07/06/27 21:52:28
>>55
ある同じ人が書くコードの評価としては参考になるが、いろいろな人の
同じステップ数のコードの比較とは違うってことかな。
57:仕様書無しさん
07/06/29 06:14:00
まあそういうことかな。そんでコードの水増しが横行した結果、
「大きさは\の額に関する評価は対象外」ってのが定着してるから、
一般的な働き方としては「一度しか書かない」ことが殆どでしょ。
これで品質の良いコードが書けるのかと常々思ってる。
いろんな書き方があったらそれらを比較して、性能・リーダビリティ・短さなど何らかの基準で
評価・取捨選択して用いるぐらいのことしなきゃいいもの作れないと思うんだけど、
今の作業標準ってそういう働き方は「工数の無駄」にしかならないんだよね。
58:仕様書無しさん
07/07/13 00:08:26
仕様がコーディングの段階で完全に固まってたりデバッグが自分の仕事じゃなかったりするなら
一度しか書かないつもりで思う存分に書き散らせる気がする。
だが現実にそううまい話はないため自己防衛策としていろいろ工夫しないとね。
59:仕様書無しさん
07/07/13 05:48:55
俺なんか、製品になるのが5K行としたら15K行は書いてるな。
文章に関しては潤一郎あたりが言ってるけど、コードでも同じだと思う。
シェイプアップした姿は美しいが、贅肉ついた姿は醜い。
60:仕様書無しさん
07/08/18 13:30:18
価値あるコードはステップ数も多い。
ゴミコードはステップ数も少ない。
なんでこんな当たり前のことに疑問を抱く奴がいるのかわからん。
61:仕様書無しさん
07/08/18 13:52:00
増やすのが簡単で減らすのが難しいのは体重と同じか
62:仕様書無しさん
07/08/19 18:09:24
>>60
こんな
URLﾘﾝｸ(www.gnu.org)
63:仕様書無しさん
07/08/19 18:18:24
>>62
>Senior Manager
> % zmail jim
> I need a "Hello, world." program by this afternoon.
ﾜﾗﾀ
64:仕様書無しさん
07/08/19 19:20:58
>>62
CUIだとメールも出せない最高責任者、ｶﾜｲｿｽ・・・
65:仕様書無しさん
07/08/19 19:38:01
まぁ何かしら予想しないと見積もり出来ないわけで、そこはさておきとして以下私見。
・予想ステップ数と現在のステップ数の比較
まぁ現在の進捗率を表すのには有効かもしれない。
・予想テスト件数とテスト件数の比較
何これ。
意味が分からない・・・。
・予想バグ件数とバグ件数の比較
品質管理の観点から良くやる。
信頼度曲線とか。
予想バグ件数はテストしてくと変わって行くけどね。
予想テスト件数と予想バグ件数を予想ソースコード量から出すのはナンセンスだと思う。
さらに、予想と実績を無理矢理合わせるなんて無駄以外の何物でもない。
客先が納得するような「～～の結果、コード量が削減出来ました」
とかいう理由捻り出す方が良いんじゃない？
66:仕様書無しさん
07/08/25 21:03:39
>>62
Chief Executive
% letter
letter: Command not found.
To: ^X ^F ^C
% help mail
help: Command not found.
% damn!
!: Event unrecognized
% logout
くそわろたｗｗ
ブックマークにいれたよwwwwwwww