(高清版)GBT 42566-2023 系统与软件工程　功能规模测量　MkII功能点分析方法

国家市场监督管理总局国家标准化管理委员会GB/T42566—2023 I 12规范性引用文件 13术语和定义 24缩略语 5 5 6 98特定场景的测量要求 9计算调整后规模(可选) 4111测量生产率及其他绩效 4212用MklⅡ功能点分析法估算工作量 附录A(规范性)技术复杂度调整 附录B(资料性)数据收集表格 附录C(资料性)本文件应用案例 IGB/T42566—2023本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。本文件修改采用ISO/IEC20968:2002《软件工程MklⅡ功能点分析计数实践指南》。本文件与ISO/IEC20968:2002相比做了下述结构调整：——增加了“第2章规范性引用文件”;——第3章对应ISO/IEC20968:2002的第10章；——增加了“第4章缩略语”;——第5章对应ISO/IEC20968:2002的第2章，以后章号条顺延；——7.4.2～7.4.9对应ISO/IEC20968:2002的4.4.1～4.4.8;——8.4对应ISO/IEC20968:2002的5.5;——10.2对应ISO/IEC20968:2002的7.1～7.5。本文件与ISO/IEC20968:2002的技术差异及其原因如下：——更改了第1章范围(见第1章),删除与本文件无关的内容，以适应我国标准化文件的应用和使用；———增加了规范性引用文件GB/T18491.1(见第3章),引用其术语，以方便本文件的理解和应用；章),确保术语与现行标准一致，增强功能规模测量标准之间的协调一致性；——增加了规则的概要描述(见第5章),以进一步描述规则的含义；——删除了ISO/IEC20968:2002的5.4,技术过时不适用；——删除了ISO/IEC20968:2002的第10章术语Albrecht1984、Enhancement、GeneralSystemCharacteristics、IFPUG,删除的内容不能达到成为术语的要求。本文件做了下列编辑性改动：—为与现有标准协调，将标准名称改为《系统与软件工程功能规模测量MkⅡ功能点分析方——在第5章增加了“注”;——在7.6增加了列项编号：a)～h);-—8.2的列项编号i)～vii)改为a)～g);——更改了附录A和附录B中的条号和条标题；——增加了附录C(资料性)“本文件应用案例”;——删除了ISO/IEC20968:2002的附录Ⅲ,因为本附录是参考文献，不符合我国标准起草规则。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由全国信息技术标准化技术委员会(SAC/TC28)提出并归口。本文件起草单位：上海宝信软件股份有限公司、中国电子技术标准化研究院、上海宝景信息技术发GB/T42566—2023网有限责任公司信息中心、浙江省电子信息产品检验研究院、山东省计算中心(国家超级计算济南中航天系统科学与工程研究院。ⅢGB/T42566—2023MklⅡ功能点分析方法是一种对信息处理应用程序进行量化分析和规模测量的方法，它量化用户提出的信息处理需求，以数字的形式表示软件产品的规模，适用于软件产品活动有关的性能测量和评估。在进行MklⅡ功能点分析的场合中，“信息处理需求”是指应用软件产品委托开发用户的功能需求集(不MkⅡ功能点分析方法由CharlesSymons在1991年出版的《软件的规模和评估：MkⅡ功能点分析》中定义，1985—1986年期间在KPMG内部开发并作为专有方法进行保护，现已公开。英国软件测量协会的测量实践委员会(MPC)目前是这个方法的解释机构，并负责该方法的持续开发。本文件的目的是制定使用MklⅡ功能点分析(FPA)的规则并提供MkⅡ功能点分析方法的标准。MklⅡ和IFPUG功能点分析方法之间的关系如下。a)这两种软件产品规模测量方法都很精细但又显著不同。主要的不同是具有更精细颗粒度的Mkll功能点分析是一个连续的测算，而IFPUG一旦达到阈值后组件规模就受限了，Mkll功能点分析方法旨在更好地反映包含大量数据的商业系统中间处理过程的复杂度。由于规模测量是基于逻辑事务和实体的，软件需求和功能详述通常在其中得以表现，因此MkⅡ功能规模的测量与开发实现软件的技术或方法无关。b)一般而言，这两个方法在400个功能点左右时给出大致相同的软件规模(对于个别软件项目来说，平均值可能相当分散)。对于更大规模的软件，MkⅡ功能点分析将会算出持续增长的、比IFPUG方法更高的规模值。c)对于某些应用(例如证券投资组合管理),这两个方法可以被认为是等同的。但是，如果用于最常见的性能测量和估算时，则倾向于使用同一种规模尺度，只在需要的时候使用一个显示平均关系的公式进行转换就可以了。1GB/T42566—2023系统与软件工程功能规模测量MkⅡ功能点分析方法整方法以及工作量估算方法。MklⅡ功能点分析方法是一种有助于测量过程效率和管理应用软件开发、增强或维护活动成本的方法。它独立于软件的技术特征测量软件产品——在软件开发过程的早期应用；本文件适用于任何从逻辑事务角度描述的软件应用程序的功能规模测量，其中每个逻辑事务包括输入、处理和输出部件。Mkll的测量规则适用于来自业务信息系统领域的应用软件，该领域每个逻辑事务处理部件主要负责数据的存储或检索。MkⅡ可能也适用于其他领域的软件，但需注意：其测量规则不考虑科学工程软件中常见的复杂算法的规模，也没有特别考虑实时性要求。其他领域也是有可能使用MklⅡ功能点分析方法的，但可能要对本文件中给出的规则进行扩展或作出新的解释。MkⅡ功能点分析方法可用于测量如下规模：——新应用程序或现有应用程序变更的需求规格或功能规格；是在线实施的。——比较内部和外部IT性能；——比较应用程序的质量和可靠性；——协助评估新项目的业务用例的成本和风险要素；——控制项目中的节奏或范围变化；——为团队成员分配工作任务；-—确定应用程序资产基础的规模；MkⅡ功能点分析独立于项目管理方法(如瀑布型、螺旋型、增量型等2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文2GB/T42566—2023软件测量功能规模测量第1部分：概念定义(ISO/IEC14143-1:1998,IDT)乘客预订。属性attribute3.53.63.73.8对现有应用程序的修改(对项目结束后已交付的用户功能进行添加，更改和删除)所产生的工作输3.93GB/T42566—2023影响程度degreeofinfluence;DI表示19个(或更多)技术复杂度调整中关于每个系数的影响的数字指标。开发development一个新的应用程序或基于现有应用程序进行独立增加的规范、构造、测试和交付。用于测量在项目完成后首次安装所开发的软件时，提供给最终用户的功能点计数。实体或数据实体类型entity(ordataentitytype)保存用户相关信息的基本事物。实体之间带有属性的关联本身也是一个实体。实体类型的子类型，继承了父类型的所有属性和关系，并可能有自身特有的其他属性和关系。功能规模测量的一种执行方式，用于测量从用户角度观察的、与商业应用相关的软件开发、增强和功能规模functionalsize通过功能用户需求进行量化而导出的软件规模。功能规模的量化过程。用户功能需求functionaluserrequirements描述软件在执行任务和提供服务时所做工作的用户需求子集。 4GB/T42566—20233.193.203.21MklⅡ功能点分析的基本功能部件，在业务上对用户有意义的最小完整信息处理单元，通过真实世3.223.24来处理和/或存储的。3.253.263.273.283.29一个将技术要求和质量要求对应用程序规模的影响纳入考虑的调整系数，使用该系数后将得出调5GB/T42566—2023整规模。3.30技术复杂度调整因子technicalcomplexityadjustmentfactors技术复杂度调整中要考虑的19个系数的集合。3.31技术需求technicalrequirements与用于软件开发、维护、支持和执行的技术以及环境相关的需求。3.32用户user在任何时刻与软件通信或交互的人或事物。4缩略语下列缩略语适用于本文件。C/S:客户端/服务器(Client/Server)CASE:计算机辅助软件工程(ComputerAidedSoftwareEngineering)DET:数据元素类型(DataElementType)FPA:功能点分析(FunctionPointAnalysis)GUI:图形用户界面(GraphicUserInterface)MkllFPA:MklⅡ功能点分析(MarkⅡFunctionPointAnalysis)MRA:多元回归分析(MultipleRegressionAnalysis)PC:个人计算机(PersonalComputer)SLOC:源代码行数(SourceLinesOfCode)TCA:技术复杂度调整(TechnicalComplexityAdjustment)TDI:总体影响程度(TotalDegreesofInfluence)5MkⅡ功能点分析方法的使用规则下面列举了MklⅡ功能点分析方法应使用的所有规则，规则的详细说明在第7章中给出。规则1:边界，功能规模的测量应发生在一定的边界之内：a)MkⅡ功能点分析用于测量应用程序中用户需求的功能规模，功能点测量发生在以功能点计数为目标的边界之内；b)这个由边界包围的应用软件或应用软件的一部分应是功能一致的主体，由一个或多个完整的逻辑事务类型组成(为便于阅读，下文中“类型”将被省略)。规则2:功能规模和逻辑事务，功能规模应由逻辑事务总体规模和发生变化的逻辑事务规模来确定：a)软件的功能规模是各个逻辑事务规模的总和，这些逻辑事务的输入和输出部件穿过封闭的6GB/T42566—2023个与这唯一的事件相关的自洽状态；逻辑事务也可由一个提取但并不改变应用信息的用户需求来触发；d)一个逻辑事务在测量应用软件规模时只能被计算一次，即使它可能被执行多次；b)处理部件的规模通过统计被逻辑事务引用的主实体类型的个数来确定，加上(如果引用了)系c)在一个实体模型内对非主实体类型的所有访问都被视引用一个单个实体，将这单个实体称之件中最多包含一次引用。规则4:逻辑事务的输入和输出部件，逻辑事务的输入和输出部件规模通过统计相关数据元素类型a)逻辑事务输入和输出的规模通过统计经由各部件穿过应用程序边界的数据元素类型的个数据元素类型是穿过应用程序边界输入或输出数据流的一部分。b)权重系数的工业平均参考值如下：输入权重是0.58(每个输入数据元素类型),处理权重是1.66(每个实体类型引用),输出权重是0.26(每个输出数据元素类型)。能点(根据GB/T42566—2023的方法得出)。本章的目的是总结Mkll功能点分析计数过程中从第1步到第6步的关键因素，附加的第7步到第8步用于确定最需要的绩效参数，可选的第9步到第11步考虑技术复杂度因子。相关规则见第6章和其他章节。应计入功能点分析结果中(见规则1)。功能需求通常在需求规格书和逻辑系统设计文档中建模，它们表达的是一个应用程序应该做什向熟悉系统运作的项目组成员以及数据实体模型的分析师了解相关信息对于计数也是极有价值的。7GB/T42566—2023对于一个新的大型开发项目，功能点计数的工作量通常占项目总工作量的0.2%～0.4%。MklⅡ功能点分析方法的功能规模测量计数过程见图1,具体阐述如下。(可选)开始4.识别和归类数据实体类型度调整系数TCA8.计算生产率和结束8GB/T42566—2023第1步确定计数的视角、目的和类型 第2步确定计数的边界事务。相关准则见7.2和7.3。第3步识别逻辑事务相关准则见7.4。第4步识别和归类数据实体类型相关准则见7.5。相关准则见7.5和7.6。第6步计算功能规模输入数据元素类型、引用的数据实体类型和输出数据元素类型的权重系数的业界平均参考值分We=1.669GB/T42566—2023第7步确定项目工作量确定项目的全部工作量和工期。更多指导见第10章。第8步计算生产率和其他绩效参数有关生产率和交付率的计算指导见第11章。第9步对影响程度进行评分本步骤是可选的。对每个技术复杂度调整的影响程度分别进行评估。更多指导按照附录A的规定执行。第10步计算技术复杂度调整本步骤是可选的。计算技术复杂度调整(TCA)。更多指导按照附录A的规定执行。第11步计算调整后规模和绩效参数本步骤是可选的。使用第10步中计算出来的TCA来计算调整后规模，再将调整后的规模来代替第8步计算公式中的功能规模(FS)进一步计算绩效参数(例如生产率和交付率)。附录B提供了数据收集表格用于辅助功能点计数。附录C则给出了MkⅡ规模测量过程的范例。7MkⅡ功能点计数的一般要求如规则1所定义，在开始Mkll功能点计数之前，第一个重要的步骤是确定应计数的应用程序的边边界的选择取决于计数的视角和目的。以下是三种常见的视角。——项目视角。为了确定所交付功能的规模，例如特定应用程序开发或增强型项目的“工作输出”,或特定应用程序维护或支持活动所支撑的功能。计数的目的是利用功能规模测量结果来评估项目开发生产率，或者估算开发项目工作量。在这种情况下，边界通过项目团队交付的或支持团队维护的功能范围来确定。——业务经理视角。为了确定支持特定商业功能领域的应用程序功能总规模，这些商业功能作为一个单元由业务经理管理。计数的目的是跟踪每年业务领域的自动化程度，或者评估业务经理团——企业视角。为了对企业进行资产评估而确定企业应用程序功能组合的规模。在此情况下，边界通过企业的整个应用程序功能组合来确定。识别不同视角的原因在于不同视角的MkⅡ功能点计数结果不能简单的累加计数，通常整体规模数值会小于各部分数值之和。示例1:一个商业领域的功能性需求分别在三个应用程序开发项目中开发。为了估算和测量三个独立的项目生产GB/T42566—2023责PC客户端应用，另一个负责主机服务器端应用。这两个项目的个项目中都要处理。如果要分别测量这两个子项目的规模，每个团队交付的全部功能会被各自单独计算。功能不被重复计算。7.2确定计数的边界一个应用程序的功能点计数边界取决于计数的视角、目的和使用类型。确定边界就确定了哪些功一旦确定应用程序的边界，即明确了软件和用户之间的概念边界线。来自于用户的输入数据穿越边界进入应用程序，输出数据离开应用程序穿越边界到达用户。在边界之内是被应用程序逻辑事务类—根据用户需求引起应用程序的一些部分改变状态；——让数据处理结果对用户可用。确定应用程序边界时，不应出现不完整的逻辑事务。任何逻辑事务都需要有穿越边界的来自用户图2是一个典型的来自于商业用户的应用程序边界的示例，包括了在线和批处理事务。应用程序边界应用程序边界在线事务用户生产环境提交任务报告在图2中，有一个在线事物更新了一个数据库。该事务涉及在终端上具有穿越应用边界的输入输在图2中，存在一个访问三个数据库的批处理事务，这个事务在生产环境中启动，在计算机操作员的控制下，生成一份发送给商业用户的报告。批处理事务来自于启动这个工作的操作员的输入，这个输入穿越了应用程序边界，输出的报告同样也穿越了应用程序边界，发送给用户。在图2中，应用程序边界之内有三个数据库。这些数据库是否被其他应用共享访问，创建、读取、更新或删除数据，对于该应用程序的功能点计数没有影响。从功能点计数目的来说，三个数据库中使用的实体数据类型在应用程序边界之内，它们被图2的两个事务所引用，在每个事务进行计数时，相关的实体引用应被计入。同一个数据库可能出现在多个应用程序的边界之内，是否计数的判断标准很简单，只要看数据是否被待计数应用程序的一个或多个逻辑事务引用。此外，一个逻辑事务一般只出现在一个应用程序中，除非同样的功能在多个应用程序中重复出现。7.3识别接口为实现特定的功能点计数而确定应用程序边界时，可能需要识别与其他应用程序的接口。按照共下面是两种接口类型：——数据文件(例如主数据记录、“事务”、信息字符串等),作为一个接口文件从一个应用程序共享给另一个应用程序；是一组逻辑事务的输入部分。例如一个命令文件(或流),或者银行终端取款，对将要处理它们的应用程序来说，是逻辑事务的输入部分。一个完整的逻辑事务包括输入、处理和输出组件，使得应用程序处于自洽状态。在上述第一种接口类型中，一个应用程序与其他应用程序共享文件。这两个应用程序，一个使得接口文件可访问(例如应用程序维护文件),另一个使用(例如读取)该接口文件，在各自边界内都要处理该文件。因此文件中的实体类型需要被每个应用程序的相关逻辑事务计入。在上述第二种接口类型中，数据从发起应用程序的逻辑事务输出部件(同样地从接收应用程序的逻辑事务输入部件)穿越公共应用程序边界。如同上述第一种接口类型，任何被传输的数据引用的实体类型都需要在发起和接收应用程序中计入，因为两者都要处理这些数据。这两种接口类型看起来像是相同逻辑需求的不同物理实现，在MklⅡ功能点计数中得到的结果也应相同，但是未必总是如此，这两种类型的接口也可能来自于不同的逻辑需求。下面给出了三个示例说明针对接口如何使用计数规则。在每个示例中假设每个处理接口的应用程序都需要独立测量规模。表格标题中的“DET”表示数据元素类型。表1规模测量示例应用程序事务输入DET数处理实体类型引用数输出DET数A订单录入2(订单，客户)1(错误提示/操作确认)B订单处理1(触发器)3(订单，客户，库存)10(订单概要信息)GB/T42566—2023表2规模测量示例应用程序事务输入DET数处理实体类型引用数输出DET数A订单录入2(订单.客户)1(错误提示/操作确认)A订单录入完成111B开始订单处理1(触发器)3(订单，客户，库存)10(订单概要信息)注：示例2给出了与示例1不同的计数方式。示例1中，应用程序A对应用程序B在处理周期内处理的任何指定应用程序事务输入DET数处理实体类型引用数输出DET数A订单录入2(订单，客户)1(错误提示等)十nB订单处理5(重新验证)3(订单，客户，库存)10(订单概要信息)表3中的十n代表的是与应用程序A和B在数据格式方面达成一致后，穿越边界输出的DET个数。如果这20个DET不需变更数据输入时的格式，能当做一个数据块使用，则计数为1。如果全部示例3与示例1、示例2是不同的，订单依次通过应用程序A和应用程序B进行处理，不需要额外a)从接口文件中读取输入：如果从接口文件中读取的信息需要确认，则需要把确认的输入算接口可访问或传输的DET个数；c)通过接口可访问或传输的文件包含的DET,此时DET会创建或引发更新一个或多个实体的操作，在发送和接收应用程序的相关逻辑事务中计入对这些数据实体的引用；GB/T42566—2023是准确地识别逻辑事务集。7.4有助于准确地识别逻辑事务，并对一些常见的计数情形进行解释说明。对有经验的Mkll功能点分析人员的测试结果表明，最常见的错误是忽略了识别系统的某些逻辑事务规模，从而低估了其规模。因此7.4关于区分逻辑事务的建议显得尤为重要。MklⅡ功能点分析人员宜了解在项目生存周期的早期，需求经常以一种概要的形式来表述，例如“系统应为任何熟悉GUI的人所用”。在这个阶段，这样的一个需求只能以技术复杂度调整来进行调节处理(此时不考虑用MklⅡ功能点方法进行规模测量)。内容，此时需求就可以使用MkⅡ功能点分析方法进行功能规模测量了。7.4.2逻辑事务的定义逻辑事务是由应用程序支持的最底层商业过程。每个逻辑事务都由三个元素组成：穿过应用程序这个定义说明：每个逻辑事务由一个唯一的外部相关事件或者一个信息请求触发，当全部处理完成后，使应用程序处于一个与触发事件相关的自洽状态。该说明需进一步解释，关键词见表4。表4逻辑事务说明关键词解释说明被触发每个逻辑事务由输入部分、相关处理和输出部分组成，处理和输出则由外界输入触发唯一的在功能点分析中，如果在每种情况下都会触发相同的处理集，那只关注唯一(忽略同内容和重复发生)的事件类型。即相同的获取和确认，引用相同的数据实体类型集、相同的格式和展示形式。因不同场景下输入值不同而导致的处理路径变化，不会被认为是产生了不同的逻辑事务类型。因此所有可能处理路径涉及的实体应在一个逻辑事务类型中计入相关事件人员对各种类型的信息感兴趣，有些信息来源于现实世界发生的事物，例如银行创建了新账户、电梯到达指定楼层、顾客在零售店为货物付款，或者电视节目进行商业广播。这些“相关事件”是应用程序需要处理的事件具有：—原子性，事件是不可分割的，不能被分解为两个或更多子事件，除非所描述的抽象(颗粒度)级别发生了变化，并且应用程序的目的和需求也发生了变化；—保持一致性和瞬时性，每个事件要么整个执行成功，要么执行失败，不存在部分执行成功：——可检查性，为了存储事件的信息，这个事件应可受观察，或者至少可以被观察者推测。在有些情况下，外部相关事件可能从逻辑事务输入方直接生成消息。在其他情况下，应用程序需要定期检查(如“轮询”)外部环境的状态来判断相关事件是否已经发生，进而生成一个输入消息。这个消息被视为逻辑事务输入方。这个轮询机制通常由外部事件触发，例如一定的时间间隔外部环境在应用程序边界之外的所有事物被看作是应用程序的外部环境。应用程序的所有用户以事件形式记录的所发生的情况和用户发出的信息获取请求都处于外部环境。值得庆幸的是，只有上述事件是为了功能点分析的目的而需要进行描述的。当然，为了建立应用程序的上下文场景，这些描述是绝对必要的GB/T42566—2023表4逻辑事务说明(续)关键词解释说明信息请求如上所述，人们希望存储并记录关于事件的信息。为了从应用程序获得已经存储的信息，用户会发出一个请求(通过外部环境的一个用户)。这会形成一个输入消息，触发一些处理和响应(输出),就像事件一样。单个的请求总是具有原子性的，且保证一致性的(根据定义，它们不引发状态变化),瞬时的、可检查的。因此信息请求(经常称为“查询”)提供了逻辑事务的一个关键源。它们与事件不一样，事件无论应用程序是否存在，总会发生；而信息请求是应用程序存在后才产生的全部完成逻辑事务的定义没有说明从接收输入消息到最后输出响应所经历的时间。这个时间可能是几微秒，也可能是几年(理论上)。总之，逻辑事务从监测到事件时开始，直到响应结果离开应用程序边界时才算是全部完成与唯一事件相关的自洽状态如上所述，事件被定义为瞬时发生的，逻辑事务被定义为记录了事件发生的事实。既然事件不能被分解，也不能部分发生，那么与之对应的逻辑事务也不能。如果存储在应用程序的信息保持正确一致，也即是自洽，那么一个事务在执行时将是整体成功或整体失败存储在应用程序中的信息项不应与其他信息项存在冲突，如果冲突情形的存在是由软件错误导致的，那么该应用程序就被认为“丧失了完整性”(但这种情况一般不能在进行功能点分析时发现)7.4.3CRUDL逻辑事务CRUDL逻辑事务是指创建(Create)、读取(Read)、更新(Update)、删除(Delete)、列举(List)。在已经存储了实体类型集合(例如商业对象集合)的应用程序中，涉及每个实体类型的处理形成了首次尝试列举应用程序的逻辑事务时，建议功能点分析人员至少列举CRUDL这5个事务类型——即便应用程序不一定需要全部这5个事务类型。后续分析一般会根据实体类型的生存历程揭示更多详细信息。特别是分析人员会发现使用单个更新事件模型是过于简单了。大多数商业实体类型展现了丰富的生存历程，每个实体的实例经历过各种GB/T42566—2023加入公司极简生命历程员工更新部分变更员工细节信息离开公司实际生命历程实际生命历程员工加入公司更新部分离开公司工作生涯分配到项目组中晋升可能获得晋升完成项目人事评价 选事务时，如果其他信息(例如事务响应时间、交易的容量或安全标准)是可以获得的，那么在事务目录以及相关定性的需求。GB/T42566—2023表5候选逻辑事务集目录事务集事务名称事件或请求响应时间容量1-维护客户信息T001增加客户信息事件120/天T002改变客户信息事件15/天T003删除客户信息事件15/天T004查询客户信息请求50/天T005列举客户信息请求<5/天2-维护账户信息TO10增加账户事件200/天当软件需求被完全详细地阐述时，事务目录将包含进行准确精细的MklⅡ功能点分析测量所需的全一个已经完成的事务目录示例见表6(其中，响应时间和容量只与技术复杂度调整计算有关)。表6已经完成的逻辑事务目录详表事务集事务名称事件或请求输入响应输出引用实体类型实体关系序号功能点响应时间容量1-维护客户信息To01增加客户信息事件成功/失败1客户1120/天T002改变客户信息事件成功/失败1客户115/天T003删除客户信息事件1成功/失败1客户115/天T004查询客户信息请求4客户账户详细信息客户账户250/天T005列举客户信息请求1客户信息列表客户1<5/天2-维护账户信息TO10增加账户事件成功/失败2客户账户2200/天7.4.5逻辑事务的三个元素每个逻辑事务由三个元素组成：输入、处理和输出。MklⅡ功能点分析对于这三个元素的功能规模制定了如下的基本假设：——输入元素的规模与得到专门处理的、组成事务输入方的DET个数成正比；——处理元素的规模与在逻辑事务过程中引用的数据实体类型(或实体)个数成正比；——输出元素的规模与得到专门处理的、组成事务输出方的DET个数成正比。MklⅡ功能点分析约定，作为最小的逻辑事务，应含有至少一个输入数据元素类型、一个输出数据元通过对组成软件应用(或项目)的逻辑事务目录的检查，能够获得三个基本的计数，即输入DET的总数、引用实体的总数、输出DET的总数。识别实体类型引用和DET的详细规则分别在7.5和7.6中——输入元素包括输入过程中获得和验证的数据，有来自于外部环境的相关事件，也有来自于其他应用程序输出的信息请求的参数；——处理元素包括信息的存储和取出，该信息描述了外部环境相关实体的状态；——输出元素包括传给外部环境信息的格式和展示。信息处理过程的这三种不同元素所提供的功能是不同的。因此，在MkⅡ功能点分析中，这三个元些功能的业界平均相关工作量一致，因此MklⅡ功能点规模提供了这些活动输出工作产品规模的业界平均测量值。7.4.6应用程序接口的逻辑事务如上所述，定义应用程序边界可以明确应用程序与外部环境和用户的接口。在考虑逻辑信息的输入和输出时，消息来源和目的地对于结果影响甚微，因为对于MklⅡ功能点分析而言，主要关注穿越应用程序边界的数据本身。一些外部用户可能是其他的应用程序，需要在此检查可能出现的各种情况，具体包括如下内容。a)与其他应用程序的程序接口两个应用程序互相操作，信息从一个应用程序传到另一个应用程序，见图4。用户图4两个应用程序间一个接口的示例在这个示例中，商业界发生的事件触发了应用程序的逻辑事件，导致此应用程序所保存的数据状态发生了变化，并对商业用户做出响应。作为此事务处理的结果，数据被写入了一个文件。这个文件后续将被第二个应用程序读取和处理。此处第二个应用程序是一个独立开发、维护和管理的软件，有其自身清楚的应用程序边界。事务完成后第一个应用程序处于一致状态，而与第二个应用程序提供的处理结果是成功或失败无关。第二个应用程序读取文件中的信息，并把其所含的记录作为输入信息流，每一个记录都形成了逻辑GB/T42566—2023可维护性最大化和支持成本最小化。且接收方应用程序会包括相应的处理并提供一个合适的输出作为响应。b)更新明显属于其他应用程序的文件常会有更多的更新(因此被视为属于第二个应用程序)。于与初始相关的所有处理都由第一个应用程序执行，所以第二个应用程序不需要执行输入验证。因团队。这是由于工作和责任的分工而出现的。在这种情况下，应用程序边界的概念可能与MkⅡ功能点c)应用程序边界的用户视角应用程序边界可以从多个不同的视角进行绘制。事务的构件可以通过检查穿越边界的输入和输出来识别，因此理解边界的本质对识别事务集有有着较大影响。考虑图5中客户端/服务器应用。商业商业用户网络文件访问程序主机数据库访问程序主机数据库本地拷贝在这个示例中，一台运行客户端程序的PC机为商业用户提供GUI前端，该程序可以访问驻留在本地文件服务器上的网络数据库。该数据库包含了普通用户数据的概要信息，更为详尽的数据存储在远程的主机数据库上。概要数据可以显示。如果用户想要更详细的信息，双击鼠标引发详细数据从远程主机上的主数据库上GB/T42566—2023释放出来。用户发起的所有更新导致网络上的使用两个数据库是为了优化响应时间。只存放概要数据的网络数据库容量很小，对于只需要概要务的响应时间就更长了。系统的商业用户视角见图6。商业商业用户网络文件访问程序主机服务器程序主机数据库访问程序主机数据库本地拷贝对于商业用户来说，并不关注数据的物理位置。用户输入数据，所需的响应显示在屏幕上。使用两个物理数据库是基于性能考虑所选择的一个技术解决方案。从用户角度看，只有一个逻辑数据库。在两个物理数据库中重复的实体类型被解释为一个逻辑实体类型。因为只存在一个包括了本地和主机数据库的边界，逻辑事务只在输入和输出穿越边界时被识别出来。相互作用的应用程序组件对于商业用户来说是不可见的，在PC和主机数据库进行消息传递中也无法识别逻辑事务。事务的示例见表7。表7事务示例序号事务名称事件或查询响应输出DET数引用实体类型引用实体类型数T001查询客户概要数据查询2显示概要数据5客户1T002查询客户详细信息查询2显示详细数据客户1但是还存在如下的一种情况：规模很有兴趣。即每个团队做多少?图7显示了PC客户端开发项目团队的视角。GB/T42566—2023客户端项目组客户端项目组网络文件主机接口商业用户本地拷贝图7PC客户端开发团队视角的边界在这个场景中用户是启动逻辑事务触发在网络文件服务器上数据处理的商业用户。如前所述，当用户双击鼠标，详细信息会通过主机服务从主机数据库中得到。从PC客户端团队视角，这是通过与主机应用的一个接口交互而达成的。PC客户端穿越系统边界输出一些数据，发送到主事务的示例见表8。表8事务示例序号事务名称事件或查询响应引用实体类型引用实体类型数T001查询客户概要数据查询2显示概要数据5客户1T002查询客户详细信息查询2向主机请求2客户系统2T003从主机接收详细数据事件显示用户详细信息系统1输出的DET数，该数也是触发事务输出方的一部分。此外，主机的响应被视为另一个逻辑事务的输入图8显示了主机项目团队的视角。PC客户端主机服务器程序主机数据库主机数据库访问程序主机数据库21GB/T42566—2023来自于PC客户端并且穿越应用程序接口(即边界)的输入由主机服务例程进行处理，主机服务例程可以访问主机数据库，并穿越应用程序边界将输出传回PC客户端。在MkⅡ功能点分析中，从项目团队的视角出发，PC客户端收到的每一个不同类型的消息都应看作是独立逻辑事务的输入方。相应地，会有处理(引用存储在主机数据库中的逻辑实体类型)和一个输出的消息(发回给PC客户端)。事务的示例见表9。表9事务示例序号事务名称事件或查询输入DET数响应输出DET数引用实体类型引用实体类型数查询客户详细信息查询2向个人计算机发送客户的详细信息客户1和主机上的文件的程序。这些程序可被未来多个项目应用，所以这个基础架构团队负责设计和构建可复用组件。图9显示了该项目基础架构团队的视角。架构项目组PC客户端用户网络文件访问程序本地拷贝主机服务器用户主机数据库主机数据库访问程序主机数据库图9基础架构团队视角的边界基础架构团队开发两个潜在可复用的程序。一个程序提供针对网络服务器上的本地概要数据的数在MkⅡ功能点分析中，从PC客户端团队和主机项目团队来看，这两个程序对于软件开发的编程语言而言只是扩展。同其他编程语言结构一样，它们是自底向上的组件，例如IF...THEN...ELSE、MOVE、READ..FILE、WRITE...RECORD、ADDATOB等。因此它们对于商业用户、PC客户端团队和主机应用项目团队来说都是不可见的。MklⅡ功能点分析通常不会将其作为应用功能计数到规模中。但是如果想要测量由基础架构团队开发的潜在可复用功能，也可以用MklⅡ功能点分析方法，只是应用时应特别注意。Mkl功能点分析是为商业应用领域的软件而设计的，将其应用在基础架构软件扩尤其注意，与PC客户端和主机组件相比，基础架构组件在确定应用程序边界颗粒度水平(或抽象22GB/T42566—2023程度)上更为精细。(相比商业用户视角，PC客户端和主机组件确定的边界抽象程度较为精细)同样地，应为每个不同的自底向上的组件集确定单独的边界，不应将完全不同的和无关的组件混合。这是因为用于描述一个组件结构的逻辑模型与描述另一个完全不同和无关的组件结构的逻辑模型不一样。任何相似之处都是偶然的，很容易导致未来的混乱。在描述不同的事物时，清楚地说明不同可以减少混淆。因此，在上述示例中，用于提供网络数据库访问的程序被封装在区域边界内，应与用于提供主机数据库访问的程序分开进行规模测量。前面的示例说明了用户视角的影响和对应用程序边界的相应理解：规模；——项目团队视角下的规模测量是对每个独立设计、开发和维护的应用程序分别进行测量，测量结果之和有时被称为交付的规模；——基础架构团队视角下的规模测量是对所有软件组件进行测量，这些软件组件扩展了由操作系上述三种测量都是根据其特有的结构在描述时使用不同的抽象和颗粒度级别得到的。在这些描述中使用的术语是不同的，因此每个测量宜保持自身特点，把它们加起来是几乎没有任何意义。当数据库管理和完整性功能代表了用户认可的商业需求，而不是技术或质量需求时，MkⅡ功能点规模就应包括它们。所以对于问题“应用程序用户是否特别要求将此功能作为商业需求的一部分?”如举例说明，软件应用程序通常期望数据是完整并且内部一致的。因此任何要求检查和维护数据库完整性和性能(例如数据库重建程序)的功能都被视为实现细节的隐性要求，在软件方案选择时通常会被加以考虑。这些功能一般作为操作环境的一部分来提供，由信息系统管理员来执行。它们不会作为独立的逻辑事务纳入Mkll功能点分析。但是，如果商业用户要求特定的功能来使得最终用户可以进行完整性检查，通过判断剩余可用空间百分比，来启动数据库重建过程，那么这样的功能应计为逻辑事务。两者的差别在于，在第二个示例中，逻辑事务应提供给商业用户可使用的接口，并且应与其他商业功能一样遵循相同的开发原则以适用于没有掌握特别信息系统知识、技能和工具的员工。如果应用程序提供“删除程序”或错误纠正工具，那么该功能应被测量。由操作环境自动提供的通用工具不应被计入。如果日志是为了保持应用程序完整性的必要部分，例如它提供了数据库备份和恢复程序成功执行的必要信息，通常认为这是商业问题的软件解决方案的隐性选择，不计入规模测量中。但是，如果这个日志是商业用户所要求的，作为一个额外的用户控制功能，例如提供给管理层定期判断事务处理的容量，那么它应被视为用户特定要求的功能，相关的任何逻辑事务需要被识别。GB/T42566—2023示例2:如果在上述事务中，用户特别说明审计日志需要显示所有处理过的如果与安全访问相关的逻辑事务由操作环境提供，不计入。额外分配给软件安全性需求(与逻辑事MklⅡ功能点分析关注的是软件功能规模测量的管理。规模测量排除了对于软件定性特征(例如性能)的考虑。这意味着Mkll功能点分析不关注响应速度、事务吞吐量等，而只关注逻辑事务。批处理程序是一个逻辑功能的物理实现，选择批处理模式一般是因为要处理诸如无需过多用户交互的大容量输入等事件。如果仅仅考虑逻辑模型，那么一个功能是通过批处理实现还是在线实现，与Mkll功能点分析无关。因此，对于批处理或在线实现的功能，采用相同的过程来识别逻辑事务和进行规模测量。批处理程序流程经常包括许多步骤，由不同的关联程序通过中间文件来实现，通常只有其中的部分程序会处理穿越逻辑应用程序边界的输入或输出。典型地，这些程序包括流程中第一个和最后一个程序，以及生成报告的程序。图10给出了一个批处理流程包括的程序步骤。序，以及生成报告的程序。图10给出了一个批处理流程包括的程序步骤。输入PI错误P4验证数据挂起文件VIP2挂起文件V2父子下一循环列表报告P3图10一个典型的批处理流程——文件整理的传递和管理在图10中，事件数据通过程序P1输入并确认。输入错误被打印程序P4输出。有效的事务数据在程序P2中排序，并与上次批处理执行中因为与主文件不匹配而挂起的事务数据合并。事务的排序文件由数据整理的程序P3读取；这个过程执行一个“父/子”更新来产生一个新版的主文件、一个汇报所有更新、插入和删除的列表和一个新版的用于执行下次批处理的挂起文件。在上述流程中，所有的逻辑事务类型数据穿越边界成为P1的输入。因此这个输入需要仔细分析来识别独立的逻辑事务。所有事务类型的输出穿越边界成为P3的列表和P4的错误报告。这两个报告需要仔细分析，因为输出可适当地归因于正确的逻辑事务。为了理解实体类型，对父子主文件进行检查和开展第三范式的数据分析。批处理流程具有关注少数逻辑事务(例如Insert_Master、Credit_Master、Debit_Master、DeleteMaster)的特征，但这些事务的处理量较大。虽然逻辑事务的处理组件分布在多个程序步骤中，但是典型的批处理的功能规模一般都较小。24GB/T42566—20237.4.9一些容易被忽视的事务在实践中，通常更新一个事务要求先获取一个事务。在验证了正确的事务已经被选择用于更新之务(在此情况下，软件规模只计一次)的不同之处，或者它的要求与正常读取不同，在这种情况下，它应计为区别于正常读取的一个独立的事务。入。一个事务可以继承先前事务的输入数据。在MkⅡ功能点分析中，逻辑事务被定义为使应用程序的数据内容保持一致的最低级别的业务流程。因此，尽管事务可能是导航式链接的，但如果连续的处理步骤使应用程序保持自身一致，那么每个步骤都被视为一个不同的逻辑事务。在MklⅡ功能点分析中导航不应计数。无论任何链接，对于任何一个事务，所有作为输入必需的同的独立事务，例如，考察创建订单的事务，可能需要执行库存查询，库存查询事务在逻辑上是独立唯一过程的独立逻辑事务。情况下，不同的人可能会使用不同的术语。结果可能是逻辑事务的目录会包含几个具有不同名称但处识别并解决此类情况是需求分析人员的职责，区分是多个事务还是具有多个名称的单一逻辑事务。应注意，MkⅡ功能点分析适用于测量功能性需求，而且详细的需求可能由不同的用户群体出于各自的个不同的用户组保留需求并根据不同用户组测量相示例1:25GB/T42566—2023示例2:7.4.9.4区分混合在单个物理实现中的逻辑需求在理解用户需求时常见的一个失误是问题的功能分解不够充分。在MkⅡ功能点分析中，功能规模测量对所有要求的逻辑事务的识别是非常敏感的。因此，在开发过程中进行需求测量时，要留意确保功能需求在第一时间就分解到用户所需要的最底层商业过程。 7.4.9.5可复用部件模块可能在多个应用程序或一个应用程序的多处地方使用，如何识别模块所代表的事务可能引发不确定性。一个逻辑事务可以由普通模块实现，例如获取客户的详细地址。这种重复不影响逻辑事务的规模。逻辑事务与物理实现没有直接关系，MkⅡ功能点分析关注逻辑视图，所以复用模块对于这个视图来说是“不可见的”。输入数据元素类型、引用的数据实体类型以及输出数据元素类型照常计数。此外，完整逻辑事务实现后可以在应用程序的多处使用。同样在这种情况下，事务只计数一次，而不考虑使用方式有多少种。若实现一个或多个逻辑事务的软件被用在多个应用程序中，则它的功能应在出现的应用程序中都得到计数(每个应用程序每个事务仅计数一次)。软件以这种方式复用并不影响功能规模测量，这种测量是对需求的测量。复用当然会影响工作量、工期和软件开发成本，但是这些影响一般都会低于不选择复用的情况。复用的收益会随着这部分开发者能力的提升而越发明显。测量规模的商业问题得到了有效解决也是完全合理的。26GB/T42566—20237.5识别实体类型7.5.1统计实体类型引用的基本规则在MklI功能点分析中，作为一种测量每个逻辑事务处理阶段规模的方法，宜统计处理过程中引用的主实体类型。果任何非主实体组件在逻辑事务中被引用(见7.5.3),系统实体也不计为主实体。在开始MklⅡ功能点分析之前，宜进行实体——关系分析或者关联数据分析以便生成应用程序实体7.5.2实体类型型保存关于实体类型的信息。示例：“员工”在人员系统中是一个实体类型。“员工的生日”是一个数据元素类型(DET)(员工的生日不是一个实如果开展了关联数据分析，得到一系列表的集合，那么每个表的主题就是一个实体类型(但不一定是主实体类型)。7.5.3区分主实体类型和非主实体类型其他的说明和提示可以帮助区分主实体类型和非主实体类型，见表10(表中条目之间没有先后次表10主实体和非主实体类型区别准则主实体非主实体属性的数量几个，取值变化频繁(例如数量)很少，例如只有代码、姓名和描述，取值很少变化经常发生发生次数可能经常变化，例如订单数量或系统中的付款永久固定，或很少变化所有权通常属于被计数的应用程序可能属于组织，被几个应用程序同时使用属性值变化的时间在一般系统操作时通常在系统运行以外的时间属性值变化的权限没有特别的权限，由普通系统用户执行系统管理员执行实体生存周期通常有许多阶段或状态通常只有“活动”或不存在，可能长期保持，当前属性得到维护27GB/T42566—2023在一个应用程序中，主实体和非主实体在整个应用范围内要进行分类，这个分类不会因为事务不同而改变。但是，一个应用程序的非主实体可能是另一个应用程序的主实体。例如，在一个维护银行账户的应户类型”就是一个非主实体。相反的，另一个市场分析的应用程序可能需要积累大量关于每个客户类型非主实体属性的允许值通常在“MasterTables”中维护，在确认很多类型的事务时通常被引用。作为一个MkⅡ功能点计数的简单规定，所有非主实体类型归并在“系统实体”中，系统实体在任意引用任意部分的非主实体类型组件的逻辑事务中被计数一次。系统实体不应因为CPM的其他规则而被认为是主实体。7.5.4子实体类型在一些情况下，有必要区分并单独统计子实体类型。一个子实体类型(或者子实体)是一个特别类型或主实体的变体，区分规则见表11。表11子实体类型区分规则实体类型子实体类型账户存款账户，储蓄账户员工永久，临时在涉及实体类型的事务中使用不同的处理逻辑时，应对子实体分别进行计数。酬不同),共计数为2。7.5.5回旋实体类型单或客户层次结构中，那么对于遍历该上下级的事务，计为2个实体引用，一个为初始引用，一个为循环7.5.6批处理系统中的逻辑实体MkIⅡ功能点分析关注逻辑实体类型的引用的计数，而不是物理文件。在批处理系统中应注意区分，在图10批处理系统示例中，事务流程包含了几个逻辑事务类型(例如创建、更新和删除),处理过程28GB/T42566—2023这个示例在处理过程中列举了几个物理文件，但是只有两个实体引用涉及到每个逻辑事务。当用MklⅡ功能点分析该系统时，检查物理文7.6识别输入和输出数据元素类型识别并统计输入和输出数据元素类型(DET)的一般规则如下。a)实例对应的类型把DET的组合(例如姓名和地址)计作是单个DET,除非有一个请求处理(例如确认)不同的部分(例如邮政编码),则分别统计单独执行的DET。把年/月/日等组成的日期计为一个DET,除非存在特别的处理流程需要将日期的几个部分分开。将继承输入的使用次数作为计数，继承输入是当一个DET输入后，存储在本地，并为两个或更多事务提供输入。如果应用程序要求输入DET提供缺省值，并显示给用户，以便用户接受或重写，那么如同普通数据输入，计1次。如果一个输入DET要求在输出时或在确认失败后再显示，那么作为输入和输出计2次。把所有要求的错误消息看成是“错误消息”元素类型的实例，计1次。操作系统或网络的错误消息当数据以数组形式展现，计数=列类型数×行类型数。如果用户想要显示连续12个月的付款信息，这可以表示为一个2列12行的数组，见表12。表12数组示例月份值4月10月11月29GB/T42566—2023计数为2列类型(月份和值)×1行类型(付款)=2,无论有多少行要添加，这个类型信息的计数都是2。表13数组值统计示例月份值总计1列类型(值)×1行类型(总计)=1,整个表的总计数就是-3。d)菜单以及事务启动当菜单仅用于导航目的时，不把菜单作为逻辑事务的一部分。MkⅡ功能点分析方法测量已提供用户信息处理功能。菜单结构仅允许用户在所提供的功能之间切换，它本身对任何信息处理功能没有数，此时应统计直接输入到事务的参数。一种类似的例外情况是，菜单选择直接启动事务，用于启动事务的数据包括选择、比较或允许范围的参数，这些均应计为输入DET。当事务“自动”开始，则应找到真正的触发事件。例如日期可能是一个有效的触发器。日期的变化，例如月末，是一个有效的外部事件，可以看作是应用程序的一个输入来触发此应用。它可计为一个输入DET。相似地，定期执行的事务也是由临时事件(日期或时间变化)启动。e)事务类型识别器时应计为一个DET。例如：一个应用程序有两个事务类型，每个事务类型的输入都由Customer_ID、Account_ID和Amout字段组成。除非识别到事务类型字段，否则应用程序无法确定这两个事务分别是credit_account或change_loan_limit。不统计自动出现在每个报告或屏幕上的标准页眉和页脚，例如版权信息。g)物理屏幕限制忽略物理屏幕的限制。例如许多应用程序的输出由需要跨多个物理屏幕的数据列表组成，需要分页、滚动才能看到全部输出。计数仍是显示的独立DET个数，忽略物理屏幕的数量。h)对输入/输出流中DET的处理粒度和独特性如果输入输出数据在一个包含多个DET的数据流中，那么输入或输出的DET可统计个数由如下逻辑来识别：1)如果逻辑事务将数据作为一个单独的DET处理，则不考虑数据流结构，应计为1个DET:输GB/T42566—2023入1个或输出1个。例如数据记录的归档，记录结构由许多DET组成，但是整个记录不存储2)如果逻辑事务在结构之内处理(确认或格式化)单个DET或一组DET,那么对每个不同处理的DET或DET组计为一个DET。i)不同形式的输入/输出当相同信息需要以不同形式展现在逻辑事务的输入或输出部分时，要谨慎使用MklⅡ功能点分析计数规则。下面是有关相同信息的不同展现形式的示例：——以不同的自然语言来输入和输出；——以黑白和彩色两种方式呈现输入和/或输出。在以上示例中信息都是相同的。因此，可能会解释为MkⅡ功能规模测量只计一种形式，却忽略了以其他形式表现的需求。但是Mkll功能点分析方法的既定目标是生成一个规模，这个规模适用于性能测量和与软件产品相关活动相关的估算。信息的不同展现形式要求软件提供更多的功能，因此忽略额外展现形式(例如以不同的语言展现)所关联的额外规模会产生不公正的低规模测量结果。下面是信息表达的不同展现形式的例子：1种情况。功能点规则通常是不计数的。此情形不适用于功能点分析。款增加排序打印。由于其他排序提供的信息相同，因此对于输出只计一个DET集合，对排序的控制计为一个输示例11:报告被格式化为132个字符的行长，有必要重新格式化为80个字符的行长。此时计数受变更影响的所GB/T42566—2023设备驱动。因为在应用程序层面没有发生任何变更，所以不统计任何新增的DET。如果设备驱动软件需要进行规模测8特定场景的测量要求8.1对图形用户界面计数8.1补充说明本手册第6章中MklⅡ功能点分析过程的第五步，对带有GUI的应用程序如何使用MkⅡ功能点分析提供了指导。8.1阐述了测量GUI应用程序的逻辑需求的规则，不是测量GUI软件环境本身。8.1.2基本原则MkIⅡ功能点分析的基础规则是测量逻辑需求，并不关注如何实现。一个GUI主要是为了方便使用而对逻辑功能需求采取的一种实现方案。因此原则上说GUI的使用不影响功能，也不改变需求规模的测量。功能点分析针对由GUI所表现的真正逻辑需求来计数。但是，由GUI环境提供的功能可能会让开发者实现没有明确要求的新增功能。例如，在非GUI情况下单个输入DET转换到GUI环境下，会再加上一个输入查询。计数时作为额外逻辑事务包括这样的额外查询是习惯的做法，即使用户没有明确的要求。一个GUI提供了人机交互的元素，表14表列举了一些元素。每个条目边上给出了所支持的交互的说明。本章的余下部分将说明这些元素如何进行计数。一些GUI控件并不支持针对已计数应用程序的任何逻辑功能，只用于帮助实现本章中提及的非功能性需求。这些控件不会被计数。各种元素通常的操作在下面总结。但是，新方法和新元素总是不断地由GUI工具提供，所以在计数和使用基本原则时，要仔细检查一个GUI元素列表。表14列举的GUI元素在用于测量应用规模时，需采用与基于字符界面的、批处理和其他非GUI实现中处理屏幕格式、打印布局等一样的方法。许多GUI元素装饰GUI环境本身的外观，增加易用性，不是应用功能，具体情况如下：——当测量一个应用程序的规模，范围需要限制在输入或显示业务信息的GUI元素中；——当一个GUI元素物理地代表了输入和输出，那么结合它们合适的事务分别统计输入和输出部分；——复选框和单选按钮可以在数组中使用，如果使用，就按第7章所定义的方法来计数。GB/T42566—2023表14GUI列表GUI元素计数领域复选框(不独占)输入/输出/非功能组合框(编辑框十下拉列表)见编辑框/下拉列表控制栏(比如一系列图标)见图标控制按钮(确定、取消，等等)非功能对话框输入/输出拖放控制见图标下拉/弹出列表框输出/输入/非功能编辑框(回车或显示框)输入/输出图标输入/输出/非功能菜单非功能非文本注释输入/输出单选按钮(独占)输入/输出屏幕热点非功能滚动条非功能文本框输入/输出屏幕可触摸区域见图标窗口控制(最小化、最大化、恢复，等等)非功能8.1说明逻辑事务中所使用的那些GUI元素的计数指南，因此仅仅属于非功能性特征部分的元素未列出。8.1.5复选框复选框见图11。区区左侧是一个复选框区这是另一个复选框这也是一个复选框图11GUI元素——复选框GB/T42566—2023复选框(CheckBox)允许数据输入或输出到一个有是或否答案的问题，比如“客户是不是有合法的--—对每一个为事务而输入业务数据的复选框计为一个输入DET;——对每一个为事务而输出业务数据的复选框计为一个输出DET;-—如果复选框用于作为应用展现形式，那么它就不计为任何事务的部分。组合框见图12。图12GUI元素——组合框一个组合框(ComboBox)是一个编辑框(EditBox)和一个下拉列表(DropDownList)的组合。每个部分都根据各自规则而独立地计数。对话框见图13。GB/T42566—2023[cunenllyHPLaseiJetHIDonusersupp\hpgiound[LPI2J](指定打印机HPLasesJetⅢIDon\usersupplhpground[LPT2]确定取消选项更多.网络.用纸图13GUI元素——对话框8.1.8下拉/弹出列表框下拉/弹出列表框见图14。左侧是一个列表框左侧是一个列表框列表来计数(但是仍然计1个输入DET);8.1.9编辑框编辑框见图15。GB/T42566—2023图15GUI元素——编辑或文本框编辑框(EditBox)的计数方法如下：——一个编辑框用于输入数据，一般与一个下拉列表(DropDownList)作为组合框联合使用，通过一个编辑框输入数据，在列表中选择和键入数据都被计为相应事务的输入数据；——包含业务数据的编辑框计为输出数据；——对每个输入或输出数据的文本框采用与一个非GUI应用相同的方法来统计DET。一个图标(Icon),或者通过拖拽来使用图标，可以给一个事务提供输入数据，比如拖拽数据到一个报告中。它也可以用来输出数据，比如一个图标的显示指示一个业务数据元素。它也可以用于属于非功能应用导航的形式。8.1.11非文本注释这个例子是声音信号、视频信号和文档的扫描输入。这可以用于输入和输出DET。常见地一个扫描的文档看作是一个单一的单元，计一个输入DET。——对于每个用于给事务输入数据的非文本注释(NonTextAnnotation),分析它的条目，把每个独立DET计为一个输入DET;——对于每个用于给事务输出数据的非文本注释，分析它的条目，把每个独立DET计为一个输8.1.12单选按钮单选按钮见图16。选项1图16单选按钮单选按钮(RadioButton)是独占式条目元素，对每个集合只有一个按钮可以被选择。它们可以给——对每个独占式单选按钮集合计为一个输入DET;——复选框和单选按钮以数组方式使用，以第7章中关于数组的计数规则来处理；——对每个单选按钮显示的框计为一个输出DET。GB/T42566—20238.1.13文本框文本框(TextBox)与编辑框(EditBox)采用相同的方法来计数。8.1.14非功能控件8.2应用组合的近似规模测量一般来说，所用的规模测量方法需与所采用视角的目的相匹配。测量一个组合的常见原因是观测维护和/或支持生产率，或者帮助对程序转换进行估算。在启动对应用组合进行规模测量之前，所需要的准确程度需要明确的确定。结果的准确程度可以说明(比如±10%、20%、50%)。重要性原则仍然适用。一个测量的成本可能超过所获信息的价值。在缺少同步更新的需求文档的情况下，对现有系统组合进行常规功能点计数，其所费成本会远高于有高质量同步更新的文档。注成本收益分析。另一个可以对不那么相似的情况处理的概算方法是CapersJones的逆推法。在他的出版物和其他文献描述了这个方法。这个方法依赖涉及系统的每个编程语言的源代码行数。代码行数的定义可以从多个源头获得。不少工具支持自动的源代码行数计算。这些结果可以有较宽的范围，依赖于设计和编获得最好的统计结果。对不少第四代语言来说，源代码行数没有意义。源代码行数可以利用由CaperJones和其他人开发的对照表转换成功能点一个更进一步的全功能点计算的替代方法使用了“采样推断法”,比逆推法更准确。在这个方法中有如下步骤：c)识别物理实现的已经准备好的可计数特征，这与功能规模存在适当的关系(比如源代码库的大d)对各功能区域的随机样例进行功能点计数(或者更好的是选择有代表性的样例);e)进行MRA来判断这些区域中已备好的可计数特征与相应的功能点计数之间的关系，以及关g)结果需要和MRA使用中的置信度一起公布。最后，另外一个全功能点计数的替代方法是利用下面相似的表格模式来估算功能，见表15。所有心应用的样例在本地得到。GB/T42566—2023表15全功能点计数过程/功能事务创建、更新查询删除sacsaca事务合计功能点(事务数量×各级别功能点取值)合计复杂度：s——简单，a——平均，c—复杂。各级别功能点取值：——创建、更新：当复杂度为s时功能点取值为4,当复杂度为a时功能点取值为12,当复杂度为c时功能点取值为20;—查询：当复杂度为s时功能点取值为3,当复杂度为a时功能点取值为10,当复杂度为c时功能点取值为17;——删除：仅存在复杂度为a的功能点取值为8。注：分类的选择和多种因素的全局考虑(各个类别的每个事务类型的平均功能点数)需要在本地环境中决定。8.3规模测量的变更受一个变更项目影响的输入、处理和输出功能也是这个项目的一部分，按其他任何功能相同的规则进行识别和列举。为了获得变更相关的总规模，只有新增功能的规则与普通规则不一样。对每个要求新增的逻辑事务，或者要变更的或者要删除的，识别所影响的输入DET、输出DET和实体引用。列举每个影响的构件为新增、修改和删除。测量一个现有应用的更改步骤如下：步骤1:分离逻辑功能识别要测量的变更项目的逻辑任务元素，然后识别涉及的逻辑事务。这些信息不会在需求文档中专门说明，分析者应从可获得的信息中把它们识别出来。事务—生成提醒信件1事务——生成政策日程表步骤2:识别并统计新逻辑事务GB/T42566—2023需要一个新事务。获取和更新地址的功能早已经在应用中开发，对这已经存在的事务，所有要加的只有一个输入类型步骤3:识别并统计不再要求的已有逻辑事务步骤4:识别受影响的现有逻辑事务如果事务的一个输入数据元素类型、一个输出数据元素类型或一个实体引用因为更改工作而变化了，那么这个事务就是被这个项目影响了。不管什么理由，变化包括任何输入DET,输出DET或实体打印地址的事务。修改位置或输入和输出的格式的需求看作是变更。即使输入或输出数据元素类型和实体类型引用的实际计数没有变化，任何业务规则的变化也视为变更。例如，如果一个输入数据元素类型的范围从100～499变到了500～999,业务要求对数据进行确这一步只为变更项目影响到的事务来开展。影响的部分。步骤6:计算更改和更改后软件的功能规模更改的功能规模计算见公式(2):式中：FSOC——变更工作的功能规模(也即是项目的工作输出);AF——新增的功能；DF——删除的功能。变更后的软件功能规模计算见公式(3):FSAC=FSBC+AFDF……(3)式中：FSAC——变更后的软件功能规模；FSBC——变更前的软件功能规模；GB/T42566—2023DF——删除的功能。步骤7(可选):判断技术复杂度调整(TCA)如果TCA在变更中也变化了，那么就有2个TCA参数了。旧TCA适用在删除的事务的功能规模。新TCA适用在新增和修改的事务的功能规模上。在绝大多数情况下TCA不受应用变更的影响。尤其注意，现在TCA不推荐作为MkⅡ功能点规模的部分。8.4应用程序包计数假设要处理的是由开发者买来的应用程序包，这个包在交付给用户前，进行裁剪、提高和补充的定制。本条关心应用程序包，例如垂直市场软件和非通用软件如电子表格、内存管理、通信包和操作系统功能等。在生存周期的每个阶段都有区分从应用还是从定制来开发功能的需要，不同的计数和基线要得到维护。较之于定制化开发，虽然在顾虑合同时要小心，但是通过在准确的可重复的计数上的一般观察，稍低程度的准确性经常是足够的，原因：第一，需求难于了解仔细；第二，应用的包构件规模是一个较不可靠的系统开发项目的近似规模指示器。在功能点计数的最早阶段往往也是应用程序包评估阶段。一个可能的方法是测量现成的应用程序包来和用户需求说明书的功能点计数的分解(事务的事务)做比较，这样可以反映由各类应用程序包实现的功能在总的功能中的比率，因此也可知道通过定制开发或者基础包改造所提供的功能比率。基于这一点，只包括与用户所要功能相关的功能点是必要的。应用程序包提供的功能列表经常罗列在用户指南的正文表格中。标记出哪些确信对应用户需求的功能可以帮助分析者抽出应用程序包(特别留意由应用程序包供应商提供的功能点计数，这些可能与基于用户需求的逻辑事务的功能点计数没有太多关系)。关于决定什么需要统计在内的原则对应用程序包来说与其他买来或复用的功能的原则是一样的。通用规则是统计那“选择的、可能修改的、集成的、测试的，或者由项目团队安装的”。与用户所需应用无关的应用程序包功能不计在功能点计数中。如下类别的构件能或者宜独立的测量：a)来自于应用程序包不需修改的事务；b)由项目团队创建的另外事务；c)应用程序包的修改(添加的、变化的和删除的);d)在整体应用测量上的净变化(增加或减少);e)来自于应用程序包要求删除的事务。交付用户方案的规模上述a)、b)、d)的规模之和减去e)的规模。软件开发项目的规模是上述b)、c)、e)的规模之和。一个基于应用程序包的系统维护的规模依赖于应用程序包构件支持的方式。例如，系统的部分比率是没有修改的，由第三方供应商维护，那么这部分系统就不应计在内部支持团队的工作规模中。最终用户报告生成器和查询工具带来进一步的考虑。这些工具的重要性日益增长，不应留在测量程序之外。测量这些工具的规模可以采用不同的方案，但是方案的选择是可被审计的，要对开发者(安装并支持工具)和最终用户都公平。理想的方法是统计由用户生成的或为用户生成的报