如何确定项目的大小（代码行，功能点，其他）

Question

您如何评估项目规模？

A部分：在开始一个项目之前。

B部分：对于一个完整的项目。

我有兴趣比较不相关的项目。以下是一些选项：

1）代码行。

• 我知道这不是衡量生产力的好指标，但这是衡量项目规模的合理指标吗？
• 如果我想估计重新创建一个项目需要多长时间，这是一个合理的方法吗？我应该估计一天有多少行代码？

2）功能点。

• 功能点定义为：
  • 输入
  • 输出
  • 查询
  • 内部文件
  • 外部接口
• 任何人都有一个关于这是否是一个好措施的观点？
• 有没有办法**实际上这样做？

有没有人有其他解决方案？花费的时间似乎可能是一个有用的指标，但不仅仅是。如果我问你什么是“更大的计划”并给你两个程序你将如何处理这个问题？

我已经在堆栈流程上看到过这方面的几个讨论，但大多数讨论如何衡量程序员的生产力。我对项目规模更感兴趣。

Answer 1

我们使用“人日”来确定项目的成本。 在一天中，一个普通人将完成该项目。 （好吧，有时多少年）

代码行不是最好的，但不是最差的单元，但排除'库'。

一项研究估计，开发人员可以写出十行/天，这仍然是最终的程序。 （但他也会制作概念，文档，管理项目等......）

例如，检查分析某些开源项目的Ohloh project，他们使用COCOMO算法（online calculator）估算成本。 基础是代码行。

Answer 2

A部分 在开始之前很难完全测量项目。如果您曾经参与过任何相当大的软件项目（听起来像您曾经这样），那么这些要求实际上会随着时间而变化。但是，如果您在敏捷环境中工作，我认为故事点是衡量软件大小的好方法。在项目开始时，您将没有所有细节，但您应该有足够的估计。不确定性的锥体http://www.construx.com/Page.aspx?hid=1648可以很好地显示您可能的准确度/精确度。

B部分 你也可以在这里使用故事点。项目完成后，您应该知道完成了多少个故事点。您还可以衡量团队的速度（故事点除以一段时间）。

这里的关键之一是你的团队使用类似的故事点测量，因此一个团队的任务需要2个故事点，这相当于你的其他团队的2点故事。

Answer 3

A部分：

恕我直言，敏捷方法提供了一种先验评估项目范围的最佳方法。您必须拥有一个具有已知速度的团队，在发布积压时首先削减，并以相同的方式为团队建立其速度的项目创建大小的故事。如果您有兴趣，可以在http://www.rallydev.com/learn_agile/agile_planning/release_planning/找到一个好的幻灯片。

Agilists将指出您实际上选择改变范围与日期/质量。所以从技术上讲，你不是在估算项目的规模。相反，您要优先考虑积压工作以适应固定的时间段。尽管如此，具有既定速度的经验丰富的团队可以让您合理地了解将在何时交付的内容。

B部分：

我认为你问题的关键部分是“无关”。 IMO这些指标只有在您比较类似项目时才会成立 - 在团队，专业知识，开发环境，应用领域等方面。项目越“无关”，比较项目规模就越困难。 KLOC和功能点指标似乎是使用最广泛的指标。

有一家名为QSM Associates（http://www.qsma.com/tools.html）的公司拥有一个庞大的比较项目数据库。您可能想查看他们的网站以获取资源。

Answer 4

OP如何衡量项目规模？我的意思是，OP会使用哪些测量单位？在您的回答中，请小心建议测量项目大小而不是（计算机）程序大小。

在回答A部分时，我会花时间和精力。时间以天为单位（或小时，如果它是一个足够小的项目），以人为单位衡量的努力。然后，这给出成本=时间x人 - 成本。在项目规划中，任何衡量标准（无论如何）都伴随着对这些估计变化的估计，例如$ 2M（+ / - $ 0.2M），这也是至关重要的。

我可能会使用计算机程序大小的度量（如LOC或函数点）来估算项目的编程部分。但我不会使用这样的估计和乘数（比如说）估算一个项目的成本和持续时间。我的意思是，我不会使用估计100天的编程加上因子2.5来获得250天的项目规模。

当然，从一开始，当你所拥有的只是项目的两行描述时，你所得到的只是一个含有大误差范围的模糊估计。在细化计划并确定子任务时，您可以更准确地进行估算。

项目完成后，我希望我的统计数据与我原来的估算结果相同，具有可比性，时间，精力和成本。我不确定我是否会使用LOC作为衡量生产力的指标，即使是追溯性的，我也更倾向于使用一些功能测量，尽管功能点分析等标准方法不能很好地工作在我正在研究的领域，复杂的科学和技术规范。

编辑：我对时间，精力和成本的建议作为适当的措施，部分是基于我作为项目经理处理非IT利益相关者（如客户，经理等）的经验。项目管理是一项业务活动而且，谈论LOC和功能点，比如总会计师或销售和营销团队，不是正确的方法。

Answer 5

我可以推荐一本关于这个主题的真正优秀书籍 - 史蒂夫麦康奈尔的Rapid Development。这是编写Code Complete的同一个人，是恕我直言，这是一本远远更好，更重要的书。它会告诉您关于项目估算和测量的所有。

Answer 6

我不确定这是否有资格作为答案，但我的声誉太低而无法评论。

你的问题非常非常广泛。有很多书籍试图以不同的运气回答你的担忧。

尝试在几行中恢复整个字段（至少）具有误导性。

我建议从这里开始：http://www.itmpi.org/这是一个很好的网站，有很多链接和适当的书目。

Answer 7

代码行是一种专门使用的危险措施。考虑2个开发人员，他们在3行中编写一些功能，而另一个在50行中实现相同功能。谁更有成效？我在大型系统上看到了这一点。这就是为什么我倾向于避开LOC。

我非常喜欢使用功能点进行功能调整。他们需要学习一些知识，但是一旦你学会了计算内容和规则的规则，它们就会带来确定性，否则就会产生主观性。基于功能点的已发布指标可以揭示您对软件和软件项目的全部洞察力，这些内容无法从LOC实现。

因此确信它们的实用性，我为所有人编写了一个应用程序，可以更容易，更快地计算功能点：projectsizer.com

一天计算300 FP是可以实现的。对于MI系统，美国每个FP的平均成本约为1500美元，所以每天计算其中300个是非常值得的。