一个软件项目如何评估工作量和成本?
发布网友
发布时间：2022-04-20 06:42
共5个回答
热心网友
时间：2023-07-17 06:46
软件开发成本估算过程可进一步细分为软件规模估算、工作量估算、成本估算和确定软件开发成本等四个过程。
其中成本估算需要对直接人力成本、间接人力成本、间接非人力成本及直接非人力成本分别进行估算。
国家标准《GB/T 36964-2018 软件工程 软件开发成本度量规范》中建议的软件开发成本估算基本流程如下图所示：
国家准中的四个估算过程，层层递进，逐步细化，最终达到科学、一致的成本估算。
一、软件规模估算
通常情况下，规模估算是软件成本估算过程的起点。
估算规模是后续计算软件项目的工作量、成本和进度的主要输入，是项目范围管理的关键，因此，在条件允许的情况下，应首先进行规模估算。
在规模估算过程中，需要注意以下情况：
在规模估算开始前，应根据可行性研究报告或类似文档明确项目需求及系统边界。项目需求除包含最基本的业务需求外，还应进行初步的子系统/模块划分，并对每一子系统或模块的基本用户需求进行说明，以保证可以根据项目需求进行规模预估。
依据项目特点和需求详细程度不同，通常估算人员在选择估算方法时应采用纳入国际标准的功能点方法进行功能规模估算，在适用IFPUG或NESMA方法时，可以根据需求的粒度和管理需要，选择预估功能点方法、估算功能点方法或者详细功能点方法。
若当前的项目需求极其模糊或不确定，可不进行规模估算，而直接采用类比法或类推法估算工作量和成本。
二、工作量估算
在完成规模估算后，应当开展工作量估算工作，若当前项目未开展规模估算，也可直接启动工作量估算工作。
工作量估算时，可采用方程法、类比法、类推法、功能点法：
方程法：即基于基准数据建立参数模型，通过输入各项参数，确定估算值。
类比法：即将待估算项目的部分属性与类似的一组基准数据进行比对，进而确定估算值。
类推法：即将待估算项目的部分属性与高度类似的一个或几个已完成项目的数据进行比对，并进行适当调整后确定估算值。
功能点法：从用户视角出发，通过量化系统功能来度量软件的规模，这种度量主要基于系统的逻辑设计。功能点规模度量方法在国际上的应用已经比较广泛，并且已经取代代码行成为最主流的软件规模度量方法。
在开展工作量估算的过程中，需要注意以下情况：
当需求极其模糊或不确定时，如果此时具有高度类似的历史项目，则可直接采用类推法，充分利用历史项目数据来粗略估算工作量。
当需求极其模糊或不确定时，如果此时具有与本项目部分属性类似的一组基准数据，则可直接采用类比法，充分利用基准数据来粗略估算工作量。
对于规模估算已经开展的项目，可采用方程法，通过输入各项参数，确定待估算项目的工作量。若客户或高层对项目的工期有明确的要求时，在采用方程法估算工作量时，工期要求有可能是方程的参数之一。
为追求估算的准确性，建议在条件允许的情况下，可采用两种估算方法，对估算结果进行交叉验证，若估算结果差别不大，可直接使用两种估算结果的平均值或以某种估算结果为准，若差别较大，需进行差异分析。
工作量的估算结果宜为一个范围而不是单一的值。
三、成本估算
在获得了工作量估算结果后，可采用科学的方法进行成本估算。
在成本估算过程中，应需要注意的情况：
类比法和类推法，同样适用于需求极其模糊或不确定时的成本估算；
间接成本是否与工作量估算结果相关取决于间接成本分摊计算方式。在绝大多数组织，项目周期越长，项目组成员越多，其分摊的间接成本就越高，此时项目的间接成本与工作量估算结果直接相关；
直接非人力成本通常与工作量估算结果无关，宜单独分项测算；
成本估算结果，也通常为一个范围，而不是单一的值。
四、确定软件开发成本
在《软件工程 软件开发成本度量规范》中，将软件开发成本分为四类，主要是为便于对成本构成（即哪些成本属于开发成本，哪些不属于开发成本）进行清晰界定。
而在实际确定软件开发成本时，通常并不是分别测定四类成本，加和后获得总成本，而是通常采用以下两种方式确定总成本：
根据人力成本费率及工作量估算直接人力成本和间接成本之和，再加上直接非人力成本，获得总成本；
根据规模综合单价和软件规模，测算出直接人力成本和间接成本之和，再加上直接非人力成本，获得总成本。
在进行软件的规模、工作量、成本估算时应遵循以下原则：
在规模估算时,应根据项目特点和需求的详细程度选择合适的估算方法；
充分利用基准数据,采用方程法、类比法或类推法,对工作量和成本进行估算；
工作量和成本的估算结果宜为一个范围值；
在进行成本估算时,如有明确的工期要求,应充分考虑工期对项目成本的影响,可以根据项目实际情况以及工期对项目的影响程度,对成本的估算结果进行调整；
成本估算过程中宜采用不同的方法分别估算并进行交叉验证。如果不同方法的估算结果产生较大差异,可采用专家评审方法确定估算结果,也可使用较简单的加权平均方法；
在软件项目的不同场景下(如预算、招投标、项目计划和变更管理等)采用国家标准时,相关要求见国家标准中附录A。
除了上述主要原则外，我们还需注意在使用基准数据时：
对于委托方和第三方，建议使用或参考软件行业基准数据进行估算。估算模型的调整因子的增减或取值有可能随着行业基准数据的变化而变化。
对于开发方，在引入行业基准数据的基础上，可逐步建立组织级基准数据库，以提高估算精度。组织级基准数据定义应与行业基准数据定义保持一致，以便于与行业基准数据进行比对分析，并持续提升组织能力。
热心网友
时间：2023-07-17 06:47
当你对项目尚不了解的情况下，你是如何估算项目需要的时间的？很难找出一位客户可以准确地说出他们的系统应该如何运行。
我参与的每一个大型项目几乎无一例外都要求系统具有“灵活性”，换句话说就是，客户希望系统能处理将来需要处理的一切，但他们也说不清究竟需要什么功能，因此，“灵活性”本质上不是系统需求，因为它是一个模糊的概念。
2、开发时间由非程序员估算
如果你不是程序员，不要私自猜测开发需要的时间，如果项目经理象写小说那样虚构估算，项目注定会失去控制，开发时间的估算应该听取程序员的意见。
3、开发人员的估算太过乐观
开发人员估算时间一般都只考虑了编码需要的时间，另外，每个人的开发速度和效率都不一样，许多开发人员在估算开发时间时都过于乐观，他们往往会忽略掉诸如项目管理，需求整理，讨论，缺勤，电脑问题等因素。
4、没有充分解剖项目
对于一个独立的功能，如果估算的开发时间超过了一周就要小心了，象这样的功能应该进一步细分，这样开发人员可以更详细地分析更复杂的问题。
5、估算多少时间就使用多少时间
给一个程序员5天时间让他完成一个任务，他就一定会用5天时间，软件开发是可以无级变速的，任何代码都可以进行改善，如果开发人员只花了3天就完成了任务，他们会用剩下的时间来调整代码或干脆做其它事情。
遗憾的是，这将会导致估算时间成为开发所需的最小时间，实际交付时间只能被进一步推迟。
6、开发人员多!=开发速度快
一个需要耗时100天的项目不可能用100个开发人员1天就完成了，开发人员越多只会导致项目复杂性呈指数级增长。
7、项目范围变更
这可能是每个开发人员感觉最头疼的问题，有时是应客户的要求对功能进行修改或添加，有时会是CEO一时兴起，觉得某个功能很酷就要求加上或修改。
8、估算被固定
估算应是一个持续的过程，应随系统的开发进度不断更新，程序员往往会认为他们能够弥补逝去的时间，但却很少有人真正做到。
9、遗忘了测试时间
要让开发人员自己测试自己的代码是不现实的，他们知道代码是如何工作的，因此会潜意识地使用一个特殊的测试方法，通常，测试和调试时间需要占到开发时间的50%。
10、估算得太死
非程序员很少能体会到软件开发的复杂性，因此很少有项目计划不*延后，影响项目进展的因素很多，估算时如果不预留部分机动时间，最终只会是一个失败的估算。
开发延迟会导致代价高昂的连锁反应，遗憾的是，出了问题大家都喜欢将责任归咎于底层的程序员，这样下去对以后的项目也会不利，因为程序员会吃一盏长一智，下一次他们要么拒绝提供估算时间，要么会夸大开发时间。
热心网友
时间：2023-07-17 06:47
用下面的过程来评估你的工程所需总工作量：
1．决定评估所需的精确度。典型的情况是，评估的精确度越高，所需的细节就越多，所需时间也越多。如果要求你做一个粗略的评估（-25%
-
+75%），你可能会在较高的水平利用最少量的细节迅速完成工作。另一方面，如果你必须提供一个精确的评估时（≤10%），可能需要多花一点时间，且在一个较低的水平需要更多的细节完成这项工作。
2．为每一个活动和整个工程的工作量做一个最初的评估。有很多可用的技巧用于评估工作量，包括任务分解（工作细分结构）、专家意见、类推等。
3．添加专用资源时间。确保你已经包括兼职人员和专用资源所需的时间。例如，这一工程可能包括兼职人员、熟练的专家、法律人员、行政人员等。
4．考虑返工（可选的）。在理想世界中，所有交付的工程一开始都是完美无缺，但在现实世界中，通常并不是这样。不考虑返工的工作计划可能较容易完成，因为低估了全部的交付工程包含的工作量。
5．添加工程管理时间，这是成功的工程管理所必须的。一般说来，增加15%的工作量用于工程管理。例如，如果一项工程评估需要12000个小时（7-8个人），那么一个全职项目经理人（1800小时）是必须的。如果一项工程评估需要1000小时，工程管理时间应该是150小时。
6．添加意外事故时间。偶然是用来反映评估的不确定性和风险性，如果要求你做一项并不完全确定的评估工作，那么可能要增加50%、75%或者更多的时间以反映不确定性。如果以前你已经多次做过这样的工程，你的意外时间可能很小——可能是5%。
7．计算加上所有细节部分的总工作量。
8．如果必要再看一遍，进行适当修改。有时当你加上工程的所有组成部分时，评估会看起来明显的高一些或低一些。如果你的评估看起来不正确，再回头看一下你的设想，调整所作评估以更好的反映现实情况。我把这种情况称为从你的经理和赞助者最初的延期。如果你的赞助商认为你评估太高，并且你也认为没有理由反对他，那么你还要在评估上作更多的工作。要确保你的评估看起来是合理的，并且准备好反击那些反对的观点。
9．文档化所有设想。你永远不会确切地了解一项工程的所有细节，因此，文档化所有你做出的设想和评估，这一点很重要。
10．这类严格的评估方法将会帮助你在可以获得的时间和资源的情况下尽量做出精确的评估。
热心网友
时间：2023-07-17 06:48
追答工作量最基本的是人天。也是成本核算单位以及软件报价的基础，如果一个人天时2000.那么每个阶段需要多少个人天就乘以2000.一个人天就是一个IT人员工作一天的工作量。
热心网友
时间：2023-07-17 06:49
大型和小型的系统四个模块资源成本的分配也是有区别的，开发周期越长，成本越高，有些小型的系统甚至不需要后期的维护。
需求分析很好理解，让人理解用户的需求，不断的跟用户确认需求，当然偶尔也会有跟客户吃饭什么的...
系统开发就多了，系统设计，搭建开发环境，写代码。
软件测试包括代码测试功能测试，目的就是保证系统的正确。
系统开发完了当然不是没事啦，用户还会来找你滴...还要派人跟用户做好软件的后期维护。
这一系列的过程有人力的成本，硬件的成本，开发工具的成本（即开发软件，当然有免费的可用），请楼主细细估算成本。
可以参考百度文库：
http://wenku.baidu.com/view/9223da44b307e87101f69601.html
