功能点分析方法在软件需求管理中的应用

2007/10/12 8:30:43 | 8793次阅读 | 来源：网友转载【已有0条评论】发表评论

软件项目面临的一个普遍困难就是需求的不确定与频繁变更，有效管理软件需求要解决的一个基本问题是确定变更的粒度大小以及对项目的影响程度。本文使用功能点标准度量需求的规模，使得采用量化方式管理软件需求成为可能，从而对功能点在软件项目管理方面的应用进行扩充。

关键词：需求管理需求变更功能点  项目管理软件度量

1.  背景

相对于传统行业的项目而言，在软件项目中经常会发生工期拖延、费用超支、质量低下、用户不满意等负面情形[1]，其原因可能包括客户要求不合理、过程管理不规范、质量意识淡漠等多种因素，但不能否认的是软件本身的特点是问题产生的根源。

相对于其他行业而言，例如土建、制造等传统行业，软件更为抽象和不易衡量，同时软件还具有容易变更的特点。再加上软件不容易量化的特点使得软件项目的计划与跟踪粒度过粗、不能及时发现项目中存在的问题，从而导致软件项目的管理往往流于形式化，不能起到应有的作用。

软件项目管理主要从四个方面关注项目的进展状况[2]，它们依次是项目的范围、时间、成本和质量，如图一所示。其中项目范围作为主要的变量，对其他三个指标产生明显的影响。而软件项目范围的不确定性则会直接导致项目工期、项目成本和项目质量的不确定性。

图一：项目管理三角形

软件项目范围的不确定性通常表现为如下两个方面：

1.    项目前期需求不明确。前期需求不明确导致项目范围不确定，而基于范围基础之上的工期、成本与质量目标显然也带有很大的不确定性。正是因为需求不明确，许多项目倾向于采用固定价合同计价模式。当后期发生追加需求时，甲方可以避免追加合同金额的情形（甲方申请由追加需求产生的额外费用是比较困难的，因为他往往缺乏有效的方法说服自己的上司追加费用与额外需求之间明确的对应关系）。可想而知，固定价合同模式对项目的乙方会产生什么样的影响。乙方只好做些力所能及的被动适应性工作，例如无可奈何的加班、质量方面的下降、工期方面的顺延等等。

2.    需求变更时无法做出可信的量化影响分析。因为需求规模的单位比较模糊，例如一个需求、需求模块等笼统提法，导致变更的需求规模描述不容易被接受。尤其是对于客户而言，基于变更的需求所推导出的对应的工期变更、成本变更和质量变更也缺乏说服力。所以当需求变更后，项目计划的修改往往是不够准确的。

在软件项目的需求管理中引入功能点分析方法可以有针对性地解决上述的问题[3]。在软件项目中引入功能点分析方法有助于：

    约束需求的详细程度
    对需求变更的影响程度综合分析
    区分需求变更及其对应的种类

2. 功能点方法概述

一个软件的大小可以通过交付给用户的功能点数来度量，就如一间房子的大小通过提供给用户的建筑面积或使用面积来度量一样。根据ISO的标准表述，功能点分析方法的目的是量化表述用户功能性需求的软件规模（A size of the software derived by quantifying the Functional User Requirement）
目前被纳入ISO标准的功能点分析方法总共有四种，分别是

    IFPUG 功能点标准
    Mark II 功能点标准
    Nesma 功能点标准
    COSMIC FFP 功能点标准
IFPUG（International Function Point User Group）功能点标准是目前软件行业采用最广泛的功能点分析方法。功能点分析方法是从用户的角度将所有的用户业务功能需求区分为驻留数据的功能需求和处理数据的事务功能需求[3]，如图二所示。