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 中。 ④ 软件复用性及软件构件库 为了促成软件的复用，以提高软件的生产率和软件产品的质量，可建立可复用的软件部 件库。根据需要，对软件部件稍做加工，就可以构成一些大的软件包。这要求这些软件部件 应加以编目，以利引用，并进行标准化和确认，以利于应用和集成。 在使用这些软件部件时，有两种情况必须加以注意： ▪ 如果有现成的满足要求的软件，应当设法搞到它。因为搞到一个现成的软件所花的费 用比重新开发一个同样的软件所花的费用少得多。 ▪ 如果对一个现存的软件或软件部件，必须修改它才能使用。这时必须多加小心，谨慎 对待，因为修改时可能会引出新的问题。而修改一个现存软件所花的费用有时会大于开发一