1、应用程序边界的识别规则大家一定要牢记，不能从技术角度去思考，必须从用户角度来定义；如果项目牵扯到多个系统，那么必须将这多个系统的边界全部描述清楚。图2 外贸订单系统用例图按不同功能点计算功能点估算分类功能点估算法将功能点分为以下5类： 1. ILF：Internal Logical File内部逻辑文件 2. EIF: External Interface File外部接口文件 3. EI: External Input外部输入 4. EO: External Output外部输出 5. EQ: External Inquiry外部查询其中，ILF和EIF属于数据类型的功能点，EI、EO、EQ
2、属于人机交互事务类型的功能点。 以外贸订单系统项目为例： 录入订单、修改订单、删除订单是EI； 查询订单是EO 统计订单是EQ 汇率查询转换系统为EIF 订单和客户是ILF识别功能点的重要原则ILF、EIF要与EI、EO、EQ分开计算。对ILF和EIF复杂度的计算可以简单理解为对数据库复杂度的计算。对EI、EO、EQ复杂度的计算可以理 解为对程序开发复杂度的计算。一般软件项目都是由数据和程序构成的，因此计算ILF、EIF和计算EI、EO、EQ之间没有任何关系。内部逻辑文件与外部接口文件ILF内部逻辑文件内部逻辑文件是指一组以用户角度识别的、在应用程序边界内且被维护的逻辑相关数据或控制信息。IL
3、F的主要目的是通过应用程序的一个或多个基本处理过程来维护数据。EIF外部接口文件外部接口文件是指一组在应用程序边界内被查询，但在其他应用程序中被维护的、以用户角度来识别的、逻辑上相关的数据。因此，一个应用程序中的EIF必然是 其他应用程序中的ILF。EIF的主要目的是为边界内的应用程序提供一个或多个通过基础操作过程来引用的一组数据或信息。 EIF所遵循的规则： 从用户角度出发识别的一组逻辑数据。 这组数据是在应用程序外部，并被应用程序引用的。 计算功能点的这个应用程序并不维护该EIF。 这组数据是作为另一个应用程序中的ILF被维护的。ILF和EIF的复杂性计算 ILF和EIF的复杂性是取决于R
4、ET（Record element type）和DET（Data element type）的数量。DET是一个以用户角度识别的、非重复的、有业务逻辑意义的字段。 DET计算的规则如下： 通过一个基本处理过程的执行，对ILF进行维护，或从ILF/EIF中返回一个特定的、用户可识别的、非重复的字段，那么每个这样的字段算一个DET。 例如：添加一个外贸订单时需要保存“订单号码、订单日期、地址、邮编”，那么对于ILF订单来说它的DET就是4个。 再如：保存订单时还会保存订单的明细。订单的明细往往作为一个子表进行保存，那么“订单号码”在主表和子表中都同时存在（主外键）。但以用户角度来识别时，存盘操作是
5、一个最小的单位，那么订单号码只能算做一个DET。 当两个应用程序维护和/或引用相同的ILF/EIF，但是每个应用程序分别维护/引用它们相应的DET时，这些DET在这两个应用程序的维护/引用中将单独计算。 例如，一个应用程序的两个“Elementary Process”基本处理过程都需要使用到“地址”的信息，地址信息又可以细分为“国家、城市、街道、邮编”。那么对于其中一个基本处理过程来说，它将整 个地址信息作为一个整体进行处理，只算一个DET；另外一个基本处理过程使用每个地址的详细信息，那么DET就是4个。 RET计算的规则如下： RET是指一个EIF/ILF中用户可以识别的DET的集合。如果把
6、DET简单理解为字段的话，那RET就可以简单理解为数据库中的表。RET在ILF /EIF中分为两种类型：可选的（Optional）和必选的（Mandatory）。计算RET的规则为以下两点： 在一个ILF/EIF中每一个可选或必选的集合都被计算为一个RET。 如果一个ILF/EIF没有子集合，则ILF/EIF被计算为一个RET。在外贸订单系统中添加一个订单时会保存“订单信息、客户的ID、部门的ID”。那么订单系统ILF中的RET为： 1. 订单信息（必选的） 2. 客户信息（必选的） 3. 部门信息（可选的） 因此ILF中RET的个数为3个。 ILF/EIF复杂度的矩阵如下：119个DET20
7、50个DET超过51个DET1个RET低中等25个RET高6个以上RET软件项目管理中的功能点估算法将功能点分为5类：ILF（Internal Logical File，内部逻辑文件）、EIF（External Interface File，外部接口文件）、EI（External Input，外部输入）、EO（External Output，外部输出）和EQ（External Inquiry，外部查询）。其中，ILF和EIF属于数据类型的功能点，EI、EO、EQ属于事务类型的功能点。EI、EO、EQ的比较 EI是处理来自应用程序边界外部的一组数据输入，它的主要目的是维护一个或多个ILF，以及/
8、或者更改系统的行为。 EO是输送数据到应用程序边界外部的过程。它的主要目的是通过逻辑处理过程向用户呈现信息。该处理过程必须包含至少一个数学公式或计算方法，或生成派生数据。一个EO也可以维护一个或多个ILF，并/或改变系统行为。 EQ是向应用程序边界外发送数据基本处理的过程。其主要目的是从ILF或EIF中通过恢复数据信息来向用户呈现。该处理逻辑不包括任何数学公式或计算方法，也不会生成任何派生数据。EQ不会维护任何一个ILF，也不会改变应用程序的系统行为。 EO和EQ的共同点是，其主要目的都是通过基本操作过程展现数据给用户。EI、EO、EQ的比较见下表。表1 EI、EO、EQ的主要目的目的EIEO
9、EQ改变应用程序的属性或行为主要目的次要目的不允许维护一个或多个ILF显示信息给用户表2 EI、EO、EQ的主要行为行为数学公式或计算被执行可以至少选择一次不可以至少一个ILF被修改至少一个ILF或EIF被引用可选必选数据被重新恢复派生数据被创建应用程序的行为或属性被修改准备或呈现信息到系统边界外接受进入系统边界内的数据的能力必须事务类型功能点的计算规则在IFPUG的定义中有一个重要的单词“Elementary Process”基本处理过程。该过程对用户来说是一个有意义的、最小的活动单位，并且是一个自包含的活动。功能点的分类，EI、EO、EQ的识别都 是基于“Elementary Proces
10、s”基本处理过程的。EI的计算规则 1. 从应用边界之外收到数据。 2. 如果进入系统边界内的数据不是一个改变系统行为的控制信息，那么至少一个ILF应该被改变。 3. 对于已识别的处理过程，至少满足下面三个条件之一。 该基本处理过程的逻辑与本应用系统中其它基本处理过程的逻辑不同。该基本处理过程应该具有唯一性。例如：不能存在两个完全一模一样的存盘操作。 在应用程序边界内，该基本处理过程所使用的这组数据应该与其他基本处理过程所使用的数据不同。 在应用程序边界内，基本处理过程所引用的ILF或EIF是不同于其它基本处理过程所引用的ILF或EIF。 EO和EQ通用计算规则 必须全部满足以下内容才能被视为
11、一个EO或EQ： 1. 从外部发送数据或控制信息到应用程序边界内。 2. 为了识别这个过程，以下三点必须满足一个： 该基本处理过程逻辑上必须是唯一的，该唯一性是指其在应用程序中与其他EO或EQ在逻辑性上保持唯一。 该基本处理过程所使用的数据应该是唯一的，该唯一性是指其在应用程序中与其他EO或EQ所使用的数据不同。 该基本处理过程所引用的ILF或EIF文件应该是唯一的，该唯一性是指其在应用程序中与其他EO或EQ所引用的ILF或EIF文件不同。 EO补充的计算规则 除了要满足上面的通用规则外，还要满足下面其中一条： 在基本操作过程中至少包含一个数学公式或计算方法 在基本操作过程中要产生派生数据 在
12、基本操作过程中至少要维护一个ILF 在基本操作过程中要改变系统的行为。 EQ补充的计算规则 基本操作过程从ILF或EIF中获取数据。 基本操作过程不能包含数学公式或计算方法。 基本操作过程不能生成派生数据 基本操作过程不能维护任何一个ILF 基本操作过程不能改变系统的行为 EI、EQ和EO的技术复杂性计算复杂性取决于FIRs和DETs的数量。FTR是被一个事物读取或维护的ILF，或者是被一个事物读取的EIF。 EI中识别FTR规则 每一个ILF应该算做一个FTR。 通过EI读取的每个ILF或EIF都应该计算为一个FTR。 既被EI维护又被读取的ILF仅计算为一个FTR。 EI中识别DET规则
13、在EI的过程中，以用户角度识别的、通过应用系统边界输入系统内部的非重复字段，应算作一个DET。 在EI的过程中，只要没有通过系统边界输入，即使它存在于系统内的一个ILF中，也不能算为一个DET。 例如，外贸订单系统中，订单的金额是被单价和数量自动计算的，那么金额是没有通过系统边界输入的，因此在EI操作中就不应该算做一个DET。 在应用程序的EI操作时，系统提示的错误信息或完成操作的信息，应该被分别计算为一个DET。 例如，在网站注册用户信息时，由于输入错误系统会显示提示信息，那么这些提示信息应该被逐个计算为一个DET。 再如，当EI操作完成时系统提示并显示出来的信息，应该被计算为一个DET。
14、在EI操作中，如果遇到主外键的字段，应该算作一个DET。 EO和EQ计算FTR的规则 1. 通用规则： 每个在EO/EQ处理过程中读取的ILF和EIF算一个FTR 2. EO额外的FTR计算规则 在EO处理过程中每个被维护的ILF算一个FTR 在EO处理过程中既被读取又被维护的ILF算一个FTR EO和EQ计算DET的通用规则 用户可识别的非重复字段，进入应用边界并指明处理什么、何时处理或处理方式，并且由EO/EQ返回或产生，那么这样的每个字段算一个DET。 例如，报表中的每个字段都是一个DET。 在应用边界内以用户角度识别的非重复字段算一个DET。 例如，在报表中起到解释或备注作用的文字信息
15、，不管是一个字、一个词或一段话，都当作一个DET。 再如，某种编号或日期，即使它被物理存储在不同字段中，但从用户角度看是一个整体的信息，因此被算作一个DET。 还有，在饼图中百分比和分类算作不同的DET。 在EO或EQ操作中，如果对系统进行输入或读取操作时，相同的字段只计算一个DET。 例如，在报表查询时，输入的字段在报表上也有显示，那么将算作同一个DET。 在应用程序的EO或EQ操作时，系统提示的错误信息或完成操作的信息，应该被计算为DET。 例如，用户查询一个列表时被拒绝，那么拒绝的提示信息就算为一个DET。 在EO或EQ操作中如果遇到主外键的字段，应该算作一个DET。 在EO或EQ过程中
16、，只要没有通过系统边界输入，就算它存在于系统内的一个ILF中，也不能算为一个DET。 例如，在公司发工资的时候，员工对应的状态信息被更新，但这个状态信息的更新是没有通过系统边界输入的，因此也不能算做一个DET。 页面的标题等类似信息不计算DET。 系统字段生成的记号不能被算作一个DET。 例如，页码、位置信息、时间、上一页和下一页等信息，都不能算作一个DET。EI复杂度计算矩阵14个DET515个DET多于16个DET01个FTR2个FTR大于2个FRTEO和EQ复杂度计算矩阵15个DET619个DET多于20个DET23个FTR多于4个FTR未调整前功能点对应矩阵EI、EO、EQ、ILF和E
17、IF技术复杂度对应的功能点如下表所示：一般34657ILF1015EIF用功能点估算法计算软件项目功能点时会用到调整因子（或称调整系数）。功能点的调整系数是通过通用系统特性及其影响程度来评定的，对每个常规系统特性的评估由其影响程度（DI）而定，分为05级： 0 毫无影响 1 偶然影响 2 适度影响 3 一般影响 4 重要影响 5 强烈影响 然后依次对以下14个系统常规特性进行打分，并带入以下计算公式算出功能点的调整因子。 Value Adjustment Factor=（ sum of （DI） * ） + 计算调整因子1. 数据通讯 数据通讯指的是应用程序直接与处理器通讯的程度。通常我们都是
18、通过某种通讯手段来实现在一个应用中所使用的数据或者控制信息。连接到本地控制器上的终端被认为是通讯设施，协议则指两个系统或设备之间进行通讯时使用的一种约定。所有的数据通讯链接都需要某种协议。0 应用程序是单纯的批处理或者PC stand-alone1应用程序是一种批处理过程，但是包含远程数据的录入或远程打印2应用程序是一种批处理过程，但是包含远程数据的录入和远程打印应用程序包括在线数据收集或者包括批处理或查询系统的远程处理的前端应用应用程序不单只是前端应用，但是仅支持一种远程处理通讯协议应用程序不单只是前端应用，还支持多于一种的远程处理通讯协议2. 分布式数据处理 分布式数据处理是应用在内部组件
19、之间传递信息的程度。这个特性是在应用边界内体现的。应用程序不支持组件之间的数据传输和处理功能应用程序为用户可能进行的处理准备数据（例如使用电子表格或者数据库等）应用程序所准备的数据是为了在系统另外一个组件上传输和处理，并非为终端用户所处理。分布式处理和数据传输是在线的，并且是单向的分布式处理和数据传输是在线的，并且是双向的由系统中最恰当的组件动态地执行处理功能3. 性能 性能是吞吐量、处理时间等指标对开发的影响。用户所提出的性能要求将直接影响到系统的设计、实施、安装和支持。用户没有提出性能方面的要求用户提出了性能和设计方面的要求，但不需要采取特定措施响应时间和吞吐量在系统峰值时是关键的，但是不
20、需要采取相应的CPU使用方面的特殊设计。处理的最后期限是在下一个工作日。在任何时候响应时间和吞吐量都是关键的，但是不需要采取相应的CPU使用方面的特殊设计。处理的完成期限比较严格。除了上面一项的要求外，由于对需求的要求比较严格，在设计阶段就要进行性能分析。除了上面一项的要求之外，在设计和实施阶段需要使用性能分析工具来判断性能要求的完成情况。4. 大业务量配置 大业务量配置是指计算机资源对应用开发的影响程度。大业务量的运行配置对设计有特殊要求，是必须考虑的一个系统特性。没有提出明确的运行方面的限制有运行方面的限制，但是不需要采取特别的措施以满足运行限制提出了一些安全和时间方面的限制应用程序的某些
21、部分对处理器有特定的要求提出的运行限制对应用的中央处理器或者专用处理器有特殊的要求除上面一项之外，还对应用的分布式组件提出了限制5. 事务处理率 事务处理率是业务交易处理速度对系统的设计、实施、安装和支持等的影响。预计不会出现周期性的高峰事务处理期预计会有周期性的高峰事务处理期（例如：每月、每季、每年）预计每周都会出现高峰事务处理期预计每天都会出现高峰事务处理期用户在应用程序需求或者服务级别协议中对事务率要求很高，因此必须在设计阶段进行性能分析。用户在应用程序需求或者服务级别协议中对事务率要求很高，因此必须进行性能分析并在设计、开发和安装阶段中使用到性能分析工具。6. 在线数据输入 在线数据输
22、入是指数据通过交互的方式输入系统的程度。系统中包括在线数据输入和控制信息功能。所有事务都是批处理的1%7%的事务是以交互式的方式进行数据录入8%15%的事务是以交互式的方式进行数据录入16%23%的事务是以交互式的方式进行数据录入24%30%的事务是以交互式的方式进行数据录入30%以上的事务是以交互式的方式进行数据录入7. 最终用户效率 最终用户效率是指对应用的人文因素及使用的便捷程度等的考虑程度。 如下功能设计是针对最终用户效率的： 页面导航 菜单 在线帮助或文档 光标自动跳转 可以滚动 在线远程打印 预定义的功能键 在线做批量提交任务 光标可以选取界面上的数据 用户使用大量反白显示、重点显
23、示、下划线或其他的标识 在线copy用户文档 鼠标拖动功能 弹出窗体 使用最少的界面完成某种商业功能 双语言支持（如果选择了这个就算4项） 语言支持（如果选择了这个就算6项） 以上的一个都不包括包括以上的13个包括以上的45个包括以上的6个或以上，但是没有用户对于效率的要求包括以上的6个或以上，对用户使用效率有较高要求，因而必须考虑用户方面的设计（例如，最少击键次数、尽可能提供默认值、模版的使用）包括以上的6个或以上，用户对效率的要求使得开发人员必须使用特定的工具和流程以判定用户对效率的要求已经被达成8. 在线更新 在线更新是指内部逻辑文件ILF被在线更新的程度。应用系统提供在线更新内部逻辑文
24、件的功能。没有在线更新包含13 个控制文件的在线更新。更新的流量低，恢复容易。包含对4 个以上控制文件的在线更新。包含对主要ILF 的更新。除了3 之外，在设计和实施中要考虑对数据丢失的防范。除了4 之外，大量的数据恢复工作要考虑成本因素，同时包含了高度自动化的恢复流程。9. 复杂处理 复杂处理描述了逻辑处理对应用开发的影响程度。它包含以下要素： 敏感控制（例如特殊的审核过程）和/或程序特定的安全处理 大量的逻辑处理 大量的数学处理 因为例外处理造成的需要重新处理的情况（例如，由TP中断、数据值缺少和验证失败导致的ATM事务） 多种可能的输入/输出造成的复杂处理 上面一个都不满足只满足一个只满
25、足两个满足三个满足四个都满足10. 可复用性 应用系统中的应用和代码经过特殊设计、开发和支持，可以在其他应用系统中复用。没有可复用的代码代码在应用之内复用应用中被其他用户复用的部分不足10%应用中被不止一个用户使用的部分超过10%应用遵从一种易于复用的方式被打包和文档化。用户在源代码级客户化该应用。应用按照一种易于复用的方式被打包和文档化。用户使用用户参数来对该应用进行客户化。11. 易安装性 易安装性指应用系统的转换和安装容易度对开发的影响程度。系统测试阶段提供了转换和安装计划/转换工具。用户对安装没有特定的要求用户对安装没有特定的要求，但有特定的安装环境要求用户提出了安装和转化的要求，转化/安装指南被经过测试提供给用户。但是转化的影响对该应用不重要。转化的影响对该应用来说是重要的。
