造价师/评估师培训: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、如果度量基线已确定,边界与分区就不要轻易改变。(北京软件造价评估技术创新联盟 罗翔)

相关新闻
 
关闭