信息工程监理的中心任务是对信息工程项目的进度目标、质量目标和风险防范，实施有效的监督、协调与控制。为了监督、控制软件项目开发过程的性能等，引入定量监理十分必要。为此，本期将首先介绍进度的定量监理过程，在下一期将介绍质量和风险的定量监理。
目录
软件开发引入定量监理做参照
软件开发定量监理的两个基本“点”
对进度定量监理的四步法
几种估算模型的介绍
软件开发引入定量监理做参照
应用软件系统开发过程中，不仅存在着信息不对称的风险，还存在着各方信息处理能力不对称引起的风险；不但有项目的特殊风险，还有项目管理风险；不但有经济风险，还有时间风险、心理风险等。
定量过程监理的目的是定量监督、控制软件项目的开发过程性能，软件开发过程性能决定了实施软件过程所获得的实际结果。
应用软件开发是非常专业的，而且是讲究分工的。需求分析、总体设计、概要和详细设计、编码、测试、安装及维护等，每一个过程都有自己的精深之处，涉及的专业面广、业务和技术性强、可见性差、风险大、可预见性小。即使应用软件承建方按规范开发模式的要求一步步进行，也会遇到许多不可预见的问题，更不用说承建方可能有不规范行为的情况。信息化系统的核心是软件，由于难以对软件工程的质量和进度等进行有效的监控，因此，若承建方不按规范进行设计、实施、测试，也不易察觉。
凡此种种，造成许多信息化系统工程项目不成功，不完善，长期收不了口，“豆腐渣”工程层出不穷，严重地影响了信息化系统工程的质量和进度，不仅损害了合同双方的利益，还给国家和社会造成了许多不应有的损失。因此，在软件开发监理过程中，引入定量的方法、手段对应用软件开发过程的某些方面进行定量计算、分析和验证，或通过定量的方法对可能出现的故障、风险进行分析判断，或为执行者提供数据进行核实，从而降低工程建设的风险，使投资的信息化系统发挥应有的作用是非常必要的。
软件开发定量监理的两个基本“点”
通过中国软件评测中心大量的监理实践，我们体会到应用软件开发过程的定量监理可以从以下三个方面展开，即：软件开发进度的监理、软件开发的质量监理和软件开发的风险监理。在进度、质量和风险的定量监理中，又分别按照度量、估算两个步骤进行定量分析、监理。
度量：根据一定的度量标准对软件开发过程中所产生的数据进行收集和整理，如代码行（LOC）和功能点（FP）的数量。它为估计不准、进度缓慢、可见性差等普遍问题提供了矫正的方法。
软件度量的主要作用有两个，一是使用软件度量建立项目基线；二是收集项目当前的生产率和质量状态，利用基线对项目当前状态进行评价，并确定软件工程过程的改进目标。
估算：通常的定义是，对未来事实非零可能性的最乐观的预测。软件项目估算是项目计划活动的基础，估算是一门科学，也是一门艺术，应当认识到，软件评估永远也不会是一门精确的科学。
对进度定量监理的四步法
软件开发引入定量监理做参照
软件开发定量监理的两个基本“点”
对进度定量监理的四步法
几种估算模型的介绍
软件开发引入定量监理做参照
应用软件系统开发过程中，不仅存在着信息不对称的风险，还存在着各方信息处理能力不对称引起的风险；不但有项目的特殊风险，还有项目管理风险；不但有经济风险，还有时间风险、心理风险等。
定量过程监理的目的是定量监督、控制软件项目的开发过程性能，软件开发过程性能决定了实施软件过程所获得的实际结果。
应用软件开发是非常专业的，而且是讲究分工的。需求分析、总体设计、概要和详细设计、编码、测试、安装及维护等，每一个过程都有自己的精深之处，涉及的专业面广、业务和技术性强、可见性差、风险大、可预见性小。即使应用软件承建方按规范开发模式的要求一步步进行，也会遇到许多不可预见的问题，更不用说承建方可能有不规范行为的情况。信息化系统的核心是软件，由于难以对软件工程的质量和进度等进行有效的监控，因此，若承建方不按规范进行设计、实施、测试，也不易察觉。
凡此种种，造成许多信息化系统工程项目不成功，不完善，长期收不了口，“豆腐渣”工程层出不穷，严重地影响了信息化系统工程的质量和进度，不仅损害了合同双方的利益，还给国家和社会造成了许多不应有的损失。因此，在软件开发监理过程中，引入定量的方法、手段对应用软件开发过程的某些方面进行定量计算、分析和验证，或通过定量的方法对可能出现的故障、风险进行分析判断，或为执行者提供数据进行核实，从而降低工程建设的风险，使投资的信息化系统发挥应有的作用是非常必要的。
软件开发定量监理的两个基本“点”
通过中国软件评测中心大量的监理实践，我们体会到应用软件开发过程的定量监理可以从以下三个方面展开，即：软件开发进度的监理、软件开发的质量监理和软件开发的风险监理。在进度、质量和风险的定量监理中，又分别按照度量、估算两个步骤进行定量分析、监理。
度量：根据一定的度量标准对软件开发过程中所产生的数据进行收集和整理，如代码行（LOC）和功能点（FP）的数量。它为估计不准、进度缓慢、可见性差等普遍问题提供了矫正的方法。
软件度量的主要作用有两个，一是使用软件度量建立项目基线；二是收集项目当前的生产率和质量状态，利用基线对项目当前状态进行评价，并确定软件工程过程的改进目标。
估算：通常的定义是，对未来事实非零可能性的最乐观的预测。软件项目估算是项目计划活动的基础，估算是一门科学，也是一门艺术，应当认识到，软件评估永远也不会是一门精确的科学。
对进度定量监理的四步法
软件项目的规模、进度估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些人为错误，导致软件项目的规模估算往往和实际情况相差甚远。因此，是监理工作的重点之一。
为了可靠地对软件项目进行估算，我们采取如下4个步骤：第一步是对软件规模进行估算。一般是通过计算LOC(源代码行数)或功能点数（FP）完成的，也可以基于过程进行估算；第二步是估算软件项目所需的工作量，以人月或人小时为单位；第三步是以自然月为单位，估算项目的进度；第四步是估算项目成本。下面来具体介绍。
1、估算项目的规模
对软件项目进行有效的估算，取决于掌握多少有关项目范围的原始资料。通常，应当根据正式的需求描述进行估算。正式的需求描述可以是需求说明书、系统规格说明书或软件需求说明书等。如果开始时缺乏一些正式的资料，也可以采用口头描述或草稿的方式开始估算工作。在得到项目范围的正式资料后，必须进行再估算。估算的两个主要方法是：
第一种方法是根据项目特征和算法进行估算。
例如，根据软件系统的输入、输出、查询、文件及外部接口等信息，使用功能点法估算出系统的规模。基于功能点估算是按照用例（Use case）来做的，而不是软件功能来做。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。通常的步骤是：
A、计算输入、输出、查询、主控文件和接口需求的数目。
B、将这些数据进行加权乘。下表为一个典型的权值表。
C、估计者根据对复杂度的判断，总数可以用乐观值、可能值或悲观值调整。
D、采用下面的方式计算功能点：
FP=总计数值×［0.65＋0.01×ΣFi］
其中，“总计数值”是所有功能点条目的总和。
Fi（i=1到14）是基于对表2中问题的回答而得到的“复杂度调整值”（0～5）。等式中的常数和信息域值的加权因子是根据经验确定的。
下面将以某个计算机辅助设计（CAD）应用为例，估算开发的软件包的输入、输出、查询、文件及外部接口。为了达到这个估算目的，我们假设复杂度加权因子都是平均的。根据对软件范围的叙述，对软件功能进行分解，识别出主要的几个功能：用户界面和控制功能、二维几何分析、三维几何分析、数据库管理、计算机图形显示功能、外设控制以及设计分析模块。最后可得到如表2所示的估算表。
由表2得到总计数值为318。
接着，估算14个复杂度加权因子（Fi,根据问题对项目的影响取值范围是0～5），表3给出了因子值。
FP=总计数值×[0.65+0.01×ΣFi]=366
第二种方法是采用类比的方法，根据历史数据来进行估算。
如果有一个以前做过的类似项目并且掌握它的规模，就可以把新项目的各个主要部分与原有项目的相应部分进行比较，得出一个比例关系，将各部分相对于原项目规模比例相加，计算出新项目的规模。如果估算者的经验丰富并且新项目与老项目具有足够的相似性，就能够得到合理的估算值。
但是采用类比法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比、需重新编码或修改的代码百分比以及需重新测试的代码百分比。根据这三个百分比，可用下面的计算公式计算等价新代码行：
等价代码行 = [(重新设计% +重新编码% +重新测试%)/3]× 已有代码行
比如：有10，000行代码，假定35%需要重新设计，55%需要重新编码，75%需要重新测试，那么其等价的代码行可以计算为：
[(30% + 50% + 70%)/3]×10,000= 5,500 等价代码行。即：重用这10000代码相当于编写5500代码行的工作量。
2、工作量估算
估算出软件规模并且对软件的开发周期进行定义后，开始估算软件项目的工作量。软件规模的估算结果是代码量，但是软件项目的开发、实施过程并不是只有编码的工作，实际上编码的工作量在这个过程中是最小的。编写文档、架构设计、系统设计、测试以及实施发布等将占用大量的工作时间。因此，对软件项目工作量的估算就是确定、估算这样一个代码量的项目所需的各种工作，相加得到项目的工作量。从软件规模（代码量）估算出项目工作量主要采用下述的两个方法：
（1）最好的方法是利用历史数据，根据以前做过的类似项目规模与新项目规模的比例关系，对照以前项目的工作量求出新项目的工作量。
采用这个方法的前提是：a.对以前项目规模和工作量的计量是正确的；b.至少有一个以前的项目的规模和新项目类似；c.新项目的开发周期、使用的开发方法、开发工具与以前项目的类似，而且开发人员的技能和经验也不能与原来的人员相差太大。
（2）如果没有历史数据可用，或者新项目与以前做过的项目差别较大，那么可以使用一个成熟的估算模型，如采用IBM模型、COCOMO模型或Putnam方法论，将软件项目规模转换成工作量。
这些模型通过对大量不同类型组织已完成项目进行研究，得出的项目规模与工作量之间的关系和转换方法。这些行业性的模型可能不如自己的历史数据精确，但是非常有效。目前，还没有一种估算模型能够适用于所有的软件类型和开发环境，在监理活动中，从这些模型得到的结果必须根据项目的实际情况慎重使用，或者采用多个模型进行估算、掌握工作量的基本范围并与实际的工作量计划比较。
下面以IBM模型为例来进行计算。 为了计算，我们应当利用逆向法将功能点转化成一个等价的SLOC数值。这一步可以使用表4的语言等价表来完成：
所以，使用java 2完成上述项目(366功能点)时，将大约需要下列SLOC数：
L = 366×46 = 16386行 = 16.386KLOC
E ＝ 5.2×L0.91 ＝ 5.2×16.3860.91 ＝ 66人/月
DOC ＝ 49×L1.01 ＝ 49×16.3861.01 ＝ 826页
3、制定计划
对软件项目进行估算的第三步是根据工作量制定项目计划，包括人员安排、工作量分解、开始和完成时间等等。可以根据自己的历史数据或行业模型决定所需的资源并落实到项目计划。可以采用上述的IBM模型或McConnell给出的方法粗略地给出项目持续时间（以IBM模型为例）：
项目需要的人员S＝0.54×E0.6 ＝0.54×660.6＝7人
项目持续时间D＝4.1×L0.36 ＝4.1×16.3860.36＝11月
4、成本估算
项目的成本估算包括许多因素：人力成本、办公费用、管理费用、设备和软件等的购置费用、场地租金、旅差费等等。对项目成本的估算取决于公司所采用的成本核算方法。有的公司某些费用并没有计入项目成本中，而是按管理费用等分摊。有的从历史数据求出生产率度量和每行成本，即行／PM(人月)和元／行，则LOC的值与元／行相乘得到成本，用LOC 的值与行／PM相除得到工作量。具体可按公司的具体情况选择。
注：本文作为示例给出的针对进度等的定量监理的估算方法只是众多方法中的一种。笔者的目的是建议监理单位在项目监理过程中根据实际情况适当采用定量的方法。更多的估算方法，可以参考有关软件评估方面的书籍和其它资料。
几种估算模型的介绍
1、IBM模型
1977年，IBM的Walston和Felix提出了如下的估算公式：
E ＝ 5.2×L0.91，L是源代码行数(以KLOC计)，E是工作量（以PM计）
D ＝ 4.1×L0.36，D是项目持续时间(以月计)
S ＝ 0.54×E0.6，S是人员需要量(以人计)
DOC ＝ 49×L1.01。DOC是文档数量(以页计)
在此模型中，一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。对于非机器指令编写的源程序，如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。
2、Putnam模型
这是1978年Putnam提出的模型，是一种动态多变量模型。它是假定在软件开发的整个生存期中工作量有特定的分布。这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。
Putnam模型可以导出一个“软件方程”，把已交付的源代码（源语句）行数与工作量和开发时间联系起来。其中，td是开发持续时间（以年计），K是软件开发与维护在内的整个生存期所花费的工作量（以人年计），L是源代码行数（以LOC计），Ck是技术状态常数，它反映出“妨碍程序员进展的限制”，并因开发环境而异。其典型值的选取如下表所示。
3、COCOMO模型（COnstructive COst MOdel）
这是由TRW公司开发。Boehm提出的结构型成本估算模型，是一种精确、易于使用的成本估算方法。在该模型中使用的基本量有以下几个：DSI（源指令条数）定义为代码或卡片形式的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句和格式语句，但不包括注释语句。KDSI＝1000DSI。MM（度量单位为人月）表示开发工作量。TDEV（度量单位为月）表示开发进度。它由工作量决定。
（1）软件开发项目的分类
在COCOMO模型中，考虑开发环境，软件开发项目的总体类型可分为三种：组织型（Organic）、嵌入型（Embedded）和介于上述两种软件之间的半独立型（Semidetached）。
（2）COCOMO模型的分类
COCOMO模型按其详细程度分成三级：即基本COCOMO模型、中间COCOMO模型、详细COCOMO模型。基本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的源代码行数（LOC）为自变量的（经验）函数来计算软件开发工作量。中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量(此时称为名义工作量)的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。