アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
COCOMOって... (スコア:1, 興味深い)
かれこれ30年近い昔のモデルで評価するのはあんまりです.(その当時の言語と言えば...)
COCOMOIIでももう10年になりますけど...
ついでに, どなかた他に良いモデルがあったら教えて下さい(笑)
# ファンクションポイントが入ればかなり違うと思う
Re:COCOMOって... (スコア:4, 興味深い)
COCOMO IIはCOCOMOに比べて無条件に上位に位置する方法ではありません。
入力パラメータを増やすことによりより正確な結果を得るものです。
それらの追加のパラメータは、各プロジェクトごとに、プロセスの成熟度やプ
ロダクトに要求される信頼性などを分析して数値化する必要があります。当該
プロジェクトに理解が深くない外部の人間にとって、これらのパラメータを求
めることは極めて難しくコストがかかることは容易に想像できるでしょう。
(もちろん、開発プロセスにCOCOMO IIを組み込んで統制されたプロジェクト
の場合は、そのような追加コストはありません。しかし、OSSプロジェクト
のうち何割がそのように統制されているでしょうか?ほぼ0割でしょう)
もともと、COCOMO IIですら大雑把な方法なので、COCOMOだろうがCOCOMO IIだ
ろうが、どちらを選んでも数値の説得性は大差はありません。レポートのマー
ケッティング上の価値は大差ないのに、行数を数えるだけで適用できるCOCOMO
と、莫大なコストをかけなければ適用できないCOCOMO IIのどちらを使うかと
言えば、COCOMOで十分だと考えるのは自然でしょう。
以上から、レポートの作成者はCOCOMO IIを知らなかったのではなく、単に
COCOMO IIが不適切だったから使用しなかっただけだと、私は考えます。
ファンクションポイントについても同様です。行数の測定はPCに高々何時間か
頑張ってもらうだけで完了します(ほぼ定数コスト)が、ファンクションポイ
ントの測定はアナリストがプロジェクトを分析する必要があり、プロジェクト
の規模に比例するコストがかかります。開発プロセスの最初からファンクショ
ンポイント法を適用しているのならともかく、事後のファンクションポイント
の利用はコスト的に極めて非現実的です。
p.s.
もちろん、今回のようなレポート作成の話ではなく、これからスタートするプ
ロジェクトのプロジェクト管理をどのように行うかという話でしたら、COCOMO
よりはCOCOMO IIの方がよい選択でしょう。ファンクションポイント法を用い
るのも悪くないかもしれません。他にも選択肢は沢山あるでしょう。