LOC 是项目估算的正确参数吗？
有很多情况下，单行代码的复杂性需要更多时间，除了 LOC 什么可能是项目估算的建议参数？
当人们谈论程序的功能点时，这是否意味着用例相关信息？
我正在尝试为完整的软件开发估计找出任何坚实的基础，包括分析、设计、测试用例准备和编码，请建议？
问问题
2106 次
6 回答
3
Steve McConnell 在快速开发中（微软出版社，1996 年）：
由于不同的编程语言对于给定的代码行数会产生如此不同的 bang，因此许多软件行业正在转向一种称为“功能点”的度量来估计程序大小。功能点是程序大小的综合度量，它基于输入、输出、查询和文件的数量的加权和。功能点很有用，因为它们允许您以独立于语言的方式考虑程序大小。
谷歌“功能点”了解更多信息。
于 2009-09-21T10:04:36.233 回答
2
鉴于开发人员可能*花费大部分时间尝试测试更改，代码行数从来都不是问题大小的良好指标。
假设您有一个现有的大型应用程序 - 更改一行代码可能看起来微不足道，但测试计划和执行可能需要数周时间。
同样，在一个易于测试的有限范围模块中添加相对大量的代码可能只需几天时间。
* 至少他们应该这样做。如果他们花更多时间编写代码而不是测试代码，那么它可能充满了错误。我的意思是在它到达您专门的 QA 团队之前。
于 2009-10-01T06:26:36.583 回答
1
LOC 是衡量问题规模的一种代理措施。
可以使用 LOC 估计，并且从历史项目中测量 LOC 计数相对便宜。但是，正如其他答案已经指出的那样，如果将 LOC 用于问题大小的代理以外的任何其他内容，则 LOC 可能会出现问题。
考虑到要求，问题的大小是相当恒定的。从规模估算，您可以进行工作量、进度和成本估算。这取决于您的计划驱动因素，例如成本或时间表。从历史数据中，您可以发现问题大小如何转化为工作量以及其他计划驱动因素如何进一步影响结果的相关性。因此，您需要测量尺寸测量和工作量与其他参数，并继续微调您的估计过程。文献中提供了一些 LOC-to-effort 措施，但它们在您的领域中不是很准确，使用您正在使用的技术和您拥有的团队。
问题大小的其他代理是功能点和故事点。我对功能点的经验是，它们很少值得付出努力。另一方面，敏捷方法中的故事点工作得非常好，因为它们是故意抽象的（因此避免了 LOC 的许多问题）并且在逐个 sprint 的基础上进行测量，并立即反馈到后续的 sprint。
于 2009-09-21T10:38:39.027 回答
1
仅当您反向使用它时。
- 编辑
但不是。它不是。这是一种几乎无用的措施，而且通常是有害的。正如您所注意到的，更少的代码几乎总是更好。
其他要检查的事情？好吧，你想测量什么？您希望从您要检查的内容的变化中看到什么结果？根据这些变化，您将做出什么样的决定？
于 2009-09-21T09:59:48.860 回答
1
不，不是。原因很简单：如果您在开发过程中生成一行新代码，您是否离解决方案更近了一步？如果您估计完成一项任务需要 1000 行代码，那么您现在是否完成了 0.1% 的任务？
代码行数可以用作衡量指标，但仅限于负面意义：对于更多的代码行数，假设您有更多的错误是合理的。根据历史数据，代码行数和错误数之间通常存在线性相关性。
以下是一些值得考虑的有用且可衡量的因素：
- 小时的劳动。
- 花费的美元：这是一个很好的选择，因为它强烈地强化了这样一个现实，即您宁愿在开发人员的桌面上找到错误，也不愿在测试人员或客户手中找到错误）。
- 达到的里程碑：系统是否在正确的日期提供给客户？
- 需求已完成：这可能很有趣——如果您在项目期间发现了新的客户需求怎么办？
简而言之，代码行数几乎是您可以使用的最糟糕的指标。
于 2009-11-03T17:59:47.817 回答
0
获得对项目持续时间的任何合理估计的唯一方法是完全实施和交付最终要求的某些子集。然后，您可以通过将它们的复杂性与已完成的工作进行比较来估计剩余的需求。
于 2010-01-25T20:00:48.677 回答