作为一个在软件行业摸爬滚打20年的老IT，自身经历了多次技术入股，也接触了很多位参与技术入股的朋友，包括开发方和参与方。 以项目技术入股，面临的最大问题就是，你的项目能值多少钱？凭什么你说你的项目值那个价？少了你不干，多了合伙人不干。 你说你的项目值500万，依据何来？有人说市场价值500万，如果真值这个价，何不直接在市场售卖？开发人员往往没有销售经验，难以组建团队来销售，那么项目只能放家里睡觉，一段时间后，过时废弃，变成一文不值的东西。 一直以来，市场上没有一种方式能对软件的价值给出科学的评估。 2019年软件价值评估国家标准正式实施，为软件的定价及开发成本和工期、质量等都提供了依据。 所以，今后，如果你想知道某款软件到底值多少钱，或者开发一套软件需要多少费用都有据可依了，我们可以算出来了。
1. 需求变更调整因子取值 该因子既反映不同估算阶段需求的完整程度，也反映实际开发过程中规模的蔓延程度，在实际用于成本估算时应结合估算阶段、需求质量、项目类型三个因素确定取值，具体需根据需求颗粒度判断。 阶段 取值 预算阶段 1.85 立项阶段 1.50 招/投标阶段 1.25 项目计划阶段 1.10 设计阶段 1.00 二期项目 预算及立项阶段 1.50 招/投标阶段 1.25 2. 软件因素调整因子取值 软件因素调整因子包括业务领域、应用类型和质量特性调整因子。 业务领域 取值 政府（OA类） 0.93 政府（电子政务类） 1.10 能源 1.02 交通 1.01 制造 1.02 电信 1.54 金融 1.62 其他 1.00 应用类型 范围 取值 业务处理 办公系统OA，人事、会计、工资、销售及其他业务处理用软件 1.0 科学计算 科学计算、数据模拟、大数据等 1.2 多媒体 图表,影像,声音等多媒体应用领域,地理信息系统,教育和娱乐用等 1.3 智能信息 自然语言处理，人工智能，专家系统、预测模型等 [...]
软件成本度量一直都是软件行业的一个痛点问题。软件度量一度乱象丛生。拍脑袋的定价方式曾大行其道。软件成本度量的乱象直接导致了软件价格的诸多问题。比如预算费用存在浪费或不足的现象，招标存在投标额过低过高等非正常状况。这些情况都是因为度量标准的缺失，导致定价没有依据。 《软件工程 软件开发成本度量规范》标准的出台为软件行业定价指定了一个国家标准，使得软件行业自此有了一个软件成本度量的标准规范。 软件成本度量的前提是软件规模大小及生产率。目前，每年都有CSBSC年度中国软件行业基准数据可以引用生产率等数据。由此，软件规模大小的度量就成为了重中之重。 软件开发成本分为人力成本和非人力成本。人力成本包括直接人力成本和间接人力成本，直接人力成本指参与项目研发的人员的工资、福利、奖金等费用，间接人力成本指部分参与项目研发的人员的费用分摊。非人力成本包括直接非人力成本和间接非人力成本。直接非人力成本指直接服务于项目所产生的设备、培训、差旅等费用，间接非人力成本指部分服务于某项目的费用分摊，如房租等。 目前，评估软件规模的方法主要分为两种：基于业务视角和基于开发视角。基于业务视角的方法从用户角度出发，如：功能点、故事点、用例点、对象点等方法。基于技术视角的方法是从开发人员的角度，方法包括代码行、数据库表、函数、接口、服务的数量等等。 基于开发视角的方法主要存在于技术人员之间，优势是实现起来简单容易，缺点是容易引起分歧，难以在项目初期进行度量，且难以在技术人员之外的其他人员之间得到应用，如部门之间、用户之间等。而基于用户视角的度量方法是站在使用者的角度来进行度量，并能够在项目初期得到应用，弥补技术度量方法的不足。因而，基于用户视角的度量方法在目前得到了广泛应用。 虽然基于用户视角的度量方法有多种，但真正被广大用户所接受的方法是功能点方法。功能点方法是IBM公司在1974-1979年间，由Albrecht通过对大量项目生产率进行研究得到的成果。随后多年不断完善升级，出现了多种标准和方法。 国家标准中，提到了如下5种估算方法都属于功能点度量方法： IFPUG NESMA FiSMA COSMIC MK II 上述5种方法各有特点，应用于不同的场景下，度量的方法和过程也各不相同。从应用角度而言，IFPUG和NESMA标准是国际上最主要的标准，国际基准比对组织中超过90%的数据采用IFPUG/NESMA方法，国内的行业数据百分百采用IFPUG/NESMA方法，由于IFPUG方法和NESMA方法被认为是基本等效的，所以近几年，这两种方法被各行业大量采用。但如想在早期（如预算）阶段进行度量，NESMA是更好的选择。 下表列出了几种不同方法的区别：
1.1 软件开发成本 software development cost 为达成软件开发项目目标开发方所需付出的各种资源代价总和。 注：资源包括人、财、物、信息等。 1.2 软件开发收入 software development income 因向委托方交付软件开发工作成果所获得的收入。 1.3 直接成本 direct cost 为达成软件开发项目目标而直接付出的各种资源代价总和。 注1：如可直接计入软件开发项目成本的直接材料、 直接人工等。 1.4 间接成本 indirect cost 与达成软件开发项目目标相关，但同一种投入可以支持一个以上项目的联合资源代价总和。 注：如开发管理人员工资、开发设备折旧、停工损失等。 1.5 人力成本 human resource cost 为达成软件开发项目目标所需付出的各种人力资源代价总和。 1.6 非人力成本 non-human resource cost 为达成软件开发项目目标所需付出的人力成本之外的其他资源代价总和。 1.7 成本度量 cost measurement 对软件开发成本的预计值进行估算或对实际值进行测量和分析的过程。 1.8 方程法 equation 基于基准数据建立参数模型，并通过输入各项参数，确定待估算项目工作量或成本估算值的方法。 1.9 类比法 comparison 将本项目的部分属性与类似的一组基准数据进行比对，进而获得待估算项目工作量或成本估算值的方法。 1.10 类推法 analogy 将本项目的部分属性与高度类似的一个或几个已完成项目的数据进行比对，适当调整后获得待估算项目工作量或成本估算值的方法。 [...]
一．什么是软件估算 软件估算是软件量化管理的重要部分。随着科技和社会的快速发展，软件应用领域在不断扩大，同时，越来越多的软件功能越来越复杂。如何更好更快开发出更多更复杂的软件是摆在软件从业者面前的重要问题。 软件估算包括：软件规模估算、生产率估算、工作量估算、软件成本估算、开发周期估算、缺陷估算、风险估算、资源估算等。 软件估算一直都是非常复杂的事情。项目变更、开发团队人员变化、需求改变、工作能力大小等都会导致估算结果的差异。据有关统计，延期的软件项目中，约有超过60%的项目是因为软件估算没有做好。不是技术水平达不到要求，而是估算结果与实际情况有重大差异或者没有进行估算导致的。所以说，软件估算是非常重要的，准确的估算结果是软件项目成功的重要保障。 失败的项目最常见的六个原因： 如上图中所示，六个原因中的任何一个都可能导致项目失败，很多时候是多个原因同时出现。做好软件估算可以完善上述原因中的不足部分，解决大多数上述问题。 二．软件估算面临的问题 软件估算虽然非常重要，但在实际中面临一些实施困难，主要表现在如下方面： 1.规模越大的软件，复杂性越高，面临的问题就越多，越难以估算； 2.需求不确定性，导致估算结果容易出现较大偏差； 3.陌生领域的项目，复杂性和认知性差，不确定性增大； 4.估算人员的水平、经验、对估算项目的理解能力等可能会对估算结果产生一定影响； 三．软件规模估算 软件规模估算是软件估算中的首要环节，是其他估算项目的基础。软件规模估算定义了软件的客观大小，而且不因为测量的人员、方式、时间的不同而变化。 对于甲方（发包方）而言，软件规模估算决定了项目的预算、招标金额，为费用申请提供了科学依据。 对于乙方（开发方）来说，软件规模估算可以帮助乙方确定投标金额，还能确定需要投入的资源及开发成本的评估等。 不识别规模的情况下，项目管理的三个重要目标无法提升：效率、质量和成本？ 效率 = 总工时/软件规模 质量 = 缺陷加权总数/软件规模 成本 = 单位成本 * 软件规模 合理地对软件项目进行规模估算，能够更加精准确定项目开发所需的资源、费用、周期等。所以说软件规模估算是其他估算内容的重中之重。 软件规模大小决定了软件的成本及开发资源的投入。由于估算活动的不确定性，软件规模是最难确定的因素，虽然不能百分百准确，但从国际到国内，软件规模已经成为衡量软件开发的一个非常重要的指标。 依据合理的方法对软件规模进行估算，相较于拍脑袋、拍大腿等的“六拍法”，可以提供更加科学合理的估算结果。 四．常见的估算方法 1. 经验法（专家法，包括PERT法、DELPHI法） 根据管理人员以往的项目或领域的经验，对未来的工作量进行估计。 2. 类推法 将本项目的部分属性与高度类似的一个或几个完成的项目进行比对，适当调整后获得待估算项目的工作量、工期或成本估算值的方法。 3. 类比法 将项目的部分属性与类似的一组基准数据进行对比，进而获得待评估项目的工作量、工期和成本估算值的方法。基于基准数据通常以50百分位数为参考而非均值。 4. 方程法 根据一个相对稳定的公式对未来的工作量进行估计。基于基准数据建模，可以与行业和企业数据相结合。 5. 交叉验证 估算过程中宜采用不同的方法分别估算，并进行交叉验证。 如果不同方法的估算结果产生较大差异，可采用专家评审的方法确定估算结果，也可以使用简单的加权平均方法。 五．软件规模度量的发展 软饭规模度量的发展经历了长期的过程。 最初，采用物理的度量方法：测量纸带的长度，或者汇总程序的字节数。这种方法在早期阶段，程序功能比较单一、开发语言相对固定的情况下，对软件规模度量提供了一定的参考价值。 后来，发展到了技术度量过程：比如代码行、函数数量、数据库、模块、类的数量等。这些方法是属于特定历史时期的产物，在那段时期，这些方法都对软件规模度量的发展起到了巨大的推动作用。也正是这些方法的出现，体现出了其中的优劣势，使得软件规模度量发展到了“功能”的阶段。 功能的规模体现在：用例数、功能点数、故事点数、页面数、窗口数、按钮数等。这其中，最得到普及应用的是功能点方法。 上纪70年代中期，IBM委派工程师Allan Albrecht和他的同事共同研究软件测量和度量分析方法。经过一年多的研究，Albrecht和他的团队发布了名为“功能点”的度量方法第一版。 [...]
前些天，发了几篇小文，大概讲了一下软件造价的部分相关内容。但由于没有从基础讲起，所以一些朋友私下找我，问了些问题。我才意识到应该先从基础说起。接下来，我会发几篇文章，就软件造价的基础问题进行描述。那么今天，我就先来普及一下什么是“软件造价”。 首先先要明确什么是“造价”。百度百科里描绘“造价”为：造价是一个汉语词汇，读音为zào jià，指制造某种东西或建筑物等所需的费用。《人民文学》1977年第10期等均有相关记载。 那么“软件造价”顾名思义，指的就是制造（开发）某种软件所需的费用了。“软件造价”是个新鲜的词汇，一直以来，我们常常说：一款软件值多少钱、一款软件的成本是多少等等类似问题，就是因为没有“软件造价”这个词。因为没有依据标准给“软件造价”这件事做依靠。你说你软件造价，凭什么信你的？ 软件造价应该包含软件研发成本、利润、税费、预期市场价值等。其中最重要的是软件研发成本的衡量。如果说一款软件已经研发完毕，我们把各种投入喀喀喀加一起，就算出来了。但是，如果软件项目还处在预算阶段，开发方还没着落的时候，如何知道成本呢？《GB/T 36964-2018 软件工程软件开发成本度量规范》标准告诉了我们如何评估软件研发的成本。 所以，对于投资方来说，软件造价告诉TA需要投入多少钱；对应开发方来说，软件造价会告诉他需要投入多少钱。
一. 什么是软件估算 做软件项目开发的时候，经常遇到的问题包括: 软件项目有多少功能？成本是多少？开发团队找什么样的？开发周期要多久？如何控制好开发质量？ 在项目正式开发实施前，这些问题必须搞清楚。那么搞清楚这些问题了，就属于软件估算。 二. 估算的内容 软件估算的内容包括: 软件规模 软件质量 软件成本 开发周期 等等。 这其中最根本的是软件规模，即软件功能量化，我们这里称作“功能点”。软件的质量、成本、周期等估算内容都是依赖于功能点的，所以功能点数量是根本。 三. 软件估算的重要性 为什么要进行软件估算呢？根据估算内容，我们也大概能够了解到估算的重要性了。 科学标准的估算结果可以给出更加准确的成本价格，避免成本价格偏差太大。特别是在当前国家严格审批和审计的情况下，科学合理且有据可依的成本价格有助于项目更容易获得申请通过，且经得起审计部门的审计。 此外，估算结果可以更好的帮您选择开发团队及人员投入。为什么这么说呢？由于地域及发展水平的问题，不同地区的开发团队其人员成本是不同的，北京这种一线城市是最高的。还有比如开发团队之前是否做过同类项目？用什么语言开发？等等，这些因素都会决定项目的成本价格、开发周期，及投入的人时数等。 假如一个项目没有事先做估算，可能会出现的结果: 项目按计划如期顺利完工（极少项目，也是理想状况）； 功能增加或调整； 前期项目费用不足，需要补充； 项目延期，迟迟没有交付； 项目烂尾，导致无法交付； 甲乙双方相互扯皮 等等 近期爆出的一个法国的项目就很有代表性。这个项目本来不大也不复杂，结果乙方用了12年，写了600多万行，甲方支付的开发费用也从几百万欧元不断上涨。最终的结局是项目不合格，甲方负责人被判入狱。结局很可悲，但也说明了如果事先做好了估算，这种结局就基本不会出现。 四. 何时进行估算？ 那么何时需要进行估算呢？ 我们认为从项目立项到实施的全过程都可以进行估算。 比如立项阶段，需要估算有多少功能，需要投入多少资源，协调哪些单位和部门，用户是谁，有多少用户，能简化多少流程，能提高多少效率，或者能有多少收益等等。 预算阶段就需要估算出来申报或投资额度的合理区间。 那么在招标阶段，项目的合理标的应该是多少？如何面对较大的投标额？ 还有在项目实施阶段，如何更好管理功能变更调整，参与人员的灵活调配，及合理的变更费用等等。
刚刚听到一则悲哀的事情：38岁浙大学霸Facebook总部跳楼。38岁了，为了工作非常拼命，每天加班到半夜，有时回家不到半天就又要去加班。终于有一天，由于没有令到上司满意，导致悲哀的事情发生。 其实这种情况在国内也非常普遍，年龄大了，还让你每天拼命写代码，做项目，大部分人都是在透支身体。这种情况还能持续多久？这个年龄还写代码的话，已经拼不过二十几岁的年轻人了。 现在给大家介绍一个IT中年转行的机会：转职做软件项目的造价评估。不浪费你多年的软件项目经验，还能面对巨大的市场，继续在IT行业发挥光和热，而且没有那么大的项目压力。这是一个新兴的行业，对每个人想要从事这个工作的人来说，机会都比较难得，有想要在这方面有所发展的朋友可以关注我，了解工作机会和行业的发展。
最近，法国一个烂项目惊爆了全世界的互联网和开发界。 该项目历时12年，总共600多万行C++代码，有50000多个类，直到最后把项目负责人逮捕入狱才算完事，这只是代表项目终止了，并没说明项目完成了。 听到这个“故事”的时候，我为这个项目的负责人感到莫大的悲哀，居然因为做项目而进监狱了！ 项目的计划是很好的，预算几百万欧元，工期2-3年。并不是一个很大很复杂的项目。 项目是如何演化的呢？ 项目资金到位后，这家公司开启了疯狂的招人计划，每隔几个月开发队伍就扩大一倍。结果7年过去了，项目还没有完成。因为延误，这家公司每天的罚金都高达数千欧元。我就纳闷了，这家公司居然还没被拖黄（这家公司有对策，下文提到）。直到有一天，公司管理者终于受不了了，就把干活的人都开掉了，新招了一批新手来开发，以此来减少开销。一段时间后，又把那些人开掉，再招一批经验丰富的人继续开发，就这样如此反复，结果又持续了几年。在这期间，这家公司经常给甲方发送金额不断增加的项目变更账单，来弥补每天巨额的工期延误罚金。整个过程中，甲方的仁义和耐心被一次次的磨光，直到最后把这家公司的负责人送入监狱。 无独有偶，美国某政府部门一个预算500万美元的项目，历时数年，最后耗资1.5亿美金，才仅仅完成了部分功能。 其实，这样的事例每天都在上演，只是很少曝光而已，都是丢人的事情，谁愿意说出来？ 如何看待一个失败的项目： 开发方团队实际生产率只有计划的1/30？ 项目开始后，发生了2900%的变更？ 项目实际费用是早期预算结果的30倍？ 事先做好估算，还会有历时12年，600多万行代码这样的烂项目吗？ 为什么会出现这种情况？ 就甲方而言，一旦签约并付款了，即使签约的开发方有各种问题，也不会轻易变更，因为变更就意味着责任人失职，意味着之前的付款打水漂了，责任人要担责的。 而对于乙方，因为急于签订合同拿下大单，对甲方的需求不清晰，导致开发人员投入不准确，形成多米诺骨牌似的连锁反应，使得项目总也完不成。 就失败项目而言，失败的原因有如下一些方面： 缺少用户的参与，导致开发出的功能不符合甲方需求 项目需求不完整，导致开发过程中误时走弯路 变更的需求，甲方需求变更，导致乙方之前的需求没做完，又要做新的需求，或者推翻之前的需求功能，按新需求继续开发 缺少领导的支持，导致甲乙双方对需求不能形成权威的确认和评定 开发方能力不足，导致换了很多人，项目越做越复杂，越来越低效 不切实际的期望，导致乙方承诺了甲方自己都无法完成的功能 可见在项目初期，做好科学估算是无比重要的。这里的估算包括成本、开发周期、质量保障等。然后甲乙双方根据估算报告中规定的细则来执行，项目的成功率会大大提升。 要避免项目落坑，如何做到科学估算，欢迎继续关注”软评老胡“的后续文章。
