一文掌握软件项目成本预算估算的方法和成本控制的秘籍

Posted PMO前沿

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一文掌握软件项目成本预算估算的方法和成本控制的秘籍相关的知识，希望对你有一定的参考价值。

每个企业都希望在完成项目后获得盈利，但不少企业到了年终后才发现项目做了不少，公司却并没能达到预期，甚至还出现了亏损。那么钱究竟去了哪里？很多公司都搞不清楚原因，出现糊涂账较多的状况，这将会造成严重的后果，尤其在疫情影响下，大环境很恶劣，如果是大公司的事业部门出现亏损，就可能会导致事业部门解散；如果是小公司出现亏损，就很容易导致公司倒闭；怎样做才能确保我们所完成的项目都能获利？

从财务角度看，要确保盈利必须做到合理估算成本，只有这样才能在对外签订合约时做出合理报价，在对内在开始项目前做出充分评估投入代价，同时在实施过程中还要控制成本得当，最后项目结束时才会有可能获得盈利。

那么我们怎样才能准确的判断软件项目值不值得做？要花多少钱？合同签多少钱才能盈利？能不能清晰知道钱花在哪里？怎样做才能控制好成本？怎么确保项目不仅仅是完成了，还能获得利润？一连串的问题将会是本文探讨的主要内容。

固定的，规规矩矩的硬件项目和工程项目相对于软件项目更容易做预算，因为硬件类、工程类项目都是实实在在能看得见的物件，BOM结构都是非常清晰，都可直接换算的项目，例如涉及到哪些硬件设备，安装的时间是多长，调测时间多长都可以通过公式计算；而对于软件项目评估预算就相对复杂了，因为软件项目研发对象是二进制代码产品，其难度、周期都不好评估，导致了费用也不好评估。而这一块不好评估的费用恰恰占了软件项目费用的最大比重，因此我们重点探讨怎样合理评估软件研发难度和周期。

在研究一个事物的时候都先搞清楚研究的对象是什么，有什么特点，然后再去分析探讨，因此在探讨软件项目预算评估之前同样先搞清楚软件项目的特点。软件项目研发一般分为两类，一类是自主研发新产品；另外一类就是企业从外面获得订单，完成订单交付项目。本文主要是围绕订单交付类型的软件项目展开探讨，对自主研发类不作探讨。

一、项目值不值得做？

在探讨项目能不能有收益之前，先要识别出项目靠不靠谱，不靠谱的项目就是个大坑，成功概率非常低，几乎不可能盈利；有的企业但凡是项目都接过来做，并没有做任何风险评估，这样的企业往往赔得多，挣的少，如果有办法能够提前预测每个项目能否顺利交付，就可以尽早规避风险，企业就可以根据评估结果来调整对项目的资金投入，少投入或不投入，将资金用在刀刃上，这更有利于获得利润。

要做到这一点，就要做好风险评估，这里给大家推荐一个风险评估工具——风险画像工具，风险画像工具一共有五个维度，分别是独特性，不确定性，临时性，跨职能性和变革性，每个维度都分别有1,3,5,8分值，如果项目特性和维度匹配度高，那么分值就高；匹配度低，那么分值就低，最后汇总5个维度的总和分值，分值越高，风险越高，越不值得做；分值越低，风险越低，越安全，越值做。如下图

l 独特性指的是公司有没有做过类似的项目？

有没有相关的经验？如果从来没有做过这类项目，打分是最高分8分，如果经常做这类项目，可以打1分，如果有部分相关的经验，不具备全部经验，那就可以打3分或5分，具体打分可以按具体项目匹配度来给分。

l 不确定性指的是所做的项目需求明不明确？

例如银行委托您的企业研发一套银行APP，APP的主要功能是让终端用户在手机能使用常规的移动支付、查询等功能，如果客户只给出简单的几句话，待确定的功能还很多，这个项目的不确定性就非常高，可以给8分；如果同样的需求，客户另外给出了详细的设计方案和验收标准，那么这个项目不确定性就非常低，可以给1分。

l 临时性指的是从项目时间角度看项目风险，项目周期越长风险越高，周期越短风险越低

例如项目周期是3年风险可以打8分，如果项目3个月可以打1分；另外如果项目正好跨年，那么风险也很高；例如项目虽然是3个月，但是正好是跨年，例如一个项目从12月份开始启动，交付时间是3月底，那么风险是比较高的，因为跨年往往组织结构会调整，可能年前的项目接口人更换了，领导也更换了，项目极有可能由于人员变动导致重新研发。

l 跨职能性指的是完成项目需要协调哪些部门，哪些人来一起把事情做完？

如果只是部门内部小组就能协调把事情做完，这样跨职能性非常低，可以打1分。如果需要整个集团或整个公司的所有部门都是卷进来，那么跨职能性就很高，可以打8分。

l 变革性指的是项目的影响范围

如果项目实施后仅仅是影响1个小组，那么变革性很低，可以打1分；如果项目实施后整个集团都受到影响，那么变革性非常高，可以打8分。

最后把5个维度的分值加起来看下分值，如果分值低，风险就低，分值高，风险就高；例如分值5分，风险是最低，这样的项目基本上没有风险，成功机率很高，项目几乎是稳赚；如果分值是40分，风险很高，这样的项目基本上风险很高，失败几率很高，这样的项目能不做就尽量不做。

二、怎样做好预算？

当我们评估风险筛选出优质的项目后，接下来要做的事情是做好项目预算。订单交付软件项目的资金流一般都是投入资金，然后消耗资金，到最后项目结束会产生盈亏，如下图3所示，可以看出要想获得盈余，就要做好前面两个环节的工作，第一个环节是准确评估预算，识别要花多大代价做项目，有没有足够成本做项目。如果评估偏乐观，申请的成本太低，极有可能因为资金不够，导致后续无法按项目计划开展工作，导致项目延期，最后导致项目无法盈利; 如果评估太悲观，申请的预算太多，可能项目没开始就被公司高层叫停，原本可以盈利的项目就这样夭折了；第二个环节是控制好成本，成本控制好了才不会导致成本增加，到最后才会达到预期的结果--客户按期付款，没有返工，项目有钱赚。

当签订合同前或要求在比较短时间内就要给出预算成本时，项目预算通常有三种方法，一种是参考历史项目做预算，第二种是参考同行报价做预算，第三种是组织专家评审自做预算。

1.参考历史项目做预算指的是看一下自己的公司里面有没有做过类似的项目，或者在通过某些渠道能不能获取到类似的项目经验。如果有做过类似的项目可以把历史项目的预算作为参考基准，当项目难度偏差不大，那预算应该是相差不大；如果相差比较大，那就要加上了一定的百分比。这就是参考项目历史经验做预算。

2.参考同行报价做预算指的是让同行给我们报价，我们参考同行的报价做预算。通常我们可以通过去打电话去询问同行，一般利用虚拟自己是客户的方式去打电话询问同行，同行才给你报价。

3.专家评审做预算指的是找一些比较资深的同事，咨询他们做这项目需要做哪些主要的事情？需要花多少钱？让专家给出建议。

我们通过以上三种办法的一种或混合并用的办法得到一些预算数据，然后用三点估算这个办法得到一个最靠谱的预算值。

什么是三点估算？这是在做项目管理比较常用的一种办法。三点估算就是(最乐观的预算+4倍最有可能的预算+上一个悲观的预算)/6。例如在做一个项目的时候，收集到最乐观的预算是300万，最有可能的预算是600万，悲观的预算1000万，那么三点估算就是（300+4*600+1000）/6 约等于617万，以这个值为预算成本。

以上是比较普遍的粗颗粒度，对预算值要得比较急的时候用的评估方法，当我们有充足的时间除了以上三种方法还有更靠谱的办法-基于项目功能点评估预算的方法。在了解基于功能点的评估预算方法之前我们先了解下软件项目成本的基本结构，项目成本主要由直接成本+间接成本构成

而直接成本主要由人力成本+非人力成本构成，人力成本主要是人员投入所需要的费用，非人力成本主要包括差旅费，通讯费，招待费，场地费，采购服务费，分包费，软硬件费用等构成，具体包括哪些费用要结合项目实际情况来确定。

 间接成本，主要包括分摊水电费，研发设备折旧费，售前及分摊前经营费用，其它费用。

而在所有费用里面往往人力成本占了80%以上的比重，怎样才能准确的评估出人力成本至关重要。评估人力成本的主要方法是从高级方案着手，然后用WBS拆分高级方案得到具体功能点，接着按功能量基线评估出功能点工作量，最后结合项目路标交付综合得到预估工作量。

 举一个例子

【项目背景】

朋友厂家承接了一个海外大客户订单，该客户对产品质量要求很高，其中有两条要求。

1.记录产品生产过程每道工序在什么时间，谁负责，经过那条流水线和记录当时的测试数据。

2.扫描或输入条码就可以把整个生产过程的数据信息（包括测试数据）都能直观展示出来

现在是2月份，希望11月份能局部试用，12月份能全面试用要做这样的一个项目，要预算成本。

【评估预算过程】

1.首先需求分析师/产品经理/架构师根据项目委托方给的项目信息编写高阶方案。

项目高阶方案从用户的使用角度把客户需求实例化图形显示，模块化。

2.根据高阶方案把功能再次分解，例如高阶方案有一项功能是支持工位数据采集，这项功能可以分解成工位基础设置，设备设置等功能。等到所有高阶方案功能都拆分成详细功能后就可以用工作量基线库算出开发需要的工作量，然后再根据工作量换算成对应的人工成本预算。

3.工作量评估

对于工作量评估不少企业都会很困惑，往往评估出来的工作量和实际工作差距偏差太大，有什么好的办法可以更准确的评估出工作量呢？

这里给大家分享下华为的做法。我所在的部门是基于工作量基线库评估工作量，什么是工作量基线库？工作量基线库可以是一个系统，也可以是一张excel表。我们的架构师分解工作任务后，就对照工作量基线库找到对应的工作任务对应的计算方法来计算工作量。基线库里面列出能开发的所有任务类型的标准工作量，不同复杂度工作量计算方法不一样，复杂度一般分为简单，中等和复杂三种难度

l  简单难度如1条javascript或几句简单的逻辑代码；

l  中等难度如需要查询数据库，对数据进行加工转换；

l  复杂难度如需要调用第三方接口，获取数据后，对数据加工，之后再对数据回写接口。

对于简单，中等，复杂都有明确的定义，具体说明会在复杂度列中注明，如下图所示。具体计算方法在工作量列也都有注明，如简单的工作量是1乘以n，中等难度7乘以n, 复杂难度12乘以n，n是指有多少个这样的类似功能接口。例如要实现2个接口，第1个接口是上报文件数量，第2个接口是上报文件的下载数量。按简单难度计算工作量1*2等于2人天，按中等难度计算工作量7*4等于14人天；按复杂难度计算工作量12*2等于24人天。

架构师计算出新特性开发工作量后，再计算安全送检的工作量。送检的工作量等于新特开发工作量乘于20%作为这个安全送检工作量，最后再加上1人月的版本发布工作量。所谓版本工作量就是发布时候的要做的工作所花的工作量，一般发布包括了准备发布材料，走发布申请流程。

工作量基线库如下图：

基线库的标准工作量来自实施部门，业务部门的专家评审和历史经验数据，一般1个季度会重新审视刷新1次，一旦确定下来就按基线库的计算方法计算，如果有歧义要等下次迭代更新。主要由开发行管负责组织维护更新。

基线库评估工作量的流程是首先由业务部或者市场部把外部需求转换成项目的需求，然后分发给到研发部，研发部收到需求后架构师设计方案和根据基线库评估工作量，评估出来之后，然后参加RAT会议，RAT会议主要是评估方案可行性和工作量是否业务部门，实施部门，出资部门各方都能接受；这个RAT会议由评估需求工作量的架构师，研发专家，业务需求方和研发方管参加，评审通过之后就正式上报预算，如果不通过再重新评审。下图是基线评估需求工作量的工作流程。

三、怎样控制好预算？

想要控制好预算，对团队内部而言主要是控制好项目过程，使得项目结果跟预期一致，这样就没有返工，没有延期，投入的成本就不会超支。控制项目过程主要聚焦控制好工期，范围，质量，人员进场和人员流动性，要想办法保证项目在工期内完成，不要超出范围，要按质量去交付，合理安排人员和在项目人员尽可能保持稳定，不流动。

首先，控制工期可以保证成本。因为每天都需要支付员工工资，每延期一天就超支一天的成本，所以不要超期；

其次，确定范围可以保证工期。控制项目不要超出范围，如果超出范围就必然增加人员投入或延期交付才能满足新增加的交付范围，这会导致成本增加；

再次，保证质量可以控制成本。如果交付的内容没有达到质量要求，交付不合格，那么就势必会返工，这样会严重超支，也会导致可信度下降，口碑受损，应该尽量避免质量没达标；

从次，合理的人员进场可以减少浪费。关于人员的进场也要注意如果所有的人都同时进项目，可能会导致有些人员闲置，例如前期做需求分析，开发人员和测试人员可以不进场，因为那时候方案都还没确定，进场会让开发人员和测试人员无所事事，浪费资源，成本也增加，应该要根据研发计划节奏，如下图，合理的安排人员进场。

最后，减少人员的流动性可以减少成本。要注意人员的流程性，尽量避免进入项目后的人员流动更替，因为所有岗位都需要学习成本，都要花时间了解岗位的工作和项目任务情况，人员的流动会增加成本，关键人员岗位的流动，还会导致项目延期，项目失败，所以对人员流动管理也是至关重要的工作。

以上是内部团队的管控，有时候项目的成败不仅仅是管好内部就可以达到预期目标，我们还要管理好项目的外部人员，通常做项目要兼顾三类人，一是用户代表，二是供应商代表，三是商业代表。

l 用户代表指的是提出需求的一方，可以是一个人或几个人，他代表出资方的利益，他关注的是产品成本，定好的成本再跟他们要多一分钱都很困难；他关注产品的质量，产品好不好用，能不能解决问题，如果不能解决问题或不好用，他就可能不埋单或对实施方提出更高的要求；他也关心什么时候能用产品，如果超了时间还没能用，那么他会不满意。

面对用户代表的需求，项目经理要控制好他对产品质量的期望和交付时间的期望。在质量期望上，在项目开始之前项目经理要降低用户代表对产品的质量要求，什么功能可以交付，什么不能交付，什么硬件需要客户方自己解决都要项目开始前谈清楚。在时间期望上，努力争取能多谈些研发时间，给内部团队充足的研发时间。并且在项目的每个阶段都应该跟用户代表确认是否在研发产品是正确的，避免后续返工。

l 商业代表他关注他代表企业方，关注的是做这个项目的意义，希望通过项目能获得一定的盈利。或许项目是为了赚钱，或许项目是为了占领某个市场细分领域，或许是为了配合企业战略目标打响品牌知名度。商业代表往往是一个人,他不关注实现难易，也不关注用户的想法，对他们来说花钱越少，越快交付越好。

l 最后一个代表是供应商代表，供应商代表指的是给项目做实际事情团队的代表，他代表实施方，通常供应商代表为内部供应商和有外部供应商，内部供应商就是我们内部的研发团队，一般是职能研发团队的部门负责人，外部供应商就是外部的这个的团队，外部团队一般表现为外包形式，一般是外包公司的接口人，他们关注的是有没有能力做这个项目，怎样做这个项目，他们关注的焦点在实施这个项目的技术及细节上。

用户代表，商业代表，供应商代表三方由于立场不一样，导致他们关注的内容不一样，如果在做项目的时候考虑漏了某一方，都有可能会导致整个项目返工，不满意。例如我们只兼顾了这个用户代表和这个商业代表，没有兼顾到供应商这边，有可能这个项目就没办法交付。

举个例子研发一个能登月机器人，不断往地球回传月球的稀有土壤，这会让公司赚不少钱，投资方希望投资1千万资金，1年的研发时间来实现这个目标，由于没有经过内外部专家的讨论，就确立项做这个项目，这是一个项目很不靠谱的项目，因为实施团队的能力无法实现登月，也没有能力把稀土送回来，显然是个失败的项目。这个例子有点夸张，但是往往我们的销售同事看到有单子都先接回来，以为挣钱，客户也觉得可以接受销售提出的价钱，于是就签订了项目合同，结果项目失败了，原因就跟登月一样，没有和内部实施团队达成一致看法。所以三个代表的达成一致看法是项目成功的关键。

我们除了要达成3个代表的对项目的一致看法，还需要让整个团队的运作高效，降低内耗，这就要对团队的运作舞台提出要求，只有健康的舞台才能让项目更高效的跑起来。要有强的团队执行，有团队定流程规则、立法，也有团队监督执法，如下图绿色框是立法，判决项目生死的高层；黄色框是监管和执法，基本上职责在于监管，协调让流程，制度执行起来更严肃，更顺畅；粉色框是执行层； 

以上主要是简单介绍了怎样排兵布阵，怎样搭建班子，把舞台搭建好，下面继续为大家介绍怎样把脉络打通，这就要从流程着手，华为之所以能把每个人的能力充分发挥得益于有完善的流程IPD体制，执行过程非常严肃，很多企业也有流程，但是再好的流程，执行不严肃也是空架子，在华为流程执行过程中有严肃的评审机制，软件研发的流程从业务部门把项目需求给到研发部开始，研发部门内部经历了产品分析，架构分析，开发，测试，交付等环节，每个环节的工作都涉及了交接，评审。如果评审不通过可以退回上游环节，如果评审通过了就可以继续下一步，每一份报告和结论都是有依据的，都是已经达成共识的。以下是详细的软件端到端工作内容。

环境、流程制度都做好了，还需要控制好项目需求的源头，很多问题实际上是在需求端没有控制好，我们在做项目需求之前都应该清楚需求的背景是什么？为什么要做这个需求？痛点是什么？并不是拿到需求就直接去做一个搬运工，就直接去做这个需求，而是我们要多提问题，问一下为什么要做这个需求，做这个需求是为了解决什么问题，有没有替代方案？只有知道了问题的背景我们才能给到一个更合适的方案。

当拿到需求时应该去聆听客户的声音，多问问为什么，往往现在的客户都会带着方案和带着问题给我们，我们要用专业的视角去识别这个方案是不是最优的方案？如果不是最优方案，应该要提出最优的方案，如果这个方案是目前最好的方案，但是我们发现有风险，也要提出风险。

我们不能只是一个需求的搬运工，对于需求方案方面，这里介绍华为的checklist内容，如图28，我们看一下需求有没有写清楚背景和收益，如果没有收益，没写清楚需求背景，就可以直接否决这个需求。如果有收益，收益怎么衡量，这个也要写清楚了。如果没写清楚收益，这个做这个需求的意义在哪里？当需求的背景和收益都清楚后，我们再看一下需求涉及那些流程？正常的流程是怎么样？异常的流程是怎么样？边界范围是什么？最新做的是什么特性？有没有都列清楚？软件易用程度如何？需要比较长的学习成本还是一看就可以使用的产品？需求方案有没有考虑到安全方面的设计？Checklist 内容就不一一说明，详细请参考图28。另外填写checklist时有涉及到必填项，都必须填写，当需求不涉及到某项必填项，我们就是要标注原因。例如某需求不涉及到保存数据到数据库，但是公司要求数据库项是必填项，那么就要写清楚本需求只是界面操作不涉及到数据库操作。

要控制好需求除了以上需求覆盖点要用checklist检查，还要注意需求方案不能增加超出范围的内容，不减少内容，不镀金，业务流程要合理正确，要列清楚需求的验收标准，要做好可行性分析避免发生风险。

四、钱都花到哪里去了？

前面介绍了准确评估预算和控制成本的方法，这里要介绍的是项目资金使用情况。当项目进行时，领导想知道各个项目投入资金情况或项目结束后能不能清楚知道项目花了多少钱？作为项目负责人，您清楚吗？财务不仅仅跟要跟职能部门挂钩，还应该跟项目挂钩，甚至跟项目明细挂钩，这样才能清楚知道项目都花了多少钱，花在哪里项目的哪方面，怎样做到呢？填写凭证时需要填写上项目及项目明细，如果没有IT系统就使用excel管理，如果有IT支撑会效果更好，统计时就可以按核算项目统计，核算项目颗粒度可以按实际管控颗粒度来定。例如下面例子是按项目颗粒度管控，统计时可以按核算项目过滤冠龙科技项目即可。

最后回顾下本文主要分享了软件预算成本的估算方法，成本的控制方法和介绍了怎样把财务和项目关联起来，方便实时监管和决策，希望对您有一定的启发和帮助，内容仅基于个人经验总结，有不足之处希望能多理解，最后祝大家做每个项目都能挣大钱。

「软件项目管理」一文详解软件项目成本计划

软件项目成本计划

序言

大家都知道，软件项目管理包含项目初始、项目计划、项目执行控制和项目结束这四大模块。其中，项目计划包含范围计划、成本计划、时间计划等9大计划。

那在今天的文章中，就带大家来了解项目计划中的成本计划。

叮，开始学习吧~🎩

一、成本估算的定义

  • 成本估算是成本管理的核心，是预测开发一个软件系统所需要的总工作量的过程。

  • 软件项目成本是指软件开发过程中所花费的工作量及相应的代价。

  • 成本估算应该以软件项目管理、分析、设计、编程、测试等过程所花费的代价作为依据。

  • 成本估算贯穿于软件的生命周期。

二、估算的基本概念

1、关于估算

  • 估算不是很准确，会有误差；
  • 项目经验数据非常重要；
  • 不要太迷信某些数学模型。

2、软件项目规模

  • 软件项目规模即工作量；
  • 例如：软件规划，软件管理，需求，设计，编码，测试，以及后期的维护等任务。

3、软件规模单位

  • LOC (Line of Code) → 表示源代码长度的测量；
  • FP (Function Point) → 用系统的功能数量来测量；
  • 人月；
  • 人天；
  • 人年。

4、软件项目成本

  • 完成软件规模相应付出的代价；
  • 待开发的软件项目需要的资金；
  • 人的劳动的消耗所需要的代价是软件产品的主要成本。

5、成本单位

成本单位通常是各种货币单位，比如：

  • 人民币元
  • 美元
  • 英镑
  • ……

6、软件规模和软件成本的关系

  • 规模是成本的主要因素，是成本估算的基础；
  • 有了规模就确定了成本。

7、成本估算结果

直接成本： 与具体项目相关的成本（如：人员工资、材料费、外包外购成本等）

间接成本： 可以分摊到各个具体项目中的成本（如：培训、房租水电、员工福利、市场费用、管理费、其他等等）

三、成本估算过程

1、估算输入

需求、资源要求、资源消耗率、进度规划、历史项目数据、学习曲线等

2、估算处理

采用一定的估算方法进行，包含直接成本和间接成本的估算。

3、估算输出

以简略或详细的形式表示，对项目所需的所有资源的成本均需要加以估计。

四、成本估算方法

1、代码行估算法

（1）定义

  • 从软件程序量的角度定义项目规模。
  • 与具体的编程语言有关。
  • 分解足够详细。
  • 有一定的经验数据（类比和经验方法）。

（2）代码行估算的优点

代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。

（3）代码行估算的缺点

  • 对代码行没有公认的可接受的标准定义。
  • 代码行数量依赖于所用的编程语言和个人的编程风格。
  • 在项目早期、需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量。
  • 代码行强调编码的工作量，只是项目实现阶段的一部分。

2、功能点估算法（重点）

（1）定义

  • 与实现的语言和技术没有关系；
  • 用系统的功能数量来测量其规模；
  • 通过评估、加权、量化得出功能点。

（2）功能点公式

  • FP = UFC * TCF
  • UFC：未调整功能点计数
  • TCF：技术复杂度因子

（3）UFC-未调整功能点计数

从处理逻辑的角度出发， UFC 可以分为 5 个功能计数项。分别是：

  • 外部输入
  • 外部输出
  • 外部查询
  • 外部接口文件
  • 内部逻辑文件

接下来我们将依据这 5 个功能计数项进行详细细述。

（4）功能计数项详述

1）外部输入(External Inputs:EI)

给软件提供面向应用的数据的项（如屏幕、表单、对话框、控件，文件等）；在这个过程中，数据穿越外部边界进入到系统内部。 如下图所示：

2）外部输出(External Outputs:EO)

向用户提供（经过处理的）面向应用的信息，例如，报表和出错信息等。 如下图所示：

3）外部查询(External Inquiry:EQ)

外部查询是一个输入引出一个即时的简单输出，没有处理过程。 如下图所示：

4）外部接口文件（External Interface Files :EIF’s）

用户可以识别的一组逻辑相关数据，这组数据只能被引用。用这些接口把信息传送给另一个系统。 如下图所示：

5）内部逻辑文件(Internal Logical Files:ILF’S)

用户可以识别的一组逻辑相关的数据，而且完全存在于应用的边界之内，并且通过外部输入维护，是逻辑主文件的数目。 如下图所示：

（5）功能计数项的复杂度等级

下面给出功能计数项的复杂度等级，如下图所示：

（6）UFC计算实例

下面，我们用一个例子来举例。

某外贸订单项目的需求评估为：

外部输入： 3 项；外部输出： 1 项；外部查询： 1 项；外部接口文件： 1 项；内部逻辑文件： 2 项。请计算出该项目的 UFC 。

他们的复杂程度如下表所示：

功能点
项简单一般复杂
外部输入2 * 31 * 40 * 6
外部输出0 * 40 * 51 * 7
外部查询0 * 31 * 40 * 6
外部接口文件0 * 51 * 70 * 10
内部逻辑文件1 * 71 * 100 * 15
总计13257
UFC45

（7）TCF-技术复杂度因子

TCF = 0.65 + 0.01(sum(Fi))，其中 Fi 为技术复杂度因子，其范围是 0-5 ， TCF 的取值范围是 0.65-1.35 。

Fi 技术复杂度因子有 14 项，如下表所示：

技术复杂度因子
F1可靠的备份和恢复F2数据通信
F3分布式函数F4性能
F5大量使用的配置F6联机数据输入
F7操作简单性F8在线升级
F9复杂界面F10复杂数据处理
F11重复使用性F12安装简易型
F13多重站点F14易于修改

技术复杂度因子的取值范围，如下表所示：

调整系数描述
0不存在或者没有影响
1不显著的影响
2相当的影响
3平均的影响
4显著的影响
5强大的影响

（8）TCF计算实例

同样，我们用外贸订单项目的例子来计算 TCF 。假设 14 个复杂度因子的影响值都是平均，计算出该项目的功能点。

① U F C = 45 UFC=45 UFC=45

② T C F = 0.65 + 0.01 ( 14 ∗ 3 ) = 1.07 TCF=0.65+0.01(14*3)=1.07 TCF=0.65+0.01(14∗3)=1.07

③ F P = U F C ∗ T C F = 45 ∗ 1.07 = 48 FP=UFC*TCF=45*1.07=48 FP=UFC∗TCF=45∗1.07=48

④ 如 果 P E = 15 工 时 / 功 能 点 ， 那 么 ： E f f o r t = 48 ∗ 15 = 720 工 时 如果PE=15工时/功能点，那么：Effort=48*15=720工时 如果PE=15工时/功能点，那么：Effort=48∗15=720工时

（9）功能点与代码行的转换

语言代码行/FP
Assembly320
C150
COBOL105
FORTRAN105
PASCAL91
ADA71
PL/165
PROLOG/LISP64
SMALLTALK21
SPREADSHEET6

3、用例点估算法（重点）

（1）图例

用例模型如下图所示：

（2）基本步骤

用例点估算方法的基本步骤为：

  • 计算未调整的角色的权值 UAW ;
  • 计算未调整的用例的权值 UUCW ;
  • 计算未调整的用例点 UUCP ;
  • 计算技术和环境因子 TCF 和 ECF ;
  • 计算调整的用例点 UCP ;
  • 计算工作量 ( man－hours ) 。

接下来将依据这几个内容进行展开介绍。

（3）计算未调整的角色的权值UAW

公式： U A W = ∑ C = c a W e i g h t ( c ) × a C a r d i n a l i t y ( c ) UAW=∑_C=caWeight(c) × aCardinality(c) UAW=∑C=c​aWeight(c)×aCardinality(c)

下面给出 Actor 权值定义表，如下表所示：

序号复杂度级别复杂度标准权值
1simple角色通过API与系统交互1
2average角色通过协议与系统交互2
3complex用户通过GUI与系统交互3

（4）计算未调整的用例的权值UUCW

公式： U u c w = ∑ C = c u W e i g h t ( c ) × u C a r d i n a l i t y ( c ) Uucw=∑_C=cuWeight(c) × uCardinality(c) Uucw=∑C=c​uWeight(c)×uCardinality(c)

下面给出 Use Case 权值定义表，如下表所示：

序号复杂度级别事务/场景个数权值
1simple1-35
2average4-710
3complex>715

（5）计算未调整的用例点UUCP

公式： U U C P = U A W + U U C W UUCP=UAW+UUCW UUCP=UAW+UUCW。例如：

表1： Actor 权值

序号复杂度级别权值参与角色数UAWi
1simple122
2average248
3complex3515

表2：Use Case 权值

序号复杂度级别权值用例数UUCWi
1simple5525
2average10220
3complex15345

（6）计算技术因子TCF

公式： KaTeX parse error: Expected group after '_' at position 19: …=0.6+(0.01×\\sum_̲\\limitsi=1^1…_ W e i g h t i × V a l u e i Weight_i×Value_i Weighti​×Valuei​ 。

假设现有某项目的复杂度因子如下图表所示：

序号技术因子说明权值
1TCF1分布式系统2.0
2TCF2性能要求1.0
3TCF3最终用户使用效率1.0
4TCF4内部处理复杂度1.0
5TCF5复用程度1.0
6TCF6易于安装0.5
7TCF7系统易于使用0.5
8TCF8可移植性2.0
9TCF9系统易于修改1.0
10TCF10并发性1.0
11TCF11安全功能特性1.0
12TCF12为第三方系统提供直接系统直接系统访问1.0
13TCF13特殊的用户培训设施1.0

具体的 TCF 值为：

T C F = 0.6 + 0.01 × ( 2.0 × 3 + 1.0 × 5 + 1.0 × 3 + 1.0 × 5 + 1.0 × 0 + 0.5 × 3 + 0.5 × 5 + 2.0 × 3 + 1.0 × 5 + 1.0 × 3 + 1.0 × 5 + 1.0 × 0 + 1.0 × 0 ) = 1.02 TCF=0.6+0.01×(2.0×3+1.0×5+1.0×3+1.0×5+1.0×0+0.5×3+0.5×5+2.0×3+1.0×5+1.0×3+1.0×5+1.0×0+1.0×0)=1.02 TCF=0.6+0.01×(2.0×3+1.0×5+1.0×3+1.0×5+1.0×0+0.5×3+0.5×5+2.0×3+1.0×5+1.0×3+1.0×5+1.0×0+1.0×0)=1.02

其中，调整系数为给定数值。

（7）计算环境因子ECF

公式： KaTeX parse error: Expected group after '_' at position 20: …1.4+(-0.03×\\sum_̲\\limitsi=1^8…_ W e i g h t i × V a l u e i ) Weight_i×Value_i) Weighti​×Valuei​) 。

假设现有某项目的环境因子如下表所示：

序号环境因子说明权值
1ECF1UML 精通程度1.5
2ECF2系统应用经验0.5
3ECF3面向对象经验1.0
4ECF4系统分析员能力0.5
5ECF5团队士气1.0
6ECF6需求稳定度2.0
7ECF7兼职人员比例高低1.0
8ECF8编程语言难易程度1.0

假设调整系数已给定，那么具体的 ECF 值为：

E C F = 1.4 + ( − 0.03 × ( 1.5 × 3 + 0.5 × 3 + 1.0 × 3 + 0.5 × 5 + 1.0 × 3 + 2.0 × 3 + 1.0 × 0 + 1.0 × 0 ) ) = 0.785 ECF=1.4+(-0.03×(1.5×3+0.5×3+1.0×3+0.5×5+1.0×3+2.0×3+1.0×0+1.0×0))=0.785 「软件项目管理」一文详解软件项目成本计划

「软件项目管理」一文详解软件项目成本计划

一个软件项目如何评估工作量和成本?

成本估算和成本预算对比

(PMP)第7章-----项目成本管理

项目成本管理