07/03/09 11:42:46
お偉いさんというものは仕事のための仕事をこさえるものだよ。
それがプロジェクトにとって有益かどうかなど関係ないのだ。
30:1
07/03/09 11:48:00
>>29
わかります。なので、手軽な回避方法を考えたいわけですね。私が
思い付くのは、
・意味の全く無いクラスを指定行数で吐き出すマクロを作る。
というぐらいですかね。これ、実際にやったかたいらっしゃいますか？
31:仕様書無しさん
07/03/09 12:16:40
素朴な疑問なんだけど、
予想テスト件数と実績テスト件数、
バグ予想件数とバグの件数
結果的にこれらの差が大きかった場合になんか問題あるの？
今度は予想が食い違った原因を究明して報告しろとか言ってくんのかな？
細かい単位のイティレーションではまだしも、最初からシステム全体の
なんてどう考えても正確にはだせないよなぁ。人間業じゃないよ。
もし出すとしたら、
・仕様が凍結されていること
・その仕様と非常に類似した同一環境、同一言語、技術ベースの既存システムがあり、そのステップ数と機能比較可能な資料があること
が最低条件かなぁ。じゃないと俺には無理だな。それこそ職人の勘頼りの
おおざっぱなものしかだせない。
32:1
07/03/09 13:48:40
>>31
> 結果的にこれらの差が大きかった場合になんか問題あるの？
ありますね。多分、その理由を報告しろとか面倒なことになります。
相手はどことは言いませんが、よくあるシステム子会社、やっていることはITゼネコンです。
基本的にシステムのことは全く分からないですし、ユーザーサイドの業務についても全く
知りません。完全丸投げですね。
ですので、ユーザーサイドから「何しているの？」と聞かれたときに答える資料が
欲しいわけですが、それがコード行数とテスト件数、というか、それ以外はできない
のです。他にもアナライズする方法は色々ありますが、彼らはその名前すら
知りませんからねw。
私としては、彼らとのやりとりを極限まで減らしたい、つまり、実質いないのと同じ
状況まで持っていきたいわけです。ま、コード放りこんで奴らの必要情報を提示し、
且つ、コード自体も辻褄をあわせるように改編する、っていうのを目指してます。
33:仕様書無しさん
07/03/10 00:03:06
>>1
基本的な認識が違う。判っていると思うが再確認。
予想ステップ数
なんの役に立つか。見積もり時の工数積算にしか役に立たない。
それも「開発工数はステップ数に比例する」という前提が成立していればの話だ
ステップ数からの予想テスト件数
テスト件数の予想は少なくとも仕様の定量化が出来ないと不可能だ。
仕様の定量化を行うには「ステップ数を基にすることが正しい」という前提がないと成り立たない
実績テスト件数
これも仕様の定量化
バグ予想件数
「バグ数はステップ数に比例する」という前提が必要だ
バグの件数
これも「バグ数はステップ数に比例する」という前提が必要
#しかしながらバグの件数はメトリクス値として最重要
沢山書かれた「前提」そのものがどれひとつとして正しくない。だが、
ステップ数マニアにとって定量化の全ての基盤はステップ数なのだ。
御愁傷様。
貴方はその顧客に対する役に立たない情報を報告する義務があるようだね。
進捗報告と品質計測の一環として。
回避の方法？自分はお役には立てないよ
34:仕様書無しさん
07/03/10 00:55:52
予想テスト件数ってのも激しく意味不明なんだが(´・ω・`)
テスト件数って仕様の種類(ブラックボックス)+分岐の数(ホワイトボックス)で
出る訳だから、実績のみあれば十分じゃね？
テスト工数見積もり用データとかに使う？
35:仕様書無しさん
07/03/10 01:00:48
そういえば、オブジェクト指向で有名wな某Oへ面接行った時に
時間辺りのステップ数聞かれたな。
いくらでも増やせます♪って答えといた(ﾟ∀ﾟ)
営業が必死でフォローしてたがなwww
36:仕様書無しさん
07/03/10 01:38:43
おまいらそうは言うがなあ。
ソフトウェアの規模をさっくり表す指標としてはなんだかんだで
行数・ステップ数が使いやすいと思うぞ。第ゼロ近似くらいにはなる。
規模の計測や工数の予想を一応仮にもやらなきゃならないなら
そんな感じでやるしかないじゃん。
ステップ数がいやならファンクションポイントなりなんなりで
きちんとやってみてくれ。
37:仕様書無しさん
07/03/10 02:09:19
その分の工数くれるんならやりまんがな
それと正確にはだせないよ。前後50%ぐらいのブレは大目に見てくれ。
38:仕様書無しさん
07/03/10 02:16:50
ソフトウェアの規模をさっくり表す指標としては
ステップ数より仕様書の文字数のほうがまだマシ
39:仕様書無しさん
07/03/10 11:35:22
いっそオブジェクトコードのバイト数でどうだろ。
コメント関係なくなるしいいじゃん。
見積もりが無理だ。
40:仕様書無しさん
07/03/10 14:22:12
そうだな、掛ける10 するところを、足し算10回して膨らませるか
41:1
07/03/10 16:55:47
色々御意見ありがとうございます。
やはり現場サイドの人間としては、ステップ数に拘るのは下らないというのは
共通認識、常識だろうと思います。ただ、自分がここで考えたいのは、意味は
無いが、それしか親会社、或は上位部署に自分達が提示するネタがない人々
にいかに関わっていくか、という点です。
つまり、自分としては、そういう人々を真正面から考えを改めるよう説得するなど
ということは微塵も考えてません。そういう人々はそういう人々で勝手に間違った
発想で仕事してもらって構わない。但し、こちらがその影響で害を被るのを極限
まで避けたいということです。
42:1
07/03/10 17:00:23
ちなみに、現状私が出している「ステップ予想」と「テスト予想」の出しかたですが、単純に
同様のシステムでの過去の実績値から出してます。例えば、ある程度まとまった機能を
持つ画面を新規で作成した場合にどれぐらいのステップ数が追加されているか。或は、
既存機能で一部見直しをした場合に、どれぐらいステップ数の変更が発生したか、その
過去実績から概算で出してます。
ただ、これは当然結果として全く違う数値になる可能性がありますので、辻褄合わせが
必要ですので、上にどなたか書いているように、不要なプログラムコードを追加するなど
をしようと思ってます。
43:仕様書無しさん
07/03/10 22:53:49
>>32,41
理不尽な相手を説得するか、システム側を直してつじつま合わせるか。
後者を選ぶのは了見が間違ってると思うがなあ。
どうしてもそうするというのなら勝手にすれば？
実績を予想に無理矢理合わせることがまかり通ったら、
その時点で「予想」の意味がないじゃないか。
過去の実績も「予想」に合わせて調整された値かもしれん。
44:仕様書無しさん
07/03/10 23:14:48
>>43
ステップ予想がそもそも現状にそぐわない無意味な手法なんだか
らいいんだよ。
「理不尽な相手を説得」するために不毛な時間を費やしたくない
って>>1は言ってるじゃん。神様には適当に愛想ふっとけばいいん
だよ。
45:仕様書無しさん
07/03/11 03:19:48
問題は二つ。
(1)ソフトウェアの規模の指標としてステップ数を使うことの是非
規模の測定が本質的に不可能だというなら、だったら逆に行数でもいいじゃん。
(2)実績が予想と食い違ったときに誤魔化すか説明するか
ここで誤魔化すべきじゃない。正直が最良の戦略のはずだ。
政治的な問題でシステム実装におかしな要素が入るなんて駄目だろ。
実績と予想が食い違う->その理由はこれこれ、を何回か繰り返せば
「ああ、そういうものなのか」とじきに慣れて文句言わなくなる。
46:1
07/03/12 10:39:23
>>45
> 規模の測定が本質的に不可能だというなら、だったら逆に行数でもいいじゃん。
不可能なら行数、というのなら、最初から出さなければいいだけですね、本当は。逆に行数を
規模測定の値として、それが意味の無いものだという注釈付きだとしても、出してしまうという
のは面倒なことになります。
これは次のことにつながります。
> 実績と予想が食い違う->その理由はこれこれ、を何回か繰り返せば
> 「ああ、そういうものなのか」とじきに慣れて文句言わなくなる。
このことは、ステップ数を出せと言っているゼネコン企業の担当は分かっている、というか、何も
分からないというかｗ。つまり、ステップ数が意味があるか無いかは、彼らにとっては最初から
どうでもいいのです。どうでもいいが、金を支払うユーザーに対して、規模の根拠を何も示せない
のでは示しがつかない、だからやっているということです。
そして、出してしまうならば、その数値が適当です、なんてことはいくらトンネル企業でも言えませんよ。
なので、彼らとしては、自分たちが知らないところで勝手につじつま合わせをしてもらえればよろしい、
そう考えているはずです。
47:仕様書無しさん
07/03/19 22:28:45
結局、見積り面倒だから全部>>1に投げてるような感じか？
48:仕様書無しさん
07/03/23 14:14:46
意味はあるが価値はない。
49:仕様書無しさん
07/03/23 23:14:18
>>1
お前は、プログラムを
作る人なの？
作らせる人なの？
どっち？
50:仕様書無しさん
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