造价师/评估师培训：010-82146681
联盟会员/机构评定：010-82146682
业务合作咨询：010-82586972
E-mail：bscea@bscea.org
功能点分析方法浅谈之边界与分区
点击：时间：2022-11-26
2022年4月，IFPUG发布了最新的白皮书《边界与分区》。
在功能点分析的方法中，在度量具体功能之前，一定要确定软件的边界（boundary）；在“非功能规模”度量的时候，则需要确定边界内的“分区”（partition）。
这些步骤很重要，对软件规模的“准确”度量很重要。但是，在实际的过程中，一些人往往有点简单粗暴。我也曾听到有“顾问”说过：要按照物理库来设置边界。
我们应该如何做正确的事呢？
1、不忘初心
看了这本白皮书，我最大的感觉是：IFPUG依然没忘初心——软件规模度量的本意是什么？
一开篇，文章就在强调：功能点分析的本意就是在规模度量中将业务和业务需求作为核心；要关注信息，关注功能（function）的重点（point），而不受技术的影响。正是这个“态度”，使得规模度量方法可一致、可重复，即：不同专家度量出相同的结果；而不受到商业的影响。
从1970年代末期，到现在的疫情时代。这40多年来，组织已经更换了很多轮“志愿者”，有些先驱已经离开了这个世界。但是，他们依然在坚持原则。
2、关键概念
2.1 目的
我们为什么要做软件度量？这一点直接影响了“计数范围”、“计数类型”以及边界与分区。
其一，无论是国内还是国外，最常见的“目的”还是与工作量（effort）有关系。
（1）项目结束后，核算一个软件应该“结算”多少工作量；
（2）项目开工前，估算软件需要多少开发工作量。
此外，国外有些组织还很关心“软件资产的多少”。他们会做产品级别（而非“项目级”）的规模度量。
在文章中，白皮书也做了总结：
对于IT（或计财）管理团队而言，他们普遍目的是：如何计算厂商（项目组）的工作量？如何付款（发奖金）？如何计算绩效？
对于业务团队，他们核心目的则是：要度量软件的价值和利益（benefits）。
这两个目的，本质是不矛盾的！因为：一定要通过功能的价值，来证明开发工作量的合理性。
2.2 边界
边界是指软件与用户之间概念上的“接口/界限”。
设置边界的原则就是：
• 要从“用户视角”来确定边界，关注点是用户能够理解、描述什么；
• 每个边界里的软件应用，代表着用户可以感知的独立的“功能域”；
• 不要受技术的影响；
• 不要受计数范围的影响；
• 可以参考一些相关资料：系统流程图、功能域、数据维护的方法，软件工作量、成本、缺陷的度量数据。
2.3 分区
“分区”是与非功能规模度量有关的概念。即：边界内拥有同类评估标准和价值的一组软件功能。一个软件应用的边界内可以有0-n个分区。
分区也是要坚持“用户视角”；要明确用户感知、理解的非功能需求是什么。例如，一类常见的非功能需求就是：边界内部的数据移动；首先，就是确定用户可以感知在边界内有几个分区？
2.3 用户
在CPM（即：功能点计数操作手册）里，对于用户的定义是：任何时候与软件发生通讯与交互的人或者事物。白皮书引用ISO 25010:2011的定义，对用户明确分类：
这里的“次级用户”，主要是包括：系统管理员、内容提供者、安全管理员、运维及系统分析员。
2.4 用户视角
用户视角是“功能需求”与“非功能需求”之和。
在国外的某些实践中，并不把系统管理员作为“用户”来看待，认为其功能不属于“用户视角”。但是系统管理员所拥有的功能是有价值的：缩短上市时间，降低维护成本，(直接或间接)提高主要用户满意度。所以，应该视为功能需求。
目前在国内，主要应用的还是功能规模度量，也有了相应的国家标准；而对于“非功能估摸”度量，还是在小范围内进行实践。国外的趋势则是在“混合度量”，即：同时度量功能与非功能规模。
3.挑战
软件度量的挑战，主要还是来自“技术”层面，来自软件行业的潮流转变——由原来的“整体”架构，转换为面向服务，到现在的“微服务”。软件被拆分成了更多的服务/组件，且是由多个厂商（项目组）来做不同的功能组件。
面对这种趋势，应该如何设置边界与分区？
软件度量一直面临着挑战。在1979年，功能点分析的方法发布之初，业界还没有图形（GUI）界面。这40多年，软件的在技术层面上有了多次颠覆式的创新。但是规模度量的方法依然没有本质的变化。
4、如何面对挑战
专家们给出的建议，来源于10多年前出版的CPM。即：根据度量目的来设置边界。
如果，“目的”是为了估算、结算供应商的工作量，或者是评估他们的生产率、缺陷密度。那么就是可以参考供应商的工作范围来设置边界。
文中举例：某个银行已有了传统的“柜面交易系统”，现在为了“数字化转型”，要新建一个移动端系统，用户可以在手机上查账、转账、付款等。即：国人都很熟悉的“手机银行”。这个例子也许从侧面说明了：国外移动应用的普及就是比中国落后。
传统的柜面系统由银行自有的IT团队开发，但是他们没有移动端的开发经验，所以决定将此部分招标。大致的思路如下：
• 与软件厂商签署功能点“单价合同”，即：按照厂商交付的功能点数量来付款；
• 按照缺陷密度来（缺陷数/功能点）计算罚金；
• 缺陷的计算期限：验收测试阶段以及上线后3个月内；
• 银行IT团队提出需求，做界面设计；
• 软件厂商负责：开发、测试、实施上线。
几个参与投标的厂商需要进行功能点分析，并估算工作量。也因此引出了问题：应该如何设置软件的边界？
有两个答案选项——
选项1：将“柜面”与“手机银行”设为两个边界。
选项2：将“柜面”与“手机银行”视为一个整体，包含在一个边界之内。理由是：手机银行一定要依赖柜面系统才能运行；其本身是不能独立运行的。
一般而言，（无论中外的咨询专家）都会推荐银行的IT管理团队选择第1个方案。其原因就是：如此可以更好地实现目的——管理开发厂商的付款与罚款。
那么选项2，也很有道理，是否也可以选择呢？
答案是：也可以如此选择，但是就是在两者之间设立“分区”，去度量非功能规模。
5、边界划分的建议
1、正名
就像是专业的BA，要给“需求”这个词前面增加一个“定语”，例如：业务需求、用户需求、软件需求等等。
对于“边界”这个词，也应该在前面增加一个描述“目的”的“定语”。例如：为了估算工作量的边界，为了测量资产的边界……
2、确保业务流程的完整性
边界划分，不应该影响业务流程的完整性、一致性。即：业务流程要尽量的“自包含”于边界内。
在识别“基本过程”（EP）的时候，我们要从业务的视角出来，并确定业务的连续性（此外，还要确定其：对用户有意义、完整、自包含，完成后系统进入稳定态）。在划分系统边界的时候，也应该如此。
3、根据计数目的来调整边界
例如：度量的目的与工作量有关，就是要考虑软件厂商的因素。
文中举例——NS软件厂商一直服务于某国的某大型电信公司，提供“计费系统”。由于技术的创新，NS将原来的系统进行了“重构”，并拆分为三个“独立”的系统：用量与评级、账单处理、应收与收款。功能上与原系统一致，但是他们使用了新的开发语言，非功能特性也有变化。
他们向客户提出了请求：按照三个系统来度量。
客户拒绝了此请求，理由是：1、功能上整体无变化；从资产管理角度上来讲，客户并没有新增资产。2、如果“划分为三”，则割裂了业务流程；3、不影响对厂商的工作量核算。
4、如果度量基线已确定，边界与分区就不要轻易改变。（北京软件造价评估技术创新联盟 罗翔）
在功能点分析的方法中，在度量具体功能之前，一定要确定软件的边界（boundary）；在“非功能规模”度量的时候，则需要确定边界内的“分区”（partition）。
这些步骤很重要，对软件规模的“准确”度量很重要。但是，在实际的过程中，一些人往往有点简单粗暴。我也曾听到有“顾问”说过：要按照物理库来设置边界。
我们应该如何做正确的事呢？
1、不忘初心
看了这本白皮书，我最大的感觉是：IFPUG依然没忘初心——软件规模度量的本意是什么？
一开篇，文章就在强调：功能点分析的本意就是在规模度量中将业务和业务需求作为核心；要关注信息，关注功能（function）的重点（point），而不受技术的影响。正是这个“态度”，使得规模度量方法可一致、可重复，即：不同专家度量出相同的结果；而不受到商业的影响。
从1970年代末期，到现在的疫情时代。这40多年来，组织已经更换了很多轮“志愿者”，有些先驱已经离开了这个世界。但是，他们依然在坚持原则。
2、关键概念
2.1 目的
我们为什么要做软件度量？这一点直接影响了“计数范围”、“计数类型”以及边界与分区。
其一，无论是国内还是国外，最常见的“目的”还是与工作量（effort）有关系。
（1）项目结束后，核算一个软件应该“结算”多少工作量；
（2）项目开工前，估算软件需要多少开发工作量。
此外，国外有些组织还很关心“软件资产的多少”。他们会做产品级别（而非“项目级”）的规模度量。
在文章中，白皮书也做了总结：
对于IT（或计财）管理团队而言，他们普遍目的是：如何计算厂商（项目组）的工作量？如何付款（发奖金）？如何计算绩效？
对于业务团队，他们核心目的则是：要度量软件的价值和利益（benefits）。
这两个目的，本质是不矛盾的！因为：一定要通过功能的价值，来证明开发工作量的合理性。
2.2 边界
边界是指软件与用户之间概念上的“接口/界限”。
设置边界的原则就是：
• 要从“用户视角”来确定边界，关注点是用户能够理解、描述什么；
• 每个边界里的软件应用，代表着用户可以感知的独立的“功能域”；
• 不要受技术的影响；
• 不要受计数范围的影响；
• 可以参考一些相关资料：系统流程图、功能域、数据维护的方法，软件工作量、成本、缺陷的度量数据。
2.3 分区
“分区”是与非功能规模度量有关的概念。即：边界内拥有同类评估标准和价值的一组软件功能。一个软件应用的边界内可以有0-n个分区。
分区也是要坚持“用户视角”；要明确用户感知、理解的非功能需求是什么。例如，一类常见的非功能需求就是：边界内部的数据移动；首先，就是确定用户可以感知在边界内有几个分区？
2.3 用户
在CPM（即：功能点计数操作手册）里，对于用户的定义是：任何时候与软件发生通讯与交互的人或者事物。白皮书引用ISO 25010:2011的定义，对用户明确分类：
2.4 用户视角
用户视角是“功能需求”与“非功能需求”之和。
在国外的某些实践中，并不把系统管理员作为“用户”来看待，认为其功能不属于“用户视角”。但是系统管理员所拥有的功能是有价值的：缩短上市时间，降低维护成本，(直接或间接)提高主要用户满意度。所以，应该视为功能需求。
目前在国内，主要应用的还是功能规模度量，也有了相应的国家标准；而对于“非功能估摸”度量，还是在小范围内进行实践。国外的趋势则是在“混合度量”，即：同时度量功能与非功能规模。
3.挑战
软件度量的挑战，主要还是来自“技术”层面，来自软件行业的潮流转变——由原来的“整体”架构，转换为面向服务，到现在的“微服务”。软件被拆分成了更多的服务/组件，且是由多个厂商（项目组）来做不同的功能组件。
面对这种趋势，应该如何设置边界与分区？
软件度量一直面临着挑战。在1979年，功能点分析的方法发布之初，业界还没有图形（GUI）界面。这40多年，软件的在技术层面上有了多次颠覆式的创新。但是规模度量的方法依然没有本质的变化。
4、如何面对挑战
专家们给出的建议，来源于10多年前出版的CPM。即：根据度量目的来设置边界。
如果，“目的”是为了估算、结算供应商的工作量，或者是评估他们的生产率、缺陷密度。那么就是可以参考供应商的工作范围来设置边界。
文中举例：某个银行已有了传统的“柜面交易系统”，现在为了“数字化转型”，要新建一个移动端系统，用户可以在手机上查账、转账、付款等。即：国人都很熟悉的“手机银行”。这个例子也许从侧面说明了：国外移动应用的普及就是比中国落后。
传统的柜面系统由银行自有的IT团队开发，但是他们没有移动端的开发经验，所以决定将此部分招标。大致的思路如下：
• 与软件厂商签署功能点“单价合同”，即：按照厂商交付的功能点数量来付款；
• 按照缺陷密度来（缺陷数/功能点）计算罚金；
• 缺陷的计算期限：验收测试阶段以及上线后3个月内；
• 银行IT团队提出需求，做界面设计；
• 软件厂商负责：开发、测试、实施上线。
几个参与投标的厂商需要进行功能点分析，并估算工作量。也因此引出了问题：应该如何设置软件的边界？
有两个答案选项——
选项1：将“柜面”与“手机银行”设为两个边界。
选项2：将“柜面”与“手机银行”视为一个整体，包含在一个边界之内。理由是：手机银行一定要依赖柜面系统才能运行；其本身是不能独立运行的。
一般而言，（无论中外的咨询专家）都会推荐银行的IT管理团队选择第1个方案。其原因就是：如此可以更好地实现目的——管理开发厂商的付款与罚款。
那么选项2，也很有道理，是否也可以选择呢？
答案是：也可以如此选择，但是就是在两者之间设立“分区”，去度量非功能规模。
5、边界划分的建议
1、正名
就像是专业的BA，要给“需求”这个词前面增加一个“定语”，例如：业务需求、用户需求、软件需求等等。
对于“边界”这个词，也应该在前面增加一个描述“目的”的“定语”。例如：为了估算工作量的边界，为了测量资产的边界……
2、确保业务流程的完整性
边界划分，不应该影响业务流程的完整性、一致性。即：业务流程要尽量的“自包含”于边界内。
在识别“基本过程”（EP）的时候，我们要从业务的视角出来，并确定业务的连续性（此外，还要确定其：对用户有意义、完整、自包含，完成后系统进入稳定态）。在划分系统边界的时候，也应该如此。
3、根据计数目的来调整边界
例如：度量的目的与工作量有关，就是要考虑软件厂商的因素。
文中举例——NS软件厂商一直服务于某国的某大型电信公司，提供“计费系统”。由于技术的创新，NS将原来的系统进行了“重构”，并拆分为三个“独立”的系统：用量与评级、账单处理、应收与收款。功能上与原系统一致，但是他们使用了新的开发语言，非功能特性也有变化。
他们向客户提出了请求：按照三个系统来度量。
客户拒绝了此请求，理由是：1、功能上整体无变化；从资产管理角度上来讲，客户并没有新增资产。2、如果“划分为三”，则割裂了业务流程；3、不影响对厂商的工作量核算。
4、如果度量基线已确定，边界与分区就不要轻易改变。（北京软件造价评估技术创新联盟 罗翔）
上一篇：需求标准化的建议与实践
下一篇：如何度量数据仓库
