软件流程和管理（六）：Cost Estimation
目录
1. 成本估算的重要性和所涉及的挑战
1.1 什么决定了项目成本？
1.2 什么是 software cost estimation 软件成本估算？
1.3 成本估算方面的挑战
1.3.1 可能的解决方案
1.3.2 估算 —— 发展历史
2. 用于成本估算的技术
2.1 成本估算的技术
2.1.1 专家的判断
2.1.2 通过 Analogy 类比进行估算
2.1.3 Parkinson’s Law 帕金森定律
2.1.4 为赢而定价 Pricing to win
2.1.5 Algorithmic cost modelling 算法成本建模
3. Software size estimation 软件规模估算技术
3.1 Software Size Estimation 软件规模估算
3.2 Source Lines of Code 代码行数 (SLOC)
3.3 Function Points 功能点(FP)
4. 敏捷软件开发生命周期中使用的成本估算技术
4.1 敏捷工作估算
4.2 敏捷估算过程
4.3 敏捷估算指南
4.4 敏捷估算技术
4.4.1 Planning Poker
4.4.2 BUCKET SYSTEM
4.4.3 Relative Mass Valuation
4.5 计算速度 Velocity
4.6 估计 Delivery Time 交付时间
4.7 关于估算的最后评论
5. Function Points 功能点(FP)
5.1 Software Requirements 软件需求
5.2 FP计算步骤
5.3 Categorize requirements - 步骤1
5.4 为每个类别或功能估计一个复杂性值 - 步骤2
5.5 Compute count total from Complexity - 步骤3
5.6 Compute value adjustment factors - 步骤4
5.7 Compute total function point - 步骤5
6. Function Points的优缺点
1. 成本估算的重要性和所涉及的挑战
1.1 什么决定了项目成本？
- 工作量 Effort
- 硬件成本 Hardware Cost
- 差旅费用 Travel Expenses
- 培训费用 Training Cost
- 沟通成本和其他成本因素 Communication Cost and other Cost Factors
1.2 什么是 software cost estimation 软件成本估算？
什么是 estimation 估算？
- 是指找到一个估计值或近似值的过程，这是一个可以用于某种目的的数值，即使 input data may be incomplete, uncertain, or unstable 输入的数据可能不完整、不确定或不稳定。
什么是 software cost estimation 软件成本估算？
- 估算建立一个特定的基于软件的系统或产品需要多少 money, effort, resources, and time 资金、精力、资源和时间。
为什么软件成本估算很重要？
- 你会在不知道你要花多少钱的情况下建造一栋房子吗？—— 当然不会。
- 由于大多数软件系统的建设成本比一栋大房子要高得多，所以在开始创建软件之前进行估算似乎是合理的。
1.3 成本估算方面的挑战
- 成本估计没有精确的科学 —— 它永远不会被认为是完全准确的
- 没有人能够合理地预测项目中可能出现的问题。
- 大多数估算方法都假定事情会按预期进行，并简单地增加一些松动，以考虑到可能出错的情况。
1.3.1 可能的解决方案
- Delay estimation 延迟估计——在项目结束时有100%的准确性，但用处不大!
- 根据以前已经完成的项目的数据进行估算
- 将系统分解成较小的部分，并为较小的部分生成估算，这比较容易。
- 使用 empirically-based 基于经验的估算方法
1.3.2 估算 —— 发展历史
2003
- 通过专家意见进行的工作量估计被认为是整个IT行业使用最多的方法。
- 成本和进度超支非常普遍（30-40%），而且估计的准确性被项目经理认为是一个问题。
2013-2014
- 基于专家的估算方法在敏捷方法论中仍然很受欢迎（2013[5]，2014[6]）。
2017
- 71%的组织采用了敏捷方法
- 9.7%的投资因项目表现不佳而损失
- 许多项目的完成时间超过了最初预定的时间（49%）和预算（43%）。
- 成本和任务时间估计不准确，在失败原因中排名靠前（28%和26%）。
2. 用于成本估算的技术
2.1 成本估算的技术
2.1.1 专家的判断
- 几位专家对所提议的软件开发技术和应用领域进行了项目成本估算。 然后对这些进行讨论、比较和调整，直到达成共识。
- 一些专家判断技术涉及独立轮询每个专家，在某些情况下进行三个估计：
- pessimistic estimate 悲观估计 (p)
- optimistic estimate 乐观估计 (o)
- most likely estimate 最可能估计 (m)
- Delphi technique：
- 要求几位专家使用他们希望的任何方法对工作量进行单独判断。
- 然后，计算出平均工作量，并提交给所有的专家。
- 然后，每个专家都有机会修改他们的估计，在某些情况下，要在所有专家之间进行讨论。
- 这种情况一直持续到没有专家愿意修改他们的估计为止。
2.1.2 通过 Analogy 类比进行估算
- 一个新项目的成本是根据同一应用领域的类似项目来估算的。
- 根据之前的经验估算一个数值
2.1.3 Parkinson’s Law 帕金森定律
- 该定律指出，工作将扩展到填补可用的时间。
- 成本是由可用资源决定的，而不是由客观评估决定的。
- 工作总是会占满所有可用时间，因此 cost 取决于当前的所有可用资源，例如你有 3 个人， 12 个月的时间，那么 cost = 36个person months
2.1.4 为赢而定价 Pricing to win
- 成本是根据客户在项目上的花费来估算的——成本取决于预算，而不是软件功能
- 取决于客户出多少钱，出多少就是多少
2.1.5 Algorithmic cost modelling 算法成本建模
- 根据一些 software metric (usually its size) 软件度量（通常是其大小）对 historical cost information 项目成本的历史成本信息，开发出一个模型
- 当一个项目的工作量需要估计时，就会计算出该指标的估计值。
- 使用该模型，预测工作量
- 算法成本估算的最一般形式是由以下几点给出的：
- ：一个恒定的因素，取决于组织惯例
- ：以选择的指标来估计软件的大小（例如，代码行、功能点）。
- ：通过实验得出的1到1.5之间的数值。
- ：结合过程、产品和开发属性（如需求的稳定性、团队的经验）得出的乘数。
3. Software size estimation 软件规模估算技术
3.1 Software Size Estimation 软件规模估算
常用于软件规模估算的指标
Source Lines of Code 代码行 (SLOC)
基于代码
Function Points 功能点 (FP)
基于需求规范
3.2 Source Lines of Code 代码行数 (SLOC)
有两种类型的SLOC：
Physical SLOC：计算不包括注释和空行的行数
Logical SLOC：衡量可执行“语句”的数量，但其具体定义与特定的计算机语言有关。
SLOC的优势：
- Scope for Automation of Counting 计数自动化的范围：由于代码行是一个物理实体，所以很容易计算，并且可以使用工具自动计算。
- An Intuitive Metric 直观的度量：代码行是衡量软件规模的一个直观指标，因为它可以被看到，其效果也可以被可视化。
SLOC的劣势：
- Variability 可变性：取决于程序员的经验、编程语言、框架支持（自动生成的代码）、重复使用等。
- 很难根据分析和设计阶段的信息来估计开发一个系统所需的代码行数。
- 对于代码行的确切含义缺乏一个普遍接受的定义
3.3 Function Points 功能点(FP)
- 用于表示用户所看到的软件系统中的 amount of functionality 功能数量。
- higher number of function points 功能点的数量越多，说明 more functionality 功能越多
- 经验证据表明，功能点和系统的复杂性之间存在正相关关系。
- 通常用于：
- Estimate the cost and effort required to design, code and test a software system 估计设计、编码和测试一个软件系统所需的成本和精力
- Predict the number of errors 预测错误的数量
- Predict the number of components 预测组件的数量
- Measure productivity 衡量生产力
- 功能点是由 Software Requirements Specification (SRS) 软件需求规格（SRS）计算出来的。
功能点的优点：
- Measures the size of the solution instead of the size of the problem 衡量解决方案的大小而不是问题的大小
- Requirements are the only thing needed for function points count 需求是计算功能点唯一需要的东西
- Can be estimated early in analysis and design 可以在分析和设计的早期进行估计
- Is independent of technology 不受技术的影响
- Is independent of programming languages 不受编程语言的影响
功能点的劣势：
- A well defined requirements specification is necessary 必须有一个明确的需求规格
- Gaining proficiency is not easy, the learning curve is quite long 熟练掌握并不容易，学习曲线相当长
- Could be quite time-consuming thus could be costly 可能相当耗费时间，因此成本很高
4. 敏捷软件开发生命周期中使用的成本估算技术
4.1 敏捷工作估算
用于工作量估算的两个关键概念：
故事点（Story points）
故事点是对一个用户故事大小的相对测量（回顾一下，系统的需求是用用户故事来记录的）。
agile 的 effort 和 cost estimation 依靠于 story points 和 velocity
速度（Velocity）
速度是对团队生产力的衡量，它由在特定时间段内交付的故事点的数量来表示。
velocity 的定义就是：在一段时间之内，能够交付的产品数量（用story points衡量），代表了团队的生产力
4.2 敏捷估算过程
- Develop user stories for the system. 为系统开发用户故事。
- Estimate the number of story points for each story, basing the estimate on the number of story points from previous stories, using a chosen technique (discussed later). 估计每个故事的故事点的数量，根据以前的故事点的数量来估计，使用选定的技术（稍后讨论）。
- Use the team’s velocity from previous experience to estimate the delivery time of the project - in the case of fixed-scope release planning develop a release burn-down chart. 利用团队以往的速度来估计项目的交付时间——如果是固定范围的发布计划，则制定一个发布消耗表。
- During development, measure the actual velocity of the team. 在开发过程中，测量团队的实际速度。
- Using this velocity, re-estimate the time it will take to deliver the product. 利用这个速度，重新估计交付产品所需的时间。
4.3 敏捷估算指南
Estimate by analogy 通过类比进行估算
- 故事点没有单位，我们的衡量标准总是以其他故事为基础。如果故事A和故事B的大小差不多，它们就应该有相同数量的故事点。
Decompose a story 分解一个故事
- 通过将一个故事分解成完成故事所需的任务，我们可以找到关于任务的测量方法，并将它们结合起来，提供一个总的测量方法。
Use the right units 使用正确的单位
- 相对单位不应过于细化。采用基于模式的尺度。例如，措施只能是1、2、4、8、12或斐波那契序列中的数字。
Use group-based estimations 使用基于组的估计
- 对于一个要由团队实施的故事，整个团队应该提供估算。 可以使用 Delphi method 或其改编的技术来达成共识。
4.4 敏捷估算技术
敏捷估算技术：
- Planning Poker 规划扑克
- BUCKET SYSTEM 桶系统
- Relative Mass Valuation 相对质量估价
- T-Shirt Sizes T恤衫的尺寸
- Affinity Estimation 亲和力估算
- Dot Voting 点状投票
4.4.1 Planning Poker
- customer 来读需求
- 针对成员的自己的理解，团队成员首先进行提问，并最终通过一组预先固定的数值中的值给出自己的评价分数
- 然后根据这些分数进行讨论
- 最终重新评估，直到获得一致的分数
4.4.2 BUCKET SYSTEM
- 坐在桌子上的团队随机挑选一张用户故事卡片，并将其放入8号桶中
- 每次随机挑选几张卡片，讨论后达成一致，并将其放入相对于前几张卡片的桶中。
- 然后，每个人被分配一组卡片，根据个人的判断，把它们放在一个合适的桶里（分而治之）。
- 最后，团队审查安置情况并达成协议
4.4.3 Relative Mass Valuation
- 摆放一张大桌子，这样故事就可以很容易地相对移动。
- 挑选任何一个故事开始，团队估计他们是否认为它是相对的。大、中、小。
- 大故事放在桌子的一端。中型故事在中间，小型故事在另一端
- 继续完成步骤2和3
- 下一步是根据表上故事的位置来分配分数值。从最简单的值得分配分数的故事开始，称它为1。
- 然后继续往上走，给每一个故事分配1分，直到有一个故事看起来至少是第一个故事的两倍难。这个故事得到2分。
4.5 计算速度 Velocity
速度等于总的已完成的故事点数除以完成这些工作的时间段（注意是时间段的个数）
测量速度的常用方法：
- 使用历史数据
- 使用以前迭代的数据
4.6 估计 Delivery Time 交付时间
预计交货时间等于所有用户故事的加和除以速度
4.7 关于估算的最后评论
- 留出足够的时间来进行适当的项目估算 —— - rushed estimates 仓促的估算是 inaccurate 不准确的、high-risk 高风险的估算
- 花费在估算上的时间的回报是递减的（准确性在达到顶峰之后会下降，不会无限制的提高，因为它只是估算，永远具有不确定性）
- 敏捷团队选择向左靠拢（敏捷中的不确定性更多，小的努力，收益的性价比更高）
- 要知道你无法消除估算中的不确定性，但小的努力会得到大的回报
5. Function Points 功能点(FP)
- 用于表示用户所看到的软件系统中的 amount of functionality 功能数量。
- higher number of function points 功能点的数量越多，说明 more functionality 功能越多
- 经验证据表明，功能点和系统的复杂性之间存在正相关关系。
- 通常用于：
- Estimate the cost and effort required to design, code and test a software system 估计设计、编码和测试一个软件系统所需的成本和精力
- Predict the number of errors 预测错误的数量
- Predict the number of components 预测组件的数量
- Measure productivity 衡量生产力
- 功能点是由 Software Requirements Specification (SRS) 软件需求规格（SRS）计算出来的。
5.1 Software Requirements 软件需求
Software Requirements Specification 软件需求规范 (SRS)
- 一份规定了对软件系统的期望的文件；被称为系统的要求。
它包括：
Functional Requirements 功能要求
- Specify the functions that are required in the system 明确指出的系统中需要的功能
Non-functional Requirements 非功能需求
- Specify requirements that are not directly functions, such as performance (quality requirements) 指定非直接功能的要求，如性能（质量要求）
5.2 FP计算步骤
- Categorize requirements 将这些需求进行分类
- Estimate a complexity value for each category or function 估计每个类别或功能的复杂度值
- Compute count total from Complexity 从复杂度计算总数
- Estimate value adjustment factors 估算价值调整因子
- Compute total function point count 计算总功能点计数
例子 Automated Trading System: Functional Requirements
| R.1 | 从第三方服务器读取前一天的交易信息（最高价、最低价、开盘价、收盘价）。 |
| R.2 | 在数据库中保存一个完整的“价格历史”。 |
| R.3 | 根据商品的价格趋势，决定哪些商品要出价，哪些商品要尝试卖出。 |
| R.4 | 将信息发送到外部电子交易账户，该账户为每种商品出价/卖价。 |
| R.5 | 当出价/要价被接受或过期，在“交易历史”数据库中记录结果。 |
| R.6 | 在一天结束时，制作一份报告，总结当天的交易以及以下信息：当天的利润/损失；每种商品的交易数量；所有商品的平均市场价格；账户摘要。 |
| R.7 | 在任何时候，用户都可以要求提供一个时期的交易历史，其中包括：交易ID；商品类型；买入/卖出；价格。 |
5.3 Categorize requirements - 步骤1
1. Categorize Requirements 需求分类
Data Functions 数据功能：
关注应用程序的数据维护 —— Internal Logical Files (ILF) 内部逻辑文件，External Interface Files (EIF) 外部接口文件。
Transaction Functions 事务功能：
关注信息在系统中的传递 —— External Inputs 外部输入（EI），External Output 外部输出（EO），External Inquiries/Queries 外部询问/查询（EQ）。
2. Categorize Requirements 分类需求（五个类别）
Data Functions 数据功能
Internal Logical File 内部逻辑文件（ILF）
内部逻辑文件（ILF）—— 用户可识别的逻辑相关数据组，完全驻留在应用程序边界内，并通过外部输入进行维护。内部逻辑文件有其固有的含义，它是在内部维护的，它有一些逻辑结构，它存储在一个文件中。
尽管这不是一条规则，但一个ILF应该至少有一个外部输出和/或外部查询。也就是说，至少有一个外部输出和/或外部查询应该包括ILF作为一个FTR。简单地说，信息被储存在ILF中，所以以后可以使用。EO或EQ可能来自另一个应用程序。值得注意的是，有可能某个特定的ILF没有被EO或EQ引用，但它却被一个EI使用（而不是维护它的EI）。
- 系统在一段时间内维护的数据的逻辑分组，并使用外部输入进行修改。
- 系统自身对这些数据进行处理和维护：关系型数据库，包含用户设置的文件
- 例子 —— 关系数据库中的表，包含用户设置的文件。
External Interface File 外部接口文件（EIF）
外部接口文件（EIF） —— 一组用户可识别的逻辑相关数据，仅用于参考目的。这些数据完全驻留在应用程序边界之外，由另一个应用程序的外部输入来维护。外部接口文件是另一个应用程序的内部逻辑文件。一个应用程序可以把一个文件算作EIF或ILF，而不是两者。一个外部接口文件有其固有的含义，它是由外部维护的（可能是由其他应用程序维护的），必须开发一个接口来获取数据，并存储在一个文件中。
包含在功能点计数中的每个EIF必须有至少一个针对它的外部输出或外部接口文件。至少有一个交易、外部输入、外部输出或外部查询应包括作为FTR的EIF。
每一个引用EIF的应用程序，都需要将其纳入他们的FP计数中。一些组织有一个拉动理论，另一些组织有一个数据推送理论。拉动理论是一个外部应用“进入”另一个应用并检索数据。那些有推动理论的组织要求应用程序创建接口（EO或EQ），由其他应用程序读取。
- 在系统外部维护的数据的逻辑分组，但可能被系统使用。
- 数据在外部维护，但是可能被内部系统进行调用：第三方服务器提供的数据，这些数据维护了当前系统状态
- 例子 —— 与ILF相同，只是数据是在系统外维护的，比如托管在第三方服务器上的数据，或者持有系统状态信息的数据结构。
传输功能
External Inputs 外部输入（EI）
外部输入（EI） —— 是一个基本过程，其中数据从外部到内部跨越边界。这个数据是来自于应用程序的外部。数据可能来自于数据输入屏幕或其他应用程序。这些数据可能被用来维护一个或多个内部逻辑文件。这些数据可以是控制信息，也可以是业务信息。如果数据是控制信息，它不需要维护一个内部逻辑文件。
如果一个外部输入在一个内部逻辑文件上增加、改变和删除（维护）信息，那么这代表三个外部输入。外部输入（尤其是更改和删除）之前可以有一个外部查询（见关于外部查询的部分）。因此，一个完整的功能屏幕是添加、更改、删除和查询。
- 从用户或另一个应用程序到系统的输入，用于控制系统的流程或提供数据。外部输入通常修改内部逻辑文件：由用户填充的数据字段、输入文件(例如编译器的程序源代码)。以及来自外部应用程序的文件提要。
External Outputs 外部输出（EO）
外部输出（EO）—— 一个基本的过程，在这个过程中，派生数据从内部传递到外部的边界。此外，一个EO可以更新一个ILF。数据创建报告或输出文件发送到其他应用程序。这些报告和文件是由一个或多个内部逻辑文件和外部接口文件中的信息创建的。
衍生数据是指在直接检索和编辑内部逻辑文件或外部接口文件的信息之外所处理的数据。衍生数据通常是算法的结果，或计算的结果。当一个或多个数据元素与一个公式相结合，产生或推导出一个或多个额外的数据元素时，衍生数据就会出现。这种衍生数据不会出现在任何FTR（内部逻辑文件或外部接口文件）中。
算法被定义为在一系列步骤中进行特定计算或解决问题的机械程序。
计算被定义为一个有一个或多个运算符的方程式。操作符是一种数学函数，如加法、减法、乘法和除法（+、-、x、/）。
应用程序之间的交易应被称为接口。你只能有一个外部输出或外部查询你的应用程序外部的数据。如果你从另一个应用程序获得数据并将其添加到你的应用程序中的一个文件，这就是一个获取和添加的组合（外部查询和外部输入）。
- 向用户提供有关系统状态的信息的输出 ：显示给用户的示例屏幕、错误消息和报告。其中的各个数据字段被分组为一个外部输出。
External Inquiries 外部询问/查询(EQ)
外部查询(EQ) —— 一个基本流程，包括输入和输出部分，导致从一个或多个内部逻辑文件和外部接口文件检索数据。输入过程不更新或维护任何FTR（内部逻辑文件或外部接口文件），输出端不包含衍生数据。
应用程序之间的交易应被称为接口。你只能有一个外部输出或外部查询你的应用程序外部的数据。如果你从另一个应用程序获取数据并将其添加到你的应用程序中的一个文件，这是一个获取和添加的组合（外部查询和外部输入）。
- 输入不用于更新内部逻辑文件，而是用于查询内部逻辑文件并提供输出;直接检索输出，不包括派生数据 ：读取用户设置或从数据库表中读取记录的示例。
Example: Functional Requirements
Automated Trading System
要看开发的主体是什么，以描述作为判断是模糊的。对于R.4来说，主体是外部的电子交易账户，虽然在描述中提到了将信息从内部发送出去的行为，但这个账户显然是一个外部接口文件。而对于R.6，主体是要制作一份报告，EO可以用于更新一个ILF，数据创建报告或输出文件发送到其他应用程序。
| R.1 | 从第三方服务器读取前一天的交易信息（最高价、最低价、开盘价、收盘价）。 | 外部输入EI |
| R.2 | 在数据库中保存一个完整的“价格历史”。 | 内部逻辑文件 ILF |
| R.3 | 根据商品的价格趋势，决定哪些商品要出价，哪些商品要尝试卖出。 | |
| R.4 | 将信息发送到外部电子交易账户，该账户为每种商品出价/卖价。 | 外部接口文件 EIF |
| R.5 | 当出价/要价被接受或过期，在“交易历史”数据库中记录结果。 | 内部逻辑文件 ILF |
| R.6 | 在一天结束时，制作一份报告，总结当天的交易以及以下信息：当天的利润/损失；每种商品的交易数量；所有商品的平均市场价格；账户摘要。 | 外部输出 EO |
| R.7 | 在任何时候，用户都可以要求提供一个时期的交易历史，其中包括：交易ID；商品类型；买入/卖出；价格。 | 外部查询 EQ |
5.4 为每个类别或功能估计一个复杂性值 - 步骤2
- 复杂度的排序是 simple, average or complex 简单、平均或复杂
- 通常是 assigned for a category 为一个类别而不是为每个需求分配 —— 相当粗略
- 一个常用的技术是基于数据元素类型 Data Element Types（DETs）、记录元素类型 Record Element Types（RETs）和文件类型参考 File Type References（FTRs）。
Data Element Types (DETs) 系统中唯一的、用户可识别的、非重复的数据字段。比如在维护一个教育系统的时候，要维护学生的信息，这些学生的信息分为 Firstname, lastname, studentID 等，这些就属于数据元素类型 Record Element Types (RETs) ILF或EIF中用户可识别的数据元素子组 File Type References (FTRs) 事务引用的文件（ILF或EIF文件）
DETs、RETs、FTRs和功能类别之间的关系
- 在 Data function 的需求类型中，衡量的指标是：DETs 和 RETs
- 在 Transaction function 的需求中，衡量的指标是：DETs 和 FTRs
- 从图中可以看出，当评估 EI, EO, EQ 等 transaction function 的时候，只用到了 DETs 和 FTRs 指标，而 ILF 和 EIF 等 data function 评价的时候只用到了 DETs 和 RTEs 指标
自动交易系统：功能分类
5.5 Compute count total from Complexity - 步骤3
从复杂度计算总计数
- 使用计数和复杂性估计值计算总计数
因为本文的实例中，无论是数据功能还是事务功能的评价都是简单，所以在上图中的 average 和 complex 选项的值都被划去了。最后计算的分数是 29。
5.6 Compute value adjustment factors - 步骤4
计算价值调整因素
- 根据14个特征计算得出
- 每个特征的排名为0-5；0为不重要，5为关键。
数据通信 Data Communications 在线更新 Online Update 分布式数据处理 Distributed Data Processing 复杂处理 Complex Processing 性能表现 Performance 可重复使用 Reusability 大量使用的配置 Heavily Used Configuration 安装方便 Installation Ease 交易率 Transaction Rate 操作简便 Operational Ease 在线数据输入 Online Data Entry 多个站点 Multiple Sites 终端用户效率 End-User Efficiency 便于改变 Facilitate Change
假设所有其他特征的评级为2
Value Adjustment = 2*5 + 4*2 + 10*2 = 38
5.7 Compute total function point - 步骤5
计算总的功能点
- 然后将计数总数和价值调整系数插入以下公式，以估计总点数
Fi - 对应于第i个VAF 价值调整因素 问题的VAF 价值调整因素
自动交易系统：计算总功能点数
6. Function Points的优缺点
功能点的优点
- Measures the size of the solution instead of the size of the problem 衡量解决方案的大小而不是问题的大小
- Requirements are the only thing needed for function points count 需求是计算功能点唯一需要的东西
- Can be estimated early in analysis and design 可以在分析和设计的早期进行估计
- Is independent of technology 不受技术的影响
- Is independent of programming languages 不受编程语言的影响
功能点的劣势
- A well defined requirements specification is necessary 必须有一个明确的需求规格
- Gaining proficiency is not easy, the learning curve is quite long 熟练掌握并不容易，学习曲线相当长
- Could be quite time-consuming thus could be costly 可能相当耗费时间，因此成本很高