1. 基于代码行和功能点的估算

软件项目的规模是影响软件项目成本和工作量的主要因素。在基于代码行（loc，line of code）和功能点（function point）的估算方法中，利用代码行和功能点来表示软件系统的规模，并通过对软件项目规模的估算进而来估算软件项目的成本和工作量。

显然,一个软件项目的代码行数目越多，它的规模也就越大。软件代码行的数目易于度量，许多软件开发组织和项目组都保留有以往软件项目代码行数目的记录，这有助于在以往类似软件项目代码行记录的基础上对当前软件项目的规模进行估算。

用代码行的数目来表示软件项目的规模简单易行，自然、直观且易于度量。但是其缺点也非常明显。在软件开发初期很难估算出最终软件系统的代码行数；软件项目代码行的数目通常依赖于程序设计语言的功能和表达能力；采用代码行的估算方法会对那些设计精巧的软件项目产生不利的影响；该方法只适合于过程式程序设计语言，不适合于非过程式程序设计语言（如函数式或者逻辑语言）。

针对上述问题，人们提出用软件系统的功能数目来表示软件系统的规模。1979年ibm的albrecht提出了计算功能点的方法。该方法需要对软件系统的二个方面进行评估，即评估软件系统所需的内部基本功能和外部基本功能，然后根据技术复杂度因子对这二个方面的评估结果进行加权量化，产生软件系统功能点数目的具体计算值。具体的，以下是软件系统功能点的计算公式。

fp = ct× (0.65 + 0.01×sfi) （i=1..14）

其中，ct是5个信息量的“加权和”，fi是14个因素的“复杂性调节值”（i =1..14），0.65和0.01是经验常数。

ct的计算方法如表 3所示，ct =（简单用户输入数×3 ＋一般用户输入数×4＋复杂用户输入数×6）+（简单用户输出数×4＋一般用户输出数×5＋复杂用户输出数×7）+（简单用户查询数×3＋一般用户查询数×4＋复杂用户查询数×6）+（简单文件数×7＋一般文件数×10＋复杂文件数×15）+（简单外部界面数×5＋一般外部界面数×7＋复杂外部界面数×10）。其中，用户输入数是指由用户提供的、用来输入的应用数据项的数目；用户输出数是指软件系统为用户提供的、向用户输出的应用数据项的数目；用户查询数是指要求回答的交互式输入的项；文件数是指系统中主文件的数目；外部界面数是指机器可读的文件数目（如磁盘或者磁带中的数据文件）。

表 3. ct值的加权计算

f_i（i=1..14）14个因素的“复杂性调节值”取值见表 4。

表 4. f_i的取值表

例如，假设项目组要开发一个软件项目a。根据用户的需求描述，该软件项目的ct取值如表 5所示。进一步的，假设该软件项目的14个复杂性调节值全部取平均程度。那么根据表 5可知，该软件项目的ct=341，14个复杂性调节因素的累加值sfi=42，因而根据公式fp = ct× (0.65 + 0.01×sfi) （i=1..14）可知，该软件项目的功能点fp=341× (0.65 + 0.01×42) = 364.87，即该项目的功能点数目大致为364。

表 5. 软件项目a的ct值

用功能点来表示软件项目规模的好处是：软件系统的功能与实现该软件系统的语言和技术无关，而且在软件开发的早期阶段（如需求分析）就可通过对用户需求的理解获得软件系统的功能点数目，因而该方法可以较好地克服基于代码行软件项目规模表示方法的不足。其不足主要体现在：该方法没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统；功能点计算主要靠经验公式，主观因素比较多；此外计算功能点所需的数据不好采集。

大量的实践表明：针对特定的程序设计语言，软件系统的功能点和代码行二者之间存在某种对应关系（如表 6所示）。根据该表的数据，一个功能点如果用汇编语言来实现大约需要320行代码，如果用c语言来实现大约需要150行代码，如果用smalltalk语言来实现大约需要21行代码。从另一个角度上看，该表反映了不同程序设计语言的描述能力是不一样的。

表 6. 功能点和代码行之间的转换表

假设用l表示软件系统的规模（或者用loc表示，或者用fp来表示）。针对一个具体的软件项目，可以采用自顶向下或者自底向上等多种方式来估算出软件项目规模的乐观值a、悲观值b和一般值m，然后根据以下公式估算出软件项目规模的期望值e：

e = (a + 4´m + b)/6

根据软件项目规模的期望值e以及下列公式，就可以估算出软件项目的成本和工作量。

生产率

pm = l / e

其中，l表示软件项目的规模（单位：loc或者fp)，e表示软件工作量（单位：人月），pm表示单个人月能够生产的功能点或者代码行数。

平均成本

ckl = s / l

其中，s为软件项目总开销，l表示软件项目的规模（单位：loc或者fp)， ckl表示每行代码或者每个功能点的平均成本。

对于一个特定的软件开发组织或者项目组而言，其软件生产率和平均成本在不同的软件项目实施中可能是比较稳定的。如果有以往软件项目的历史信息，可以很容易地获得关于软件开发组织或者项目组的pm和ckl值。因此，一旦估算出了软件项目的规模，获得了软件开发组织或者项目组的pm和ckl的值，就可根据公式ckl = s / l计算出软件项目的成本s = ckl´ l，也可根据公式pm = l / e计算出软件项目的工作量e= l / pm。

例如，假设项目组要开发一个软件项目a，经过估算该项目的规模是364个功能点。进一步的，根据以往的历史数据，该项目组软件开发的生产率是8fp/人月，每个功能点的平均成本为12000元人民币，那么该软件项目的开发成本s = 6800元人民币´ 364 = 247，5200元人民币，工作量为e= 364/ 8 = 45.5人月。

基于经验模型的估算

基于经验模型的估算根据以往软件项目实施的经验数据（如成本、工作量和进度等）建立相应的估算模型，并以此为基础对软件项目开发的有关属性进行估算。构造性成本模型cocomo（constructive cost model）是目前应用最为广泛的经验模型之一。

在二十世纪七十年代后期，boehm对多达63个软件项目的经验数据进行了分析和研究，在此基础上于1981年提出了cocomo模型用于对软件项目的规模、成本、进度等方面进行估算。boehm把cocomo模型分为基本、中间和详细三个层次，分别支持软件开发的三个不同阶段。基本cocomo模型用于估算整个软件系统开发所需的工作量和开发时间，适合于软件系统开发的初期。中间层次的cocomo模型用于估算各个子系统的工作量和开发时间，适合在获得各个子系统信息之后对软件项目的估算。详细层次的cocomo模型用于估算独立的软构件，适合在获得各个软构件信息之后对软件项目的估算。由于篇幅限制，本书仅介绍基本cocomo模型，其模型形式描述如下。

e = a * (kloc)b 。其中e是软件系统的工作量(单位：人月) ，a和b是经验常数，其取值见表 7，kloc是软件系统的规模（单位：千行代码）。该公式描述了软件系统的规模与工作量之间的关系。

d = c * ed。其中d是开发时间（单位：月），c和d是经验常数，其取值见表 7。该公式描述了软件系统的开发时间与工作量之间的关系。

表 7. 基本cocomo模型参数的取值

cocomo模型是一个综合经验模型，它考虑了诸多因素，因而是一个比较全面的估算模型。cocomo模型有许多参数，其取值来至于经验值。该估算模型比较实用、易于操作，在欧盟国家应用较为广泛。

例如，针对上面所述的软件项目a，如果已估算出该项目的软件规模是33.3kloc，而且该项目属于半独立型，即cocomo模型中的参数a、b、c、d的取值分别是3.0、1.12、2.5、0.35，那么根据模型公式e =a * (kloc)b可以估算出该项目的工作量是3.0*(33.3)1.12，即152人月；然后根据公式d = c * ed可以估算出该项目的开发时间是2.5*(152)0.35，即14.5月。

2. 其它估算方法

其它估算方法包括：专家估算、类比估算等等。

专家估算方法是由一组专家来对软件项目所需的成本、工作量和进度等进行估算。一般地，这些专家具有应用领域或者开发环境方面的知识、参与了以往类似软件项目的开发。为了避免专家估算的片面性，专家估算方法一般要求每位专家给出估算的最小值a、可能值m和最大值b，然后计算出每位专家估算的平均值esti =（a+4m+b）/6，最后根据各位专家的估算情况计算出最终的估算值est=(est1+est2+est3+……+estn)/n。如果软件开发组织或者项目组拥有一批经验丰富的专家，可以考虑采用该方法。专家估算方法具有人为因素多、主观因素大的特点，一般应用于软件开发的初期阶段，此时软件项目组往往难以获得估算软件项目所需的各种数据和信息。

类比估算方法是指估算人员根据以往类似软件项目实施所积累下来的数据，通过分析待开发软件项目和以往软件项目二者之间的相似性，估算出软件项目的开发工作量、成本和进度等。使用该方法的前提是：待估算的软件项目和以往的软件项目必须具有一定的相似性（如它们均属于同样的应用领域），并且拥有以往类似软件项目的开发数据（如工作量、周期、参与的人数、规模和成本等）。

软件估算发生在事前，因而估算的结果与实际的结果有所偏差是不可避免的。但是，如果估算的偏差过大，那么估算的结果将会对软件项目的实施和管理产生消极的影响，甚至可能导致软件项目的失败。因此，在对软件项目的规模、成本和工作量等进行估算的过程中，要避免低劣的估算，尽可能地获得合理和准确的估算数据。