功能点分析法的思考
在编制项目计划时，必须先对软件规模有个整体估计，然后再分配到各阶段、各类活动、各个明细任务中中，如果每个明细任务都可以在预期时间内完成，那么计划也就能如期完成，并且人力资源成本也被严格控制了。因此，在编制计划时，对项目整体上的规模估计非常重要。
根据互联网上的资料以及我的观察，国内主流的估算方法分为三类：主观估计法、代码行法及功能点分析法。Delphi法是主观估计的一种，只是因为有多个人员的参与并进行多轮估计，会使主观估计的结果趋于客观。scrum敏捷方法中，也存在类似的多人主观估计，通过“敏捷扑克”多人同时出牌，是一个很好的实践。
代码行法主要有以下几个问题：其一，不同编程语言的开发效率不等，一些工具自动生成了一些代码行，这样，实现相同的功能，所需代码行及时间可能大相径庭。其二，我国软件业的职业教育水平参差不齐，为了实现相同功能，不同编码人员采取的算法逻辑各不相同，最终输出的代码行数差距很大。其三，对于在现有代码基础上增加新功能的情况，可能新增代码只占少部分，更多的是修改原有代码，而被修改的代码行与工作量是否存在线性关系着实可疑。
假设为了实现一个功能模块X，程序员A写了1000行代码，花了2个星期；类似的功能模块Y，程序员B写了2000行代码，他需要花费4个星期吗？如果他们的工作经验近似，那么程序员B应该同样花费2个星期的时间。程序员B在实现每个功能点时，很少考虑复用，而是不断复制粘贴自己的代码，再进行修改，很快就完成了2000行代码，实现了模块功能。程序员A，则基本不复制粘贴代码，而是修改原有函数，通过函数复用来实现。（PS：一个真实的案例，某位同学在1个月时间内完成了6万行代码，并受到表彰。）
功能点分析法在理论模型上更适合软件开发的实际情况。在上面的例子中，通过估算模块X与模块Y所包含的功能点数，判断模块规模，再分发工作任务。不论最终输出的代码是1000行还是2000行，只要功能点数相同，则工作量相同，应在相同的工期内完成。
功能点分为数据功能与交易功能两大类。数据功能包括内部逻辑文件（ILF）与外部接口文件（EIF）两类；交易功能包括外部输入（EI）、外部输出（EO）、外部查询（EQ）三类。功能点分析法通过计数ILF、EIF、EI、EO、EQ的数量及复杂性，折算为对应功能点数，再根据每功能点的生产率数据，估算所需要的工作量。功能点分析法利用软件工作量与需求功能的线性关系估算工作量，这种关系不受开发人员编程风格（喜欢拷贝还是函数复用）、是否为系统升级改进等因素影响，较代码行法更为稳定可信。
谋求寻找工作量与需求功能之间的关系，这个想法并不非常新颖，“拍脑袋法”一般也不是毫无根据，更多的是根据需求功能的复杂与否、数量多寡来估计。功能点分析法的精髓在于对功能点的抽象，以较小的估算时间投入，达到在初期估算规模的目的。大中型系统的需求经常有变更，甚至在概要设计后，都有一定需求变更。在初期，需求更难以准确捕捉。因此，功能点分析法关注于容易在早期观察的两个层面：数据与应用边界。
内部逻辑文件（ILF）是一组用户可以识别的、存在内部关联的数据或控制信息。外部接口文件（EIF）是一组用户可以识别的、在本应用被引用的数据或控制信息。因为“用户可以识别”这一特性，决定了ILF、EIF在早期就可以发现。根据ILF与EIF相关的数据元素类型（DET）和记录元素类型（RET），确定ILF、EIF的复杂性，并估算其功能点数。
外部输入（EI）、外部输出（EO）、外部查询（EQ）关注的则是应用边界，即以从应用边界外向系统发送数据为目的的，是EI，反之则是EO或EQ。系统向应用边界外发送数据或者从应用边界外向系统发送数据，都是交易功能。在系统开发需求阶段，交易功能一般发现的不完整。但当需求规格说明书初步完成时，一般所有交易功能都能被发现。尽管在开发过程中，需求的描述将更将清晰，可能还会新增部分功能，但新增功能的同时可能会删除一部分功能。交易功能的功能点数总体规模还相对稳定。（假设还未开发）
在完成了数据功能、交易功能的功能点估算后，再应用调整因子进行调整，功能点估算法似乎已经非常完美了。但实际上，实际应用功能点估算法的案例并不占很大比例。功能点分析法在现阶段推广使用，也还有一些局限：
一、将需求功能点分解为数据功能与交易功能2个层面，分别统计功能点再累加，这种方法对于规模与风险适中的项目比较适合，对于极端情况则不太适用。例如，对于一个100人日以下的项目，开发代码时可以不遵循数据功能与交易功能分别实现的做法，直接在界面层面实现数据操作，一次实现了2个层面的功能点。这样，尽管“质量”不高，但实际上这样的项目，经常并不要求非常高的质量。因此，我们可以发现，小项目使用功能点分析法计算出来的工作量往往偏大。对于内部逻辑非常复杂的情况，用数据功能与交易功能2个层面来抽象，可能也不能涵盖其内部蕴含的复杂性（目前手头还缺乏数据实证）。
二、人日数与功能点之间的生产率缺乏历史数据。生产率受很多因素影响：行业特点、员工技能、质量要求等。即便在同一家公司，完成一个功能点的人日数也很难达到稳定。一般的，小项目的质量要求较低，完成一个功能点就比较快；互联网应用界面质量要求高，完成一个功能点较慢；大项目除了质量要求因素以外，为了消解技术风险，以全生命周期衡量的生产率也会较低。
要在一个实体中真正应用功能点分析法，还存在很多困难。
