我在工作场所(一所大学)见过,大多数学生都使用COCOMO进行最终文凭工作的软件估算成本。我的猜测是,这种估算成本的方法有些陈旧(COCOMO于1981年成立),因此我的问题是:
How do you estimate costs in your software?
我看过类似的东西:
费用=(每小时工作量+估计的空闲时间)* HourlyRate
那不是我想要的,我正在寻找一个正确的(科学地)定义的成本模型
编辑我已经找到了一些相关的问题:
我在工作场所(一所大学)见过,大多数学生都使用COCOMO进行最终文凭工作的软件估算成本。我的猜测是,这种估算成本的方法有些陈旧(COCOMO于1981年成立),因此我的问题是:
How do you estimate costs in your software?
我看过类似的东西:
费用=(每小时工作量+估计的空闲时间)* HourlyRate
那不是我想要的,我正在寻找一个正确的(科学地)定义的成本模型
编辑我已经找到了一些相关的问题:
Answers:
万一您陷入瀑布模式,我使用的唯一相当准确的方法是:
您将得到一个非常精确的数字。我并不是说这很准确,但是会很准确。
准确性完全取决于能否根据过去的经验为每个任务提出一个数字,或者找到以前做过的事情。您拥有的经验越多,您获得的估计就越好。
在执行项目时,针对每个任务跟踪时间,并写下您错过的任务,以便您进行比较。随着时间的推移,这会使您变得更好。
软件估算非常困难。我使用的一种方法是尽可能细化需求并分别估算每个需求。然后添加一个“忽悠系数”,它可以是一个乘数(乘以两倍)或一个固定的量(对于未预期的工作为x小时)。如果您没有很好的需求,那么出于实际目的进行估算是不可能的。
我已经了解了一些“严格的”方法,例如功能点估计及其为现代应用程序设计的一些变体。我认为这些方法中有价值的部分是,它确实对已知要求进行了更详细的分析,然后我可能会给出其他要求。
即使您有一个好的模型,也很难获得一套好的数据来处理。衡量生产力很难。人们几乎可以使用任何指标。
我之所以停止使用它,是因为我的组织功能失调,无法从软件估算中受益,但是我确实对Cost Xpert组及其工具有所关注。但它非常昂贵,对于大多数组织而言,可能不值得付出成本和学习所需要的时间。
我们通常所做的是将整个工作范围划分为主要模块/元素,可以将其视为子项目。换句话说,它们是那些工作部分,客户将其视为项目的独立部分,并且客户希望分别进行估算。
完成后,我们将每个模块划分为任务,子任务,甚至更小的子子任务,以便可以很容易地估算每个模块,并且估算需要一到十个工时。这样,我们就可以详细了解该项目的工作范围。
最后一步是在里程碑之间分配任务。我们这样做是为了让每个里程碑客户都可以看到可见的结果。这有助于通过一个里程碑并转移到另一个里程碑。所以最后我们得到了类似的东西:
<ol>
<li>
Primary task 1 - 5 hrs
<ol>
<li>Subtask 1.1 – 3 hrs</li>
<li>Subtask 1.2 – 2 hrs</li>
</ol>
</li>
<li>
Primary task 2 - 9 hrs
<ol>
<li>Subtask 2.1 – 1 hrs</li>
<li>Subtask 2.2 – 2 hrs</li>
<li>Subtask 2.2 – 5 hrs</li>
</ol>
最初,我们只是使用Excel工作表来完成的。但是两年多以前,我们开始为此使用软件工具。www.evenflow.com,www.swproposal.com和其他一些产品很少能提供帮助。我不记得所有清单。我们很久以前就做过研究。希望对您有所帮助。
好的问题是如何精确估算。我们认为没有100%正确的估计。唯一的方法是将整个工作范围划分为尽可能小的任务。较小的任务将对您所做的项目进行更详细的审查和分析。因此无论如何都会提高准确性。