Sage_Xiong (风诰)

让乙方在谈判桌前有底气大胆的谈判！

Sage_Xiong — Sat, 01 Jun 2024 23:43:57 +0800

在上篇文章《软件开发商务谈判中，我们尝试把甲乙双方拉到同一尺度下的第一步！》中，我们通过 IFPUG 的软件模型将甲乙双方针对软件开发这个工作拉到了同一个水平线上来讨论成本问题。

IFPUG 分析法的提出不但没有解决甲乙双方在商务谈判过程中的困境，同时，IFPUG 功能点分析法在使用过程中，还存在两个主要的问题：

IFPUG 在软件的非功能性需求并没有进行测算，无法准确的体现出软件开发商在实际开发中的工作量。
在软件项目早期，没办法非常确定事务性功能（EI，EO，EQ）的时候，就没办法准确的核算具体的功能点，IFPUG 方法就没办法很好的应用，还在项目早期徒增工作量。

不解决这两个问题，乙方对功能点的分析结果是没有底气的，也不敢轻易的使用功能点分析的方法进行项目估算。

IFPUG 调整后的功能点

IFPUG 在最初进行功能点分析时，得到的是完全不考虑非功能性需求的功能点。为了解决没有考虑非功能性需求的问题，IFPUG 使用调整系数（value adjustment factor，VAF），对功能点进行修正，用以体现非功能性需求的工作量。

IFPUG 的 VAF 和 14 个通用系统特性（General System Characteristics，GSC）相关联：

数据通讯（Data Communications）;
分布式数据处理（Distributed Data Processing）；
性能（Performance）；
使用强度高的配置（Heavily Used Configuration）；
交易速度（Transaction Rate）；
在线数据输入（Online Data Entry）；
最终用户的效率（End-User Effciency）；
在线更新（Online Update）；
复杂的处理（Comples Processing）；
可重用性（Reusability）；
安装的简易性（Installation Ease）；
运行的简易性（Operational Ease）；
多场地（Multiple Sites）；
允许变更（Facilitate Change）；

在完成初步的功能点分析之后，再根据系统的特点针对这 14 个通用系统特性计算出调整系数（VAF）。

调整系数（VAF）的计算公式：

VAF = (TDI * 0.01) + 0.65

TDI（Total Degree of Influence）：所有的 GCS 的影响程度相加得到的整体影响程度。

确定好了 VAF 的值之后，就可以根据 VAF 对初始的功能点（UFP）进行修正，得到调整后的功能点（FP）：

FP = UFP * VAF

14 项通用系统特性（General System Characteristics，GSC）的影响程度判断暂时先不进行说明，后面再单独说明吧。

到这里，IFPUG 提出了非功能性需求度量的解决方案。但是，在项目早期时，怎么对软件开发项目进行快速估算，还是没有很好的解决方案。

NESMA 功能点分析法

NESMA 是荷兰软件度量协会（Netherland Software Measurement Association）的简称。

在项目早期时，由于无法清楚的缺点软件的具体功能，想判断清楚 ILF、EIF、EI、EO、EQ（具体定义参考软件开发商务谈判中，我们尝试把甲乙双方拉到同一尺度下的第一步！）是不可能的。

NESMA 为了解决这个矛盾，发现在项目早期，我们很难判断的是事务型的功能（EI、EO、EQ），数据型功能（ILF、EIF）在项目早期，是相对好确定的，并且趋于稳定的。

数据型功能一般都是与业务相关的数据集合。

例如之前提到的人力资源管理系统的组织架构管理模块为例：

组织架构管理

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

上文的需求描述中，虽然明确了新建、修改、删除、合并、改变归属关系等功能，但是，在具体的项目实施过程中，软件功能的需求变更是经常发生的事情。如果在开发过程中甲方突然发现，我需要一个岗位信息的 Excel 导出功能，方便人力部门做报表的统计。那么这时的变更做还是不做？那如果在做预算时，考虑到变更成本，成本核算的依据又是什么？这些都会给需求的变更埋下隐患，导致在项目早期进行估算困难。

回过头再来看看组织架构管理的功能需求描述可以发现，整个组织架构管理模块包含的业务信息集就部门和岗位两类信息，除此之外，不再包含其他的业务信息。

是不是可以把功能点分摊到相对稳定的数据型功能（ILF 和 EIF），进而实现在项目早期对项目进行估算呢？

当然可以！

NESMA 基于上面的这个想法，把项目的功能点分摊到了数据型功能（ILF 和 EIF）上，分别得到了 ILF 和 EIF 的功能点计数值：

功能类型	ILF	EIF
计数值	35	15

在项目早期，组织架构管理模型的功能点估算就可以只使用部门和岗位两个 ILF 进行估算：

UFP = 35 x 2 = 70

人力资源管理系统的组织架构管理模块的初始功能点（UFP）就是 70 。这样就解决了项目早期的功能点估算问题。

还有哪些待解决的问题？

至此，还有什么问题没有解决呢？先回过头看看甲乙双方的困境。

甲方的困境：

进行商务谈判时，无据可依，全凭专家经验。
无法识别合理性报价。
系统延续性强，商务谈判地位处于弱势。

乙方的困境：

公司报价缺少较为权威的依据支撑，难以帮助甲方完成预算申报。
面对新的业务领域，专家经验估算法偏差巨大，导致项目亏损。
需求模糊不清，为项目变更埋下隐患。

貌似好像，什么都没解决？不过，我们好像已经从把甲乙双拉到同一个谈判桌进行谈判，发展到了乙方有能力在项目早期进行谈判的时候进行快速的功能点估算了。

想要完全解决这个困境，只能再想办法了。

未完待续。

PS. 各位如果对软件造价或者软件项目管理实务感兴趣的我们可以多多交流哟！

软件开发商务谈判中，我们尝试把甲乙双方拉到同一尺度下的第一步！

Sage_Xiong — Wed, 08 May 2024 09:31:18 +0800

上篇文章拿了一个人力资源管理系统的案例来作引，说明了甲乙双方在软件开发项目中的困境。忘记的可以再回头看一看。

我们应该怎么 “度量” 软件开发

先把上篇文章中提到的人力资源管理系统的例子贴过来。

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

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

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

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

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

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

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

今天先来说说功能点估算的第一个方法——IFPUG 估算法。

国际功能点用户组织（International Function Point Users Group, IFPUG）

Allan J. Albrecht 1979 年在 IBM 工作时首次在《衡量应用程序开发生产力》一书中提出了功能点估算法。随后，他成立了国际功能点用户组织（International Function Point Users Group, IFPUG），他发明的这个功能点估算方法也就称为了 IFPUG 功能点估算法。

IFPUG 作为一个非营利性、会员管理的组织，其使命是成为推广和鼓励有效的应用软件开发和维护。随着时间的推移，IFPUG 方法已经成为国际上使用最广泛的功能规模度量方法之一，特别适用于信息系统。

在 IFPUG 的发展历程中，该组织不断更新和改进其功能点计数标准，以适应不断变化的软件工程实践。

1994 年，发布 IFPUG 计数实践手册 4.0 版
1999 年，发布 IFPUG 计数实践手册 4.1 版
2001 年，发布 IFPUG 计数逻辑文件的实践指南
2003 年，发布 IFPUG 功能大小的框架
2004 年，发布 IFPUG 计数实践手册 4.2 版
2005 年，发布 IFPUG 计数实践手册 4.3 版
2015 年，发布 IFPUG 早期功能点分析和一致的成本估算

IFPUG 估算法的原理

IFPUG 估算法在进行软件规模估算前，先建立了一个软件功能模型。将软件能够完成的功能分为了两种类型：事务功能和数据功能。

简单的理解就是，一个软件要为人服务的话，一是要能够自己保存维护一定的数据（数据功能），二是要能够提供操作这些数据的一些方法（事务功能）。

从程序员的角度来说，程序就是数据和算法的集合，也是蛮科学的。

数据功能：

IFPUG 估算针对程序的数据功能定义了 2 个模型：

ILF: Internal Logical File，内部逻辑文件
EIF: External Interface File，外部接口文件

IFPUG 官方定义的 ILF 和 EIF 是用户可识别的逻辑相关数据和控制信息。只是分别处于不同的系统中，ILF 处于我们评估的目标系统中，EIF 不处于我们的目标系统中。

官方的定义直译过来过于晦涩，说说我个人简单的理解就是，ILF 和 EIF 必须是对用户有实际用途的信息集。这个信息集的内容可以只是数据，同时，也可以是一些状态的表示数据。但是，一定是要对用户有实际意义！

事务功能：

EI: External Input，外部输入
EQ: External Inquiry，外部查询
EO: External Output，外部输出

IFPUG 功能点方法怎么用？

IFPUG 估算法就是基于软件的功能点的这个模型，来确定软件的基本功能，进而确定功能点数。IFPUG 在实际使用时，主要分为以下几个步骤：

收集资料
划定软件边界
识别功能性需求
计算功能点

收集资料

搞懂要干啥，当然是第一步了。比如之前的人力资源系统的需求说明：

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

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

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

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

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

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

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

划定软件边界

软件的边界是一个很抽象的概念，先来看一个比较实际的弱电控制的例子。

在弱电设备集成好后，集成单位 A 把设备交给施工单位 B 时，会提供一个施工图纸。

图纸上会标明每个线接到哪一个端子排上。双方约定好，上方的就是集成商 A 负责的内容，端子排下方的接线就是施工方 B 负责的内容。

这个端子排，就是区分双方工作的边界，也是责任划分的边界。

软件在开发出来前，都是很抽象的，不是很直观。那怎么把抽象的内容表现出来？——可视化。

画一个方框代替我们的系统，就好了。

这一步很重要，是可视化的第一步，也是把抽象的软件功能实例化的第一步。

识别功能性需求

定义好了软件边界，就可以根据收集到的需求信息，进行功能识别了。主要目的是判断好功能的类型，这个需求是数据功能（ILF？EIF？）还是事务功能（EI？EO？EQ？）。

例如，人力资源管理系统的组织架构管理模块：

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

首先，识别这个模块中的数据功能。上面的需求信息，整个模块主要是对部门信息和岗位信息的各种相关操作。因此，这个模块的数据功能主要就包含：部门信息和岗位信息。再确定，这些信息的维护是我们要开发的软件系统内部维护还是系统外部维护的。显然，这里没有其他的系统了，信息的维护是在我们系统的内部进行，就可以确定部门信息和岗位信息是ILF了。

然后，再针对这两个信息，把相关的事务功能识别出来。

最后，根据 5 种基本的功能类型，确定每个功能的类别就可以了，我简单做了一个功能识别：

ILF: Internal Logical File，内部逻辑文件
EIF: External Interface File，外部接口文件
EI: External Input，外部输入
EQ: External Inquiry，外部查询
EO: External Output，外部输出

识别完各种功能类型之后，就可以进入下一步：计算功能点了。

计算功能点

IFPUG 估算法针对不同的功能，有不同的功能点技术方法。

数据功能

数据功能的功能点数的确定，要依赖数据功能的复杂程度，下面分别是 ILF 和 EIF 的计数规则。

ILF 功能点计数规则：

复杂度	功能点数
低	7
中	10
高	15

EIF 功能点计数规则：

复杂度	功能点数
低	5
中	7
高	10

也就是说，如果某个 ILF 功能的复杂度是高，那么这个功能项的功能点计数就是 15 ，如果某个 EIF 功能的复杂度是中，那么这个功能项的功能点计数就是 7 。

那么，问题就来了：怎么判断每个功能项的复杂程度？拍脑袋吗？

IFPUG 为了解决 ILF 和 EIF 的复杂度问题引入了 RET 和 DET 的概念。

RET（Record Element Types）: 用户可以识别的数据的子集。
DET（Data Element Types）: 用户可以识别的非重复的域。

RET 和 DET 怎么理解呢？

还是拿人力资源管理系统的组织架构管理模块来举个例子：

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

岗位信息包括了 2 个部分：

岗位说明
相关联工资级别

岗位信息就是我们系统中维护的信息总集合，也就是ILF，而岗位说明和相关工资级别就是这个数据集的子集，也就是上面提到的RET。

DET 就是岗位说明和相关工资级别这两个信息集里面的各种字段，在这里没有更多明确的信息进行说明。

每个 ILF 和 EIF 都有对应的 RET 和 DET 。

因此，在确定 ILF 或 EIF 的复杂度时，根据下面的矩阵，就可以确定:

	1~19 个 DET	20~50 个 DET	51 个以上 DET
1 个 RET	低	低	中
2~5 个 RET	低	中	高
6 个以上 RET	中	高	高

由于 ILF 和 EIF 的信息给得不全面，暂时将 ILF 和 EIF 的复杂度都先确定为中来进行功能点的计算，为什么进行这样选择，后面说明 NESMA 功能点估算时会进一步说明，暂时先不细说了：

ILF: 10
EIF: 7

事务功能

EI: External Input，外部输入

EQ: External Inquiry，外部查询

EO: External Output，外部输出

确定完数据功能，就可以开始进行事务功能的确定了。同样，确定事务功能的功能点计数，也需要判断各功能的复杂度：

EI 和 EQ 的复杂度确定：

复杂度	功能点数
低	3
中	4
高	6

EO 的复杂度确定：

复杂度	功能点数
低	4
中	5
高	7

事务功能的确定，需要依靠上面说的 DET 和引入的一个新的概念 FTR 。

FTR（File Types Referenced）:被引用或更新的内部逻辑档案。

FTR 又怎么理解？

还是看人力资源管理系统的例子：

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

在系统中完成岗位的新增这个操作的时候，需要把岗位说明和相关工资级别两个信息都录入到系统中，才能保障整个功能的完善。这里的 FTR 就引用了 2 种不同的文件类型，因此，岗位新建这个功能的 FTR 就可以确定是 2 了。

每个 EI、EO、EQ 都有自己独立的 RET 和 FTR 需要确定，以便来判断各自的复杂程度：

EI 的复杂度确定：

FTR\DET	1~4	4~15	16 以上
0~1	低	低	中
2	低	中	高
3 个以上	中	高	高

EO 和 EQ 的复杂度确定：

FTR\DET	1~5	6~19	20 以上
0~1	低	低	中
2~3	低	中	高
4 个以上	中	高	高

同样的，由于 EI、EO、EQ 的各种信息更多的细节都还需要确定，复杂度我们都先按照中等复杂度等级来确定功能点计数：

EI: 4
EO: 5
EQ: 4

计数点数总结

为了方便，我先把 5 种功能类型的计数复杂度都以中级来进行功能点计数：

功能类型	ILF	EIF	EI	EO	EQ
功能点计数值	10	7	4	5	4

按照上面的这个表格计算，就可以获得最基础的功能点数是多少了：

还有什么问题没有解决？

絮絮叨叨了这么多，我们先回过头来看看我们得到的功能点数有什么缺陷？

首先，按照 IFPUG 确定的软件模型，来简化软件系统，是不是太理想了？有很多情况都无法涵盖的，软件系统的非功能性需求都没办法衡量，是不是不太科学？比如：我微服务框架分布式部署和单体架构的软件功能能一样？

当然不一样了！但是，我们得到了一个基本衡量软件规模的基本模型，可以用数据对软件规模进行量化了，对这些非功能性的需求，那我们再在刚才的基本点数上进行修正就可以了呀。所以，IFPUG 针对 14 个通用的系统特性确定了一个基本方法来对刚刚得到的功能点数进行修正，来获得修正后的功能点数，以此来反映系统的其他功能情况。怎么调整修正？我们后面再说！

其次，IFPUG 这么复杂，在确定复杂性的时候还需要知道每个功能类型的复杂程度才能判断功能点的计数情况，我软件项目早期要是能确定这些东西，软件项目还能有这么多变更？IFPUG 也没解决这个问题呀！

对！到目前为止，我们是没有针对这个问题有很好的解决方案。但是，是不是有一种可能性：基于这个模型，我们可以积累相关的数据，然后根据数据来估算新的软件项目情况？在有新的软件项目的时候，能够判断个大概？

最后，IFPUG 功能点估算比用户故事点估算麻烦这么多，最后还有这么多问题没解决，是不是反而把自己的工作搞复杂了？我用故事点估算的方法用得很好呀。迭代计划做完，大家评估好故事点，给客户或者老板一报就完事了。

不！功能点估算和故事点估算、用例点估算、代码行估算有本质的区别。像我上一篇文章说的：我们怎样 “度量” 软件开发？，功能点的方法是根据基本模型来确定软件的规模，模型确定好之后，是不以团队的能力，开发的环境改变的。这样的好处是，能够让非软件开发的专业人员也参与进来，方便专业的软件技术人员形成统一的认识！非专业人员不会因为没有技术背景，没法参与进软件规模的讨论中。

可能还会有人问：什么是功能点？

那，什么是 “米”（m）？什么是 “千米”（km）？

“米”（metre/meter，法 mètre）是国际单位制基本长度单位，符号为 m，一米等于 10 分米。可以用来衡量长、宽、高。

1 米=光在真空中于 1/299 792 458 秒的时间内所经过的路线的长度。

同样的，功能点也是衡量软件功能规模的基本单位，可以用来衡量软件的规模大小。ISO/IEC 14143 系列的标准是对功能点有明确的定义的。所以，从使用的角度来说，不必纠结功能点到底是什么。功能点，就是一种度量单位，它度量的是软件规模的大小，就够了。

在我们怎么 “度量” 软件开发？中，甲乙双方在针对人力资源管理系统的商务谈判时，都陷入到了自己的困境。

甲方的困境：

进行商务谈判时，无据可依，全凭专家经验。
无法识别合理性报价。
系统延续性强，商务谈判地位处于弱势。

乙方的困境：

公司报价缺少较为权威的依据支撑，难以帮助甲方完成预算申报。
面对新的业务领域，专家经验估算法偏差巨大，导致项目亏损。
需求模糊不清，为项目变更埋下隐患。

IFPUG 没能解决双方的困境，但至少，IFPUG 做到了第一步：把甲乙双方的商务谈判拉到了同一个尺度（功能点）下。甲乙双方讨论的功能点相对客观。不会像故事点一样，乙方团队的不同，同一个用户故事，评估出来的故事点不同。稍微，客观了一点。

后续，我们再进一步讨论，怎么解决双方的这个困境！源管理系统 ** 的商务谈判时，都陷入到了自己的困境。

甲方的困境：

进行商务谈判时，无据可依，全凭专家经验。
无法识别合理性报价。
系统延续性强，商务谈判地位处于弱势。

乙方的困境：

公司报价缺少较为权威的依据支撑，难以帮助甲方完成预算申报。
面对新的业务领域，专家经验估算法偏差巨大，导致项目亏损。
需求模糊不清，为项目变更埋下隐患。

后续，我们再进一步讨论，怎么解决双方的这个困境！

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

Sage_Xiong — Fri, 26 Apr 2024 12:45:10 +0800

没有度量就没有管理。

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

人力资源管理系统需求

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

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

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

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

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

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

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

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

接收到项目报价情况

在甲方经过一轮咨询之后，接触了 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 开发商的开发能力是不是不行？

面临的问题

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

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

甲方的困境

站住甲方的角度:

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

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

无法识别合理性报价。

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

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

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

乙方的困境

站在乙方的角度：

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

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

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

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

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

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

解决方案

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

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

ISO/IEC 19761（COSMIC_FFP 方法）
ISO/IEC 20926（IFPUG 方法）
ISO/IEC 20968（Mk II 方法）
ISO/IEC 24570（NESMA 方法）
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 模型考虑了模型的可扩展性，使用者可以根据自己环境因素的特点扩展模型。

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

萌新报道

Sage_Xiong — Mon, 08 Mar 2021 09:05:41 +0800

大家好，我叫风诰，现在还是一名在职的嵌入式软件工程师，最近陷入职业困扰，无意中在 B 站看到了关于社区的视频，才了解到原来还有这么一群厉害的人，希望在社群里可以和大家多多交流。我目前是以 C 语言为主要的开发语言，做的是物联网方向。前几个项目的主要技术都是涉及到 LoRa 或 NB-IoT 的低功耗无线网络传输技术。萌新初来乍到，还请各位大牛多多关照哟。