课程前言

需求拆分，功能点估算，基于功能点的计划，进度跟踪与控制，度量体系，度量工具

本课程在有限的时间内，让学员迅速体验基于功能点的计划、控制与度量的完整过程。

课程特色

1.世界唯一可以直接进行自动功能点估算的需求 -估算体系。

2.将功能点的应用从工作量、成本，扩展使用范围，至包含编码量、测试用例、测试与发布质量管理。

3.基于功能点的量化成熟度评估模型，实现结果驱动评估。

4.配套工具Ada Scope、Ada PPM。

课程时长

形式1：2天连续现场培训 适合以学习知识为目的的客户。

此课程的学员，需要参加《SEAi需求分析法》课程，或将两个课程合并讲授。

形式2：2天现场讲完主课+0.5天现场答疑 适合有体系建立、年度计划等实际需求的客户，中间可讲课上的知识、模板、工具带入真实工作。

形式3：2天现场讲完主课+0.5天+0.5天远程答疑 同上，但非北京本地的客户，或受疫情限制的北京客户。

课程受众及收益

针对参训学员，本课程会涉及到以下几种不同角色，并获取相应收益：

中级管理者（20～50下属），大项目经理、多个项目的经理或部门经理，主要负责部门绩效管理、团队建设。

基层管理者（1～5下属），小型团队的技术与任务负责人，负责排定微观计划，判断功能点的完成情况，填报跟踪表。

初级管理者（5～20下属），项目经理级别的负责人，主要负责团队内计划、任务分配、时间协调、跟踪并发现问题，控制进度。

核心开发与测试人员，理解功能点与代码、测试用例之间的关系，从而理解计划的制定依据、跟踪依据。

针对参训企业，若企业正在制定相关的估算、计划、考核体系，本课程有有以下相应收益：

7大核心度量项：功能点FP，工作量（标准人天）MD，工期，合理代码行数，合理测试用例数，合理测试缺陷数，合理发布缺陷数

流程：形成完整的需求分析、整体计划（立项、合同、年度计划）、迭代计划（2周~1个月）、度量的生命周期。

过程文档：《端到端敏捷开发流程（从需求、估算到度量）》

指南：《QAD量化敏捷开发电子书1.2》包括需求分析法、快速功能点法、度量、与敏捷开发的结合等内容

模板：整体估算《SEAi 估算模板 整体需求.xlsx》《SEAi 估算模板 整体估算项目级参数.xlsx》《SEAi 估算模板 整体估算结果.xlsx》迭代估算《SEAi 估算模板 整体估算结果.xlsx》《SEAi 估算模板 迭代需求.xlsx》

课程体系

1.学习和使用成本大大降低

a.学习：标准IFPUG课程的教学时间为5天 ，国内造价管理课程为2天 ，而本课程讲述相同内容所需的时间只有0.5天左右，其他时间在讲扩展应用。

b.使用：一般早期功能点估算需要总研发成本的1.5%左右，而结项时的度量又需要1.5%左右 ，对应成本为每年50万/100研发人员；所以多数企业即使能建立度量体系也无法长期执行。本课程的估算结果为SEAi

本课程讲师是美国SPR（生产力研究所，世界最大的度量咨询公司）授权的IFPUG标准功能点讲师。

本课程讲师是中国最早的造价估算标准《软件成本度量规范》的编写组组长。此标准由讲师在2008年左右的一个培训课程编写而成，而国内后续的北京市地标、工信部标准、国标、国军标均由此标准改写而成。

某全程应用功能点方法的银行，总研发人数2000人，其中有30人全职负责计数已经完成项目的功能点。

需求分析的副产品，分析完的需求可自动完成度量，借助模板工具几乎不花费时间（甚至比一般需求分析更快）；而度量也借助工具，几乎不花费时间且精度更高。

2.扩展了应用范围

a.传统功能点估算一般仅限于早期进行立项时的造价估算，成本高昂而用途单一。

b.本课程体系可用于逻辑代码行、测试用例数、测试缺陷数、发布缺陷数的预测和跟踪管理，从而拓展到全程；对于入口需求的标准化（SEAi需求分析法）更是将估算和度量向前推进到需求分析阶段。

3.与敏捷开发接轨

a.在敏捷开发大行其道的大背景下，所有估算与度量体系必须与之兼容，而不能让团队分别为了两个目的进行两次估算和度量，甚至两种不同目的的需求拆分。

b.在本课程的体系中，

i.使用SEAi需求中的层次，即“实体（ILF/EIF）”代替史诗故事，“行为（EI/EO/EQ）”代替用户故事，估算的同时顺便解决了用户故事拆分的难题。

ii.使用SEAi需求体系直接映射完成用户故事地图。

iii.使用敏捷功能点代替故事点（后者难以形成可横向比较的标准）。

iv.使用SEAi需求层次拆分微服务，速度提升几十倍且有固定、一致的模式。

v.每个迭代形成一轮度量数据，反思会以评估、改进这些数据为主，而不再聚焦于各种扯不清的管理问题。

课程形式

两种形式均要求现场分组为2~6组，每组5~8人，现场推选一个产品经理。此产品经理应现场能提供一个企业实际产品的需求（或1人年左右工作量的片段）。

实物教学形式

适合正在使用敏捷开发、看板，希望借助功能点作为敏捷辅助措施情况。

以80*60cm大白纸、粉色/蓝色/黄色纸片为主要载体，在桌上、墙上完成练习。

电子教学形式

适合希望课后立刻落地，形成以功能点基础的估算、度量、考核体系的情况。

每组至少携带一台电脑，在电脑上各自预装不同实际产品的需求（另需提前准备另一个需求文档给讲师作为讲解依据）。课上会使用此需求，将其改为讲师所用的模板，并使用与之对应的Word及Ada Scope估算工具完成估算。

课程特色

本课程的讲师是中国最早的功能点标准《软件成本定额规范》的编写者（2009年，由讲师的培训大纲改写而来）。在长达一年的标准编写过程中，80多家甲乙方企业参与其中，提出了很多当时悬而未决的问题。加之在之后Scrum、DevOps等敏捷开发逐渐流行起来，逐渐产生了更多的冲突。

本课程的讲师在此后的12年间持续研究这些问题，逐渐找到了答案，其中多数在世界范围内也是独一无二的 。

核心问题1：对入口需求文档要求

早在标准评审时就有甲方代表提出：需求文档写法各异，功能点所需计数的元素散落其中还多有遗漏；无论要求功能点计数人员去熟悉所有需求，还是要求所有需求编写人员来学习功能点，都是难以做到的事情。因此是否存在一种需求编写的方法或模板，只要要求需求人员按此编写需求，就能大大方便功能点的计数？

经过对IFPUG、NESMA、ISBSG、SPA、韩国标准组织（韩国标准是迄今为止世界上最完善的功能点标准，已上升到法律层级）的研究，均未提及这类方法。

解决：

讲师在之后持续对此问题关注，在2013年左右发明了第一个版本QUML（量化统一建模语言），可以在36~41分钟左右完成105功能点 的从需求沟通到拆分至EI、EO、EQ层面（其中需求沟通内容5分钟）。2017年的纯文字版本SEAi需求分析法诞生，时间进一步降低至10分钟左右（含5分钟需求沟通时间） 。

SEAi需求分析法有标准的文档目录结构，可以拷贝到Excel模板中自动计数。

本课程讲师是世界最大的度量组织，美国SPR生产力研究所的授权功能点讲师，为其翻译了全套400多页功能点课程PPT；也是ISBSG主席Peter Hill的亲传弟子，对国际功能点的最新进展有持续的关注。但上述问题的答案无论在网站、图书、文章中均未见讨论。

105功能点是一个典型的、拥有3个ILF的场景的功能点规模，按2018年国内生产率，大致对应4个人月工作量。

讲师在30分钟的演讲时长内，5分钟进行体系介绍，5分钟一个随机观众提出一个随时需求，5分钟完成实体和行为拆分（即ILF/EIF/EI/EO/EQ），5分钟从空白Excel现场做一个估算表（功能点数，工作量，COCOMO工期，代码行数，测试用例数，测试缺陷数，发布缺陷数），5分钟完成用户故事地图和2~3个迭代的MVP划分，5分钟回答问题。

至此，需求与功能点计数法完成了解耦。

在仅计算功能点技术时间时，SEAi在EI/EO/EQ精度的计数速度相当于9600功能点/人天，远超标准IFPUG200~400功能点/人天的计数速度，甚至超过数据库回归法（一种在项目完成时，利用数据库表粗略计算功能点的结算方法），达到了Capers Johns在2005年的设想。

核心问题2：对已经完成项目的功能点重新计数问题

在软件开发过程中，不可避免地会发生需求变更。因此在项目完成时进行结算、结项等活动，要评价项目的完成情况，则需要对实际完成的功能点重新计数。重新计数的成本非常高昂，某银行有2000研发人员，其中有30个测试人员常年全职负责已完成项目的功能点技术，成本高达1000多万，占研发的1.5%。

实际上，出于避免此高昂成本的目的，多数行业和企业数据中所用的生产率公式都是 计划功能点/实际人天，而非 实际功能点/实际人天。

解决：

讲师凭借多年的研发经验，发明了MVC反射法（适合Web前后端系统和原生态移动端）、Swagger提取法（适合只有后端的系统），可瞬间完成对已经完成开发代码的功能点计数，成本接近为零。在特定环境中若存在偏差，则只需要对此类型应用建立人工计数对比，之后用自动计数+修正机制即可快速计数。

此外还提出了AFP敏捷功能点的计算公式，即AFP=行为*5.4（此处的行为可以理解为接口），这使得在研发环境中计算实际功能点数变得更加容易 ，甚至可以做到自动化。

核心问题3：与敏捷开发的兼容性

功能点诞生于1979年，简化于1994~2004年左右，在中国出现标准则是2009年。此后敏捷开发逐渐开始流行，因此也引发了功能点与用户故事体系的矛盾与融合问题。问题集中在：功能点计数项（ILF/EIF/EI/EO/EQ）与用户故事（史诗故事，用户故事）是否可以融合？两者前后关系是什么（一般用户故事要在迭代前才能获得，而功能点则在立项时就需要）？若融合后，那些不直接来自需求的用户故事如何处理？

解决：

讲师凭借敏捷开发的实践和授课经验，在SEAi需求分析法中创立了更容易被研发人员接受的命名体系， 包括Entity实体 = ILF/EIF ≈ 史诗故事，行为 = EI/EO/EQ ≈ 用户故事，而将与需求无关的事物统称为Task任务（不在SEAi范围内），从而将两者完美融合。在多达200多场次的敏捷开发培训中，有超过1500个团队在练习中使用了这种方法对自己的产品需求进行了分解。

核心问题4：性价比问题（全程使用问题）

若完整应用功能点，前前后后可能要增加3%的研发成本，而其作用不过是前面计算一下工作量和成本，后期再做一个结算，中间一无用处。在没有功能点的时候这些事情也不是不能做，是否值得为此大费周章？

  借助广泛使用的Swagger等工具，可以自动获取接口的数量（相当于EI/EO/EQ），但却无从获知实体的数量（相当于ILF/EIF）。传统功能点方法的所有计数公式中，都需要ILF/EIF，大大限制了自动计数功能。

解决：

形成完整的QAD量化敏捷开发体系（此内容另有《QAD量化敏捷开发 企业级敏捷转型框架》课程跟省里），包括：

1.管理扩展

a.计划

i.使用SEAi需求分析法，在需求获取时就考虑到功能点。按功能点结构和层次和语言来组织需求，要比随意写的需求更快，而一旦完成，就可以用Excel表自动计数。

ii.在立项早期，使用早期功能点估算公式FP=实体*35进行整体估算。

估算范围从工作量、工期，拓展到合理代码行数，合理测试用例数、测试缺陷数、发布缺陷数。

iii.在迭代计划，使用中期功能点估算公式FP=行为*5.4进行迭代估算。

估算范围同上。

b.跟踪

i.在迭代反思会上，统计上述估算数据的实际结果，进行反思。

将原来Scrum只反思“行为、文化”导致无从下手，改为对“结果”的反思，从而可以立刻找到改善编码、测试、质量的措施。

ii.在制定MVP和用户故事地图时时，使用场景作为第一层，实体（ILF/EIF）作为第二层，行为（EI/EO/EQ）作为第三层，通过上下挪动行为形成

iii.在DevOpsBan上，使用行为（EI/EO/EQ）作为工作项，直观查看到功能的进展。

iv.在评价敏捷项目时，使用实际的生产率、缺陷密度、编码消耗率，而非与敏捷过程的符合度。

2.技术扩展

a.设计/编码时

i.划分微服务时，将微服务归类为场景微服务（若干个实体聚合）、实体（ILF）微服务（1实体=1微服务）、行为（EI/EO/EQ）微服务中（增改删=1微服务，查=1微服务）的一种，在SEAi需求就位时可以在1小时内完成10人年产品的划分与讨论。

ii.用编码消耗率（逻辑代码行数/功能点，业界中值27）控制代码量，代码量越少越好。

iii.简单设计：实体（ILF/EIF）=数据库表/业务类/controller，行为（EI/EO/EQ）=接口/独立功能页面

b.测试时，

i.用测试密度（测试用例数/功能点，业界中值1.2）控制测试密度，不同类型产品取值不同。

ii.用测试缺陷密度（测试缺陷数/功能点，业界中值0.28）控制测试质量。

iii.用发布缺陷密度（发布缺陷数/功能点，业界中值0.014）控制发布质量。

iv.用发测比（发布缺陷密度/测试缺陷密度）来评价测试效果。

零散问题（解决中）

1.多端开发问题：在功能点创生时没有考虑到只有后端、有多个前端的问题

2.维护型调整因子校准问题：是否所有维护都可以按标准公式

悬而未决问题

1.边界问题：若可以任意划分边界，则在边界处会多出很多EI/EO/EQ，以及EIF，从而增加功能点数。在微服务中此问题尤为突出，其功能点数可能比正常数法高出数倍。边界问题是未来影响功能点可用性的关键问题。潜在答案：

a.使用规模调整因子（韩国标准有，国内标准普遍没有）

b.废弃EIF的概念，但保留调用所需的EI/EO/EQ（讲师推荐）

课程大纲

预热：什么是功能点和功能点计数项（0.5H）

简单介绍课程目标、功能点的背景知识等等。

学员尽量按实际团队或业务领域分为4~5个小组，每组有自己的需求（实际产品需求，供拆分功能点练习使用）。

功能点的最基本概念

NESMA功能点定义

ILF内部逻辑文件与EIF外部接口文件

EI外部输入，EO外部输出，EQ外部查询

功能点在完整的QAD量化敏捷开发中的位置

第一步：准备需求文档（5H）

第一类文档：已经由业务部门写成的现成文档/客户有规定模板的需求

此类文档的编写者由于没有经过功能点的培训，因此其文档中不存在功能点计数项的清晰条目，还存在大量从字面上看不到的功能点。因此需要对其进行标记、分析后方可计数。

课堂练习：在自己的需求文档中，标识实体（ILF、EIF），并计算早期规模（Indicative Function Point）。在天然的文档中，行为（EI、EO、EQ）遗漏率太高，识别并补充的技巧，需要在下一练习中才能学到。

第二类文档：需求尚未写成，因此可以按功能点从头编写的文档

特色内容：在实践与教学过程中，讲师发明了一种全新的需求分析法“SEAi需求分析法”，用这种方法可以在写需求的时候就顺便完成功能点的拆分工作，通过简单工具甚至可以自动计算功能点数，是普通功能点计数法速度的20~5000倍左右。此方法还可以把需求遗漏率从30~70%降低到5%左右（初学可至15%左右）。

本章节将使用讲师的“SEAi需求结构”的简化版本，在极短的时间内，即可将Word或人类语言拆分并表达为前三层，其第二层就是ILF和EIF（统称为实体），第三层则是EI、EO、EQ（统称为行为），因此可直接用于计算功能点。

课堂练习：1. 将大型需求拆分为场景；2. 在每个场景描述中识别实体（ILF、EIF）；3. 用CRUD方法发现潜在的行为（EI、EO、EQ）；4. 计算中期规模（Estimated Function Point）。

第二步：功能点估算（2.5H）

课程特色：本课程讲师是世界最大度量咨询美国SPR（生产力研究所）授权的国际标准功能点讲师，也是中国《软件成本定额规范》（成文于2009年，是工信部、北京市标准、国标、国军标的共同前身）编写组组长。国内所有标准所采纳的NESMA体系产生于2003~2004年左右，因此在出现移动开发、敏捷开发后，某些内容已经不适用。以下内容将在标准之外扩展了一些近10年来才出现的新技术如多端开发，以及如何识别和避免标准中存在问题的调整因子如开发语言调整因子。

功能点的历史及定义变化

IFPUG功能点定义五种计数项

复杂的调整因子定义（本课程中弃用）

NESMA两级简化体系

Indicative Function Point

Estimated Function Point

AFP简化体系

Agile Function Point

调整因子

软件因素调整因子

应用类型调整因子

规模调整因子

变更调整因子

二次开发调整因子

维护调整因子

多端开发调整因子

开发因素调整因子

团队经验因子

语言类型因子

实际使用中因子的选择

课堂练习：1. 使用功能点定义重新理解并修订之前的需求拆分；2. 将大型需求拆分为场景；3. 使用调整因子对功能点总量进行调整；4. 使用自动工具从三层需求结构中直接计算功能点     

第三步：造价估算及其标准（2.5H）

课程特色：本课程讲师是中国《软件成本定额规范》的编写组组长，之后所有国内标准如工信部、北京市标准、国标、国军标均从此标准演化而来。在早期探讨国内标准取舍、优化时，不但继承并发扬了国外的已有标准，也遗留了一些尚未解决的问题。以下内容不仅解释了各种计算公式的依据，也增加了对标准不完善之处的处理。

此外讲师还增加了与研发息息相关的编码、测试估算值，从而使得功能点不再是费时费力而功能单一的技术。

中国的功能点发展历史及标准历史

初期功能点的引入

中国标准时代

行业协会标准：《软件成本低额规范》

北京市地方标准

工信部标准

国标

国军标

其他主要参考体系

韩国标准

澳大利亚Southern Scope

标准估算过程

功能点定义

估算的三个时机

功能点计数

调整因子计算

派生计算项

工作量（标准人天）

成本（不同标准中有两种不同的计算策略）

开发成本计算

总成本计算

工期

讲师增补的数值：

逻辑代码行数，代码混沌指数

测试用例数，测试缺陷数，发布缺陷数

基准比对与五点估算

课堂练习：估算工具与实战I

SEAi需求模板（整体需求部分）

此模板是一种格式化的Word文档，使用特定的符号系统包含了功能点的各种要素。只要在其中编写需求（或将其中的标记符号应用于企业自身的需求文档），即可供相应的工具完成自动化计数。

课堂练习（二选一）：

1.将之前的需求以特定格式填写在模板中

2.在企业自身的需求文档中引入SEAi脚本符号系统

Ada Scope软件

此软件使用简化的功能点计算过程（兼容各种国内标准），可直接读取SEAi需求模板中的功能点符号，通过设定不同的调整因子数值，自动完成计算。

计算结果包括：原始功能点，调整因子，调整后功能点，工作量，成本，代码行数，测试用例数，测试缺陷数，发布缺陷数。

课堂练习：

1.计算一个较大型项目的功能点及派生数据

第四步：基于功能点的计划，跟踪，度量，评估（1H）

整体计划

整体计划包括项目早期的立项、合同等计划。也包括了敏捷开发的整体计划。

新产品开发的功能点计划

二次开发功能点的计算

其他功能点不覆盖的工作量（如数据导入等）

其他估算与计划方法

数学方法（代码行法、类比法）

非数学方法（专家估算法）

迭代计划

课程特色：本课程讲师还是活跃的敏捷开发培训师（场次高达200多次，包括100场金融客户、50场电信客户），根据NESMA的NFP简化公式，讲师推导出了“敏捷功能点AFP”的简化形式，用以取代故事点作为敏捷开发的计划和度量单位；并使用相关的度量项跟踪迭代的进行情况。

迭代计划中使用功能点

使用SEAi需求条目代替用户故事

直接从SEAi条目数计算功能点

维护类任务功能点计算

其他估算方法

故事点

鸡蛋估算法，T恤估算法

迭代跟踪，度量，评估

迭代跟踪产品的进度

量化地跟踪产品的内在质量

使用迭代开发+功能点度量来跟踪，可以有效防止虚假进度。

内在质量的持续跟踪

可以防止在项目结束时发生质量问题而导致看似顺利的进程受阻。

整体跟踪，度量，评估

课程特色：此扩展内容建立了基于功能点的项目评估体系，整体包括6项核心指标，利用基准比对Benchmarking方法进行跨团队/部门/企业/行业的横向对比。

整体跟踪发生在项目完成，或大型里程碑（必须是迭代式而非瀑布式里程碑）处，对计划的执行情况进行评估。

实际完成功能点数据的快速/自动收集

数据库表法，界面计数法，函数反射法，接口反射法

核心指标度量与评估

生产率FP/人天，成本RMB/FP，编码消耗率LLOC/FP

测试密度TC/FP，测试缺陷密度TD/FP，发布缺陷密度RD/FP

QAMMI量化敏捷成熟度模型

基于功能点+Benchmarking的横向比较

课堂练习：估算工具与实战II

SEAi需求模板（迭代需求部分）

SEAi模板中可分批次完成需求，并在不同批次中引入需求的维护、变更、删除等标识，以供迭代开发、维护型项目使用。

课堂练习（二选一）：

1.将之前的需求切分为3个迭代

2.选择适当的需求，将其标识为增强、废弃，模拟正常开发中的可能情况

Ada Scope软件

此软件可读取需求文档中的迭代计划，并计算出单个迭代的对应功能点和相关派生数据。

计算结果包括：原始功能点，调整因子，调整后功能点，工作量，成本，代码行数，测试用例数，测试缺陷数，发布缺陷数。

课堂练习：

1.计算上述文档中的一个迭代

其他：功能点的扩展应用（详见各个模块的时间）在两天课程中，以下内容会被压缩至0.5~1小时，只做介绍；有要求的除外

课程特色：本课程将功能点应用从报价，扩展到研发管理的全程，从而使得功能点不再是只有管理层关注的数据。

QAC量化敏捷编码（量化敏捷重构）（1H仅培训）

以下方法并非“重构”特有，对高标准要求的新项目一样适用。

基于功能点的重构决策

基于功能点的重构计划

重构团队人力模型

基于功能点的重构跟踪

重构案例分享

潜在练习：此处可对一个实际的正将、正在重构的项目进行练习

QAT量化敏捷测试（1H仅培训）

基于功能点的测试密度计划 TC/FP

基于功能点的测试密度度量

归一化测试密度 RD/FP

基于4个100%的自动化测试策略

潜在练习：此处可现场采集各个项目的度量数据，并按行业计算数据的合理性

QAM量化敏捷度量/绩效管理（0.5H仅培训）

拓展的度量项

技术相关：CCI代码混沌指数

测试相关：测试覆盖率，测试频率，测试效率自动化率

发布相关：发布频率，发测比，线上缺陷次率

基于功能点的敏捷团队绩效管理

与业界基线的比较

基于功能点的个人绩效管理