大约十年前,我的一个酒友给了我一个非常伟大的智慧。在任何项目咨询中,都要问三个问题:1.我们要解决的问题是什么?2.可交付成果是什么?3.我们怎么知道什么时候结束?他补充说,任何一个项目如果在项目开始前有任何问题没有得到回答,就永远不应该承担这个项目。

在本案中,我们有另一个软件评估方法恐怖故事,其中的估计似乎高得离谱。在回答他的恐怖故事时,我会指出他没有回答第二和第三个问题,他也没有真正回答第一个问题,只是说“我们想建造这样的东西。”

我将进一步指出,他甚至没有明确地询问功能点估计在估计总数中包括或不包括哪些任务。例如,函数点估计器在允许文档的情况下需要付出多少额外的努力?如果他的估计是针对应用程序的,没有任何文档,而函数点估计器的估计是针对有完整文档的应用程序的,那么,我认为在所需的工作总量(和时间)上存在一些分歧。

只是我的感觉不会吗 任何一个像样的程序员 一周(我甚至不说周末) 完成它?

开发人员总是倾向于低估实际完成某项工作所需的时间。他们认为不会有bug,需求不会有任何变化,也不会有以前从未做过的事情,他们必须花上几天的时间去弄清楚。

从我所能看到的 截图,这个应用程序是一个 小excel改进应用程序。我可以 花200英镑买了微软办公软件 给我更多的钱 互操作性(.xls文件)和

你是在比较一个完全定制的软件和一个销售数百万份的软件的价格?说真的?

实际情况是,大多数软件评估方法实际上低估了,尽管乍一看,这似乎是违反直觉的。我曾经在一家公司工作过,那里每个人月300行代码被认为是一个很高的估计值,而大多数月份我们输入的代码大约是200-250行。但是让我们用200行代码吧,那就是每个工作日10行代码。谁不能在一个工作日内写出10行代码?加油!我可以写50到100行或更多的代码在一个好日子!然而,使用这些数字的公司却一再推迟进度、超出预算地完成项目。为什么?好吧,范围蠕变,正如迈克尔·博格沃德所说,是一个很大的问题。但是让我们把它从图片中拉出来一分钟,假设客户和客户第一次就做对了。为什么一个公司每天只估计10行代码?

• 需求分析
• 基于需求的软件设计
• 与团队成员协调接口和架构的会议。
• 间接费用(与管理层的状态会议、病假、假期等)
• 编写单元测试
• 为整个应用程序编写测试计划
• 应用程序级测试

不是FP专家。不过,我们目前正在研究FP。特别是,我们正在对旧项目执行FP分析,我们有工作量/成本等指标,然后我们可以评估它对我们评估/确定项目规模的有用性。

我的观点是,这将是一个有用的自上而下的'数量级'估计,以补充自下而上的估计。如果可以应用一种以上的估计技术来帮助验证到达“hold-up”的数字,这总是好的。

除非你有以前项目的FPA历史数据,否则FPA最终肯定会高估整个项目,使用行业标准。

一个好的团队领导者总是在做评估之前先评估他的团队能力。FPA也是如此,行业标准数据是基于历史数据得出的,而且这些数据因公司、团队和开发商而异。

所以我想说,如果你在未经调整的计数上使用-35%的最佳情况,你将达到~64的调整FP计数。这将给你大约3周半的估计。根据经验,我想说的是,这种应用程序可以做得比那早很多,但任何彻底的测试、调试、文档和其他书面工作都会使它进一步扩展,FP会考虑到这一点。很有可能你的团队每小时做一次FP。按照正常标准,编码和测试占FP计数的25%,因此在这种情况下,即使以99 FPs的数字计算,编码和测试部分也会降到25 FPs,这在这种情况下更容易理解。

我在实践中也看到,一些公司设计了自己的复杂性表,因此如果3个ret和10个det表示一家公司的平均复杂性,那么另一家公司会将其评为低复杂性。这将在很大程度上影响最终的FP计数。

因此,在你真正开始依赖FPA来制定成本和时间估算之前,请使用FP工具作为指导,并为以前的项目收集尽可能多的数据。

顺便说一句,我认为像这样一个简单软件的成本估算在今天看来是荒谬的,外包和自由职业者才是发展方向。一直从事这一行业的大公司对软件开发的收费仍然高得离谱。例如,如果你想让一个3级支持工程师在一个好的托管公司帮助你处理服务器,他们每小时收费250美元,但是你可以从世界其他地方的人那里得到同样的建议,收费25美元,甚至2.5美元。

希望我的2美分对你有用。

在我以前的公司,我们会这样计算——尤其是如果有人 欲望 支付费用;)

在某种程度上,我们应该说FP适合于中大型项目,可以扩展到350-400 FPs。

基于时间的支付间接导致绩效下降。我记得我对项目的各个方面都做了大量的研究,但是如果它有一个基于项目的付款方式,我可能没有这样做。是潜意识而不是道德。 最佳实践是参考“项目”定义(在有限的时间和预算内)并根据限制做出决策。这与工作本身无关,也就是说,雨天买伞的钱比平时买伞的钱要多得多。不要为所做的事和它的价值而烦恼。关注工作对客户及其选择的价值。

将您引用的示例中的值插入这个方便的在线函数点计算器( http://developergeeks.com/functionpoint.aspx

1. 调整FPs:42.9
2. 预计人月:0.54

假设一个工作月有160个小时,那么计算出来大约是86.4个小时,或者一个开发人员大约两个工作周。不是像你在第二步中总结的那样五个星期。考虑到为付费客户开发系统需要更多的关注和努力,而不是为了自娱自乐而在深夜敲打一些代码,我不认为这是一个不合理的估计。

真的不是一个轻量级的指标。如果小时/FP波动如此之大 很多,那么重点是什么,也许我可以用用户故事 点,这是快得多,可以说几乎不确定。

正如您所发现的,每个功能点的生产力高度依赖于许多因素,如团队经验、工具、编程语言、平台等。因此,行业标准很好地了解,但在大多数情况下完全没有用(以我的拙见)。重复计数的主要价值在于根据自己的团队生产力历史建立自己的“基准点”。这反过来将帮助你看到趋势,也有助于计划和预测未来变化所需的时间。 如果你在寻找速度,只需应用全局计数而不是详细计数。在做一些示例计数(比如准备考试时)时,你会注意到详细计数和全局计数之间的差异不足以让你睡过头(按百分比)。

这种讨论是绝对误导,因为问题已经假设FPA是一种努力估计技术。

函数大小(以函数点表示)可以是估计模型(如COCOMO)的许多输入因素之一。如果我们同意功能需求的“数量”是软件项目的一个努力驱动因素,那么就不会多,也不会少。