在软件开发过程中，我们有哪些方法进行“度量”？

[SageXiong]

没有度量就没有管理。

软件开发的成本估算是一个复杂的过程，涉及多个因素和步骤。往往不同的软件开发商，给出的价格差异巨大，导致甲方在选择开发商时，选择困难，比如下面人力资源管理系统的案例。

人力资源管理系统需求

假设，现在某甲方需要一套人力资源管理系统，甲方单位业务部门人员列出了比较原始的业务需求，具体需求描述如下：

1. 组织架构管理 对公司组织架构进行维护和图形化显示，包括部门、岗位等信息。可以对部门进行新建、修改、删除、合并、改变归属关系、设定岗位人数并根据已录入的档案信息自动显示实际岗位人数。支持部门、岗位信息的 Excel 模板导入功能。可以对岗位进行新建、修改、查询、删除等，岗位信息包括岗位说明、相关联工资级别等。

2. 招聘管理 对于空缺岗位生成招聘申请，人力资源主管和部门主管审批后自动发布到外部招聘渠道。可以查询招聘信息或删除已过期的招聘信息。对应聘人员信息进行管理，将得到的简历、面试情况录入到系统并进行维护。

3. 档案管理 对员工的信息进行管理，包括员工基本信息（如姓名、年龄、性别、岗位、电话、邮件等）、家庭档案信息、培训记录、工作记录。还包括员工照片、社保号码登。授权用户可以对员工档案进行查询或进行修改（如调动、离职、绩效考核信息填写等）。

4. 人力地图 将公司的全部或某部门组织架构图显示出来，并可查看员工的基本信息。本人可以维护部分个人信息，如手机号码、个人主页地址、个人说明等。

5. 培训管理 制定公司年度培训计划进行管理，并对每次公司级培训简历培训记录并对培训效果进行分析。提供年度培训久啊的建立、修改、审核、审批等功能。对每次培训进行管理，可自动发送培训通知，培训后填写培训满意度、培训总结。可以对某时间段内的培训或选定培训进行培训效果的比较和分析。

6. 人力资源分析 包括基于人数的分析和基于部门的分析。基于人数的分析包括统计各岗位、各部门、各学历、各年龄段的人数、各岗位/部门实际人数和空缺人数等。基于部门的分析包括分析各部门到岗率、入/离职情况、岗位构成、学历构成、年龄构成等。

7. 报表中心 授权用户可查看或打印员工基本信息、培训信息、工作情况、考核情况、并提供人力资源常用模板（如离职申请、培训申请等）的下载和打印。

接收到项目报价情况

在甲方经过一轮咨询之后，接触了 A 、B 、C 三个软件开发商。这三家软件开发商与甲方都是第一次合作。三家开发商给出的报价方案分别如下：

A 开发商

A 开发商基于对以上需求的了解之后，项目经理按以往的项目经验，对项目进行了 WBS 的分解：

• 需求：10 人天
• 设计：10 人天
• 构建：80 人天
• 测试：10 人天
• 部署：10 人天
• 管理：60 人天

项目总工期为 60 天，合计的总工作量是 180 人天，人均每天按 1000 元计算，完成这个人力资源管理系统需要 18 万元。

B 开发商

B 开发商看了以上需求后，采用 Scrum 的开发方式，把人力资源管理系统规划成 5 个 Sprint 进行开发，每个 sprint 为 14 天，共计 70 天，故事点合计共 10 个，每个故事点按 3 万元计算，完成这个人力资源管理系统需要 30 万元。

C 开发商

C 开发商提供的报价清单，说自己曾经做过类似的人力资源管理系统，并向甲方演示了自己的 Demo 实例，与以往的项目对比后，提出了在 80 个工作日内，以 27 万元的成本可以完成开发的报价方案。

如何选择开发商？

A 、B 、C 三位软件开发商的报价对比情况如下：

开发商	价格	工期
A	18 万	60 天
B	30 万	70 天
C	27 万	80 天

请问，如果你作为甲方，在只有以上信息的情况下，如何选择合适的软件开发商来开发这个人力资源管理系统，才能保证这个软件开发项目顺利完成？

如果甲方在项目管理方面比较喜欢传统的瀑布流的管理方式的话，在看到 A 开发商提供的报价方案之后，会更喜欢，因为 A 开发商凭借自己的经验，提供了相对与其他 2 位开发商更为完整的工作分解结构作为报价依据，看起来似乎很有说服力。

C 开发商拿出了自己曾经开发的人力资源管理系统进行了演示，甲方在看了 Demo 后，发现系统基本能满足大部分的需求，但是，价格相对于 A 方案贵了近 1.5 倍，有点不知如何判断。

在了解了软件开发相关的基本知识后，发现 B 开发商的方案是按行业比较推崇的敏捷开发框架来进行的报价，似乎也很可信，看起来蛮先进，但是，敏捷开发团队的名声不太好，概念很新，从调研的情况来看，敏捷开发的项目有更多的加班，但是加班更多，怎么工期比 A 供应商的还长？ B 开发商的开发能力是不是不行？

面临的问题

在双方进行商务谈判的过程中，面临了几个问题：

1. 开发商的报价都是按照各自的报价体系，从内部看没有问题，但是，甲方没办法找到客观的参考，而且各自的成本和工期差异很大，软件工程的复用性强，造成选择困难。
2. B 开发商认为甲方的需求并不完善，有很多模糊的地方并未定义清楚，例如：培训管理的审批流程未提供明确的定义。所以，提供的报价包含了自己的风险成本，相对偏高。
3. C 开发商演示的 Demo 让甲方对项目成功获得了很大信心，但是成本是 A 开发商成本的 1.5 倍，甲方在与 C 开发商进行成本谈判时，C 开发商根据以往的经验，拒绝了甲方提供的新的成本方案，谈判陷入了僵局。

甲方的困境

站住甲方的角度:

1. 进行商务谈判时，无据可依，全凭专家经验。

信息化采购需统一按照政府采购流程进行，各项软件开发工作量的评估和谈判工作由谈判小组实施。而谈判文件中缺少明确的软件工作量评估的原则、方法及流程，以致谈判小组成员无拒可依，全凭专家经验评估，导致谈判专家之间的评估误差很大。

1. 无法识别合理性报价。

在信息项目招投标中，由于该总局业务系统较复杂，软件项目类型多种多样，包括新项目开发、升级完善、运行维护等类型软件系统，各投标商的报价方法五花八门，报价额度也千差万别，以致招标方无法合理识别投标商的报价，谈判双方口径不一致，谈判效率低下。

1. 系统延续性强，商务谈判地位处于弱势。

由于该总局的大量项目是在既有业务系统上进行功能的修改，扩充及维护，因此延续性较强，不宜频繁更换供应商。谈判双方的知识背景不对称，使得商务谈判议价时甲方所提疑问经常被乙方所谓的复杂技术挡回，甲方无法了解真实的生产成本。

乙方的困境

站在乙方的角度：

1. 公司报价缺少较为权威的依据支撑，难以帮助甲方完成预算申报。

在针对某政府电子政务项目的销售公关时，甲方要求乙方根据业务需求文档给出相对应的报价预算，报价需要有科学的方法或行业法规支撑，以便其在申请预算时，符合相关要求。

1. 面对新的业务领域，专家经验估算法偏差巨大，导致项目亏损。

公司随着业务的不断拓展，经常涉及新的领域，由于专家经验的局限性，在面对新业务项目的估算时，导致估算偏差巨大，带来了领导决策上的失误，使得项目出现投入不足，工期延误以及项目亏损。

1. 需求模糊不清，为项目变更埋下隐患。

在项目预算阶段，各甲方提出的需求粗细程度不一，有些需求虽然写的篇幅很大，对功能描述的语言很多，但没有描述到关键点上，为后续项目开发工作埋下了严重的隐患，直接导致需求变更加剧。

解决方案

为了解决甲乙双方针对软件开发造价矛盾，国内也出了很多的软件成本度量的标准，旨在提供科学的成本控制依据和规范的成本量化方法。

软件成本度量相关的标准主要是 ISO/IEC 14143 系列标准，包括了：基本概念、基准模型、功能规模测量的功能域确定和使用指导。标准的内容考虑得非常全面，但是想要理解标准的内容也需要耗费非常多的时间。其中，ISO/IEC 13132-6 （信息技术 软件测量 第 6 部分：ISO/IEC 14143 系列标准和相关国际标准使用指导）提供了功能规模测量（ FSM ）相关标准的概括说明以及系列标准之间的关系，以及 ISO/IEC 的功能规模测量方法，包括以下 5 项：

1. ISO/IEC 19761 （ COSMIC_FFP 方法）
2. ISO/IEC 20926 （ IFPUG 方法）
3. ISO/IEC 20968 （ Mk II 方法）
4. ISO/IEC 24570 （ NESMA 方法）
5. ISO/IEC 29881 （ FiSMA 方法）

国家为了满足行业发展需求，基于 ISO/IEC 14143 系列标准，制定了功能规模测量的国家标准。在 2018 年，发布了 GB/T 36964-2018 《软件工程 软件开发成本度量规范》。其中，主要用到的功能测量方法也是 ISO/IEC 的 5 种功能规模测量（ FSM ）方法。

功能规模测量方法

功能点分析法是较为简单直接的功能规模估算方法，它关注的重点是软件用户所要求的功能来测量软件的规模。

COSMIC_FFP 方法

COSMIC 是一种全功能点（ Full Function Point, FFP ）分析方法，适合应用在实时系统和嵌入式系统的功能规模测量。COSMIC 关注每个功能点所引起的数据移动。COSMIC 的度量过程分为以下几步：FSM 目的和范围的确定、FUR 的识别、软件层的识别、功能性用户的识别、软件边界的识别、功能过程的识别、数据组的识别、数据移动的识别、数据移动的分类、功能规模的计算、FUR 变更的规模计算。

IFPUG 方法

IFPUG 从用户对应用系统的功能需求出发，对应用系统的两类功能需求（事务性功能和数据功能）进行分析。IFPUG 针对不同类型的应用，设置了工作量的调整因子，官方在适用范围方面的说明是适用于所有类型的软件开发项目和维护项目，但是，我个人的看法是，该方法在实时操作系统的使用场景下，还是不够准确。

Mk II 方法

Mk II 将软件描述成一系列的逻辑事务集合，与 IFPUG 相比，减少了逻辑文件识别的主观性，Mk II 在适用性方面，尤其适用于管理信息系统（ MIS ）类项目。

NESMA 方法

NESMA 是基于 IFPUG 发展出来的一个功能点估算方法。相对于 IFPUG 方法，NESMA 提供了 3 类功能点分析方法：详细功能点分析、估算功能点分析和预估工功能点分析。在项目不同的阶段，采用不同的估算方法能有效的提高估算的工作效率。

FiSMA 方法

FiSMA 借鉴了 IFPUG 的设计思想，对 7 个不同的基础功能模块（ BFC ）进行了标识：最终用户互动导航和查询服务（ q ）、最终用户互动输入服务（ i ）、最终用户费互动输出服务（ o ）、提供给其他应用的接口服务（ f ）、数据存储服务（ d ）、算法和操纵服务（ a ）。在操作性上，FiSMA 服务类型划分较为细致，更能反映出软件的特性，但也因其繁多的分类数量，降低了本方法的操作性。在适应性上，FiSMA 适用于所有软件项目，但要求用户了解被度量应用的技术实现方式。

软件源代码行测量方法

COCOMO II 模型是我接触过更代码行比较相关的软件成本度量模型。它以软件规模作为估算的依据，使用 17 个工作量乘数与 5 个规模因子来体现不同软件项目在环境、运行平台、人员、产品等方面的差异。但是，COCOMO II 的模型过于复杂了，虽然使用与所有类型的软件项目，但是在操作性上就大打折扣了。

用例点估算方法

用例点（ Use Case Point, UCP ）估算方法是基于用例图，利用已经识别出的用例和执行者，根据它们的复杂程度划分计算用例点。分为：角色的复杂性程度级别划分及计数、用例复杂性程度级别划分及计数、计算未调整用例点数和使用技术复杂性程度因子和环境复杂性程度因子调整用例点 4 个步骤。

对象点估算方法

对象点（ Object Point ）估算法基于加权的概念，将不同的对象赋予对应的对象点数值并求和，已获得软件的规模，它包括 3 个基本对象类型：界面、报表和组件。

故事点估算方法

在敏捷型项目开发过程中，经常使用故事点估算的方法评估用户故事。用于估计实现一个或多个用户故事的复杂度，它是对工作量的一种描述方式。通常，采用类似于计划扑克这样的方法来完成估算。但是，故事点是一种相对的估计，团队不一样，每个团队针对同一个用户故事评估出来的故事点数也不一样。

评估方法对比

方法名	应用领域	度量角度	基本组件
IFPUG	所有类型软件	终端用户	5 个系统组件
Mk II	逻辑事务能被确定的任何软件	终端用户	逻辑事务
COSMIC	商业应用软件和实时系统	终端用户、开发者	功能过程
NESMA	所有类型软件	终端用户	5 个系统组件
FiSMA	所有类型软件	开发者	7 个基础功能模块
COCOMO II	所有类型软件	终端用户、开发者	17 个工作量乘数与 5 个规模因子
用例点	所有类型软件	终端用户、开发者	角色和用例
对象点	逻辑事务能被确定的任何软件	终端用户	3 个基本对象组件
故事点	所有类型软件	开发者	用户故事

在实际的项目过程中，要尽可能选择适合项目特点的软件规模度量方法。虽然，COCOMO II 方法非常复杂，公式也非常多，但是，COCOMO II 是当今世界上应用最广泛的软件成本估算模型之一，对成本测量非常严格的软件项目，COCOMO II 方法是非常适合的。同时，COCOMO II 模型考虑了模型的可扩展性，使用者可以根据自己环境因素的特点扩展模型。

但在项目实施过程中，甲方往往都不具备软件开发的领域知识。想要通过代码行之类的方法与所有的相关方达成共识，是有一定难度的，因此，找到一种简单高效的软件开发的度量方法，也是软件工程一直在探索的领域。

[lzjunika]

有这么多 ISO/IEC 方法，还是增加不对称沟通的复杂度，最终还是无解
想办法了解甲方预算范围，按这个范围评估，即所谓看人下菜，应该是现在的主流方式

[flmn]

我觉得吧，使劲跟 C 聊，让他降价，毕竟有现成的东西在那里。
B 最不靠谱了。

[SageXiong]

@lzjunika 呃~ ISO 的方法虽然复杂，但是，确实是可以减少沟通复杂度的。看人下菜不就是把甲方当冤大头嘛

[SageXiong]

@flmn 为啥 B 最不靠谱？敏捷开发这么不靠谱的吗？

[zhouyg]

@SageXiong #4 文中说 B 加班多，加班多肯定不靠谱的，而且加班写的代码也容易出问题

[flmn]

@SageXiong B 最后 30w 肯定包不住，继续加故事点