如何确定项目的大小(代码行、功能点、其他)【已关闭】

我们用“人日”来衡量一个项目的成本。 一个普通人能在多少天内完成这个项目。(嗯,有时多少年)

代码行不是最好的,但不是最差的单元,而是排除“库”。

一项研究估计开发人员每天可以写十行代码,这将保留在最终的程序中。(但他还将制定概念、文件、管理项目等…)

例如,检查 Ohloh project 分析了一些开源项目,他们用 COCOMO 算法(算法) online calculator ) 基础是代码行。

A部分 在开始之前,很难完全测量一个项目。如果您曾经参与过任何相当大的软件项目(听起来像是这样),那么需求实际上会随着时间的推移而变化。但是,我认为,如果您在敏捷环境中工作,那么故事点是衡量软件大小的一种好方法。在项目开始时,您将不知道所有的细节,但您应该有足够的时间给出一个估计。不确定性锥体 http://www.construx.com/Page.aspx?hid=1648 提供了一个很好的可视化,显示您可能是多么的精确。

B部分 你也可以在这里使用故事点。项目完成后,您应该知道您完成了多少个故事点。您还可以测量团队的速度(故事点除以某个时段)。

这里的关键之一是,您的团队正在使用类似的故事点度量,因此一个团队的任务需要2个故事点,这相当于另一个团队的2个故事点。

第一部分:

imho,敏捷方法提供了评估项目范围的最佳方法。您必须拥有一个具有已知速度的团队,在发布积压工作中进行第一次削减,并且以相同的方式为团队建立其速度的项目确定故事大小。在那里有一个很好的滑板平台 http://www.rallydev.com/learn_agile/agile_planning/release_planning/ 如果你感兴趣的话。

Agilists会指出您实际上选择了改变范围和日期/质量。所以从技术上讲,你并不是在估计项目的规模。相反,您正在优先处理您的积压工作,以适应固定的时间段。不过,一个有经验的团队,有既定的速度,可以给你一个合理的想法,什么时候会交付。

第二部分:

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

有一家叫QSM Associates的公司( http://www.qsma.com/tools.html )有大量的比较项目数据库。您可能需要查看他们的网站以获取资源。

我能推荐一本关于这个主题的非常好的书吗- Rapid Development 史蒂夫·麦康奈尔。这是同一个人写的代码完整,是一个远,远更好,更重要的书。它会告诉你 一切 您需要了解项目评估和度量。

OP如何衡量项目规模?我的意思是,OP会使用什么测量单位?在您的答案中,请注意建议项目大小而不是(计算机)程序大小的度量。

作为对A部分的回答,我会花时间和精力。以天(或小时,如果是一个足够小的项目)来衡量的时间,以人来衡量的努力。然后给出成本=时间x人员成本。在项目规划中,重要的是,任何衡量指标的估计(无论是什么)都必须附有这些估计的变化估计,例如200万美元(+/-0.20万美元)。

我可能会使用计算机程序大小的度量,例如loc或函数点来估计项目的编程部分。但我不会用这样的估计和乘数(比如)来估计一个项目的成本和持续时间。我的意思是,我不会用100天的编程时间加上2.5的系数来得到250天的项目规模。

当然,在一开始,当您所拥有的只是对项目的两行描述时,那么您将得到的只是一个带有较大误差界限的模糊估计。当您优化计划并确定子任务时,您可以更准确地估计。

一旦项目完成,我将希望我的统计数据与我最初的估计数据保持相同的形式,以便于比较,从而节省时间、精力和成本。我不确定我是否曾经使用loc作为生产力的度量,即使是回顾性的,我更倾向于使用一些功能交付的度量,尽管功能点分析等标准方法在我目前工作的领域(复杂的科学和技术代码)工作得不太好。

编辑:我对适当措施的时间、努力和成本的建议,部分是基于我作为项目经理处理客户、经理等非IT利益相关者的经验。项目管理是一项业务活动,与首席会计师或销售和营销团队讨论LOC和职能点不是他走对了。

我不确定这是否可以作为回答,但我的声誉太低,无法置评。

你的问题非常,非常广泛。有很多书试图用各种各样的运气来回答你的担忧。

尝试在几行中恢复整个领域是(至少)误导性的。

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

代码行是专门使用的危险措施。考虑两个开发人员,一个在3行中编写一些功能,另一个在50行中实现相同功能。谁更有效率?我在一个大系统中已经看到了这一点。这就是为什么我倾向于避开LOC。

我非常喜欢使用功能点进行功能大小调整。他们需要一点学习,但是一旦你学会了计算什么和如何计算的规则,他们就会在其他地方带来确定的主观性。基于功能点发布的度量可以揭示您的软件和软件项目的一系列洞察,而这是您无法从loc实现的。

我深信它们的实用性,于是写了一个应用程序供所有人使用,使计算功能点变得越来越容易和快速: projectsizer.com

每天计算300 fp是完全可以实现的。一个MI系统的每个FP的美国平均成本约为1500美元,因此每天计算300美元是非常值得的。