GIS工程讲义 第八讲 GIS工程计划与管理

第八讲 1 项目管理过程 它所涉及的范围覆盖了整个工程过程 。 为使项目开发获得成功 ， 必须对开发项目的工作范围 、 可能遇到的风险 、 需要的资源 (人 、硬软件 )、 要实现的任务 、 经历的里程碑 、 花费的工作量 (成本 )， 以及进度的安排等等做到心中有数：而项目管理可以提供这些信息 。 这种管理开始于技术工作开始之前 ， 在从概念到实现的过程中持续进行 ， 最后终止于工程过程结束 。 (1)启动一个项目 设计人员和用户是在系统工程阶段确定项目的目标和范围 。 目标标明了项目的目的 ， 但不涉及如何去达到这些目的 。 范围标明了要实现的基本功能 ， 并尽量以定量的方式界定这些功能 。 当明确了项目的目标和范围后 ， 就应考虑可能的解决方案 ， 标明技术和管理上的要求 。 虽然涉及方案细节不多 ， 但有了方案 ， 管理人员和技术人员就能够据此选择一种 “ 好的 ” 方法 ，确定合理 、 精确的成本估算 ， 实际可行的任务分解以及可管理的进度安排 。 (2) 度量 进行度量工作 ， 是为了帮助工程人员了解产品开发的技术过程和产品 。 对开发过程进行度量的目的是为了改进开发过程 ， 而对产品进行度量的目的是为了提高产品质量 。 度量的作用是为了有效地定量地进行管理。度量的目的是为了把握软件工程过程的实际情况和它所生产的产品质量。在对过去未度量过的事项进行度量时，需要解决的问题是：哪些度量适合于过程和产品 ?如何使用收集到的数据 ?用于比较个人、过程或产品的度量是否合理 ? (3) 估算 - 在软件项目管理过程中一个关键的活动是制定项目计划 。 在做计划时 ， 必须就 需要的人力 、 项目持续时间 、成本作出估算 。 这种估算大多是参考以前的花费作出的 。 如果新项目与以前的一个项目在大小上和功能上十分类似 ， 则新项目所需要的工作量 、 开发时间 、 成本大致与那个老项目相同 。 但对于背景完全生疏的项目 ， 只凭过去的经验作出估算可能就不够了 。 现在已有了许多用于开发的估算技术 。 虽然各有其优缺点 ，但以下几方面是共同的：事先建立工作范围；以度量(以往的度量 )为基础作出估算；把项目分解为可单独进行估算的小块 。 管理人员可使用各种估算技术 ， 并可用一种估算技术作为另一种估算技术的交叉检查 。 (4)风险分析 风险分析对于软件项目管理是决定性的 ， 然而现在还是有许多项目不考虑风险就着手进行 。 如果谁不主动地攻击 (项目和技术 )风险 ， 它们就会主动地攻击谁 ” 。 风险分析实际上就是贯穿在软件工程过程中的一系列风险管理步骤 ，其中包括风险识别 、 风险估计 、 风险管理策略 、风险解决和风险监督 ， 它能让人们去主动 “ 攻击 ” 风险 。 (5)进度安排 每一个软件项目都要求制定一个进度安排 ， 但不是所有的进度都得一样安排 。 对于进度安排 ，需要考虑的是：预先对进度如何计划 ?工作怎样就位 ?如何识别定义好的任务 ?管理人员对结束时间如何掌握 ， 如何识别和监控关键路径以确保结束 ?对进展如何度量 ?以及如何建立分隔任务的里程碑 。 软件项目的进度安排与任何一个工程项目的进度安排没有实质上的不同 。 首先识别一组项目任务 ， 再建立任务之间的相互关联 ， 然后估算各个任务的工作量 ， 分配人力和其他资源 ， 制定进度时序 。 (6)追踪和控制 一旦建立了开发进度安排 ， 就可以开始着手追踪和控制活动 。 由项目管理人员负责追踪在进度安排中标明的每一个任务 。 如果任务实际完成日期滞后于进度安排 ， 则管理人员可以使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响 。 此外 ，还可对资源重新定向 ， 对任务重新安排 ， 或者(作为最坏的结果 )可以修改交付日期以调整已经暴露的问题 。 用这种方式可以较好地控制系统的开发 。 2 生产率和质量的度量 对于任何一个工程项目来说度量都是最基本的工作 ， “ 如果谁能够度量他所说的事物并能用数字来表示它时 ， 则说明他了解了它；但当他不能度量它 ， 也不能用数字表示出来时 ， 则说明他对那种事物的知识还比较贫乏 、 不足；这也可能是了解的开始 ， 但在他的思想中很难达到科学的境地 ” 。 2 1 软件度量 软件度量涉及范围较广 。 在软件项目管理范围内 ， 应主要关心生产率与质量的度量 ， 即根据投入工作量 ， 对软件开发活动和开发成果的质量作出度量 。 从计划和估算的目的出发 ， 必须弄清历史情况；在以往的项目中 ， 软件开发生产率如何 ?生产出的软件产品的质量又怎样 ?通过以往的生产率数据和质量数据如何来推断现在的生产率和质量 ?如何利用这些数据来进行更精确的计划和估算 ? 对软件进行度量的目的是：表明软件产品的质量 、弄清软件开发的生产率 、 给出使用了新的软件工程方法和工具所得到的 (在生产率和质量两方面 )的效益 、 建立项目估算的 “ 基线 ” 、 帮助调整对新的工具和附加培训的要求 。 在物理世界中的度量有两种方式 。 一种是 直接度量 (如度量一个螺栓的长度 )；一种是 间接度量 (如用次品率来度量生产出的螺栓质量 )。 软件度量也同样分为两类 。 工程过程的直接度量 包括所投入的成本和工作量 。 软件产品的直接度量包括产生的代码行数( 执行速度 、 存储量大小 、 在某种时间周期中所报告的错误数 。 而产品的间接度量 则包括功能性 、 复杂性 、 效率 、 可靠性 、可维护性和许多其他的质量特性 。 只要事先建立特定的度量规则 ，很容易做到直接度量开发软件所需要的成本和工作量 、 产生的代码行数等 。 但是 ， 软件的功能性 、 效率 、 可进一步将软件度量范围如图 1所示那样进行分类 。 从图中可知 ， 软件生产率度量主要集中在软件工程过程的输出；软件质量度量可指明软件能够在多大程度上满足明确和不明确的用户要求 (软件使用合理性 )；而技术度量则主要集中在软件的一些特性 (如逻辑复杂性 、 模块化程度 )上而不是软件开发的全过程 。 2 2 面向规模的度量 面向规模的度量是对软件和软件开发过程的直接度量 。软件开发组织可以建立一个如图 2所示的面向规模的数据表格来记录项目的某些信息 。 该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据 。 如项目 1的开发规模为12 1代码行 )， 工作量用了 24个人月 ， 成本为168000元 。 需要注意的是 ， 在表格中记载的工作量和成本属于整个软件工程的活动 (分析 、 设计 、 编码和测试 )， 而不仅仅是编码活动 。 进一步地 ， 关于项目 1的信息还表明开发出的文档有 365页 ， 在交付用户使用后第一年内发现了 29个错误 ， 有 3个人参加了项目1的软件开发工作 。 对于每一个项目 ， 可以根据表格中列出的基本数据进行一些简单的面向规模的生产率和质量的度量 。 例如 ， 可以根据图 2对所有的项目计算出平均值： 生产率 月 ) 质 量错误数 此外 ， 也可以计算出其他令人感兴趣的度量： 成 本：元 文 档文档页数 对面向规模的度量一直是有争议的 ， 还没有一种为人们普遍接受的度量软件开发过程的方法 。 争议主要集中在是否使用代码行数 (为度量准则 。 它能够很容易地被计算出来 ， 许多现存的软件估算模型都是使用 而且大量以 而反对者们则认为 它们不适用于设计很好且较短的程序 ， 也不适合于非过程型语言 。 若在估算中使用 ， 很难达到要求的精度 (计划人员必须在分析和设计远未完成之前就要估算出需要生产的 2 3 面向功能的度量 面向功能的软件度量是对软件和软件开发过程的间接度量 。 面向功能度量的注意力集中于程序的 “ 功能性 ”和 “ 实用性 ” ， 而不是对 该度量是由 他提出了一种叫做功能点方法的生产率度量法 ， 该方法利用有关软件数据域的一些计数度量和软件复杂性估计的经验关系式 ， 导出功能点 功能点通过填写图 3所示的表格来计算 。 首先要确定五个数据域的特征 ， 并在表格中相应位置给出计数 。 数据域的值以如下方式定义： 一旦收集到上述数据 ， 就可以计算出与每一个计数相关的加权复杂性值 。 使用功能点方法的单位要自行拟定一些准则 ， 用以确定一个特定项是简单的 、 平均的还是复杂的 。 尽管如此 ， 复杂性的确定多少还是带点主观因素的 。 计算功能点 ， 使用如下的关系式： 计数 X(0 65十 0 01 ) (13 1) 其中 ， 总计数是由图 13 3所得到的所有加权复杂性值的和； Fi(i 1到 14)是复杂性校正值 ， 它们应通过逐一回答图 4所提问题来确定 。 i)是求和函数 。 上述等式中的常数和应用于数据域计数的加权因数可经验地确定 。 2 4 软件质量的度量 质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后 。 在软件交付之前得到的度量提供了一个定量的根据 ， 以作出设计和测试质量好坏的判断 。 这一类度量包括程序复杂性 、 有效的模块性和总的程序规模 。 在软件交付之后的度量则把注意力集中于残存的差错数和系统的可维护性方面 。 特别要强调的是 ，运行期间的软件质量度量可向管理者和技术人员表明软件工程过程的有效性达到什么程度 。 (1)影响软件质量的因素 这些因素从三个不同的方面来评估软件质量 ， 即产品的运行 (使用 )、 产品的修正 (变更 )及产品的转移 (为使其在不同的环境中工作而作出修改 ， 即移植 )。 他们在自己的论文中介绍了这些质量因素之间的关系 (叫做框架 )和软件工程过程的其他方面 。 参看前讲 。 (2)质量的度量 已经有许多软件质量度量方法 ， 使用得最广泛的是事后度量或验收度量 。它包括正确性 、 可维护性 、 完整性和可使用性 。 2 5 协调不同的度量方法 代码行数和功能点之间的关系与实现软件的程序设计语言和设计质量有关 。 有一些研究试图找出 “ 应用提供的功能数 ， 可以其于这个应用所使用或产生的数据来作出估算 。 而且 ， 功能的估算应与要开发的 。 表 13 1给出使用各种程序设计语言建立一个功能点所需要的平均代码行数的粗略估算表中的数据表明 ， 个 个 ) 4倍的 “ 功能性 ” 。 而一个 45倍的 “ 功能性 ” ， 在 可用来根据 (1)人的因素：软件开发组织的规模和专长； (2)问题因素：问题的复杂性和对设计限制 ， 以及需求的变更次数； (3)过程因素：使用的分析与设计技术 、 语言 和 及评审技术； (4)产品因素：计算机系统的可靠性和性能； (5)资源因素： 硬件和软件资源 的有效性 。 对于一个给定的项目 ， 上述的某一因素的取值高于平均值 (条件非常有利 )， 那么与那些同一因素的取值低于平均值 (条件不利 )的项目比 ， 它的软件开发生产率较高 。 对于上述的五个因素 ， 从高度有利到不利条件的改变将以如表 2所示的方式影响生产率 。 3 在工程过程中使用度量 通过对生产率度量和质量度量提出要求和评价 ， 管理部门能够建立改进工程过程的目标 。 如果软件开发过程能够得到改进 ， 对整个机构的工作将产生直接影响 。而要建立改进目标 ， 就必须了解软件开发的当前状态因此 ， 可使用度量来建立过程的基线 ， 根据此基线来评估改进 。 3 1 建立基线 建立实用的项目估算 、 生产高质量的软件 、 按期提交产品 ， 这是软件项目管理人员必然会遇到的一些最基本的也是最重要的问题 。 通过使用度量建立项目基线 ，就能对这些问题进行管理 。 此外 ， 质量度量数据一旦收集到 ， 软件开发组织就可以根据它们来调整其软件工程项目 ， 以消除那些对软件开发有重大影响的错误产生的根源 。 基线由从以往的软件开发项目中收集到的数据构成 ， 可以像图 2所示的表格那样简单 ， 也可以像图 7所给出的那样复杂 。 为了帮助计划 、 成本和工作量估算 ， 基线的数据应当具有下列属性： (1)数据必须是合理的 、 精确的 ， 应当避免单纯根据以往项目进行 “ 盲目估算 ” ； (2)应当从尽可能多的项目中收集数据； (3)对于所有成为数据收集对象的项目 ， 对代码行的解释都应是一致的； (4)基线数据的应用必须与要做估算的工作类似 。 如果把一个适用于批处理系统工作的基线用于估算一个实时微处理器的应用就没有什么意义 。 3 2 度量数据的收集、计算和评价 建立一个基线的过程如图 5所示 。 理想情况下 ， 建立基线所需要的数据应在开发的过程中进行收集 。 然而这很难做到 。 因此 ， 数据收集要求对以往的项目做历史调查 ， 并根据调查结果来构造所需要的数据 。 一旦收集到数据 ， 就可以做度量计算 。 最后 ， 应当对计算出来的数据进行评价 ， 并把它们用到估算中去 。 数据评价的焦点应集中于所得结果的合理性上：计算出来的中间值是否适合手头的项目 ?是否存在某些被掩盖的情况会导致估算中用到的某些数据无效 ?等等 。 必须对这些问题进行分析以免盲目地使用度量数据 。 图 7给出了一张表格模型 ， 可使用它对历史软件基线数据进行收集和计算 。 这种模型包括了成本数据 、 面向规模的数据 、 面向功能的数据 ， 可以计算面向源代码行数 应当注意的是 ， 要想收集到这个模型所要求的所有数据不总是可能的 。如果使用这个模型对以往的许多项目进行收集和计算 ，就能建立起软件度量基线 。 4 软件项目估算 在做软件项目估算时往往存在某些不确定性 ，使得软件项目管理人员无法正常进行管理 而导致产品迟迟不能完成 。 现在已使用的实用技术是时间和工作量估算 。 因为估算是所有其他项目计划活动的基石 ， 且项目计划又为软件工程过程提供了工作方向 ， 所以不能没有计划就开始着手开发 ， 否则将会陷入盲目性 。 4 1 针对估算的考虑 估算资源 、 成本和进度时需要经验 、 有用的历史信息 、足够的定量数据 。 估算有风险 。 增加风险的因素如图 8所示 。 图中的轴线表示所估算项目的特征 。 项目的规模对于软件估算的精确性影响也比较大 。 因为随着软件规模的扩大 ， 软件了元素之间的相互依赖 、相互影响程度也迅速增加 ， 因而估算的一个重要方法 问题分解也会变得更加困难 。 由此可知 ， 项目的规模越大 ， 开发工作量越大 ， 估算的风险越高 。 项目的结构化程度也影响项目估算的风险 。 结构性是指功能分解的简便性和处理信息的层次性 。 图 8表明随着结构化程度的提高 ， 精确估算的能力也能提高 ， 而风险将减少 。 历史信息的有效性也影响估算的风险 。 回顾过去 ， 就能够仿效做过的事 ， 且改进出现问题的地方 。 在对过去的项目进行综合的软件度量之后 。 就可以借用来比较准确地进行估算 ， 安排进度以避免重走过去的弯路 ，而总的风险也减少了 。 4 2 项目计划的目标 项目计划的目标是提供一个能使项目管理人员对资源 、成本和进度做出合理估算的框架 。 这些估算应当在软件项目开始时的一个时间段内作出 ， 并随着项目的进展定期更新 。 如上所述 ， 在不断发现导致合理估算的信息的过程中 ， 逐步达到计划的目标 。 下面将讨论与项目计划有关的各项活动 。 4 3 系统的范围 项目计划的第一项活动是确定系统的范围 。 4 4 开发中的资源 项目计划的第二个任务是对完成该项目所需的资源进行估算 。 图 9把系统开发所需的资源画成一个金字塔 ， 在塔的底部必须有现成的用以支持软件开发的工具 硬件工具及软件工具 ，在塔的高层是最基本的资源 人 。 通常 ， 对每 种资源 ， 应说明以下四个特性：资源的描述 、 资源的有效性说明 、 资源在何时开始需要 、使用资源的持续时间 。 最后两个特性统称为时间窗口 。 对每一个特定的时间窗口 ， 在开始使用它之前就应说明它的有效性 。 4 5软件项目估算 在计算技术发展的早期 ， 软件的成本在基于计算机的系统的总成本中只占一个很小的百分比 。 在软件成本的估算上 ， 出现一个数量级的误差 ， 其影响相对还是比较小的 。 但现在软件在大多数基于计算机的系统中已成为最昂贵的部分 。 如果软件成本估算的误差很大 ， 就会使盈利变成亏损 。 对于开发者来说 ， 成本超支可能是灾难性的 。 软件成本和工作量的估算从来都没有成为一门精确的科学。因为变化的东西太多，人、技术、环境、政治，都会影响软件的最终成本和开发的工作量。但是，软件项目的估算还是能够通过一系列系统化的步骤，在可接受的风险范围内提供估算结果。 4 6 分解技术 当一个待解决的问题过于复杂时 ， 可以把它进一步分解 ， 直到分解后的子问题变得容易解决为止 。 然后 ，分别解决每一个子问题 ， 并将这些子问题的解答综合起来 ， 从而得到原问题的解答 。 软件项目估算是一种解决问题的形式 ， 在多数情况下 ， 要解决的问题 (对于软件项目来说 ， 就是成本和工作量的估算 )非常复杂 ， 想一次性整体解决比较困难 。因此 ， 对问题进行分解 ， 把其分解成一组较小的接近于最终解决的可控的子问题 ， 再定义它们的特性 。 (1) 前面已经介绍了代码行 (功能点 ( 并使用它们作为基本数据来计算生产率度量 。 在软件项目估算中 ， 在两个方面使用了 当做一个估算变量 ， 用于量度软件每一个元素的大小 。 联合使用从过去项目中收集到的基线数据和其他估算变量 ， 进行成本和工作量估算 。 但两者有许多共同特性 。 项目计划人员首先给出一个有界的软件范围的叙述 ， 再由此尝试着把软件分解成一些小的可分别独立进行估算的子功能 。 然后对每一个子功能估算其 P(11。 接着 ， 把基线生产率度量 (如 ， P 做特定的估算变量 ， 导出子功能的成本或工作量 。 将子功能的估算进行综合后就能得到整个项目的总估算 。 作为 考察一个为计算机辅助设计 (用而开发的软件包 。 系统定义评审指明 ， 软件是在一个工作站上运行 ， 其接口必须使用各种计算机图形设备 ， 包括鼠标 、 数字化仪 、 高分辩率彩色显示器和激光打印机 。 在这个实例中 ， 使用 当然 ， 但这时需要进行在前节所说的数据域取值的估算 。 根据系统定义 ， 软件范围的初步叙述如下； “ 软件将通过操作员接收 2维或 3维几何数据 。 操作员通过用户界面与 这种用户界面将表现出很好的人机接口设计特性 。 所有的几何数据和其他支持信息保存在一个 要开发一些设计分析模块以产生在各种图形设备上显示的输出 。 软件要设计得能控制并能与各种外部设备 ， 包括鼠标 、 数字化仪 、 激光打印机和绘图仪交互 ” 。 现在假定进一步的细化已做过 ， 并且已识别出该软件包具有以下主要的软件功能：用户界面和控制功能 、二维几何分析 、 三维几何分析 、 数据库管理 、 计算机图形显示功能 、 外设控制 、 设计分析模块 。 通过下述的分解技术 ， 可得到如表 3所示的估算表 。 表中给出了 从表中的前三列可以看出 ， 计划人员对外设控制功能所需要的 其最佳估算值和悲观估算值之间仅相差 450代码行 。 另一方面 ， 对三维几何分析功能相对来说不很熟悉 ， 在最佳估算值和悲观估算值之间相差达 4000计算出的各功能的期望值放入表中的第 4列 。 然后对该列垂直求和 ， 得到该 3360。 从历史的基线数据求出生产率度量，即行 。在这种情况中，计划人员需要根据复杂性程度的不同，对各功能使用不同的生产率度量值。在表中的成本和工作量这两列的值分别用 与元行相乘，及用 与行 此可得，该项目总成本的估算值为 657000元，总工作量的估算值为 145人月 ( (2)工作量估算 工作量估算是估算任何工程开发项目成本的最普遍使用的技术 。 每一项目任务的解决都需要花费若干人日 、人月或人年 。 每一个工作量单位都对应于一定的货币成本 ， 从而可以由此作出成本估算 。 类似于 工作量估算首先从软件项目范围抽出软件功能 。 接着给出为实现每一软件功能所必须执行的一系列软件工程任务 ， 包括需求分析 、 设计 、编码和测试 。 表 4给出了解各个软件功能和相关的软件工程任务 。 计划人员针对每一软件功能 ， 估算完成各个软件工程任务所需的工作量 (如人月 )， 并记在表 4的中心部分 。高级技术人员主要投入到需求分析和早期的设计任务中 ， 而初级技术人员则进行后期设计任务 、 编码和早期测试工作 ， 他们所需成本比较低 。 最后一个步骤就是计算每一个功能及软件工程任务的工作量和成本 ， 横向和纵向的总计给出所需要的工作量 。 如果工作量估算是不依赖 那么就可得到两组能进行比较和调和的成本与工作量估算 。 如果这两组估算值合理地一致 ， 则估算值是可靠的 。 如果估算的结果不一致 ， 就有必要做进一步的检查与分析 。 在表中 ， “ 前期 ” 的开发任务 (需求分析和设计 )， 花费了 75个人月 ， 说明这些工作相当重要 。 与每个软件工程任务相关的劳动费用率记入表中费用率 (元 )这一行 ， 这些数据反映了 “ 负担 ” 的劳动成本 ，即包括公司开销在内的劳动成本 。 在此例中 ， 需求分析的劳动成本为 5200元 比编码和单元测试的劳动成本高出 22 。 08000元和 153人月( 若与使用 成本相差 7 ， 而工作量相差 5 ， 所得到的结果非常接近一致 。 如果两种估算方法所得结果之间的一致性很差 ， 就必须重新确定估算所使用的信息 。 如果要追寻产生差距的原因 ， 不外乎以下两个原因之一 ， 计划人员没有充分了解或误解了项目的范围； 用于 过时了 (即使用这些数据不能正确反映软件开发机构的情况 )， 或者是误用了 。 计划人员必须确定产生差距的原因再来协调估算结果 。 5 软件开发成本估算 这一节讨论软件开发成本 ， 主要是指软件开发过程中所花费的工作量及相应的代价 ， 不包括原材料和能源的消耗 ， 主要是人的劳动的消耗 。 此外 ， 软件产品不存在重复制造过程 ， 它的开发成本是以一次性开发过程所花费的代价来计算的 。 因此软件开发成本的估算 ，应是从软件计划 、 需求分析 、 设计 、 编码 、 单元测试 、组装测试到确认测试 ， 整个软件开发全过程所花费的人工代价作为依据的 。 5 1 软件开发成本估算方法 对于一个大型的软件项目 ， 由于项目的复杂性 ， 开发成本的估算不是一件简单的事 ， 要进行一系列的估算处理 。 主要靠分解和类推的手段进行 。 基本估算方法分为三类 。 (1)自顶向下的估算方法 这种方法的想法是从项目的整体出发 ， 进行类推 。 即估算人员根据以前已完成项目所耗费的总成本 (或总工作量 )， 推算将要开发的软件的总成本 (或总工作量 )，然后按比例将它分配到各开发任务中去 ， 再检验它是否能满足要求 。 参看表 5。 这种方法的优点是估算工作量小 ， 速度快 。 缺点是对项目中的特殊困难估计不足 ， 估算出来的成本盲目性大 ， 有时会遗漏被开发软件的某些部分 。 (2)自底向上的估计法 这种方法的想法是把待开发的软件细分 ， 直到每一个子任务都已经明确所需要的开发工作量 ， 然后把它们加起来 ， 得到软件开发的总工作量 。 这是一种常见的估算方法 。 它的优点是估算各个部分的准确性高 。缺点是缺少各项子任务之间相互联系所需要的工作量 ，还缺少许多与软件开发有关的系统级工作量 (配置管理 、质量管理 、 项目管理 )。 所以往往估算值偏低 ， 必须用其他方法进行检验和校正 。 (3)差别估计法 这种方法综合了上述两种方法的优点 ， 其想法是把待开发的软件项目与过去已完成的软件项目进行类比 ，从其开发的各个子任务中区分出类似的部分和不同的部分 。 类似的部分按实际量进行计算 ， 不同的部分则采用相应的方法进行估算 。 这种方法的优点是可以提高估算的准确程度 ， 缺点是不容易明确 “ 类似 ” 的界限 。 5 2 专家判定技术 专家判定技术就是由多位专家进行成本估算 。 由于单独一位专家可能会有种种偏见 。 因此 ， 最好由多位专家进行估算 ， 取得多个估算值 。 有多种方法把这些估算值合成一个估算值 。 例如 ， 一种方法是简单地求各估算值的中值或平均值 。 其优点是简便 。 缺点是可能会由于受一 、 二个极端估算值的影响而产生严重的偏差 。 另一种方法是召开小组会 ， 使各位专家们统一于或至少同意某一个估算值 。 优点是可以摈弃蒙昧无知的估算值 ， 缺点是一些组员可能会受权威或政治因素的影响 。 为了避免上述不足 ， 作为统一专家意见的方法 。 用 (1)组织者发给每位专家一份软件系统的规格说明书(略去名称和单位 )和一张记录估算值的表格 ， 请他们进行估算 。 (2)专家详细研究软件规格说明书的内容 。 然后组织者召集小组会议 ， 在会上 ， 专家们与组织者一起对估算问题进行讨论 。 (3)各位专家对该软件提出三个规模的估算值 ， 即： 该软件可能的最小规模 (最少源代码行数 )； 最可能的源代码行数 )； 最多源代码行数 )。 无记名地填写表格 ， 并说明做此估算的理由 。 (4)组织者对各位专家在表中填写的估算值进行综合和分类 ， 做以下事情： 1)计算各位专家 (序号为 i， I=1， 2， ， n)的估算期望值且和估算值的期望中值正： 2)对专家的估算结果进行分类摘要 。 (5)组织者召集会议 ， 请专家们对其估算值有很大变动之处进行讨论 。 专家对此估算值 ， 做一次估算 。 (6)在综合专家估算结果的基础上 ， 组织专家再次无记名地填写表格 。 从 (4)到 (6)适当重复几次 。 最终可获得一个得到多数专家共识的软件规模 (源代码数 ） ： 最后 ， 通过与历史资料进行类比 ， 根据过去完成项目的规模和成本等信息 ， 推算出该软件每行源代码所需成本 。 然后再乘以该软件源代码行数的估算值 ， 得到该软件的成本估算值 ， 5 3 软件开发成本估算的经验模型 软件开发成本估算的依据是开发成本估算模型 。开发成本估算模型通常采用经验公式中预测软件项目计划所需要的成本 、 工作量和进度 。 用以支持大多数模型的经验数据都是从有限的一些项目样本中得到的 。 因此 ， 还没有一种估算模型能够适用于所有的软件类型和开发环境 ，从这些模型中得到的结果必须慎重使用 。 (1) 1977年 ， 责的 60个项目的数据 。 中各项目的源代码行数从 400行到 467000行 ， 开发工作量从 121758使用 20种不同语言和 66种计算机 。 利用最小二乘法拟合 ， 得到如下估算公式： E 5 2 D= S： 0 54 9 其中 ， 以 ， 以， 以人计 )，以页计 )。 例如 ， 一个软件的开发工作量如表 7所示 。 该软件共有源代码 2900行 ， 其中 ， 500行用于测试 ， 2400行是执行程序的源代码 。 则劳动生产率是： (2900500) 10 240( 但不是一个通用公式 。 在应用中有时要根据具体实际 情况 ， 对公式中的参数进行修改 。 6 风险分析 风险分析实际上是 4个不同的活动：风险识别 ， 风险估计 ， 风险评价和风险驾驭 。 6 1 风险识别 可用不同的方法对风险进行分类 。 从宏观上来看 ， 可将风险分为项目风险 、 技术风险和商业风险 。 项目风险识别潜在的预算、进度、个人(包括人员和组织 )、资源、用户和需求方面的问题，以及它们对软件项目的影响。如项目复杂性、规模和结构等都可构成风险因素。 技术风险识别潜在的设计、实现、接口、检验和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术 (不成熟 )也是风险因素。技术风险之所以出现是由于问题的解决比所预想的要复杂。 商业风险有以下 5种： (1)建立的软件虽然很优秀但不是真正所想要的 (市场风险 )；(2)建立的软件不适合整个软件产品战略；(3)销售部门不清楚如何推销这种软件；(4)由于课题改变或人员改变而失去上级管理部门的支持； (5)失去预算或人员的承诺 (预算风险 )。 6 2 风险估计 风险估计使用两种方法来估价每一种风险 。 1. 估计一个风险发生的可能性 。 2. 估计那些与风险有关的问题可能产生的结果 。 项目计划人员与管理人员 、 技术人员一起 ， 进行 4种风险估计活动： (1)建立一个尺度或标准来表示一个风险的可能性； (2)描述风险的结果； (3)估计风险对项目和产品的影响 ， (4)确定风险估计的正确性 。 6 3 风险评价 在风险分析过程中进行风险评价的时候 ， 应当建立一个三元组： 其中 ， 概率 )， 而 在做风险评价时 ， 应当进一步检验在风险估计时所得到的估计的准确性 ， 尝试对已暴露的风险进行优先排队 ， 并着手考虑控制和 (或 )消除可能出现风险的方法 。 一个对风险评价很有用的技术就是定义风险参照水准 。 对于大多数软件项目来说 ， 成本 、 进度和性能就是三种典型的风险参照水准 。 即就是说 ， 对于成本超支 、 进度延期 、 性能降低 (或它们的某种组合 )， 有一个表明导致项目终止的水准 。 果风险的某种组合造成了一些问题 ， 从而超出了一个或多个参照水准 ， 就要中止工作 。 在做软件风险分析的环境中 ， 一个风险参照水准就有一个单独的点 ， 叫做参照点或崩溃点 。 在这个点上 ， 要公正地给出可接受的判断 ， 看是继 续执行项目工作 ， 还是终止它们 (出的问题太大 )。 因此 ， 可能需要利用性能分析 、 成本模型 、任务网络分析 、 质量因素分析等做判断 。 图 13用图示来表示这种情况 。 如果因为风险的一个组合引出造成项目成本和进度超出的问题 ，将有一个水准 (在图中用曲线表示 )， 当超出时 ，将导致项目终止 (黑色阴影区域 )。 在参照点上 ，要对作出是继续进行还是终止的判断公正地加权 。 在做风险评价时 ， 按以下步骤执行： (1)为项目定义风险参照水准； (2)尝试找出在每个 每个参照水准之间的关系； (3)预测参照点组以定义一个终止区域 ，用一条曲线或一些易变动区域来界定； (4)努力预测复合的风险组合将如何形成一个参照水准。 6 4 风险驾驭和监控 风险驾驭是指利用某些技术 ， 如原型化 、软件自动化 、 软件心理学 、 可靠性工程学以及某些项目管理方法等设法避开或转移风险 。 风险驾驭与监控活动的图解说明如图 14所示。与每一风险相关的三元组 (风险描述，风险可能性、风险影响 )是建立风险驾驭 (风险消除 )步骤的基础。例如，假如人员的频繁流动是一项风险 于过去的历史和管理经验，频繁流动可能性的估算值 0%相当高 )，而影响 目开发时间增加 15，总成本增加 12 给出了这些数据之后 ， 建议可使用以下风险驾驭步骤： (1)与现在在职的人员协商 ， 确定人员流动的原因 (如 ， 工作条件差 ，收入低 ， 人才市场竞争等 )； (2)在项目开始前 ， 把缓解这些原因 (避开风险 )的工作列入已拟定的驾驭计划中 。 (3)当项目启动时 ， 做好人员流动会出现的准备 。 采取一些办法以确保人员一旦离开时项 目仍能继续 (削弱风险 )； (4)建立项目组 ， 以使大家都了解有关开发活动的信息； (5)制定文档标准 ， 并建立一种机制以保证文档能够及时产生； (6)对所有工作组织细致的评审 (以使更多的人能够按计划进度完成自己的工作 )； (7)对每一个关键性的技术人员 ， 要培养后备人员 。 看图 14， 风险驾驭步骤要写进风险驾驭与监控计划 并且作为整个项目计划的 部外为项目管理人员所使用 。5中列出 。 一旦制定出 项目已开始执行，风险监控就开始了 风险监控是一种项目追踪活动 ， 它有三个主要目标： (1)做里程碑事件跟踪和主要风险因素跟踪 ，判断一个预测的风险事实上是否发生了； (2)进行风险再估计 ， 确保针对某个风险而制定的风险消除步骤正在合理地使用； (3)收集可用于将来的风险分析的信息 。 7 进度安排 软件开发项目的进度安排有两种考虑方式： (1)系统最终交付日期已经确定 ， 软件开发部门必须在规定期限内完成； (2)系统最终交付日期只确定了大致的年限 ， 最后交付日期由软件开发部门确定 。 7 1 软件开发小组人数与软件生产率 对于一个小型的软件开发项目 ， 一个人就可以完成需求分析 、 设计 、 编码和测试工作 。 但是 ， 随着软件开发项目规模的增大 ， 就会有更多的人共同参与同一软件项目的工作 。 例如 10个人 1年可以完成的项目 ， 若让1个人干 10年是不行的 。 因此 ， 需要多人组成开发小组共同参加 个项目的开发 。 当几个人共同承担软件开发项目中的某一任务时 ， 人与人之间必须通过交流来解决各自承担任务之间的接口问题 ， 即通信问题 。 通信需花费时间和代价 ， 会引起软件错误增加 ， 降低软件生产率 。 若两个人之间需要通信 ， 则称在这两个人之间存在一条通信路径 。 如果一个软件开发小组有 每两人之间都需要通信 ， 则总的通信路径有 n () 2 (条 ) 假设一个人单独开发软件 ， 生产率是 5000行人年 。若 4个人组成一个小组共同开发这个软件 ， 则需要 6条通信路径 ， 如图 13 16(a)所示 。 若在每条通信路径上耗费的工作量是 250行人年 。 则小组中每个人的软件生产率降低为 50006 250 4=5000375=4625行人年如果小组有 6名成员 ， 通信路径增加到 15条 ， 如图13 16(b)所示 。 每条通信路径消耗的工作量不变 ， 则小组中每个成员的软件生产率降低为 500015 250 6=5000625 4375行人年 。 7 2 任务的确定与并行性 当参加同一软件工程项目的人数不止一人的时候 ， 开发工作就会出现并行情形 。图 17表示了一个典型的由多人参加的软件工程项目的任务图 。 在图 17中可以看到 ， 软件开发进程中设置了许多里程碑 。 里程碑为管理人员提供了指示项目进度的可靠依据 。 当一个软件工程任务成功地通过了评审并产生了文档之后 ， 就完成了一个里程碑 。 7 3 制定开发进度计划 在 13 3节讨论的每一项软件估算技术都能得出完成软件开发任务所需人月 (或人年 )数 的估算值 。 有 一种常用来估计在整个定义与开发阶段工作量分配的建议方案 ， 称为 40一 20一 40规则 。 它指出在整个软件开发过程中 ， 编码的工作量仅占 20 ， 编码前的工作量占 40 ， 编码后的工作量占 40 。 事实上 ， 这个规则相当粗糙 ， 只能用来作为一个指南 。 实际的工作量分配比例必须按照每个项目的特点来决定 。 7 4 进度安排的图形方法 软件项目的进度安排与任何一个多重任务工作的进度安排基本差不多 ， 因此 ，只要稍加修改 ， 就可以把用于一般开发项目的进度安排的技术和工具应用于软件项目 。 (1)甘特图 ( 甘特图用水平线段表示任务的工作阶段；线段的起点和终点分别对应着任务的开工时间和完成时间；线段的长度表示完成任务所需的时间 。 图 18给出一个具有 5个任务的甘特图 (任务名分别为 A、 B、 C、 D、 E)。 如果这 5条线段分别代表完成任务的计划时间 ， 则在横坐标方向附加一条可向右移动的纵线 。 它可随着项目的进展