LOC 项目估算参数是否正确？
LOC 项目估算参数是否正确？
在很多情况下，单行代码的复杂性需要花费更多时间， 除了 LOC 之外，项目估算的建议参数还有哪些？
当人们谈论程序的功能点时，这是否意味着用例相关信息？
我正在努力寻找完整软件开发评估的坚实基础，其中包括分析、设计、测试用例准备和编码，请提出建议？
Is LOC correct parameter for project estimation?
there are so many scenarios where complexity takes much more time for a single line of code,
other than LOC what could be the suggested parameter for project estimation?
As peoples are talking about functional point of program does it mean for use case related information?
i am trying to find out any solid base for full software developement estimation which can consist analysis, design, testcase preparation, and coding, please suggest?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
Steve McConnell 在《快速开发》中（微软出版社，1996 年）：
谷歌“功能点”了解更多信息。
Steve McConnell in Rapid Development (Microsoft Press, 1996):
Google "Function Point" for more information.
由于开发人员可能*花费大部分时间来尝试测试更改，因此代码行数从来都不是问题大小的良好指标。
假设您有一个现有的大型应用程序 - 更改一行代码可能看起来微不足道，但测试计划和执行可能需要数周时间。
同样，在易于测试的单个有限范围模块中添加相对大量的代码可能只需要几天的时间。
* 至少他们应该这样做。如果他们花在编写代码上的时间多于测试代码的时间，那么代码可能充满了错误。我的意思是在它到达您的专门 QA 团队之前。
Seeing as developers are likely to* spend most of their time trying to test changes, lines-of-code is never a good indicator of size of a problem.
Let's suppose you have an existing large application - changing a single line of code may seem trivial, but the test planning and execution could take weeks.
Likewise, adding a relatively large amount of code in a single limited-scope module which is easily testable might be only a few days.
* they should do, at least. If they're spending more time writing code than testing it, it is probably full of bugs. And I mean BEFORE it reaches your dedicated QA team.
仅当您以相反的方式使用它时。
——编辑
但是没有。事实并非如此。这是一种几乎无用的措施，而且通常是有害的。正如您所注意到的，代码越少越好。总是。
还有其他要检查的事情吗？好吧，你想衡量什么？您希望从您要检查的事物的变化中看到什么结果？根据这些变化，您将做出什么样的决定？
Only if you use it in the inverse.
-- Edit
But no. It isn't. It's a mostly useless measure, and generally harmful. As you note, less code is almost always better.
Other things to check? Well, what are you trying to measure? What result do you want to see from a change in the things that you would be checking? What sort of decisions will you be making on the basis of these changes?
LOC 是衡量问题规模的一种代理衡量标准。
可以使用 LOC 估计，并且从历史项目中测量 LOC 计数相对便宜。但是，正如其他答案已经指出的那样，如果 LOC 用于代替问题大小的代理之外的任何其他用途，则可能会出现问题。
考虑到需求，问题的大小是相当恒定的。从规模估算中，您可以进行工作量、进度和成本估算。这取决于您的计划驱动因素，例如成本或时间表。从历史数据中，您可以找到问题大小如何转化为工作量以及其他规划驱动因素如何进一步影响结果的相关性。因此，您需要衡量尺寸测量和工作量与其他参数的比较，并不断微调您的估计过程。文献中提供了一些 LOC-to-effort 衡量标准，但它们在您的领域、您正在使用的技术以及您拥有的团队中并不是很准确。
问题大小的其他指标是功能点和故事点。我对功能点的经验是，它们很少值得付出努力。另一方面，敏捷方法中的故事点效果很好，因为它们是故意抽象的（从而避免了 LOC 的许多问题），并且在逐个冲刺的基础上进行测量，并立即反馈到后续冲刺中。
LOC is one proxy measure for measuring the problem size.
LOC estimate can be used, and LOC count is relatively cheap to measure from historical projects. But LOC can be problematic if used for anything else than a proxy for problem size, as already pointed out by other answers.
Problem size is rather constant given the requirements. From a size estimate you can go to effort, schedule and cost estimates. It depends on your planning drivers such as cost or schedule. From the historical data you can find correlation how problem size translates to effort and how other planning drivers further influence the outcome. So you need to measure size measure and effort vs. other parameters and keep on fine-tuning your estimation process. There are some LOC-to-effort measures available in the literature, but they are not very accurate in your domain, using the technology you are using, and the team you have.
Other proxies for problem size are function points and story points. My experience on function points is that they are rarely worth the effort. On the other hand, story points in agile methods work very well since they are deliberately abstract (thus avoiding a lot of problems with with LOC) and measured on a sprint-by-sprint basis, with instant feedback into following sprints.
不，不是。原因很简单：如果你在开发过程中产生了一行新代码，你是否离解决方案又近了一步？如果您估计需要 1000 行代码来完成一项任务，那么您现在该任务完成了 0.1% 吗？
代码行数可以用作衡量标准，但仅限于负面意义：对于更多数量的代码，可以合理地假设您有更多的错误。根据历史数据，代码行数和错误数之间通常存在线性相关性。
以下是一些值得考虑的有用且可衡量的因素：
简而言之，代码行数几乎是您可能使用过的最糟糕的指标。
No, it isn't. The reason is simple: if you produce a new line of code during your development, are you one step closer to a solution? If you estimated 1000 lines of code to complete a task, are you now 0.1% complete with that task?
Lines of code can be used as a metric but only in the negative sense: for a greater number of lines of code, it is reasonable to assume that you have a greater number of bugs. Based on historical data, there is generally a linear correlation between lines of code and bug count.
Here are some useful and measurable factors that are worth considering:
In short, lines of code is very nearly the worst possible metric you could ever use.
对项目持续时间进行合理估计的唯一方法是完全实施并交付最终需求的某些子集。然后，您可以通过将剩余需求的复杂性与已完成的工作进行比较来估计剩余需求。
The only way to get any reasonable estimate on project duration is to COMPLETELY implement and deliver some subset of the final requirements. Then you can estimate the remaining requirements by comparing their complexity against the completed work.