笔记-信息应用系统监理工作-20.5 应用软件建设的投资控制
20.5 应用软件建设的投资控制
20.5.1 软件项目投资控制概念
软件项目投资控制是项目监理的一个重要组成部分，为了保证完成项目所花费的实际成本不超过其预算成本而展开的项目成本估算、项目预算编制和项目投资控制等方面的管理活动。项目成本管理也是为了确保项目在核准的预算内按时、保质、经济、高效地完成项目各项目标而开展的一种必要的项目控制过程。必须加强对项目实际发生成本的控制，一旦软件项目成本失控，就很难在预算内完成项目，不良的投资控制常常会使项目处于超出预算的危险境地，且难以追加预算。但是在软件项目的实际实施过程中，预算超估算，决算超预算的现象还是屡见不鲜，这种成本失控的情况通常是有下列原因造成的：
（1）成本估算工作、成本预算工作不够准确精细。
（2）软件项目的特点使得开发成本难以精确估算。据有关方面统计，目前**估算的软件开发成本与实际成本相差在20%以内，时间估算相差在50%**以内就相当不错了。
（3）项目在进行成本估算和成本预算以及指定项目投资控制方法上并没有统一的标准和规范可行。
（4）思想认识上存在误区，认为项目具有创新性，导致项目实施过程中变量太多、变数太大，实际成本超出预算成本也在所难免，理所当然。
软件项目的投资控制主要是在批准的预算条件下确保项目的保质按期完成，其主要包括：资源计划、成本估算、成本预算、成本控制，在第一篇的投资控制章节中已有详细的描述，因此在本节重点讨论的是软件项月成本估算、成本控制的技术与方法。
20.5.2 成本估算技术与方法
在软件项目建设的前期过程中，业主对软件项目所需要的成本估算往往随意性很大，在进行估算时缺少规范性的依据和手段方法，总是认为无法做出正确的估算，只要将成本尽量压低就可以了。在监理已经前期介入的情况下，业主肯定会要求监理对项目成本做准确的估算。
实际上，尽管软件项目在开发、实施过程中存在着很大的不确定性，但是只要在软件项目成本的控制工作方面树立正确的思想，采取适当的方法，遵循一定的程序，严格按照软件项目投资控制的要求做好估算、预算和投资控制工作，将项目的实际投资控制在预算成本以内是完全可能的。
1. 成本估算的概念与原则
（1）成本估算指的是预估完成软件项目各工作所需资源（人、材料、设备等）的费用的近似值。
（2）当软件项目在一定的约束条件下开发、实施时，价格的估计是一项重要的因素。
（3）成本估计应该与工作质量的结果相联系。
（4）成本估计过程中，亦应该考虑各种形式的费用交换。比如在多数情况下，延长工作的延续时间通常是与减少工作的直接费用相联系在一起的；相反，追加费用将缩短项目工作的延续时间。因此，在成本估计的过程之中必须考虑附加的工作对工程期望工期缩短的影响。
2. 成本估计的主要依赖的资料
软件项目成本从直观上理解是为了实现项目目标、完成软件项目活动所必须的资源的价格所决定的。因此编制项目成本估算，要以在确定的项目资源需求和项目组织对这些资源的预计价格为基础进行估算。编制成本估算的依据实际上就是对项目的资源需求和这些资源的预计价格产生影响的因素。具体地说，编制项目成本估算的依据主要有以下几个。
1）工作分解结构图（WBS）
工作分解结构图是编制项目资源需求计划的基础，也是项目成本估算的依据。
2）资源需求计划
即资源计划安排结果。资源需求计划界定了项目实施所需要的各种资源的数量和质量目标。
3）资源价格
为了计算项目各工作费用必须知道各种资源的单位价格，包括人员费用、设备、差旅的费用等。如果某种资源的实际价格不知道，就应该给它的价格做出估计。要想估算软件项目成本，必须掌握每种资源的市场价格情况，如果无法知道实际价格，应该根据历史价格资料，做出恰当的估计。
4）项目的延续时间
项目的延续时间将直接影响到项目工作经费的估算，因为它将直接影响分配给它的资源数量。一般，项目持续时间的延长会导致项目所需资源的增加，而项目所需的各种资源都是须支出货币资金才能够获得的，同时资金本身具有时间价值。例如，自有资金存入银行会产生利息，借贷资金使用期间要支付利息。因此在估算项目成本时，应该充分考虑项目的持续时间。
5）历史信息
同类项目的历史资料始终是项目执行过程中可以参考的最有价值的资料，包括项目文件、共用的项目成本估计数据库及项目工作组的知识等，特别是对软件开发项目，如果有类似的项目做比较，估算的项目总成本有效性就可以大大提高。
3. 成本估计的方法和工具
1）类比估计法
通常是与原有的类似已执行项目进行类比以估计当期项目的费用，又称为“自上而下估算法”。这种方法的基本操作步骤是：
（1）监理项目组的高层次管理人员收集以往类似项目的有关历史资料；
（2）会同有关成本方面的专家对当前项目的总成本进行估算；
（3）将估算结果按照项目工作分解结构图的层次结构传递给下层的项目监理人员，在此基础上，他们对自己所负责的工作和活动的成本进行估计：
（4）继续向下一层监理人员传递估计信息，参见图20.18。
2）参数模型法
将项目的特征参数作为预测项目成本数学模型的基本参数。如果模型是依赖于历史信息，模型参数容易数量化，且模型应用仅是项目范围的大小，则它通常是可靠的。
3）从下向上的估计法
这种技术通常先估计各个独立工作的费用，然后再汇总从下往上估计出整个项目的总费用，参见图20.19。
4）计算工具的辅助
项目管理软件及电子表格软件辅助项目成本的估计。
5）成本估计的基本结果
（1）项目的成本估计
描述完成项目所需的各种资源的费用，包括劳动力、原材料、库存及各种特殊的费用项，如折扣、费用储备的影响，其结果通常用劳动工时、工日、材料消耗量等表示。
（2）详细的说明
成本估计的详细说明应该包括：
- 工作估计范围描述，通常是依赖于WBS作为参考；
- 对于估计的基本说明，如成本估计是如何实施的；
- 各种所做假设的说明；
- 指出估计结果的有效范围。
软件项目的规模、进度估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的缺乏、估算工具缺乏以及一些人为错误，导致软件项目的规模估算往往和实际情况相差甚远，因此是监理的重点之一。
4.软件开发工作量和成本评估的例子
软件项目估算的基本步骤为了可靠地对软件项目进行估算，我们采取如下三个步骤：对软件规模进行估算。一般是通过计算 LOC（源代码行数）或功能点数（FP）完成的，也可以基于过程进行估算。
- 估算软件项目所许的工作量，以人月或人小时为单位。
- 以自然月为单位估算项目的进度。
- 估算项目成本。
（1）估算项目的规模
对软件项目进行有效的估算取决于掌握多少有关项目范围的原始资料。应当根据正式的需求描述进行估算，正式的需求描述可以是需求说明书、系统规格说明书或软件需求说明书等。如果开始时缺乏一些正式的资料，也可以采用口头描述或草稿的方式开始估算工作，在得到项目范围的正式资料后，必须进行再估算。估算的两个主要方法是：
- 根据项目特征和算法。例如，使用功能点法根据软件系统的输入、输出、查询、 文件及外部接口等信息，估算出系统的规模。基于FP估算的分解是集中于信息域值，而不是软件功能。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。通常的步骤是：
① 计算输入、输出、查询、主控文件，和接口需求的数目。
② 将这些数据进行加权乘。表20-5为一个典型的权值表。
③ 估计者根据对复杂度的判断，总数可以用乐观值、可能值或悲观值调整。
④ 采用下面的方式计算功能点：
FP=总计数值*0.65+0.01EFi
其中，“总计数值”是所有功能点条目的总和。
Fi（i=1,2,…,14）是基于对表20-5中问题的回答而得到的“复杂度调整值”（0－5）。等式中的常数和信息域值的加权因子是根据经验确定的。
监理估算某个计算机辅助设计（CAD）应用而开发的软件包的输入、输出、查询、文件及外部接口。为了达到这个估算目的，假设复杂度加权因子都是平均的。根据对软件范围的叙述，对软件功能进行分解，识别主要的几个功能：用户界面和控制功能、二维几何分析、三维几何分析、数据库管理、计算机图形显示功能、外设控制以及设计分析模块。可得到如表20-6所示的估算表。
接着，估算14个复杂度加权因子（其中Fi根据问题对项目的影响取值范围是0－5），表20-7给出了因子值。
- 类比的方法。如果有一个以前做过的类似项目，并且掌握它的规模，就可以把新项目的各个主要部分与原有项目的相应部分进行比较，得出一个比例关系，将各部分相对于原项目规模比例相加，计算出新项目的规模。如果估算者的经验丰富并且新项目与老项目具有足够的相似性，就能够得到合理的估算值。
但是采用类比法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中须重新设计的代码百分比，须重新编码或修改的代码百分比以及须重新测试的代码百分比。根据这三个百分比，可用下面的计算公式计算等价新代码行：
等价代码行=[（重新设计%十重新编码%+重新测试%）/3]×己有代码行
比如，有10000行代码，假定35%需要重新设计，55%需要重新编码，75%需要重新测试，那么其等价的代码行可以计算为：
[（30%+50%+70%）/3] × 10000= 5500（等价代码行）
即重用这10000代码相当于编写5500代码行的工作量。
（2）工作量估算
估算出软件规模，并且对软件的开发周期进行定义后开始估算软件项目的工作量。软件规模的估算结果是代码量，但是软件项目的开发、实施过程并不只仅有编码的工作，实际上编码的工作量在这个过程中是最小的。编写文档、架构设计、系统设计、测试以及实施发布等将占用大量的工作时间。因此，对软件项目工作量的估算就是确定、估算这样一个代码量的项目所需的各种工作，相加得到项目的工作量。从软件规模（代码量）估算出项目工作量主要采用下述的两个方法：
- 最好的方法是利用历史数据，根据以前做过的类似项目规模与新项目规模的比例关系，对照以前项目的工作量求出新项目的工作量。采用这个方法的前提是：①对以前项目规模和工作量的计量是正确的；②至少有一个以前的项目规模和新项目类似；③新项目的开发周期、使用的开发方法、开发工具与以前项目的类似，而且开发人员的技能和经验也不能与原来的人员相差太大。
- 如果没有历史数据可用，或者新项目与以前做过的项目差别较大，那么可以使用一个成熟的估算模型，如采用IBM模型、COCOMO模型或Putnam方法论将软件项目规模转换成工作量。这些模型通过对大量不同类型组织已完成项目进行研究，得出的项目规模与工作量之间的关系和转换方法。这些行业性的模型可能不如自己的历史数据精确，但是非常有效，因为还没有一种估算模型能够适用于所有的软件类型和开发环境。在监理活动中，从这些模型中得到的结果必须根据项目的实际情况慎重使用，或者采用多个模型进行估算，掌握工作量的基本范围并与实际的工作量计划比较。以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是文档数量（以页计）
在此模型中，一般指一条机器指令为一行源代码。一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。对于非机器指令编写的源程序，如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。
为了计算，我们应当利用逆向法将功能点转化成一个等价的LOC数值。这一步可以使用表20-8的语言等价表来完成：
所以使用Java 2完成上述项目（366功能点）时，将大约需要下列LOC数：
L=366 × 46=16386（行）=16.386 （KLOC）
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相除得到工作量。具体可按公司的具体情况选择。
（5）几种估算模型简介
软件开发工作量、成本估算是依据开发经验估算模型进行估算的。估算模型通常采用经验公式来预测软件项目计划所需要的成本、工作量和进度数据。还没有一种估算模型能够适用于所有的软件类型和开发环境，从这些模型中得到的结果必须慎重使用。在这里我们给出几个常用的估算模型。
IBM模型
上面的例子用的就是IBM模型，在此就不做进一步的说明了。
Putnam模型
这是1978年Putnam提出的模型，是一种动态多变量模型。它是假定在软件开发的整个生存期中工作量有特定的分布。这种模型是依据在一些大型项目（总工作量达到或超过30个人年）中收集到的工作量分布情况而推导出来的，但也可以应用在一些较小的软件项目中。
Putnam模型可以导出一个“软件方程”，把已交付的源代码（源语句）行数与工作量和开发时间联系起来。其中，td是开发持续时间（以年计），K是软件开发与维护在内的整个生存期所花费的工作量（以人年计），L是源代码行数（以LOC计），CK是技术状态常数，它反映“妨碍程序员进展的限制”，并因开发环境而异。其典型值的选取如表20-9所示。
COCOMO模型（Constructive Cost Model）
这是由TRW公司开发的，Boehm提出的结构型成本估算模型，是一种精确、易于使用的成本估算方法。在该模型中使用的基本量有以下几个：DSI（源指令条数）定义为代码或卡片形式的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句和格式语句，但不包括注释语句。KDSI=1000 DSI。MM（度量单位为人月）表示开发工作量。TDEV（度量单位为月）表示开发进度，它由工作量决定。
① 软件开发项目的分类
在COCOMO模型中，考虑开发环境，软件开发项目的总体类型可分为三种：组织型（Organic ）、嵌入型（Embedded）和介于上述两种软件之间的半独立型（Semidetached）。
② COCOMO模型的分类
COCOMO模型按其详细程度分成三级：基本COCOMO模型、中间COCOMO模型和详细COCOMO模型。基本COCOMO模型是一个静态单变量模型，它用一个已估算出来的源代码行数（LOC）为自变量的（经验）函数来计算软件开发工作量。中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量（此时称为名义工作量）的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。
③ 基本COCOMO模型
基本COCOMO模型的工作量和进度公式如表20-10所示。
利用上面公式，可求得软件项目，或分阶段求得各软件任务的开发工作量和开发进度。
④ 中间COCOMO模型
进一步考虑15种影响软件工作量的因素，通过定下乘法因子，修正COCOMO工作量公式和进度公式，可以更合理地估算软件（各阶段）的工作量和进度。
中间COCOMO模型的名义工作量与进度公式如表20-11所示。
对15种影响软件工作量的因素fi按等级打分，如表20-12所列。此时，工作量计算公式改成：
⑤ 详细COCOMO模型
详细COCOMO模型的名义工作量公式和进度公式与中间COCOMO模型相同。但分层、分阶段给出工作量因素分级表（类似于表20-12）。针对每一个影响因素，按模块层、子系统层、系统层，有三张不同的工作量因素分级表，供不同层次的估算使用。每一张表中工作量因素又按开发中各个不同阶段给出。
例如，关于软件可靠性（RELY）要求的工作量因素分级表（子系统层），如表20-13所示。使用这些表格，可以比中间 COCOMO模型更方便、更准确地估算软件开发工作量。
20.5.3 成本控制
成本控制指在软件项目成本的形成过程中，对开发、实施、维护、培训所消耗的人力资源、物质资源和费用开支，进行指导、监督、调节和限制，及时纠正将要发生和己经发生的偏差，把各项项目费用控制在计划成本的范围之内，保证成本目标的实现。软件项目投资控制的目的，在于降低项目成本，保证项目进度，提高经济效益。
1. 成本控制的原则
（1）投资控制不能脱离技术管理和进度管理独立存在，相反要在成本、技术、进度三者之间进行综合平衡。及时和准确的成本、进度和技术跟踪报告，是项目经费管理和成本控制的依据。
（2）成本控制就是要保证各项工作要在它们各自的预算范围内进行。投资控制的基础是事先就对项目进行的费用预算。
（3）成本控制的基本方法是规定各部门定期上报其费用报告，再由控制部门对其进行费用审核，以保证各种支出的合理性，然后再将已经发生的费用与预算相比较，分析其是否超支，并采取相应的措施加以弥补。
2. 成本控制的内容
成本控制主要关心的是影响改变费用的各种因素，确定费用是否改变以及管理和调整实际的改变。成本控制包括：
（1）监控费用执行情况以确定与计划的偏差；
（2）确使所有发生的变化被准确记录在费用线上；
（3）避免不正确的、不合适的或者无效的变更反映在费用线上；
（4）股东权益改变的各种信息。
成本控制还应包括寻找费用向正反两方面变化的原因，同时还必须考虑与其他控制过程（如范围控制、进度控制、质量控制等）相协调，比如不合适的费用变更可能导致质量、进度方面的问题，或者导致不可接受的项目风险。
3. 投资成本控制的依据
（1）费用花费情况。
（2）实施执行报告。这是费用控制的基础，实施执行报告‘通常包括项目各工作的所有费用支出，同时也是发现问题的最基本依据。
（3）改变的请求。改变的请求可能是口头的也可能是书面的，可能是直接的也可能是非直接的，可能是正式的也可能是非正式的：改变可能是请求增加预算，也可能是减少预算。
4. 投资成本控制的方法与技术
（1）费用控制改变系统。通常是说明费用被改变的基本步骤，包括文书工作、跟踪系统及调整系统，费用的改变应该与其他控制系统相协调。
（2）实施的度量。主要帮助分析各种变化产生的原因，挣得值分析法是一种最为常用的分析方法。费用控制的一个重要工作是确定导致误差的原因，以及如何弥补、纠正所出现的误差。
（3）附加的计划。很少有项目能够准确地按照期望的计划执行，不可预见的各种情况要求在项目实施过程中重新对项目的费用做出新的估计和修改。
（4）计算工具。通常是借助相关的项目管理软件和电子制表软件来跟踪计戈费用、实际费用和预测费用改变的影响。