如何估计没有源代码的项目的SLOC？

Question

最近，我开始熟悉COCOMO模型，用于计算开发移动应用程序所需的工作量(人工月)和持续时间(以月为单位)。要计算工作量，应根据COCOMO II示范定义手册使用以下公式。

PM =A*尺码^E*(EMs的产品)

在这个公式中，大小应该用KSLOC表示(数千行源代码)。当还没有编写一行代码时，我怎么知道我的移动应用程序的KSLOC呢？人们通常只是做一个有教养的猜测，还是他们，例如，他们使用类似的项目作为他们的评估的基础？或者，在您还没有任何代码的情况下，是否有一些特定的方法来估计SLOC？

Answer 1

将SLOC输入到COCOMO的唯一方法是估计这个值。您可以使用不同的评估方法来尝试对正在设计的软件应用程序的大小作出估计。您可以考虑分解和重组、类推估计、基于代理的估计和专家分组判断，以估计作为COCOMO输入的大小。

您选择的方法很可能取决于您的环境。例如，如果你没有一群知识渊博的人，你真的不能在小组中使用专家判断。如果您这样做了，您可以使用任意数量的技术(包括我提到的其他技术)作为对团队评估工作的个人贡献。

如果您有良好的历史项目，那么您可以使用类比或基于代理的估计来与以前的项目或组件进行比较。如果您以前制作的组件的大小和作用域相似，那么您可以计算它。但是，如果您使用的是一种新的编程语言，或者您对过去的估计没有很好的历史记录，那么最好的方法是继续将工作分解成更小的、容易估计的部分，估计这些部分，然后滚动总备份。

需要考虑的其他事情是在COCOMO中使用功能点而不是SLOC。考虑到一组需求，计算功能点的数量要比试图估计SLOC的数量要容易一些。

Answer 2

首先，您可能应该意识到，这已经作为COCOMO的一个问题被引用了一段时间。相当多的人认为，替代方案，如功能点分析，更有意义(至少有些人声称经验证明了它的优越性)。

尽管如此，在我看来，你并没有给出不同的替代方案。一方面，你注意到：“有教养的猜测。”另一方面，你指出“使用类似的项目作为评估的基础”。

我认为这是一回事。看类似的项目基本上只是对自己进行项目规模教育(或者再教育)的一种方法。实际上，对大多数人来说，这是一个几乎必要的步骤。至少在我的经验中，大多数项目的贡献者实际上并不知道有多少行代码最终出现在这个项目中，而没有进行一些检查(考虑到代码重用之类的事情，这通常比在项目的目录树(S)上运行wc更多)。

我自己的观点:代码行更能分散注意力而不是帮助。看看之前的一个项目，他说：“这需要大约六个月的时间，大约是原来的两倍，所以可能要花一年左右的时间。”这样做的准确性至少要低得多。如果您想要添加更多的工作来改进这一点，那么是的，我发现功能点是一种合理的方法--通常将一组需求转换为至少一些功能点的概念是相当简单的(如果不能，这通常是因为需求缺乏给出有意义的估计所必需的细节)。

Answer 3

我会提供一个肯定不会令你满意的答案，但我必须提醒你注意以下几点。

在计算机科学中，和任何科学一样，在使用数学工具之前，你需要彻底评估你的意图是否与工具的有效性领域相对应。你确定这里是这样的吗？

COCOMO

科学基金会

COCOMO等统计估计模型基于对软件特性和开发环境的假设，以及对现有项目的大量统计。其思想是，具有相同特征的项目是相对同质的。

例如，初始COCOMO 已开发使用回归分析对有限的一组项目在一个工业分支。当然，COCOMO II扩大了所考虑的基础和标准。但它也是基于一个假设历史基础很大的统计模型。在你所指的手册中提醒了这一点：

..。假设生命周期阶段和劳动力类别包括在其努力和时间表的估计.这些定义和其他定义(.)用于收集COCOMO II校准的所有数据。如果使用其他定义和假设，则需要调整COCOMO II估计值或重新调整其系数。

该方法于2000年更新。否则说它可以追溯到史前。因此，它既不能考虑开发工具和项目管理中的技术转移，也不能考虑移动开发的特点。

你真的认为这样的方法会比在跳蚤市场上发现的水晶球更精确吗？-很抱歉，这么直接--

功能点替代

功能点法是一种比COCOMO更易于应用的方法。然而，它也有其局限性：

• 首先，它主要根据项目的外部特性来估计总体努力。这并没有考虑到在面向对象的世界中通过软件重用实现的提升。
• 同样，它是基于大量项目的统计数据的积累，在你所瞄准的技术中。

请再说一遍，这里有有效的历史数据吗？

其他方法

自那以后，软件估计一直是一个微妙的课题。有几种方法不太正式，但提供了可用的数字。例如：

• 类比估计：你采取一个类似的项目，看看他们有多近和有多不同，并相应地调整估计。有趣的是，为了递归地评估工作中的差异:对于差异，您可以根据其他地方测量到的类似差异来估算差异，也可以使用其他评估方法(包括FP和COCOMO)，但不确定程度将低于从头开始估算，因为您已经有了一个共同的基础，原则上应该是总体的重要组成部分。在您的上下文中，如果没有内部移动体验，请忘记这一点(除非您能够找到一些现有的开源项目并将其大小作为起点--但这需要有经验的s.o.来估计差异)。
• 德尔菲法：您需要一个专家小组(例如，高级开发人员和/或项目经理对您所设想的项目有经验，最终是独立的第三方，例如来自协作业务合作伙伴的专家)，并提出一个小组评估。这里的关键是，专家不直接相互作用，以免相互影响，但他们的个别估计是汇总在一起的。
• 您可以在专家之间进行直接交互的变体也是可能的。
• 您还可以考虑到一些风险管理技术和工作，例如，使用最小和最坏的情况来评估不确定性的影响。

根据我自己的经验，这些方法是非常有效的。当类似的项目有重要的历史数据时，类似的方法是好的。但进入新领域时，德尔菲法(最终对不同参与者的信任系数不同，根据他们各自的成功轨迹)是我认为最有效的方法。这是因为专家们考虑到了他们对项目的所有知识，包括对团队有效性的信心，使用的开发方法，以及他们认为必要的不确定性和利润率)。

结论

有些人声称这一切都是估计。他们是完全正确的。但是最好从一个近似的猜测开始，来估计球队的规模并得到一个预算，而不是毫无头绪。此外，估算并不是一门精确的科学，而且有许多潜在的误差来源。因此，评估必须在项目期间定期重新评估。