第九章软件管理 复习要求 1.了解软件过程的概念、软件过程框架和软件过程模型 2.了解软件项目管理的过程 3.了解软件度量的种类,面向规模和面向功能的度量以及质量度量的种类。 4.掌握LOC估算和FP估算的方法,分解技术和工作量估算方法。 5.了解软件成本估算的概念,掌握 COCOMO成本估算方法。 6.了解软件成本一效益估计方法 7.了解风险分析的步骤,风险的种类、风险项目和风险构成 8.了解软件进度安排方法及图形工具 9.了解软件项目划分的方式,项目组织的模式,人员配备的原则和条件。 内容提要 1.软件过程 (1)软件过程的概念 软件工程是一种层次化的技术,如图91所 工具 示。软件工程的过程层是将结合在一起的凝聚力 量,使得计算机软件能够及时、合理地被开发出 来。软件过程定义了一组关键过程域(KPAs), 过程 它们构成软件项目管理的基础,并规定了技术方 质量关注点 法的采用、工程产品(模型、文档、数据、报告 表格等)的产生、里程碑的建立、质量的管理以 图91软件工程层次 及适当的变更控制。 软件过程是软件生存期中的一系列相关软公共过程框架 件工程活动的集合。每一个软件过程又是由一组 框架活动 工作任务、项目里程碑、软件工程产品和交付物 以及质量保证(SQA)点等组成。一个软件过程可 「工作任务 以用图92的形式来表示。首先建立一个公共过 里程碑、交付物 程框架,其中定义了少量可适用于所有软件项目 SOA点 的框架活动,而不考虑它们的规模和复杂性。再 给出各个框架活动的任务集合,使得框架活动能 够适合于项目的特点和项目组的需求。最后是保 保护伞活动 护伞活动,如软件质量保证、软件配置管理以及 测量等,它们独立于任何一个框架活动并将贯穿 图92软件过程 于整个过程。 (2)软件过程模型 软件工程过程模型的选择基于项目和应用的特点、采用的方法和工具、要求的控制和需
1 图 9.1 软件工程层次 图 9.2 软件过程 第九章 软件管理 一、复习要求 1. 了解软件过程的概念、软件过程框架和软件过程模型。 2. 了解软件项目管理的过程。 3. 了解软件度量的种类，面向规模和面向功能的度量以及质量度量的种类。 4. 掌握 LOC 估算和 FP 估算的方法，分解技术和工作量估算方法。 5. 了解软件成本估算的概念，掌握 COCOMO 成本估算方法。 6. 了解软件成本―效益估计方法。 7. 了解风险分析的步骤，风险的种类、风险项目和风险构成。 8. 了解软件进度安排方法及图形工具。 9. 了解软件项目划分的方式，项目组织的模式，人员配备的原则和条件。 二、内容提要 1. 软件过程 (1) 软件过程的概念 软件工程是一种层次化的技术，如图 9.1 所 示。软件工程的过程层是将结合在一起的凝聚力 量，使得计算机软件能够及时、合理地被开发出 来。软件过程定义了一组关键过程域(KPAs)， 它们构成软件项目管理的基础，并规定了技术方 法的采用、工程产品(模型、文档、数据、报告、 表格等)的产生、里程碑的建立、质量的管理以 及适当的变更控制。 软件过程是软件生存期中的一系列相关软 件工程活动的集合。每一个软件过程又是由一组 工作任务、项目里程碑、软件工程产品和交付物 以及质量保证(SQA)点等组成。一个软件过程可 以用图 9.2 的形式来表示。首先建立一个公共过 程框架，其中定义了少量可适用于所有软件项目 的框架活动，而不考虑它们的规模和复杂性。再 给出各个框架活动的任务集合，使得框架活动能 够适合于项目的特点和项目组的需求。最后是保 护伞活动，如软件质量保证、软件配置管理以及 测量等，它们独立于任何一个框架活动并将贯穿 于整个过程。 (2) 软件过程模型 软件工程过程模型的选择基于项目和应用的特点、采用的方法和工具、要求的控制和需 质量关注点 过程 方法 工具 公共过程框架 保护伞活动 框架活动 任务集合 工作任务 里程碑、交付物 SQA 点
交付的产品。 L B.S. Raccoon使用了分级几何表示,用以讨论软件工程过程的本质 所有的软件开发都可以看成是一个问题循环解决过程,如图9.3所示。其中包括4个截 然不同的阶段:状态捕获、问题定义、技术开发和方案综合。状态捕获表示了事物的当前状 态:问题定义标识了需要解决的特定问题:技术开发利用某些技术来解决问题;方案综合导 出最终的结果(如文档、程序、数据、新的事务功能、新的产品)。 以上的问题循环解决过程可以用于软件工程 的不同开发级别上。它可用于考虑整个应用系统的 问题定义 宏观级,也可用于建造程序构件的中间级,甚至还 可用于源代码行级。因此,可以用分级几何表示来 技术开发 给出过程的理想化的视图。首先定义一个分级几何槌莎 表示的模式,然后相继地在更小的规模上递归地应 用分级几何表示:模式中嵌套模式。在图94中, 方案综合 问题循环解决过程的每一个阶段又包含一个同样 图93问题解决循环的各个阶段 的问题循环解决过程,该循环中每一个步骤中还可 以再包含另一个问题循环解决过程。这样一直继续下去,直到某个合理的边界为止。对于软 件来说,就是源代码行 状态捕获 图94问题循环解决过程中阶段嵌套阶段 实际上,想要如图94那样清楚地划分这些活动是很困难的,因为在阶段内部常常会出 现一些交叉的任务,它们还可能会跨越阶段。不过,这种简化的视图表达了一个重要的思想 不管软件项目选择了什么样的过程模型,但所有阶段,包括状态捕获、问题定义、技术开发、 方案综合,在某个细节级别上都同时存在。由于给出了如图94所示的递归的性质,上述的4 阶段论不但可用于整个应用的分析,而且同样地可用于某一代码段的生成。 (3)过程建造技术 为使得软件过程模型适合于软件项目组的使用,需要开发一些过程技术工具,以帮助软 件开发组织分析它们当前的过程,组织工作任务,控制和监控进度,管理技术质量 使用过程技术工具,可以建造一个自动模型,模型包含前面提到的公共过程框架、任务 集合及保护伞活动。该模型一般表示成一个网络,对其加以分析,就能够确定典型的工作流 程,考察可能导致减少开发时间、降低开发成本的可选的过程结构
2 问题定义 技术开发 方案综合 状态 捕获 图 9.3 问题解决循环的各个阶段 交付的产品。L.B.S.Raccoon 使用了分级几何表示，用以讨论软件工程过程的本质。 所有的软件开发都可以看成是一个问题循环解决过程，如图 9.3 所示。其中包括 4 个截 然不同的阶段：状态捕获、问题定义、技术开发和方案综合。状态捕获表示了事物的当前状 态；问题定义标识了需要解决的特定问题；技术开发利用某些技术来解决问题；方案综合导 出最终的结果(如文档、程序、数据、新的事务功能、新的产品)。 以上的问题循环解决过程可以用于软件工程 的不同开发级别上。它可用于考虑整个应用系统的 宏观级，也可用于建造程序构件的中间级，甚至还 可用于源代码行级。因此，可以用分级几何表示来 给出过程的理想化的视图。首先定义一个分级几何 表示的模式，然后相继地在更小的规模上递归地应 用分级几何表示：模式中嵌套模式。在图 9.4 中， 问题循环解决过程的每一个阶段又包含一个同样 的问题循环解决过程，该循环中每一个步骤中还可 以再包含另一个问题循环解决过程。这样一直继续下去，直到某个合理的边界为止。对于软 件来说，就是源代码行。 图 9.4 问题循环解决过程中阶段嵌套阶段 实际上，想要如图 9.4 那样清楚地划分这些活动是很困难的，因为在阶段内部常常会出 现一些交叉的任务，它们还可能会跨越阶段。不过，这种简化的视图表达了一个重要的思想： 不管软件项目选择了什么样的过程模型，但所有阶段，包括状态捕获、问题定义、技术开发、 方案综合，在某个细节级别上都同时存在。由于给出了如图 9.4 所示的递归的性质，上述的 4 阶段论不但可用于整个应用的分析，而且同样地可用于某一代码段的生成。 (3) 过程建造技术 为使得软件过程模型适合于软件项目组的使用，需要开发一些过程技术工具，以帮助软 件开发组织分析它们当前的过程，组织工作任务，控制和监控进度，管理技术质量。 使用过程技术工具，可以建造一个自动模型，模型包含前面提到的公共过程框架、任务 集合及保护伞活动。该模型一般表示成一个网络，对其加以分析，就能够确定典型的工作流 程，考察可能导致减少开发时间、降低开发成本的可选的过程结构。 问题 定义 技术 开发 方案 综合 状态 捕获 问题 定义 技术 开发 方案 综合 状态 捕获 问题 定义 技术 开发 方案 综合 状态 捕获 状态捕获
旦创建了一个可接受的过程,就可以使用其它过程技术工具来分配、监视、甚至控制 在软件过程模型中定义的所有软件工程任务。软件项目组的每一个成员都可以使用这样的工 具来开发检查表,列出所有将要执行的工作任务、将要产生的工作产品和将要实施的软件质 量保证活动。过程技术工具还可用于协调适合某一特定工作任务的其它CASE工具的使用。 2、软件项目管理过程 软件项目管理包括进度管理、成本管理、质量管理、人员管理、资源管理、标准化管理 管理的对象是进度、系统规模及工作量估算、经费、组织机构和人员、风险、质量、作业和 环境配置等。软件项目管理所涉及的范围覆盖了整个软件生存期 为使软件项目开发获得成功,一个关键问题是必须对软件开发项目的工作范围、可能遇 到的风险、需要的资源(人、硬/软件)、要实现的任务、经历的里程碑、花费工作量(成本), 以及进度的安排等等做到心中有数。而软件项目管理可以提供这些信息。通常,这种管理在 技术工作开始之前就应开始,而在软件从概念到实现的过程中继续进行,并且只有当软件开 发工作最后结束时才终止。 (1)启动一个软件项目 在制定软件项目计划之前,必须先明确项目的目标和范围、考虑候选的解决方案、标明 技术和管理上的要求。有了这些信息,才能确定合理、精确的成本估算,实际可行的任务分 解以及可管理的进度安排。 项目的目标标明了软件项目的目的但不涉及如何去达到这些目的。范围标明了软件要实 现的基本功能,并尽量以定量的方式界定这些功能。候选的解决方案虽然涉及方案细节不多, 但有了方案,管理人员和技术人员就能够据此选择一种“好的”方法,给出诸如交付期限 预算、个人能力、技术界面及其它许多因素所构成的限制 (2)制定项目计划 制定计划的任务包括 估算所需要的人力(通常以人月为单位)、项目持续时间(以年份或月份为单位)、成 本(以元为单位 作出进度安排,分配资源,建立项目组织及任用人员(包括人员的地位、作用、职责、 规章制度等),根据规模和工作量估算分配任务。 进行风险分析,包括风险识别、风险估计、风险优化、风险驾驭策略、风险解决和风 险监督。这些步骤贯穿在软件工程过程中 制定质量管理指标:如何识别定义好的任务?管理人员对结束时间如何掌握,并如何 识别和监控关键路径以确保结束?对进展如何度量?以及如何建立分隔任务的里程碑。 编制预算和成本 准备环境和基础设施等。 (3)计划的追踪和控制 旦建立了进度安排,就可以开始着手追踪和控制活动。由项目管理人员负责在过程执 行时监督过程的实施,提供过程进展的内部报告,并按合同规定向需方提供外部报告。对于 在进度安排中标明的每一个任务,如果任务实际完成日期滞后于进度安排,则管理人员可以 使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响。可 对资源重新定向,对任务重新安排,或者(做为最坏的结果)可以修改交付日期以调整己经暴 露的问题。用这种方式可以较好地控制软件的开发。 (4)评审和评价计划的完成程度 项目管理人员应对计划完成程度进行评审,对项目进行评价。并对计划和项目进行检查 使之在变更或完成后保持完整性和一致性
3 一旦创建了一个可接受的过程，就可以使用其它过程技术工具来分配、监视、甚至控制 在软件过程模型中定义的所有软件工程任务。软件项目组的每一个成员都可以使用这样的工 具来开发检查表，列出所有将要执行的工作任务、将要产生的工作产品和将要实施的软件质 量保证活动。过程技术工具还可用于协调适合某一特定工作任务的其它 CASE 工具的使用。 2、软件项目管理过程 软件项目管理包括进度管理、成本管理、质量管理、人员管理、资源管理、标准化管理。 管理的对象是进度、系统规模及工作量估算、经费、组织机构和人员、风险、质量、作业和 环境配置等。软件项目管理所涉及的范围覆盖了整个软件生存期。 为使软件项目开发获得成功，一个关键问题是必须对软件开发项目的工作范围、可能遇 到的风险、需要的资源(人、硬／软件)、要实现的任务、经历的里程碑、花费工作量(成本)， 以及进度的安排等等做到心中有数。而软件项目管理可以提供这些信息。通常，这种管理在 技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，并且只有当软件开 发工作最后结束时才终止。 (1) 启动一个软件项目 在制定软件项目计划之前，必须先明确项目的目标和范围、考虑候选的解决方案、标明 技术和管理上的要求。有了这些信息，才能确定合理、精确的成本估算，实际可行的任务分 解以及可管理的进度安排。 项目的目标标明了软件项目的目的但不涉及如何去达到这些目的。范围标明了软件要实 现的基本功能，并尽量以定量的方式界定这些功能。候选的解决方案虽然涉及方案细节不多， 但有了方案，管理人员和技术人员就能够据此选择一种“好的”方法，给出诸如交付期限、 预算、个人能力、技术界面及其它许多因素所构成的限制。 (2) 制定项目计划 制定计划的任务包括： ▪ 估算所需要的人力（通常以人月为单位）、项目持续时间（以年份或月份为单位）、成 本（以元为单位）。 ▪ 作出进度安排，分配资源，建立项目组织及任用人员(包括人员的地位、作用、职责、 规章制度等)，根据规模和工作量估算分配任务。 ▪ 进行风险分析，包括风险识别、风险估计、风险优化、风险驾驭策略、风险解决和风 险监督。这些步骤贯穿在软件工程过程中。 ▪ 制定质量管理指标：如何识别定义好的任务？管理人员对结束时间如何掌握，并如何 识别和监控关键路径以确保结束？对进展如何度量？以及如何建立分隔任务的里程碑。 ▪ 编制预算和成本。 ▪ 准备环境和基础设施等。 (3) 计划的追踪和控制 一旦建立了进度安排，就可以开始着手追踪和控制活动。由项目管理人员负责在过程执 行时监督过程的实施，提供过程进展的内部报告，并按合同规定向需方提供外部报告。对于 在进度安排中标明的每一个任务，如果任务实际完成日期滞后于进度安排，则管理人员可以 使用一种自动的项目进度安排工具来确定在项目的中间里程碑上进度误期所造成的影响。可 对资源重新定向，对任务重新安排，或者(做为最坏的结果)可以修改交付日期以调整已经暴 露的问题。用这种方式可以较好地控制软件的开发。 (4) 评审和评价计划的完成程度 项目管理人员应对计划完成程度进行评审，对项目进行评价。并对计划和项目进行检查, 使之在变更或完成后保持完整性和一致性
(5)编写管理文档 项目管理人员根据合同确定软件开发过程是否完成。如果完成,应从完整性方面检査项 目完成的结果和记录,并把这些结果和记录编写成文档并存档。 3、软件生产率和质量的度量 (1)软件度量 对软件进行度量,是为了表明软件产品的质量,弄清软件开发人员的生产率,给出使用 了新的软件工程方法和工具所得到的(在生产率和质量两方面)的效益,建立项目估算的“基 线",帮助调整对新的工具和附加培训的要求 软件度量分为两类: 直接度量:软件工程过程的直接度量包括所投入的成本和工作量。软件产品的直接度 量包括产生的代码行数(LOC)、执行速度、存储量大小、在某种时间周期中所报告的差错数。 间接度量:产品的间接度量则包括功能性、复杂性、效率、可靠性、可维护性和许多 其它的质量特性 只要事先建立特定的度量规程,很容易做到直接度量开发软件所需要的成本和工作量、 产生的代码行数等。但是,软件的功能性、效率、可维护性等质量特性却很难用直接度量判 明,只有通过间接度量才能推断 我们可进一步将软件度量如图9.5所示那样 「技术度量 分类。软件生产率度量主要关注软件工程过程的结 质量度量 果:软件质量度量则指明了软件适应明确和不明确 生产率度量 的用户要求(软件使用合理性)到什么程度:技术度 量主要关注软件的一些特性(如逻辑复杂性、模块化 面向规模的度量 程度)而不是软件开发的全过程 面向功能的度量 从图9.5中还可以看到另一种分类方法:面向 面向人的度量 规模的度量用于收集与直接度量有关的软件工程输 出的信息和质量信息。面向功能的度量提供直接度 量的尺度。面向人的度量则收集有关人们开发软件 图95软件度量 所用方式的信息和人们理解有关工具和方法的效率的信息 (2)面向规模的度量 面向规模的度量是对软件和软件开发过程的直接度量。首先需要建立一个如表91所示 的面向规模的数据表格,记录过去几年完成的每一个软件项目和关于这些项目的相应面向规 模的数据。 表91面向规模的度量 项目工作量(人月)元(千)规模(KOc)文档页数|错误数|开发人数 ccc-04 对于每一个项目,可以根据表格中列出的基本数据进行一些简单的面向规模的生产率和 质量的度量。例如,可以根据表9.1对所有的项目计算出平均值 生产率=KLOC/PM(人月)成本=元/LOC 质量=错误数/KLOC 文档=文档页数/KLOC
4 (5) 编写管理文档 项目管理人员根据合同确定软件开发过程是否完成。如果完成，应从完整性方面检查项 目完成的结果和记录，并把这些结果和记录编写成文档并存档。 3、软件生产率和质量的度量 (1) 软件度量 对软件进行度量，是为了表明软件产品的质量，弄清软件开发人员的生产率，给出使用 了新的软件工程方法和工具所得到的(在生产率和质量两方面)的效益，建立项目估算的“基 线"，帮助调整对新的工具和附加培训的要求。 软件度量分为两类： ▪ 直接度量：软件工程过程的直接度量包括所投入的成本和工作量。软件产品的直接度 量包括产生的代码行数(LOC)、执行速度、存储量大小、在某种时间周期中所报告的差错数。 ▪ 间接度量：产品的间接度量则包括功能性、复杂性、效率、可靠性、可维护性和许多 其它的质量特性。 只要事先建立特定的度量规程，很容易做到直接度量开发软件所需要的成本和工作量、 产生的代码行数等。但是，软件的功能性、效率、可维护性等质量特性却很难用直接度量判 明，只有通过间接度量才能推断。 我们可进一步将软件度量如图 9.5 所示那样 分类。软件生产率度量主要关注软件工程过程的结 果；软件质量度量则指明了软件适应明确和不明确 的用户要求(软件使用合理性)到什么程度；技术度 量主要关注软件的一些特性(如逻辑复杂性、模块化 程度)而不是软件开发的全过程。 从图 9.5 中还可以看到另一种分类方法：面向 规模的度量用于收集与直接度量有关的软件工程输 出的信息和质量信息。面向功能的度量提供直接度 量的尺度。面向人的度量则收集有关人们开发软件 所用方式的信息和人们理解有关工具和方法的效率的信息。 (2) 面向规模的度量 面向规模的度量是对软件和软件开发过程的直接度量。首先需要建立一个如表 9.1 所示 的面向规模的数据表格，记录过去几年完成的每一个软件项目和关于这些项目的相应面向规 模的数据。 表 9.1 面向规模的度量 项目 工作量(人月) 元(千) 规模(KLOC) 文档页数 错误数 开发人数 aaa-01 24 168 12.1 365 29 3 ccc-04 62 440 27.2 1224 86 5 fff-03 43 314 17.5 1050 64 6 … … … … … … … 对于每一个项目，可以根据表格中列出的基本数据进行一些简单的面向规模的生产率和 质量的度量。例如，可以根据表 9.1 对所有的项目计算出平均值： 生产率 ＝ KLOC／PM（人月） 成本 ＝ 元／LOC 质量 ＝ 错误数／KLOC 文档 ＝ 文档页数／KLOC 图 9.5 软件度量
(3)面向功能的度量 面向功能的软件度量是对软件和软件开发过程的间接度量。面向功能度量的关注点在于 程序的“功能性”和“实用性”,而不是对LOC计数。一种典型的生产率度量法叫做功能点 度量,该方法利用软件信息域中的一些计数度量和软件复杂性估计的经验关系式而导出功能 点FPs( Function Points)。 功能点通过填写表92所示的表格来计算。首先确定五个信息域的特征,并在表格中相 应位置给出计数。信息域的值以如下方式定义: 用户输入数:各个用户输入是面向不同应用的输入数据,对它们都要进行计数。输入 数据应有别于查询数据,它们应分别计数 用户输出数:各个用户输出是为用户提供的面向应用的输出信息,它们均应计数。这 里的输出是指报告,屏幕信息,错误信息等,在报告中的各数据项不应再分别计数。 用户查询数:查询是一种联机输入,它导致软件以联机输出的方式生成某种即时的响 应。每一个不同的查询都要计数 文件数:每一个逻辑主文件都应计数。这里的逻辑主文件,是指逻辑上的一组数据, 它们可以是一个大的数据库的一部分,也可以是一个单独的文件 外部接口数:对所有被用来将信息传送到另一个系统中的机器可读写的接口(即磁带 或磁盘上的数据文件)均应计数 表92功能点度量的计算 加权因数 信息域参数计数 加权计数 简单中间复杂 用户输入数口囗口 口囗口 用户输出数口口口 口囗口 用户查询数口口口 口囗口 文件数口口口 外部接口数口口口 旦收集到上述数据,就可以计算出与每一个计数相关的复杂性值。使用功能点方法的 机构要自行拟定一些准则以确定一个特定项是简单的、平均的还是复杂的。 计算功能点,使用如下的关系式: FP=总计数×(0.65+0.01×sUM(Fi)) (9.1) 其中,总计数是由表92所得到的所有加权计数项的和:Fi(i=1到14)是复杂性校正 值,它们应通过逐一回答表9.3所提问题来确定。SUM(Fi)是求和函数。上述等式中的常 数和应用于信息域计数的加权因数可经验地确定 旦计算出功能点,就可以仿照LOC的方式度量软件的生产率、质量和其它属性 生产率=FP/PM(人月) 成本=元/FP 质量=错误数/FP 文档=文档页数/FP 表9.3计算功能点的校正值 定每个校正因素的尺度是0-5 没有影响偶然的适中的普通的重要的极重要的
5 (3) 面向功能的度量 面向功能的软件度量是对软件和软件开发过程的间接度量。面向功能度量的关注点在于 程序的“功能性”和“实用性”，而不是对 LOC 计数。一种典型的生产率度量法叫做功能点 度量，该方法利用软件信息域中的一些计数度量和软件复杂性估计的经验关系式而导出功能 点 FPs（Function Points）。 功能点通过填写表 9.2 所示的表格来计算。首先确定五个信息域的特征，并在表格中相 应位置给出计数。信息域的值以如下方式定义： ▪ 用户输入数：各个用户输入是面向不同应用的输入数据，对它们都要进行计数。输入 数据应有别于查询数据，它们应分别计数。 ▪ 用户输出数：各个用户输出是为用户提供的面向应用的输出信息，它们均应计数。这 里的输出是指报告，屏幕信息，错误信息等，在报告中的各数据项不应再分别计数。 ▪ 用户查询数：查询是一种联机输入，它导致软件以联机输出的方式生成某种即时的响 应。每一个不同的查询都要计数。 ▪ 文件数：每一个逻辑主文件都应计数。这里的逻辑主文件，是指逻辑上的一组数据， 它们可以是一个大的数据库的一部分，也可以是一个单独的文件 ▪ 外部接口数：对所有被用来将信息传送到另一个系统中的机器可读写的接口(即磁带 或磁盘上的数据文件)均应计数。 表 9.2 功能点度量的计算 加 权 因 数 简单 中间 复杂 用户输入数 □□□ 3 4 6 = □□□ 用户输出数 □□□ 4 5 7 = □□□ 用户查询数 □□□ 3 4 6 = □□□ 文 件 数 □□□ 7 10 15 = □□□ 外部接口数 □□□ 5 7 10 = □□□ 总 计 数 □□□ 一旦收集到上述数据，就可以计算出与每一个计数相关的复杂性值。使用功能点方法的 机构要自行拟定一些准则以确定一个特定项是简单的、平均的还是复杂的。 计算功能点，使用如下的关系式： FP ＝ 总计数×〔0.65＋0.01×SUM（Fi）〕 （9.1） 其中，总计数是由表 9.2 所得到的所有加权计数项的和；Fi（i = 1 到 14）是复杂性校正 值，它们应通过逐一回答表 9.3 所提问题来确定。SUM（Fi）是求和函数。上述等式中的常 数和应用于信息域计数的加权因数可经验地确定。 一旦计算出功能点，就可以仿照 LOC 的方式度量软件的生产率、质量和其它属性： 生产率 ＝ FP／PM（人月） 成本 ＝ 元／FP 质量 ＝ 错误数／FP 文档 ＝ 文档页数／FP 表 9.3 计算功能点的校正值 评定每个校正因素的尺度是 0―5 0 1 2 3 4 5 没有影响 偶然的 适中的 普通的 重要的 极重要的 信息域参数 计数 加权计数
1系统是否需要可靠的备份和恢复? 2是否需要数据通信? 3是否有分布式处理的功能? 4性能是否是关键? 5系统是否将运行在现有的高度实用化的操作环境中? 6系统是否要求联机数据项? 7联机数据项是否要求建立在多重窗口显示或操作上的输入事务? 8是否联机地更新主文件? 9输入、输出、文件、查询是否复杂? 10内部处理过程是否复杂? 11程序代码是否要设计成可复用的? 12设计中是否包含变换和安装? 13系统是否要设计成多种安装形式以安装在不同的机构中? 14应用系统是否要设计成便于修改和易于用户使用? 功能点度量是为了商用信息系统应用而设计的。 Jones将其扩充,使这种度量可以被用 于系统和工程软件应用,称之为特征点FPs( Feature points)。特征点度量适合于算法复杂性 高的应用。实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高,适于特征点度量 为了计算特征点,可以象上面描述的那样,对信息域值进行计数和加权。此外,需要对 个新的软件特征“算法”进行计数。可定义算法为“在一个特定计算机程序内所包含的 个有界的计算问题。”如矩阵求逆、二进位串转换为十进制数、处理一个中断等都是算法。 计算特征点可使用如表94所示的表格。对于每一个度量参数只使用一个权值,并且使用等 式(9.1)来计算总的特征点值 表94特征点度量的计算 信息域参数计数 权值 加权计数 用户输入数 用户输出数 用户查询数 口口口×4 □囗口 外部接口数 □囗口 囗囗 总计数 口口囗 必须注意,特征点与功能点表示的是同一件事:由软件提供的“功能性”或“实用性” 事实上,对于传统的工程计算或信息系统应用,两种度量会得出相同的FP值。在较复杂的 实时系统中,特征点计数常常比只用功能点确定的计数高出20%到35%。 (4)软件质量的度量 质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。在软件交付之前得到 的度量提供了一个定量的根据,以做出设计和测试质量好坏的判断。这一类度量包括程序复 杂性、有效的模块性和总的程序规模。在软件交付之后的度量则把注意力集中于还未发现的 差错数和系统的可维护性方面。特别要强调的是,软件质量的售后度量可向管理者和技术人 员表明软件工程过程的有效性达到什么程度 虽然已经有许多软件质量的度量方法,但事后度量使用得最广泛。它包括正确性、可维
6 Fi 1 系统是否需要可靠的备份和恢复？ 2 是否需要数据通信？ 3 是否有分布式处理的功能？ 4 性能是否是关键？ 5 系统是否将运行在现有的高度实用化的操作环境中？ 6 系统是否要求联机数据项？ 7 联机数据项是否要求建立在多重窗口显示或操作上的输入事务？ 8 是否联机地更新主文件？ 9 输入、输出、文件、查询是否复杂？ 10 内部处理过程是否复杂？ 11 程序代码是否要设计成可复用的？ 12 设计中是否包含变换和安装？ 13 系统是否要设计成多种安装形式以安装在不同的机构中？ 14 应用系统是否要设计成便于修改和易于用户使用？ 功能点度量是为了商用信息系统应用而设计的。Jones 将其扩充，使这种度量可以被用 于系统和工程软件应用，称之为特征点 FPs（Feature Points）。特征点度量适合于算法复杂性 高的应用。实时处理、过程控制、嵌入式软件应用的算法复杂性都偏高，适于特征点度量。 为了计算特征点，可以象上面描述的那样，对信息域值进行计数和加权。此外，需要对 一个新的软件特征“算法”进行计数。可定义算法为“在一个特定计算机程序内所包含的一 个有界的计算问题。”如矩阵求逆、二进位串转换为十进制数、处理一个中断等都是算法。 计算特征点可使用如表 9.4 所示的表格。 对于每一个度量参数只使用一个权值，并且使用等 式（9.1）来计算总的特征点值。 表 9.4 特征点度量的计算 信息域参数 计数 权值 加权计数 用户输入数 □□□ 4 = □□□ 用户输出数 □□□ 5 = □□□ 用户查询数 □□□ 4 = □□□ 文 件 数 □□□ 7 = □□□ 外部接口数 □□□ 7 = □□□ 算 法 □□□ 3 = □□□ 总 计 数 □□□ 必须注意，特征点与功能点表示的是同一件事：由软件提供的“功能性”或“实用性”。 事实上，对于传统的工程计算或信息系统应用，两种度量会得出相同的 FP 值。在较复杂的 实时系统中，特征点计数常常比只用功能点确定的计数高出 20％到 35％。 (4) 软件质量的度量 质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。在软件交付之前得到 的度量提供了一个定量的根据，以做出设计和测试质量好坏的判断。这一类度量包括程序复 杂性、有效的模块性和总的程序规模。在软件交付之后的度量则把注意力集中于还未发现的 差错数和系统的可维护性方面。特别要强调的是，软件质量的售后度量可向管理者和技术人 员表明软件工程过程的有效性达到什么程度。 虽然已经有许多软件质量的度量方法，但事后度量使用得最广泛。它包括正确性、可维
护性、完整性和可使用性。Gilb提出了它们的定义和度量。 ①正确性:一个程序必须正确地运行,而且还要为它的用户提供某些输出。正确性要 求软件执行所要求的功能。对于正确性,最一般的度量是每千代码行(KLOC)的差错数,其 中将差错定义为已被证实是不符合需求的缺陷。差错在程序交付用户普遍使用后由程序的用 户报告,按标准的时间周期(典型情况是1年)进行计数 ②可维护性:包括当程序中发现错误时,要能够很容易地修正它:当程序的环境发生 变化时,要能够很容易地适应之;当用户希望变更需求时,要能够很容易地增强它。还没有 种方法可以直接度量可维护性,因此必须采取间接度量。有一种简单的面向时间的度量, 叫做平均变更等待时间MTC( Mean Time To Change)。这个时间包括开始分析变更要求、 设计合适的修改、实现变更并测试它、以及把这种变更发送给所有的用户。一般地,一个可 维护的程序与那些不可维护的程序相比,应有较低的MTC(对于相同类型的变更)。 ③完整性:这个属性度量一个系统抗拒对它的安全性攻击(事故的和人为的)的能力 软件的所有三个成分:程序、数据和文档都会遭到攻击 为了度量完整性,需要定义两个附加的属性:危险性和安全性。危险性是特定类型的攻 击将在一给定时间内发生的概率,它可以被估计或从经验数据中导出。安全性是排除特定类 型攻击的概率,它也可以被估计或从经验数据中导出。一个系统的完整性可定义为: 完整性=∑(1一危险性×(1一安全性)) 其中,对每一个攻击的危险性和安全性都进行累加 ④可使用性:即用户友好性。如果一个程序不具有“用户友好性”,即使它所执行的 功能很有价值,也常常会失败。可使用性力图量化“用户友好性”,并依据以下四个特征进 行度量: 为学习系统所需要的体力上的和智力上的技能 为达到适度有效使用系统所需要的时间 当软件被某些人适度有效地使用时所度量的在生产率方面的净增值 用户角度对系统的主观评价(可以通过问题调查表得到) 4、软件项目的估算 在做软件估算时往往存在某些不确定性,这将使得软件项目管理人员无法正常进行管 理。因为估算是所有其它项目计划活动的基石,且项目计划又为软件工程过程提供了工作方 向,所以我们不能没有计划就开始着手开发,否则将会陷入盲目性。 (1)估算 估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的 勇气。估算本身带有风险。增加风险的各种因素如图96所示。图中的轴线表示被估算项目 的特征 结构化、定义、不确定性的程度 低风险区 基于以往工作量的复杂性 工作量的大小 图96估算与风险 项目的复杂性对于増加软件估算的不确定性影响很大。复杂性越高,估算的风险就越高
7 护性、完整性和可使用性。Gilb 提出了它们的定义和度量。 ① 正确性：一个程序必须正确地运行，而且还要为它的用户提供某些输出。正确性要 求软件执行所要求的功能。对于正确性，最一般的度量是每千代码行(KLOC)的差错数，其 中将差错定义为已被证实是不符合需求的缺陷。差错在程序交付用户普遍使用后由程序的用 户报告，按标准的时间周期(典型情况是 1 年)进行计数。 ② 可维护性：包括当程序中发现错误时，要能够很容易地修正它；当程序的环境发生 变化时，要能够很容易地适应之；当用户希望变更需求时，要能够很容易地增强它。还没有 一种方法可以直接度量可维护性，因此必须采取间接度量。有一种简单的面向时间的度量， 叫做平均变更等待时间 MTTC（Mean Time To Change)。 这个时间包括开始分析变更要求、 设计合适的修改、实现变更并测试它、以及把这种变更发送给所有的用户。一般地，一个可 维护的程序与那些不可维护的程序相比，应有较低的 MTTC（对于相同类型的变更)。 ③ 完整性：这个属性度量一个系统抗拒对它的安全性攻击(事故的和人为的)的能力。 软件的所有三个成分：程序、数据和文档都会遭到攻击。 为了度量完整性，需要定义两个附加的属性：危险性和安全性。危险性是特定类型的攻 击将在一给定时间内发生的概率，它可以被估计或从经验数据中导出。安全性是排除特定类 型攻击的概率，它也可以被估计或从经验数据中导出。一个系统的完整性可定义为： 完整性 ＝ ∑（1－危险性×（1－安全性）） 其中，对每一个攻击的危险性和安全性都进行累加。 ④ 可使用性：即用户友好性。如果一个程序不具有“用户友好性”，即使它所执行的 功能很有价值，也常常会失败。可使用性力图量化“用户友好性”，并依据以下四个特征进 行度量： ▪ 为学习系统所需要的体力上的和智力上的技能； ▪ 为达到适度有效使用系统所需要的时间； ▪ 当软件被某些人适度有效地使用时所度量的在生产率方面的净增值； ▪ 用户角度对系统的主观评价(可以通过问题调查表得到)。 4、软件项目的估算 在做软件估算时往往存在某些不确定性，这将使得软件项目管理人员无法正常进行管 理。因为估算是所有其它项目计划活动的基石，且项目计划又为软件工程过程提供了工作方 向，所以我们不能没有计划就开始着手开发，否则将会陷入盲目性。 (1) 估算 估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的 勇气。估算本身带有风险。增加风险的各种因素如图 9.6 所示。图中的轴线表示被估算项目 的特征。 图 9.6 估算与风险 项目的复杂性对于增加软件估算的不确定性影响很大。复杂性越高，估算的风险就越高
但是,复杂性是相对度量,它与项目参加人员的经验有关。例如,一个实时系统的开发,对 于过去仅做过批处理应用项目的软件开发组来说是非常复杂的,但对于一个过去开发过许多 高速过程控制软件的软件小组来说可能就是很容易的了。此外,这种度量一般用在设计或编 码级,而在软件计划时(设计和代码存在之前)使用就很困难。因此,可以在计划过程的早期 建立其它较为主观的复杂性评估,如功能点复杂性校正因素。 项目的规模对于软件估算的精确性和功效影响也比较大。因为随着软件规模的扩大,软 件元素之间的相互依赖、相互影响程度迅速增加,因而估算的一个重要方法—一问题分解会 变得更加困难。由此可知,项目的规模越大,开发工作量越大,估算的风险越高 项目的结构化程度也影响项目估算的风险。所谓结构性是指功能分解的简便性和处理信 息的层次性。结构化程度的提高,进行精确估算的能力就能提高,而风险将减少。 历史信息的有效性也影响估算的风险。回顾过去,就能够仿效做过的事,且改进出现问 题的地方。在对过去的项目进行综合的软件度量之后,就可以借用来比较准确地进行估算, 安排进度以避免重走过去的弯路,而总的风险也减少了 风险靠对不确定性程度定量地进行估算来度量,此外,如果对软件项目的作用范围还不 十分清楚,或者用户的要求经常变更,都会导致对软件项目所需资源、成本、进度的估算频 频变动,增加估算的风险。计划人员应当要求在软件系统的规格说明中给出完备的功能、性 能、接口的定义。更重要的是,计划人员和用户都应认识到经常改变软件需求意味着在成本 和进度上的不稳定性 (2)软件的范围 软件项目计划第一项活动就是确定软件的范围。应当从管理角度和技术角度出发,确定 明确的和可理解的项目范围,明确地给出定量的数据(如同时使用该软件的用户数目,发送表 格的长短,最大允许响应时间等),指明约束条件和限制(如存储容量)。此外还要叙述某些质 量因素(如给出的算法是否容易理解、是否使用高级语言等)。 软件范围包括功能、性能、限制、接口和可靠性。在估算开始之前,应对软件的功能进 行评价,并对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有 关,因此常常采用某种程度的功能分解。性能的考虑包括处理和响应时间的需求。约束条件 则标识外部硬件、可用存储或其它现有系统对软件的限制。 功能、性能和约束必须在一起进行评价。当性能限制不同时,为实现同样的功能,开发 工作量可能相差一个数量级。功能、性能和约束是密切联系在一起的。 软件与其它系统元素是相互作用的。计划人员要考虑每个接口的性质和复杂性,以确定 对开发资源、成本和进度的影响。接口的概念可解释为: 运行软件的硬件(如处理机与外设)及间接受软件控制的设备(如机器、显示器) 必须与新软件链接的现有的软件(如数据库存取例程、子程序包、操作系统) 通过终端或其它输入/输出设备使用该软件的人 该软件运行前后的一系列操作过程。 对于每一种情况,都必须清楚地了解通过接口的信息转换 软件范围最不明确的方面就是可靠性的讨论。软件可靠性的度量已经存在,但它们在项 的这个阶段难得用上。因此,可以按照软件的一般性质规定一些具体的要求以保证它的可 靠性。 (3)软件开发中的资源 软件项目计划的第二个任务是对完成该软件项目所需的资源进行估算。图97把软件开 发所需的资源画成一个金字塔,在塔的底部有现成的用以支持软件开发的工具——硬件及软 件工具,在塔的高层是最基本的资源——人。通常,对每一种资源,应说明4个特性:资源 的描述,资源的有效性说明,资源在何时开始需要,使用资源的持续时间。最后两个特性统
8 但是，复杂性是相对度量，它与项目参加人员的经验有关。例如，一个实时系统的开发，对 于过去仅做过批处理应用项目的软件开发组来说是非常复杂的，但对于一个过去开发过许多 高速过程控制软件的软件小组来说可能就是很容易的了。此外，这种度量一般用在设计或编 码级，而在软件计划时(设计和代码存在之前)使用就很困难。因此，可以在计划过程的早期 建立其它较为主观的复杂性评估，如功能点复杂性校正因素。 项目的规模对于软件估算的精确性和功效影响也比较大。因为随着软件规模的扩大，软 件元素之间的相互依赖、相互影响程度迅速增加，因而估算的一个重要方法──问题分解会 变得更加困难。由此可知，项目的规模越大，开发工作量越大，估算的风险越高。 项目的结构化程度也影响项目估算的风险。所谓结构性是指功能分解的简便性和处理信 息的层次性。结构化程度的提高，进行精确估算的能力就能提高，而风险将减少。 历史信息的有效性也影响估算的风险。回顾过去，就能够仿效做过的事，且改进出现问 题的地方。在对过去的项目进行综合的软件度量之后，就可以借用来比较准确地进行估算， 安排进度以避免重走过去的弯路，而总的风险也减少了。 风险靠对不确定性程度定量地进行估算来度量，此外，如果对软件项目的作用范围还不 十分清楚，或者用户的要求经常变更，都会导致对软件项目所需资源、成本、进度的估算频 频变动，增加估算的风险。计划人员应当要求在软件系统的规格说明中给出完备的功能、性 能、接口的定义。更重要的是，计划人员和用户都应认识到经常改变软件需求意味着在成本 和进度上的不稳定性。 (2) 软件的范围 软件项目计划第一项活动就是确定软件的范围。应当从管理角度和技术角度出发，确定 明确的和可理解的项目范围，明确地给出定量的数据(如同时使用该软件的用户数目，发送表 格的长短，最大允许响应时间等)，指明约束条件和限制(如存储容量)。此外还要叙述某些质 量因素(如给出的算法是否容易理解、是否使用高级语言等)。 软件范围包括功能、性能、限制、接口和可靠性。在估算开始之前，应对软件的功能进 行评价，并对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有 关，因此常常采用某种程度的功能分解。性能的考虑包括处理和响应时间的需求。约束条件 则标识外部硬件、可用存储或其它现有系统对软件的限制。 功能、性能和约束必须在一起进行评价。当性能限制不同时，为实现同样的功能，开发 工作量可能相差一个数量级。功能、性能和约束是密切联系在一起的。 软件与其它系统元素是相互作用的。计划人员要考虑每个接口的性质和复杂性，以确定 对开发资源、成本和进度的影响。接口的概念可解释为： ▪ 运行软件的硬件(如处理机与外设)及间接受软件控制的设备(如机器、显示器)； ▪ 必须与新软件链接的现有的软件(如数据库存取例程、子程序包、操作系统)； ▪ 通过终端或其它输入／输出设备使用该软件的人； ▪ 该软件运行前后的一系列操作过程。 对于每一种情况，都必须清楚地了解通过接口的信息转换。 软件范围最不明确的方面就是可靠性的讨论。软件可靠性的度量已经存在，但它们在项 目的这个阶段难得用上。因此，可以按照软件的一般性质规定一些具体的要求以保证它的可 靠性。 (3) 软件开发中的资源 软件项目计划的第二个任务是对完成该软件项目所需的资源进行估算。图 9.7 把软件开 发所需的资源画成一个金字塔，在塔的底部有现成的用以支持软件开发的工具──硬件及软 件工具，在塔的高层是最基本的资源──人。通常，对每一种资源，应说明 4 个特性：资源 的描述，资源的有效性说明，资源在何时开始需要，使用资源的持续时间。最后两个特性统
称为时间窗口。对每一个特定的时间窗口,在开始使用它之前就应说明它的有效性 人:需要的技能,开始时间,工作期限,有效性 具今硬件:开发系统,目标机器,新系统其它硬件部 工 软件:支持软件,实用软件 投入时间,持续时间,有效性 图97软件开发所需的资源 ①人力资源 在考虑各种软件开发资源时,人是最重要的资源。在安排开发活动时必须考虑人员的技 术水平、专业、人数、以及在开发过程各阶段中对各种人员的需要 计划人员根据范围估算,选择为完成开发工作所需要的技能。并在组织状况(如管理人 员、高级软件工程师等)和专业(如通信、数据库、微机等)两方面做出安排。 对于一些规模较小的项目(1个人年或者更少),只要向专家做些咨询,也许一个人就可 以完成所有的软件工程步骤。对一些规模较大的项目,在整个软件生存期中,各种人员的参 与情况是不一样的。图9.8画出了各类不同的人员随开发工作的进展在软件工程各个阶段的 参与情况的典型曲线 人高 高级技术人员 员参加程度 初级技术人员 管理人员 计需概详编 设设 测测测 划析计计码试试试 图98管理人员与技术人员的参与情况 个软件项目所需要的人数只能在对开发的工作量做出估算之后才能决定 ②硬件资源 硬件是作为软件开发项目的一种工具而投入的,可考虑三种硬件资源 宿主机( Host machine)—软件开发时使用的计算机及外围设备 目标机( Target machine)——运行已开发成功软件的计算机及外围设备; 其它硬件设备——一专用软件开发时需要的特殊硬件资源 宿主机连同必要的软件工具构成一个软件开发系统。通常这样的开发系统能够支持多种 用户的需要,且能保持大量的由软件开发小组成员共享的信息。但在许多情况下,除了那些 很大的系统之外,不一定非要配备专门的开发系统。因此,所谓硬件资源,可以认为是对现 存计算机系统的使用,宿主机与目标机可以是同一种机型 可以定义系统中其它的硬件元素为软件开发的资源。例如,在开发自动排版软件的过程
9 称为时间窗口。对每一个特定的时间窗口，在开始使用它之前就应说明它的有效性。 图 9.7 软件开发所需的资源 ① 人力资源 在考虑各种软件开发资源时，人是最重要的资源。在安排开发活动时必须考虑人员的技 术水平、专业、人数、以及在开发过程各阶段中对各种人员的需要。 计划人员根据范围估算，选择为完成开发工作所需要的技能。并在组织状况(如管理人 员、高级软件工程师等)和专业(如通信、数据库、微机等)两方面做出安排。 对于一些规模较小的项目(1 个人年或者更少)，只要向专家做些咨询，也许一个人就可 以完成所有的软件工程步骤。对一些规模较大的项目，在整个软件生存期中，各种人员的参 与情况是不一样的。图 9.8 画出了各类不同的人员随开发工作的进展在软件工程各个阶段的 参与情况的典型曲线。 图 9.8 管理人员与技术人员的参与情况 一个软件项目所需要的人数只能在对开发的工作量做出估算之后才能决定。 ② 硬件资源 硬件是作为软件开发项目的一种工具而投入的，可考虑三种硬件资源： ▪ 宿主机(Host machine)──软件开发时使用的计算机及外围设备； ▪ 目标机(Target machine)──运行已开发成功软件的计算机及外围设备； ▪ 其它硬件设备──专用软件开发时需要的特殊硬件资源； 宿主机连同必要的软件工具构成一个软件开发系统。通常这样的开发系统能够支持多种 用户的需要，且能保持大量的由软件开发小组成员共享的信息。但在许多情况下，除了那些 很大的系统之外，不一定非要配备专门的开发系统。因此，所谓硬件资源，可以认为是对现 存计算机系统的使用，宿主机与目标机可以是同一种机型。 可以定义系统中其它的硬件元素为软件开发的资源。例如，在开发自动排版软件的过程
中,可能需要一台照相排版机。所有硬件元素都应当由计划人员指定。 ③软件资源 软件在开发期间使用了许多软件工具来帮助软件的开发。软件工程人员使用在许多方面 都类似于硬件工程人员所使用的CAD/CAE工具的软件工具集。这种软件工具集叫做计算 机辅助软件工程(CASE)。主要的软件工具可做如下分类。 业务系统计划工具——业务系统计划工具借助特定的“元语言”建立一个组织的战略 信息需求的模型,导出特定的信息系统。这些工具要解答一些简单但重要的问题,例如,业 务关键数据从何处来?这些信息又向何处去?如何使用它们?当它们在业务系统中传递时又 如何变换?要增加什么样的新信息? 项目管理工具——项目管理人员使用这些工具可生成关于工作量、成本及软件项目持 续时间的估算。定义开发策略及达到这一目标的必要的步骤。计划可行的项目进程安排。以 及持续地跟踪项目的实施。此外,管理人员还可使用工具收集建立软件开发生产率和产品质 量的那些度量数据。 ·支持工具——支持工具可以分类为文档生成工具、网络系统软件、数据库、电子邮件、 通报板,以及在开发软件时控制和管理所生成信息的配置管理工具 分析和设计工具——一分析和设计工具可帮助软件技术人员建立目标系统的分析模型 和设计模型。这些工具还帮助人们进行模型质量的评价。它们靠对每一个模型进行执行一致 性和有效性的检验,帮助软件技术人员在错误扩散到程序中之前排除之。 编程工具——一系统软件实用程序、编辑器、编译器及调试程序都是CASE中必不可少 的部分。而除这些工具之外,还有一些新的编程工具。面向对象的程序设计工具、第四代程 序生成语言。高级数据库査询系统,及一大批PC工具(如表格软件) 组装和测试工具——测试工具为软件测试提供了各种不同类型和级别的支持。有些工 具,像路径覆盖分析器为测试用例设计提供了直接支持,并在测试的早期使用。其它工具, 像自动回归测试和测试数据生成工具,在组装和确认测试时使用,它们能帮助减少在测试过 程中所需要的工作量。 原型化和模拟工具——原型化和模拟工具是一个很大的工具集,它包括的范围从简单 的窗口画图到实时嵌入系统时序分析与规模分析的模拟产品。原型化工具把注意力集中在建 立窗口和为使用户能够了解一个信息系统或工程应用的输入/输出域而提出的报告。使用模 拟工具可建立嵌入式的实时应用,例如,为一架飞机建立航空控制系统的模型。在系统建立 之前,可以对用模拟工具建立起来的模型进行分析,对系统的运行时间性能进行评价。 维护工具——维护工具可以帮助分解一个现存的程序并帮助软件技术人员理解这个 程序。软件技术人员必须利用直觉、设计观念和人的智慧来完成逆向工程过程及再工程 框架工具——这些工具能够提供一个建立集成项目支撑环境(IPSE)的框架。在多数 情况,框架工具实际提供了数据库管理和配置管理的能力与一些实用工具,能够把各种工具 集成到IPSE中 ④软件复用性及软件构件库 为了促成软件的复用,以提高软件的生产率和软件产品的质量,可建立可复用的软件部 件库。根据需要,对软件部件稍做加工,就可以构成一些大的软件包。这要求这些软件部件 应加以编目,以利引用,并进行标准化和确认,以利于应用和集成。 在使用这些软件部件时,有两种情况必须加以注意: 如果有现成的满足要求的软件,应当设法搞到它。因为搞到一个现成的软件所花的费 用比重新开发一个同样的软件所花的费用少得多 如果对一个现存的软件或软件部件,必须修改它才能使用。这时必须多加小心,谨慎 对待,因为修改时可能会引出新的问题。而修改一个现存软件所花的费用有时会大于开发
10 中，可能需要一台照相排版机。所有硬件元素都应当由计划人员指定。 ③ 软件资源 软件在开发期间使用了许多软件工具来帮助软件的开发。软件工程人员使用在许多方面 都类似于硬件工程人员所使用的 CAD／CAE 工具的软件工具集。这种软件工具集叫做计算 机辅助软件工程（CASE）。主要的软件工具可做如下分类。 ▪ 业务系统计划工具──业务系统计划工具借助特定的“元语言”建立一个组织的战略 信息需求的模型，导出特定的信息系统。这些工具要解答一些简单但重要的问题，例如，业 务关键数据从何处来？这些信息又向何处去？如何使用它们？当它们在业务系统中传递时又 如何变换？要增加什么样的新信息？ ▪ 项目管理工具──项目管理人员使用这些工具可生成关于工作量、成本及软件项目持 续时间的估算。定义开发策略及达到这一目标的必要的步骤。计划可行的项目进程安排。以 及持续地跟踪项目的实施。此外，管理人员还可使用工具收集建立软件开发生产率和产品质 量的那些度量数据。 ▪ 支持工具──支持工具可以分类为文档生成工具、网络系统软件、数据库、电子邮件、 通报板，以及在开发软件时控制和管理所生成信息的配置管理工具。 ▪ 分析和设计工具──分析和设计工具可帮助软件技术人员建立目标系统的分析模型 和设计模型。这些工具还帮助人们进行模型质量的评价。它们靠对每一个模型进行执行一致 性和有效性的检验，帮助软件技术人员在错误扩散到程序中之前排除之。 ▪ 编程工具──系统软件实用程序、编辑器、编译器及调试程序都是 CASE 中必不可少 的部分。而除这些工具之外，还有一些新的编程工具。面向对象的程序设计工具、第四代程 序生成语言。高级数据库查询系统，及一大批 PC 工具(如表格软件）。 ▪ 组装和测试工具──测试工具为软件测试提供了各种不同类型和级别的支持。有些工 具，像路径覆盖分析器为测试用例设计提供了直接支持，并在测试的早期使用。其它工具， 像自动回归测试和测试数据生成工具，在组装和确认测试时使用，它们能帮助减少在测试过 程中所需要的工作量。 ▪ 原型化和模拟工具──原型化和模拟工具是一个很大的工具集，它包括的范围从简单 的窗口画图到实时嵌入系统时序分析与规模分析的模拟产品。原型化工具把注意力集中在建 立窗口和为使用户能够了解一个信息系统或工程应用的输入／输出域而提出的报告。使用模 拟工具可建立嵌入式的实时应用，例如，为一架飞机建立航空控制系统的模型。在系统建立 之前，可以对用模拟工具建立起来的模型进行分析，对系统的运行时间性能进行评价。 ▪ 维护工具──维护工具可以帮助分解一个现存的程序并帮助软件技术人员理解这个 程序。软件技术人员必须利用直觉、设计观念和人的智慧来完成逆向工程过程及再工程。 ▪ 框架工具──这些工具能够提供一个建立集成项目支撑环境（IPSE）的框架。在多数 情况，框架工具实际提供了数据库管理和配置管理的能力与一些实用工具，能够把各种工具 集成到 IPSE 中。 ④ 软件复用性及软件构件库 为了促成软件的复用，以提高软件的生产率和软件产品的质量，可建立可复用的软件部 件库。根据需要，对软件部件稍做加工，就可以构成一些大的软件包。这要求这些软件部件 应加以编目，以利引用，并进行标准化和确认，以利于应用和集成。 在使用这些软件部件时，有两种情况必须加以注意： ▪ 如果有现成的满足要求的软件，应当设法搞到它。因为搞到一个现成的软件所花的费 用比重新开发一个同样的软件所花的费用少得多。 ▪ 如果对一个现存的软件或软件部件，必须修改它才能使用。这时必须多加小心，谨慎 对待，因为修改时可能会引出新的问题。而修改一个现存软件所花的费用有时会大于开发一