ソースコードがまだないプロジェクトのSLOCを見積もるにはどうすればよいですか？
最近、私はCOCOMO IIモデルに慣れてきて、モバイルアプリケーションの開発に必要な労力（月数）と期間（月単位のカレンダー時間）を計算しています。作業量を計算するには、次の式を COCOMO IIモデル定義マニュアル に従って使用する必要があります。
PM = A *サイズ^ E *（EMの製品）
方程式では、サイズはKSLOC（コードの数千のソース行）で表す必要があります。コードが1行も記述されていない場合、モバイルアプリケーションのKSLOCを知るにはどうすればよいですか？人々は通常、知識に基づいた推測をするだけですか、たとえば、推定の基礎として同様のプロジェクトを使用しますか？または、コードがまだない状況でSLOCを推定するための特定の方法はありますか？
SLOC入力をCOCOMOに取得する唯一の方法は、それを推定することです。設計中のソフトウェアアプリケーションのサイズを推定するために使用できるさまざまな推定方法があります。 COCOMOへの入力として使用するサイズを推定するために、分解と再構成、類推による推定、プロキシベースの推定、専門家によるグループでの判断を検討できます。
選択する方法は、環境によって決まる可能性があります。たとえば、知識のある人のグループがない場合、グループで専門家の判断を実際に使用することはできません。もしそうなら、あなたはグループの努力を見積もる個々の貢献として、（私が言及する他のものを含む）いくつものテクニックを使うことができます。
優れた履歴プロジェクトがある場合は、類推による推定またはプロキシベースの推定を使用して、以前のプロジェクトまたはコンポーネントと比較できます。サイズとスコープが似ている以前に作成したコンポーネントがある場合は、それを数えることができます。ただし、新しいプログラミング言語を使用している場合、または過去の見積もりの良い履歴がない場合は、作業をより小さく簡単に見積もられる部分に分解し続け、それらを見積もり、合計をロールバックするのが最善の方法です。 。
SLOCの代わりにCOCOMO IIで function points を使用することを検討する必要があります。一連の要件がある場合、SLOCの数を見積もるよりも、関数ポイントの数を数える方が簡単な場合があります。
まず、おそらくこれは、しばらくの間、ココモの問題として挙げられてきたことに気づくはずです。 関数ポイント分析 などの代替案はより理にかなっているとかなりの数の人が考えています（少なくとも、経験がその優位性を裏付けると主張する人もいます）。
そうは言っても、あなたが本当に別の選択肢を与えてきたようには思えません。一方では、「推測による推測」に注意してください。もう1つは、「同様のプロジェクトを見積もりの基礎として使用する」ことです。
これらは本当に同じことだと思います。同様のプロジェクトを検討することは、基本的にはプロジェクトのサイズについて自分自身を教育する（またはおそらく再教育する）方法にすぎません。現実的には、ほとんどの人にとってこれはほぼ必要なステップです。少なくとも私の経験では、ほとんどのプロジェクトのほとんどの貢献者は、何も見ずにそのプロジェクトに何行のコードが含まれているかを実際に知りません（そして、コードの再利用のようなものを考えると、通常はwcもプロジェクトのディレクトリツリーにあります）。
私自身の見方：コードの行は、助けるよりも気を散らすために多くを行います。以前のプロジェクトを見て、「約6か月かかりましたが、これは約2倍のサイズなので、おそらく1年程度かかるでしょう」と言うのは、少なくとも同じくらい正確で、作業量はかなり少なくなります。それを改良するためにさらに作業を追加したい場合は、はい、私は関数ポイントが合理的なアプローチであることを発見しました-通常、一連の要件を少なくともいくつかの関数ポイントの概念に変換することはかなり簡単です（そして、 't、それは通常、要件が意味のある見積もりを与えるために必要な詳細を欠いているためです）。
私は確かにあなたを喜ばせない答えを提供しますが、いくつかの点であなたの注意を喚起する必要があります。
コンピュータサイエンスでは、すべての科学について、数学ツールを使用する前に、使用目的がツールの有効性のドメインに対応しているかどうかを完全に評価する必要があります。ここでそうなのですか？
ココモの科学的基盤
COCOMOなどの統計的推定モデルは、ソフトウェアの特性と開発環境、および既存のプロジェクトの大規模な統計に関する仮定に基づいています。同じ特性を共有するアイテムは比較的均質であるという考え方です。
たとえば、最初のCOCOMO 開発された は、1つの産業部門の限られた一連のプロジェクトで回帰分析を使用しています。もちろん、ココモIIは考慮されるベースと基準を拡大します。しかし、それはまた、大規模な歴史的基盤を想定した統計モデルに基づいています。これはあなたが参照しているマニュアルで思い出されます：
...ライフサイクルのフェーズと労働カテゴリについての想定は、その取り組みとスケジュールの見積もりでカバーされています。これらおよびその他の定義（...）は、COCOMO IIが較正されたすべてのデータを収集する際に使用されました。他の定義と仮定を使用する場合は、COCOMO IIの推定値を調整するか、その係数を再調整する必要があります。
この方法は2000年に更新されました。それ以外の場合は、先史時代にさかのぼります。したがって、開発ツールとプロジェクト管理の両方での技術的な変化や、モバイル開発の特性を考慮することはできませんでした。
そのような方法は、今日では、フリーマーケットで水晶玉が見つかったという見積もりの精度が上がると思いますか？ -とても直接的であることを申し訳ありません-
関数ポイントの代替
関数点法は、COCOMOよりもIMOで簡単に適用できるものです。ただし、次のような制限もあります。
- まず、主にプロジェクトの外部特性に関する全体的な取り組みを推定します。これは、オブジェクト指向の世界でソフトウェアを再利用して達成できるブースティングを考慮していません
- 繰り返しますが、これは、対象とするテクノロジーにおける、多数のプロジェクトに関する統計の蓄積に基づいています。
繰り返しますが、ここには有効な履歴データがありますか？
その他のアプローチ
ソフトウェアの見積もりは、これまでデリケートな問題でした。あまり正式ではないが、使用可能な数値を提供する方法がいくつかあります。例えば：
- 類似の見積もり ：同様のプロジェクトを取り、それらがどの程度近く、どの程度異なっているかを確認し、それに応じて見積もりを調整します。ここで面白いのは、違いを再帰的に評価するために評価することです。違いについては、他の場所で測定された同様の違いに基づいて違いを推定するか、他の評価方法（FP =とCOCOMO）ですが、原則として全体のかなりの部分を占める共通のベースがすでにあるため、不確実性のレベルは最初からの見積もりよりも低くなります。この状況では、社内にモバイルエクスペリエンスがない場合、これについては忘れてください（既存のオープンソースプロジェクトをいくつか見つけて、そのサイズを開始点として測定できる場合を除きますが、これは、違いを見積もる経験がある人を想定しているためです）。
- delphi method ：専門家のパネル（たとえば、上級開発者やプロジェクトマネージャーが想定している種類のプロジェクトの経験、最終的には共同ビジネスパートナーの専門家などの独立した第三者）を選び、グループの見積もり。ここでの鍵は、お互いに影響を及ぼさないために、専門家が直接相互作用しないことですが、彼らの個々の推定値は集計されます。
- エキスパート間で直接やり取りできるバリエーションも可能です。
- また、いくつかのリスク管理手法を考慮に入れて、たとえば最小および最悪のシナリオで作業して、不確実性のランスを評価することもできます。
私自身の経験では、これらの方法は非常に効果的です。類似のプロジェクトの重要な履歴データがある場合、類似の方法が適しています。しかし、新しいフィールドに入るときは、デルファイアプローチ（最終的には、参加者ごとに、それぞれの成功トラックに応じて信頼係数が異なる）が最も効果的だと思います。これは、専門家がプロジェクトに関するすべての知識を考慮しているためです。これには、チームの有効性への自信、使用されている開発方法、必要と思われる不確実性とマージンが含まれます）。
結論
一部の人々は、これはすべて客観的であると主張します。彼らは完全に正しいです。しかし、まったく手掛かりがない場合よりも、チームのサイズを決めて予算を獲得するための概算の推測から始める方がよいでしょう。さらに、推定は正確な科学ではなく、多くの潜在的なエラーの原因があります。そのため、見積もりはプロジェクト中に定期的に再評価する必要があります。