到预定的要求,需要在软件开发的各个阶段采取相应的措施加以保证。因此,软件的可维护 性是产品投入运行以前各阶段面向上述各质量特性要求进行开发的最终结果 (2)可维护性的度量 人们一直期望对软件的可维护性做出定量度量,但要做到这一点并不容易。许多研究工 作集中在这个方面,形成了一个引人注目的学科—软件度量学。下面我们介绍度量一个可 维护的程序的七种特性时常用的方法。这就是质量检查表、质量测试、质量标准。 质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。评价者针对检查表上 的每一个问题,依据自己的定性判断,回答“Yes”或者“No”。质量测试与质量标准则用于 定量分析和评价程序的质量。由于许多质量特性是相互抵触的,要考虑几种不同的度量标准 相应地去度量不同的质量特性 ①可理解性 可理解性表明人们通过阅读源代码和相关文档,了解程序功能及其如何运行的容易程 度。一个可理解的程序主要应具备以下一些特性:模块化(模块结构良好、功能完整、简明) 风格一致性(代码风格及设计风格的一致性),不使用令人捉摸不定或含糊不清的代码,使用 有意义的数据名和过程名,结构化,完整性(对输入数据进行完整性检查)等。 用于可理解性度量的检查表的内容有:程序是否模块化?结构是否良好?每个模块是否 有注释块,说明程序的功能、主要变量的用途及取值、所有调用它的模块、以及它调用的所 有模块?在模块中是否有其它有用的注释内容,包括输入输出、精确度检査、限制范围和约 束条件、假设、错误信息、程序履历等?在整个程序中缩进和间隔的使用风格是否一致?在 程序中每一个变量,过程是否具有单一的有意义的名字?程序是否体现了设计思想?程序是 否限制使用一般系统中没有的内部函数过程与子程序?是否能通过建立公共模块或子程序来 避免多余的代码?所有变量是否是必不可少的?是否避免了把程序分解成过多的模块、函数 或子程序?程序是否避免了很难理解的、非标准的语言特性? 对于可理解性,可以使用一种叫做“90-10测试”的方法来衡量。即把一份被测试的源 程序清单拿给一位有经验的程序员阅读10分钟,然后把这个源程序清单拿开,让这位程序员 凭自己的理解和记忆,写出该程序的90%。如果程序员真的写出来了,则认为这个程序具有 可理解性,否则这个要重新编写 ②可靠性 可靠性表明一个程序按照用户的要求和设计目标,在给定的一段时间内正确执行的概 率。关于可靠性,度量的标准主要有:平均失效间隔时间MTTF( Mean time to failure)、平 均修复时间MIIR( Mean Time To Repair error)、有效性A(=MIBD/(MIBD+MDT))。 度量可靠性的方法,主要有两类: ■根据程序错误统计数字,进行可靠性预测。常用方法是利用一些可靠性模型,根据程 序测试时发现并排除的错误数预测平均失效间隔时间MITF ■根据程序复杂性,预测软件可靠性。用程序复杂性预测可靠性,前提条件是可靠性与 复杂性有关。因此可用复杂性预测出错率。程序复杂性度量标准可用于预测哪些模块最可能 发生错误,以及可能出现的错误类型。了解了错误类型及它们在哪里可能出现,就能更快地 查出和纠正更多的错误,提高可靠性。 用于可靠性度量的检查表的内容有:程序中对可能出现的没有定义的数学运算是否做了 检查?如除以“0”。循环终止和多重转换变址参数的范围,是否在使用前做了测试?下标的 范围是否在使用前测试过?是否包括错误恢复和再启动过程?所有数值方法是否足够准确? 输入的数据是否检査过?测试结果是否令人满意?大多数执行路径在测试过程中是否都已执 行过?对最复杂的模块和最复杂的模块接口,在测试过程中是否集中做过测试?测试是否包 括正常的、特殊的和非正常的测试用例?程序测试中除了假设数据外,是否还用了实际数据?12 到预定的要求，需要在软件开发的各个阶段采取相应的措施加以保证。因此，软件的可维护 性是产品投入运行以前各阶段面向上述各质量特性要求进行开发的最终结果。 (2) 可维护性的度量 人们一直期望对软件的可维护性做出定量度量，但要做到这一点并不容易。许多研究工 作集中在这个方面，形成了一个引人注目的学科──软件度量学。下面我们介绍度量一个可 维护的程序的七种特性时常用的方法。这就是质量检查表、质量测试、质量标准。 质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。评价者针对检查表上 的每一个问题，依据自己的定性判断，回答“Yes”或者“No”。质量测试与质量标准则用于 定量分析和评价程序的质量。由于许多质量特性是相互抵触的，要考虑几种不同的度量标准， 相应地去度量不同的质量特性。 ① 可理解性 可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程 度。一个可理解的程序主要应具备以下一些特性：模块化(模块结构良好、功能完整、简明)， 风格一致性(代码风格及设计风格的一致性)，不使用令人捉摸不定或含糊不清的代码，使用 有意义的数据名和过程名，结构化，完整性(对输入数据进行完整性检查)等。 用于可理解性度量的检查表的内容有：程序是否模块化? 结构是否良好？每个模块是否 有注释块，说明程序的功能、主要变量的用途及取值、所有调用它的模块、以及它调用的所 有模块？在模块中是否有其它有用的注释内容，包括输入输出、精确度检查、限制范围和约 束条件、假设、错误信息、程序履历等？在整个程序中缩进和间隔的使用风格是否一致？在 程序中每一个变量，过程是否具有单一的有意义的名字？程序是否体现了设计思想？程序是 否限制使用一般系统中没有的内部函数过程与子程序？是否能通过建立公共模块或子程序来 避免多余的代码？所有变量是否是必不可少的？是否避免了把程序分解成过多的模块、函数 或子程序？程序是否避免了很难理解的、非标准的语言特性？ 对于可理解性，可以使用一种叫做“90－10 测试”的方法来衡量。即把一份被测试的源 程序清单拿给一位有经验的程序员阅读 10 分钟，然后把这个源程序清单拿开，让这位程序员 凭自己的理解和记忆，写出该程序的 90％。如果程序员真的写出来了，则认为这个程序具有 可理解性，否则这个要重新编写。 ② 可靠性 可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概 率。关于可靠性，度量的标准主要有：平均失效间隔时间 MTTF(Mean Time To Failure）、平 均修复时间 MTTR(Mean Time To Repair error)、有效性 A( = MTBD∕(MTBD+MDT))。 度量可靠性的方法，主要有两类： ▪ 根据程序错误统计数字，进行可靠性预测。常用方法是利用一些可靠性模型，根据程 序测试时发现并排除的错误数预测平均失效间隔时间 MTTF。 ▪ 根据程序复杂性，预测软件可靠性。用程序复杂性预测可靠性，前提条件是可靠性与 复杂性有关。因此可用复杂性预测出错率。程序复杂性度量标准可用于预测哪些模块最可能 发生错误，以及可能出现的错误类型。了解了错误类型及它们在哪里可能出现，就能更快地 查出和纠正更多的错误，提高可靠性。 用于可靠性度量的检查表的内容有：程序中对可能出现的没有定义的数学运算是否做了 检查？如除以“0”。循环终止和多重转换变址参数的范围，是否在使用前做了测试？下标的 范围是否在使用前测试过？是否包括错误恢复和再启动过程？所有数值方法是否足够准确？ 输入的数据是否检查过？测试结果是否令人满意？大多数执行路径在测试过程中是否都已执 行过？对最复杂的模块和最复杂的模块接口，在测试过程中是否集中做过测试？测试是否包 括正常的、特殊的和非正常的测试用例？程序测试中除了假设数据外，是否还用了实际数据？