第 七 讲 GIS 工程计划与管理

1. 第 七 讲 GIS工程计划与管理

2. 第 七 讲 GIS工程计划与管理 7.1 项目管理过程概述 7.2 生产率和质量的度量 7.3 在工程过程中使用度量 7.4 软件项目估算 7.5 软件开发成本估算 7.6 风险分析 7.7 进度安排 7.8 项目的组织与计划

3. 7.1 项目管理过程概述 • GIS项目管理的对象是GIS工程项目。它所涉及的范围覆盖了整个工程过程。 • 为使项目开发获得成功，必须对开发项目的工作范围、可能遇到的风险、需要的资源(人、硬／软件)、要实现的任务、经历的里程碑、花费的工作量(成本)，以及进度的安排等等做到心中有数：而项目管理可以提供这些信息。这种管理开始于技术工作开始之前，在从概念到实现的过程中持续进行，最后终止于工程过程结束。

4. 7.1 项目管理过程概述 7.1.1 项目启动 明确系统的目标和范围（系统的基本功能），考虑可能的解决方案，说明技术和管理上的要求。 • 目标标明了项目的目的，但不涉及如何去达到这些目的。范围标明了要实现的基本功能，并尽量以定量的方式界定这些功能。 • 当明确了项目的目标和范围后，就应考虑可能的解决方案，标明技术和管理上的要求。

5. 7.1 项目管理过程概述 7.1.2 度量 • 度量的目的，是帮助工程人员了解产品开发的技术过程和产品。对开发过程进行度量的目的是为了改进开发过程，而对产品进行度量的目的是为了提高产品质量。 • 度量的作用是为了有效地定量地进行管理。度量的目的是为了把握软件工程过程的实际情况和它所生产的产品质量。在对过去未度量过的事项进行度量时，需要解决的问题是：哪些度量适合于过程和产品?如何使用收集到的数据?用于比较个人、过程或产品的度量是否合理?

6. 7.1 项目管理过程概述 7.1.3 估算 • 在软件项目管理过程中一个关键的活动是制定项目计划。 • 在做计划时，必须就需要的人力、项目持续时间、成本作出估算。 • 经验估算，参考以前类似的项目。 • 也可利用估算技术，虽然它们各有其优缺点，但以下几方面是共同的：事先建立工作范围；以度量(以往的度量)为基础作出估算；把项目分解为可单独进行估算的小块。管理人员可使用各种估算技术，并可用一种估算技术作为另一种估算技术的交叉检查。

7. 7.1 项目管理过程概述 7.1.4 风险分析 • 风险分析对于软件项目管理是决定性的 • 风险分析实际上就是贯穿在软件工程过程中的一系列风险管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和风险监督。 • TomGilb在他的有关软件工程管理的书中写道：“如果谁不主动地攻击(项目和技术)风险，它们就会主动地攻击谁”。

8. 7.1 项目管理过程概述 7.1.5 进度安排 • 每一个软件项目都要求制定一个进度安排。 • 首先识别一组项目任务，再建立任务之间的相互关联，然后估算各个任务的工作量，分配人力和其他资源，制定进度时序。 • 对于进度安排，需要考虑的是：预先对进度如何计划?工作怎样就位?如何识别定义好的任务?管理人员对结束时间如何掌握，如何识别和监控关键路径以确保结束?对进展如何度量?以及如何建立分隔任务的里程碑。软件项目的进度安排与任何一个工程项目的进度安排没有实质上的不同。

9. 7.1 项目管理过程概述 7.1.6 追踪和控制 • 一旦建立了开发进度安排，就可以开始着手追踪和控制活动。 • 由项目管理人员负责追踪在进度安排中标明的每一个任务。如果任务实际完成日期滞后于进度安排，则管理人员可以使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响。 • 此外，还可对资源重新定向，对任务重新安排，或者(作为最坏的结果)可以修改交付日期以调整已经暴露的问题。用这种方式可以较好地控制系统的开发。

10. 7.2 生产率和质量的度量 • 对于任何一个工程项目来说度量都是最基本的工作，GIS工程也不例外。 LordKelvin曾说过：“如果谁能够度量他所说的事物并能用数字来表示它时，则说明他了解了它；但当他不能度量它，也不能用数字表示出来时，则说明他对那种事物的知识还比较贫乏、不足；这也可能是了解的开始，但在他的思想中很难达到科学的境地”。

11. 7.2 生产率和质量的度量 Basili和Zelkowitz确定了五种影响软件生产率的重要因素： • 人的因素：软件开发组织的规模和专长； • 问题因素：问题的复杂性和对设计限制，以及需求变更次数 • 过程因素：使用的分析与设计技术、语言和CASE工具的有效性，及评审技术； • 产品因素：计算机系统的可靠性和性能； • 资源因素：CASE工具、硬件和软件资源的有效性。

12. 7.2 生产率和质量的度量 7.2.1 软件度量 • 软件度量涉及范围较广。在软件项目管理范围内，应主要关心生产率与质量的度量，即根据投入工作量，对软件开发活动和开发成果的质量作出度量。从计划和估算的目的出发，必须弄清历史情况；在以往的项目中，软件开发生产率如何?生产出的软件产品的质量又怎样?通过以往的生产率数据和质量数据如何来推断现在的生产率和质量?如何利用这些数据来进行更精确的计划和估算? • 对软件进行度量的目的是：表明软件产品的质量、弄清软件开发的生产率、给出使用了新的软件工程方法和工具所得到的(在生产率和质量两方面)的效益、建立项目估算的“基线”、帮助调整对新的工具和附加培训的要求。

13. 7.2 生产率和质量的度量 软件度量可分为两类： • 直接度量：工程过程的直接度量包括所投入的成本和工作量。软件产品的直接度量包括产生的代码行数(LOC)、执行速度、存储量大小、在某种时间周期中所报告的错误数。 • 间接度量：产品的间接度量则包括功能性、复杂性、效率、可靠性、可维护性和许多其他的质量特性。 • 只要事先建立特定的度量规则，很容易做到直接度量开发软件所需要的成本和工作量、产生的代码行数等。但是，软件的功能性、效率，可进一步将软件度量范围如下图所示那样进行分类。

14. 7.2 生产率和质量的度量 从图中可知，软件生产率度量主要集中在软件工程过程的输出；软件质量度量可指明软件能够在多大程度上满足明确和不明确的用户要求(软件使用合理性)；而技术度量则主要集中在软件的一些特性(如逻辑复杂性、模块化程度)上而不是软件开发的全过程。

15. 7.2 生产率和质量的度量 7.2.2 面向规模的度量 • 面向规模的度量是对软件和软件开发过程的直接度量。软件开发组织可以建立一个面向规模的数据表格来记录项目的某些信息。 • 指标包括工作量、经济成本、代码行数、文档页数、错误数和人数等

16. 7.2 生产率和质量的度量 7.2.2 面向规模的度量 • 下面的表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据。 • 如项目aaa—01的开发规模为12.1kLOC(千代码行)，工作量用了24个人月，成本为168000元。 • 进一步地，关于项目aaa—01的信息还表明开发出的文档有365页，在交付用户使用后第一年内发现了27个错误，有3个人参加了项目aaa—01的软件开发工作。

17. 7.2 生产率和质量的度量 • 对于每一个项目，可以根据表格中列出的基本数据进行一些简单的面向规模的生产率和质量的度量。例如，可以根据图2对所有的项目计算出平均值： 生产率＝kLOC／PM(人月) 质 量＝错误数／kLOC 此外，也可以计算出其他令人感兴趣的度量： 成 本＝元／LOC 文 档＝文档页数／kLOC • 对面向规模的度量一直是有争议的，还没有一种为人们普遍接受的度量软件开发过程的方法。争议主要集中在是否使用代码行数(LOC)作为度量准则。 • LOC度量的支持者们认为LOC是所有软件开发项目的必然产物，它能够很容易地被计算出来，许多现存的软件估算模型都是使用LOC或者kLOC作为关键输入的，而且大量以LOC为根据的文献和数据已经存在。而反对者们则认为LOC度量与程序设计语言有关，它们不适用于设计很好且较短的程序，也不适合于非过程型语言。若在估算中使用，很难达到要求的精度(计划人员必须在分析和设计远未完成之前就要估算出需要生产的LOC)。

18. 7.2 生产率和质量的度量 7.2.3 面向功能的度量 • 面向功能的软件度量是对软件和软件开发过程的间接度量; • 面向功能度量的注意力集中于程序的“功能性”和“实用性”; • 该度量是由Albrecht首先提出来的。他提出了一种叫做功能点方法的生产率度量法，该方法利用有关软件数据域的一些计数度量和软件复杂性估计的经验关系式，导出功能点FPS(Function Points)。 • 功能点通过填写图3所示的表格来计算。首先要确定五个数据域的特征，并在表格中相应位置给出计数。数据域的值以如下方式定义：

19. 7.2 生产率和质量的度量 • 一旦收集到上述数据，就可以计算出与每一个计数相关的加权复杂性值。使用功能点方法的单位要自行拟定一些准则，用以确定一个特定项是简单的、平均的还是复杂的。尽管如此，复杂性的确定多少还是带点主观因素的。计算功能点，用如下的关系式： FP＝总计数*(0.65十0.01 *sum(Fi)) • 其中，总计数是由上图所得到的所有加权复杂性值的和；Fi(i＝1到14)是复杂性校正值，它们应通过逐一回答下图所提问题来确定。sum(Fi)是求和函数。上述等式中的常数和应用于数据域计数的加权因数可经验地确定。

20. 7.2 生产率和质量的度量 7.2.4 软件质量的度量 • 质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。 • 在软件交付之前得到的度量提供了一个定量的根据，以作出设计和测试质量好坏的判断。这一类度量包括程序复杂性、有效的模块性和总的程序规模。 • 在软件交付之后的度量则把注意力集中于残存的差错数和系统的可维护性方面。特别要强调的是，运行期间的软件质量度量可向管理者和技术人员表明软件工程过程的有效性达到什么程度。

21. 7.2 生产率和质量的度量 （1）影响软件质量的因素 McCall定义了一组质量因素。这些因素从三个不同的方面来评估软件质量，即产品的运行(使用)、产品的修正(变更)及产品的转移(为使其在不同的环境中工作而作出修改，即移植)。 （2）质量的度量 已经有许多软件质量度量方法，使用得最广泛的是事后度量或验收度量。它包括正确性、可维护性、完整性和可使用性。

22. 7.2 生产率和质量的度量 7.2.5 协调不同的度量方法 • 代码行数和功能点之间的关系与实现软件的程序设计语言和设计质量有关。有一些研究试图找出FP度量和LOC度量间的关连。 • 下表给出使用各种程序设计语言建立一个功能点所需要的平均代码行数的粗略估算。表中的数据表明，一个Ada的LOC比—个FORTRAN的提供了几乎1-4倍的“功能性”。在FP和LOC之间的关系方面，Jones给出了更精确的数据，可用来根据LOC数计算功能点数。

23. 7.2 生产率和质量的度量

24. 7.3 在工程过程中使用度量 通过对生产率度量和质量度量提出要求和评价，管理部门能够建立改进工程过程的目标。如果软件开发过程能够得到改进，对整个机构的工作将产生直接影响。而要建立改进目标，就必须了解软件开发的当前状态因此，可使用度量来建立过程的基线，根据此基线来评估改进。 7.3.1 建立基线 • 建立实用的项目估算、生产高质量的软件、按期提交产品，这是软件项目管理人员必然会遇到的一些最基本的也是最重要的问题。通过使用度量建立项目基线，就能对这些问题进行管理。 • 质量度量数据一旦收集到，软件开发组织就可以根据它们来调整其软件工程项目，以消除那些对软件开发有重大影响的错误产生的根源。

25. 7.3 在工程过程中使用度量 基线由从以往的软件开发项目中收集到的数据构成，为了帮助计划、成本和工作量估算，基线的数据应当具有下列属性： • 数据必须是合理的、精确的，应当避免单纯根据以往项目进行“盲目估算”； • 应当从尽可能多的项目中收集数据； • 对于所有成为数据收集对象的项目，对代码行的解释都应是一致的； • 基线数据的应用必须与要做估算的工作类似。如果把一个适用于批处理系统工作的基线用于估算一个实时微处理器的应用就没有什么意义。

26. 7.3 在工程过程中使用度量 7.3.2 度量数据的收集、计算和评价 建立一个基线的过程如图5所示。理想情况下，建立基线所需要的数据应在开发的过程中进行收集。因此，数据收集要求对以往的项目做历史调查，并根据调查结果来构造所需要的数据。一旦收集到数据，就可以做度量计算。最后，应当对计算出来的数据进行评价，并把它们用到估算中去。数据评价的焦点应集中于所得结果的合理性上：计算出来的中间值是否适合手头的项目?是否存在某些被掩盖的情况会导致估算中用到的某些数据无效?等等。必须对这些问题进行分析以免盲目地使用度量数据。

27. 7.3 在工程过程中使用度量 右图给出了一张表格模型，可使用它对历史软件基线数据进行收集和计算。这种模型包括了成本数据、面向规模的数据、面向功能的数据，可以计算面向源代码行数IOC的度量和面向FP的度量。应当注意的是，要想收集到这个模型所要求的所有数据不总是可能的。如果使用这个模型对以往的许多项目进行收集和计算，就能建立起软件度量基线。

28. 7.4 软件项目估算 在做软件项目估算时往往存在某些不确定性，使得软件项目管理人员无法正常进行管理而导致产品迟迟不能完成。现在已使用的实用技术是时间和工作量估算。因为估算是所有其他项目计划活动的基石，且项目计划又为软件工程过程提供了工作方向，所以不能没有计划就开始着手开发，否则将会陷入盲目性。 7.4.1 针对估算的考虑 • 估算资源、成本和进度时需要经验、历史信息、足够的定量数据。增加风险的因素如下图所示。轴线表示所估算项目的特征。 • 项目规模对于软件估算的精确性影响也比较大。因为随着软件规模的扩大，软件元素之间的相互依赖、相互影响程度也迅速增加，因而估算的一个重要方法——问题分解也会变得更加困难。

29. 7.4 软件项目估算 • 项目的结构化程度也影响项目估算的风险。结构性是指功能分解的简便性和处理信息的层次性。图8表明随着结构化程度的提高，精确估算的能力也能提高，而风险将减少。 • 历史信息的有效性也影响估算的风险。回顾过去，就能够仿效做过的事，且改进出现问题的地方。在对过去的项目进行综合的软件度量之后。就可以借用来比较准确地进行估算，安排进度以避免重走过去的弯路，而总的风险也减少了。

30. 7.4 软件项目估算 7.4.2 软件项目估算的内容 （1）计划的目标 • 项目计划的目标是提供一个能使项目管理人员对资源、成本和进度做出合理估算的框架。这些估算应当在软件项目开始时的一个时间段内作出，并随着项目的进展定期更新。 • 如上所述，在不断发现导致合理估算的信息的过程中，逐步达到计划的目标。 （2）系统的范围 软件项目估算要确定系统的范围。包括系统的功能、性能、限制、接口和可靠性等。

31. 7.4 软件项目估算 （3）开发中的资源 • 对完成该项目所需的资源进行估算。 • 把系统开发所需的资源画成一个金字塔，在塔的底部必须有现成的用以支持软件开发的工具——硬件工具及软件工具； • 在塔的高层是最基本的资源——人。 • 通常，对每一种资源，应说明以下四个特性：资源的描述、资源的有效性说明、资源在何时开始需要、使用资源的持续时间。最后两个特性统称为时间窗口。对每一个特定的时间窗口，在开始使用它之前就应说明它的有效性。

32. 7.4 软件项目估算 （4）成本和工作量估算 • 在计算技术发展的早期，软件的成本在基于计算机的系统的总成本中只占一个很小的百分比。在软件成本的估算上，出现一个数量级的误差，其影响相对还是比较小的。但现在软件在大多数基于计算机的系统中已成为最昂贵的部分。如果软件成本估算的误差很大，就会使盈利变成亏损。对于开发者来说，成本超支可能是灾难性的。 • 软件成本和工作量的估算从来都没有成为一门精确的科学。因为变化的东西太多，人、技术、环境、政治，都会影响软件的最终成本和开发的工作量。但是，软件项目的估算还是能够通过一系列系统化的步骤，在可接受的风险范围内提供估算结果。

33. 7.4 软件项目估算 7.4.3 分解技术 • 当一个待解决的问题过于复杂时，可以把它进一步分解，直到分解后的子问题变得容易解决为止。然后，分别解决每一个子问题，并将这些子问题的解答综合起来，从而得到原问题的解答。 • 软件项目估算是一种解决问题的形式，在多数情况下，要解决的问题(对于软件项目来说，就是成本和工作量的估算)非常复杂，一次性整体解决比较困难。因此，对问题进行分解，分解成一组较小的接近于最终解决的可控的子问题，再定义它们的特性。 （1）LOC和FP估算 • 前面介绍了代码行(LOC)和功能点(FP)，并使用它们作为基本数据来计算生产率度量。在软件项目估算中，两个方面使用LOC和FP数据： • 当做一个估算变量，用于量度软件每一个元素的大小。 • 联合使用从过去项目中收集到的基线数据和其他估算变量，进行成本和工作量估算。

34. 7.4 软件项目估算 • LOC和FP是两个不同的估算技术。但两者有许多共同特性。项目计划人员首先给出一个有界的软件范围的叙述，再由此尝试着把软件分解成一些小的可分别独立进行估算的子功能。然后对每一个子功能估算其LOC或FP(FP估算变量)。接着，把基线生产率度量(如，LOC／PM或FP／PM)用做特定的估算变量，导出子功能的成本或工作量。将子功能的估算进行综合后就能得到整个项目的总估算。 • 作为LOC和FP估算技术的一个实例，考察一个为计算机辅助设计(CAD)应用而开发的软件包。系统定义评审指明，软件是在一个工作站上运行，其接口必须使用各种计算机图形设备，包括鼠标、数字化仪、高分辩率彩色显示器和激光打印机。在这个实例中，使用LOC作为估算变量。当然，FP也可使用，但这时需要进行在前节所说的数据域取值的估算。

35. 7.4 软件项目估算 • 根据系统定义，软件范围的初步叙述如下；“软件将通过操作员接收2维或3维几何数据。操作员通过用户界面与CAD系统交互并控制它，这种用户界面将表现出很好的人机接口设计特性。所有的几何数据和其他支持信息保存在一个CAD数据库内。要开发一些设计分析模块以产生在各种图形设备上显示的输出。软件要设计得能控制并能与各种外部设备，包括鼠标、数字化仪、激光打印机和绘图仪交互”。 • 现在假定进一步的细化已做过，并且已识别出该软件包具有以下主要的软件功能：用户界面和控制功能、二维几何分析、三维几何分析、数据库管理、计算机图形显示功能、外设控制、设计分析模块。通过下述的分解技术，可得到如表3所示的估算表。表中给出了LOC的估算范围。

36. 7.4 软件项目估算

37. 7.4 软件项目估算 • 从表中的前三列可以看出，计划人员对外设控制功能所需要的LOC是相当清楚的，其最佳估算值和悲观估算值之间仅相差450代码行。另一方面，对三维几何分析功能相对来说不很熟悉，在最佳估算值和悲观估算值之间相差达4000LOC。计算出的各功能的期望值放入表中的第4列。然后对该列垂直求和，得到该CAD系统的LOC估算值33360。 • 从历史的基线数据求出生产率度量，即行／PM和元／行。在这种情况中，计划人员需要根据复杂性程度的不同，对各功能使用不同的生产率度量值。在表中的成本和工作量这两列的值分别用LOC的期望值E与元／行相乘，及用LOC的期望值E与行／PM相除得到。因此可得，该项目总成本的估算值为657000元，总工作量的估算值为145人月(PM)。

38. 7.4 软件项目估算 （2）工作量估算 • 工作量估算是估算任何工程开发项目成本的最普遍使用的技术。每一项目任务的解决都需要花费若干人日、人月或人年。每一个工作量单位都对应于一定的货币成本，从而由此作出成本估算。 • 类似于LOC或FP技术，工作量估算首先从软件项目范围抽出软件功能。接着给出为实现每一软件功能所必须执行的一系列软件工程任务，包括需求分析、设计、编码和测试。表4给出了解各个软件功能和相关的软件工程任务。 • 计划人员针对每一软件功能，估算完成各个软件工程任务所需的工作量(如人月)，并记在表4的中心部分。高级技术人员主要投入到需求分析和早期的设计任务中，而初级技术人员则进行后期设计任务、编码和早期测试工作，他们所需成本比较低。

39. 7.4 软件项目估算

40. 7.4 软件项目估算 • 最后一个步骤就是计算每一个功能及软件工程任务的工作量和成本，横向和纵向的总计给出所需要的工作量。如果工作量估算是不依赖LOC或FP估算而实现的，那么就可得到两组能进行比较和调和的成本与工作量估算。如果这两组估算值合理地一致，则估算值是可靠的。如果估算的结果不一致，就有必要做进一步的检查与分析。在表中，“前期”的开发任务(需求分析和设计)，花费了75个人月，说明这些工作相当重要。 • 与每个软件工程任务相关的劳动费用率记入表中费用率(元)这一行，这些数据反映了“负担”的劳动成本，即包括公司开销在内的劳动成本。在此例中，需求分析的劳动成本为5200元／PM，比编码和单元测试的劳动成本高出22％。

41. 7.4 软件项目估算 • CAD软件总成本和总工作量的估算分别为708000元和153人月(PM)。若与使用LOC技术导出的数据相比，成本相差7％，而工作量相差5％，所得到的结果非常接近一致。 • 如果两种估算方法所得结果之间的一致性很差，就必须重新确定估算所使用的信息。如果要追寻产生差距的原因，不外乎以下两个原因之一： • 计划人员没有充分了解或误解了项目的范围； • 用于LOC估算的生产率数据不适合于本项目，过时了(即使用这些数据不能正确反映软件开发机构的情况)，或者是误用了。计划人员必须确定产生差距的原因再来协调估算结果。

42. 7.5 软件开发成本估算 • 软件开发成本，主要是指软件开发过程中所花费的工作量及相应的代价，不包括原材料和能源的消耗，主要是人的劳动的消耗。 • 软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。 • 因此软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、组装测试到确认测试，整个软件开发全过程所花费的人工代价作为依据的。

43. 7.5 软件开发成本估算 7.5.1 软件开发成本估算方法 对于一个大型的软件项目，由于项目的复杂性，开发成本的估算不是一件简单的事，要进行一系列的估算处理。主要靠分解和类推的手段进行。基本估算方法分为三类。 （1）自顶向下的估算方法 • 这种方法的想法是从项目的整体出发进行类推。即估算人员根据以前已完成项目所耗费的总成本(或总工作量)，推算将要开发的软件的总成本(或总工作量)，然后按比例将它分配到各开发任务中，再检验它是否能满足要求。表5是一个可参考例子 • 这种方法的优点是估算工作量小，速度快。缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。

44. 7.5 软件开发成本估算

45. 7.5 软件开发成本估算 （2）自底向上的估计法 这种方法的想法是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。这是一种常见的估算方法。它的优点是估算各个部分的准确性高。缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量(配置管理、质量管理、项目管理)。所以往往估算值偏低，必须用其他方法进行检验和校正。 （3）差别估计法 这种方法综合了上述两种方法的优点，其想法是把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和不同的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。这种方法的优点是可以提高估算的准确程度，缺点是不容易明确“类似”的界限。

46. 7.5 软件开发成本估算 7.5.2 专家判定技术 • 由多位专家进行成本估算，取得多个估算值。 • 把多位专家的估算值合成一个估算值。 • 例如，一种方法是简单地求各估算值的中值或平均值。其优点是简便。缺点是可能会由于受一、二个极端估算值的影响而产生严重的偏差。另一种方法是召开小组会，使各位专家们统一于或至少同意某一个估算值。优点是可以剔除蒙昧无知的估算值，缺点是一些组员可能会受权威或政治因素的影响。为了避免上述不足，Rand公司提出了Deiphi技术，作为统一专家意见的方法。用Deiphi技术可得到极为准确的估算值。

47. 7.5 软件开发成本估算 (1)组织者发给每位专家一份软件系统的规格说明书(略去名称和单位)和一张记录估算值的表格，请他们进行估算。 (2)专家详细研究软件规格说明书的内容。然后组织者召集小组会议，在会上，专家们与组织者一起对估算问题进行讨论。 (3)各位专家对该软件提出三个规模的估算值，即： di——该软件可能的最小规模(最少源代码行数)； mi——该软件最可能的规模(最可能的源代码行数)； bi——该软件可能的最大规模(最多源代码行数)。 无记名地填写表格，并说明做此估算的理由。 (4)组织者对各位专家在表中填写的估算值进行综合和分类，做以下事情： 1)计算各位专家(序号为i，I=1，2，…，n)的估算期望值： 2)对专家的估算结果进行分类摘要。

48. 7.5 软件开发成本估算 (5)组织者召集会议，请专家们对其估算值有很大变动之处进行讨论。专家对此估算值，做一次估算。 (6)在综合专家估算结果的基础上，组织专家再次无记名地填写表格。 (7)从(4)到(6)适当重复几次。最终可获得一个得到多数专家共识的软件规模(源代码数）： 最后，通过与历史资料进行类比，根据过去完成项目的规模和成本等信息，推算出该软件每行源代码所需成本。然后再乘以该软件源代码行数的估算值，得到该软件的成本估算值。

49. 7.5 软件开发成本估算 7.5.3 软件开发成本估算的经验模型 软件开发成本估算的依据是开发成本估算模型。开发成本估算模型通常采用经验公式中预测软件项目计划所需要的成本、工作量和进度。用以支持大多数模型的经验数据都是从有限的一些项目样本中得到的。因此，还没有一种估算模型能够适用于所有的软件类型和开发环境，从这些模型中得到的结果必须慎重使用。

50. 7.5 软件开发成本估算 IBM模型 • 1977年，Walston和Felix总结了IBM联合系统分部(FSD)负责的60个项目的数据。各项目的源代码行数从400行到467000行，开发工作量从12PM到11758PM，共使用20种不同语言和66种计算机。利用最小二乘法拟合，得到如下估算公式： E＝5.2×L0.91 D=4.1×L0.36=13.47×E0.35 S＝0.54×E0.6 DOC=49×L1.01 • 其中，L是源代码行数(以KLOC计)，E是工作量(以PM计)，D是项目持续时间，S是人员需要量(以人计)，DOC是文档数量(以页计)。 • 例如，一个软件的开发工作量如表7所示。该软件共有源代码2900行，其中，500行用于测试，2400行是执行程序的源代码。则劳动生产率是：(2900—500)／10＝240(LOC／PM) • IBM模型是一个静态单变量模型，但不是一个通用公式。在应用中有时要根据具体实际情况，对公式中的参数进行修改。