致力于提升研发企业的持续创新能力

第一阶段：需求结构化与功能点估算
一、课程简介
很多时候开发组和过程管理组都存在一个矛盾，就是开发组熟悉业务但不擅长方法，而过程组擅长方法而不熟悉业务。因此常常出现过程组为了自己的问题（估算，度量，绩效管理等）尝试让开发组学会和使用自己的方法工作，而开发组不愿意花自己的时间、用别人的方法解决别人的问题……
这一问题在整个开发过程中都存在，而在需求管理中尤为突出。因为需求管理实际上涉及到市场、销售（或业务部门）、售前、高层、开发、测试、支持……等众多角色，若每一种角色都基于自己的需要提出一种管理方法，那么企业的管理成本会非常之高。
本咨询包旨在介绍一种能贯穿整个研发过程中的需求管理方法，使得各种不同角色的需求能无缝地集成在一起。我们会看到如何在功能点思想的指导下，使需求管理变成开发团队的日常活动，其度量与采集工作也变得不再耗费工作量，摆脱“初期敷衍”“末期造假”的怪圈。
二、课程周期
 2天
三、受众人群
项目参与人员及产品经理，需求分析工程师等
四、课程大纲：
本阶段的核心收益
本阶段完成后，需求分析人员只需要按一种规则编写需求文档，就可以从中直接计数功能点。
详情包括：
1. 形成一个一线业务人员很容易编写的需求文档规则，满足此规则的文档可以无形之中直接提取功能点
2. 学习功能点的基本知识，以便固化规则
3. 学习规则中常见的问题，以避免错误
4. 学习如何从满足上述规则的文档中计数功能点
5. 学习需求发生变化时，如何自动同步需求文档和功能点计数
6. 前瞻性了解此文档如何直接指导开发、测试、维护工作，并最终进行度量分析

这一文档重结构不重形式（Word，在线Wiki，管理工具均可），实际上代表了整个研发团队对产品或项目需求结构的统一认识。
功能点第一步：用功能树表达需求边界与架构（1小时）
功能树是一种由大及小地勾勒系统功能边界的方法。
在此阶段，会在宏观上，借助子系统和模块的识别来避免大片功能的缺失。
为了便于一线人员理解，此处将暂时不涉及“功能点”的定义、分类等学术问题，而只使用大家熟悉的一线场景和术语。
现场演练：用WORD列出产品的子系统与模块
现场企业人员会首先使用一张大白纸尝试描述产品需求的大结构，即上述知识点中子系统和模块的级别。
在讨论、分析、问答并达成一致后，形成Word文档结构。

此处将完成功能树前两个级别的表达：
 功能树全貌
 功能树第一级：子系统（反应用户关系的场景）
 功能树第二级：模块（反应数据关系的场景）
 功能树第三极：业务数据（用户可以理解并识别的业务数据，ILF/EIF前身）
 功能树第四级：业务操作（用户可以理解并识别的业务操作，EI/EO/EQ前身）
功能点第二步：列出功能点计数项（4小时）
功能点计数项包括文件（ILF，EIF，可理解为业务实体或业务数据），交易（EI，EO，EQ，可理解为用例）两种。
在此阶段，会在微观上，借助精益需求建模方法（一种由UML的ER图和User Case图演进产生的新图形）。功能树是一种由大及小地勾勒系统功能边界的方法，可以有效避免这种情况。
现场演练：用ER图分析出产品中的实体（ILF和EIF，即业务数据）
现场企业人员会使用ER图列出业务数据，并利用其关系形成精益的（不多不少的）业务数据集合。
注：这些实体（业务数据）未来将演化为功能点中的ILF和EIF，且对应关系为1：1，但现在尚不需要对其进行深入了解。
现场演练：用精益需求建模法发现用例（将演化为EI/EO/EQ，即业务操作）
现场企业人员会使用用例图（扩展四色图+状态图中的某些元素）绘制单个模块内部的用例。
注：这些用例未来将演化为功能点中的EI，EO，EQ，且对应关系为1：1；但现在上不需要对其进行深入了解。
现场演练：将子系统/模块/实体/用例表达为树状结构
现场企业人员会使用Word的目录，将练习1～3中发现的不同级别的需求要素，表达为一个统一的四级树状结构。
此处重点是功能树三、四两个级别的表达：
 功能树全貌
 功能树第一级：子系统（反应用户关系的场景）
 功能树第二级：模块（反应数据关系的场景）
 功能树第三极：业务数据（用户可以理解并识别的业务数据，ILF/EIF前身）
 功能树第四级：业务操作（用户可以理解并识别的业务操作，EI/EO/EQ前身）
功能点第三步：功能点基本定义（1小时）
在功能树中识别并判断功能点的类型。
 功能点元素
 ILF内部逻辑文件
 EIF外部接口文件
 EI外部输入
 EQ外部查询
 EO外部输出
现场演练：从功能树中识别功能点（1）
识别基本的ILF，EIF，EI，EO，EQ
功能点第四步：功能点计数常见问题（0.5小时）
学习并避免功能点计数中常见的多估和漏估情况。
 容易漏估的功能点
 隐含操作
 查看所有
 查看详情
 删除
 小练习：容易漏估的功能点
 容易多估的功能点
 数据字段
 编码数据
 小练习：容易多估的功能点
 功能点快速识别口诀
现场演练：从功能树中识别功能点——检查漏估和多估（2）
识别可能漏估的的ILF，EIF，EI，EO，EQ
功能点第五步：功能点复杂度与复杂度调整因子（0.5小时）
了解IFPUG对复杂度、调整因子的设计与局限。
 复杂度（不建议应用的实践）
 文件复制度因子：RETs
 操作复杂度因子：FTRs, DETs
 复杂度对应表
 IFPUG复杂度调整因子（不建议应用的实践）
功能点第六步：应用调整因子（0.5小时）
了解IFPUG对复杂度、调整因子的设计与局限；了解现在应用最广的韩国政府的调整因子。
 IFPUG的14个应用调整因子（不建议应用的实践）
 韩国政府的调整因子（推荐）
早期/快速功能点：NESMA快速功能点方法（0.5小时）
学习以更快速但精度可接受的北欧快速功能点方法。
 “估计的功能点”方法  Estimated Function Point
 “指示性的功能点”方法 Indicative Function Point
注：国际标准中的4个功能点体系对第2～5步的定义都是相同或及其接近的，但由于第5～6步占据了80%以上的工作量而效果却不明显，因此NESMA给出了一个跳过5～6步但又保持相当高精度的方法；因此可以认为本培训主要是基于NESMA方法的。
功能点第七步：从功能点到工作量，工期（1小时）
 工作量估算
 “功能点耗时率”
 工期估算
 COCOMOII模型
现场演练：估算一个实际的项目的功能点规模，并预测其工作量、工期
注意：视企业在第一阶段后实践的情况，此练习很可能只有部分团队能完成。
本阶段的现场实践活动
除上述已经分阶段描述的“现场演练”外，还包括：
工作文档指导：团队文档点评与指导
讲师会对个别团队以往需求进行点评，并给出未来需要改进和调整的，以便团队在下一阶段咨询到来之前完成文档改造工作。
现场展示：使用火星人自动计数功能点
讲师会讲授如何把项目的Word文档导入火星人，自动计数功能点数量。
本阶段可能会提到但不详细讲解的内容
以下内容属于之后咨询和培训的内容，但为了便于企业理解，会在相应的点上提到。
为了清晰表达，按CMMI的级别进行了归类。实际应用时并不需要同步实施相应的CMMI活动，但若能同步进行，则可以事半功倍。

1. 功能点的项目级应用
a) 使用功能点度量进度（只能在迭代式开发，包括敏捷开发中使用）（CMMI2 MA）
b) 使用功能点度量质量（CMMI2 MA）
c) 基于功能点提升生产率和质量的工程方法
走到第1步，基本上可以满足CMMI2中度量分析过程域的需要。
2. 全过程的功能点方法
a) 功能点与UML中实体和用例的关系
b) 功能点与数据库表的关系
c) 功能点与敏捷开发中史诗故事与用户故事的关系
d) 功能点与编码的关系，由功能点派生类与函数，使用asp.net/Spring等MVC框架时对应关系尤佳
e) 功能点与测试用例的对应关系
f) 功能点与客户提交问题的关系
走到第2步，基本上可以满足CMMI3中很多工程类过程域的需要。
3. 组织级功能点应用
a) 从已有历史项目挖掘功能点数据（无需成型的Word文档，甚至无需任何文档）（CMMI3 OPD）
b) 用数据回归技术建立企业内部修正系数（CMMI3 OPD，CMMI4 OPP）
c) 基于建立企业的基准比对（Bechmarking）（CMMI3 OPD，CMMI4 OPP）
d) 基于基准比对方法进行计划（CMMI3 IPM）
e) 基于基准比对方法进行绩效管理（CMMI3 IPM，CMMI4 QPM）
f) 基于组织数据对过程性能的监控与改进（CMMI4 OPP，QPM，CMMI5 CAR）
走到第3步，基本上可以满足CMMI3和4中对组织级管理的绝大部分需求。