5软件工程基础知识(3)

• 白盒测试法

    			- 白盒测试也称为结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。
    			- 白盒测试常用的技术
  
    				- (1)逻辑覆盖。
  
    				  逻辑覆盖考察用测试数据运行被测程序时对程序逻辑的覆盖程度，主要的逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖6种。
  
    					- ①语句覆盖。
  
    						- 语句覆盖是指选择足够的测试数据，使被测试程序中的每条语句至少执行一次。
    						- 语句覆盖对程序执行逻辑的覆盖很低，因此一般认为它是很弱的逻辑覆盖。
  
    					- ②判定覆盖。
  
    						- 判定覆盖是指设计足够的测试用例，使得被测程序中的每个判定表达式至少获得一次“真”值和“假”值，或者说是程序中的每一个取“真”分支和取“假”分支至少都通过一次，因此判定覆盖也称为分支覆盖。判定覆盖要比语句覆盖更强一些。
  
    					- ③条件覆盖。
  
    						- 条件覆盖是指构造一组测试用例，使得每一判定语句中每个逻辑条件的各种可能的值至少满足一次。
  
    					- ④判定/条件覆盖。
  
    						- 判定/条件覆盖是指设计足够的测试用例，使得判定中每个条件的所有可能取值（真假）至少出现一次，并使每个判定本身的判定结果(真/假)也至少出现一次。
  
    					- ⑤条件组合覆盖。
  
    						- 条件组合覆盖是指设计足够的测试用例，使得每个判定中条件的各种可能值的组合都至少出现一次。满足条件组合覆盖的测试用例是一定满足判定覆盖、条件覆盖和判定/条件覆盖的。
  
    					- ⑥路径覆盖。
  
    						- 路径覆盖是指覆盖被测试程序中所有可能的路径。
  
    				- (2)循环覆盖。
  
    					- 执行足够的测试用例，使得循环中的每个条件都得到验证。
  
    				- (3)基本路径测试。
  
    					- 基本路径测试法是在程序控制流图的基础上通过分析控制流图的环路复杂性，导出基本可执行路径集合，从而设计测试用例。设计出的测试用例要保证在测试中程序的每一条独立路径都执行过，即程序中的每条可执行语句至少执行一次。此外，所有条件语句的真值状态和假值状态都测试过。路径测试的起点是程序控制流图。程序控制流图中的结点代表包含一个或多个无分支的语句序列，边代表控制流。
  
    						- McCabe度量法
  
    							- McCabe度量法是由Thomas McCabe提出的一种基于程序控制流的复杂性度量方法。
    							- McCabe复杂性度量又称为环路度量，它认为程序的复杂性在很大程度上取决于控制的复杂性。单一的顺序程序结构最为简单，循环和选择构成的环路越多，程序就越复杂。这种方法以图论为工具，先画出程序图，然后用该图的环路数作为程序复杂性的度量值。程序图是退化的程序流程图，也就是说，把程序流程图中的每个处理符号都退化成一个结点，原来连接不同处理符号的流线变成连接不同点的有向弧，这样得到的有向图称为程序图，如图5-17所示。程序图仅描述程序内部的控制流程，完全不表现对数据的具体操作以及分支和循环的具体条件。
  
    								- 
  
    							- 根据图论，在一个强连通的有向图G中，环的个数V(G)由以下公式给出：V(G)=m-n+2p
  
    								- 其中，V（G)是有向图G中的环路数，m是图G中弧的个数，n是图G中的结点数，p是G中的强连通分量个数。
  
    									- p通常取1
  
    							- 也可以环路个数=闭合区域+1
    							- 在一个程序中，从程序图的入口点总能到达图中的任何一个结点，因此，程序总是连通的，但不是强连通的。为了使程序图成为强连通图，从图的入口点到出口点加一条用虚线表示的有向边，使图成为强连通图。这样就可以使用上式计算环路复杂性了。
  
    								- 环路复杂性度量反映了程序（或模块）的控制结构的复杂性。McCabe发现（G=10是一个实际模块的上限。当模块的环路复杂度超过10时，要充分测试这个模块变得特别难。
  
    			- 白盒测试的原则
  
    				- (1)程序模块中的所有独立路径至少执行一次。
    				- (2)在所有的逻辑判断中，取“真”和取“假”的两种情况至少都能执行一次。
    				- (3)每个循环都应在边界条件和一般条件下各执行一次。
    				- (4)测试程序内部数据结构的有效性等。
  
    - 测试用例由测试输入数据和与之对应的预期输出结果组成。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
  

  • 系统维护

    • 可维护性

      • 1）评价指标

        • (1)可理解性

          • 指别人能理解系统的结构、界面、功能和内部过程的难易程度。模块化、详细设计文档、结构化设计和良好的高级程序设计语言等都有助于提高可理解性。

            • 可靠性是指一个系统对于给定的时间间隔内、在给定条件下无失效运作的概率。可

            • 以用MTTF/(1+MTTF)来度量，其中MTTF为平均无故障时间。

              • mean time to failure

        • (2)可测试性

          • 诊断和测试的容易程度取决于易理解的程度。好的文档资料有利于诊断和测试，同时，程序的结构、高性能的测试工具以及周密计划的测试工序也是至关重要的。为此，开发人员在系统设计和编程阶段就应尽力把程序设计成易诊断和测试的。此外，在进行系统维护时，应该充分利用在系统测试阶段保存下米的测试用例。

            • 可用性是在给定的时间点上，一个系统能够按照规格说明正确运作的概率。可以用

            • MTBF/(1+MTBF)来度量，其中MTBF为平均失效间隔时间。

              • mean time between failures

        • (3)可修改性

          • 诊断和测试的容易程度与系统设计所制定的设计原则有直接关系。模块的耦合、内聚、作用范围与控制范围的关系等都对可修改性有影响。

            • 可维护性是在给定的使用条件下，在定的时间间隔内，使用规定的过程和资源完

            • 成维护活动的概率。可以用1/(1+MTTR)采度量，其中MTTR为平均修复时间。

              • mean time to repair

      • 2）维护与软件文档

        • 文档是软件可维护性的决定因素。由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档显得非常重要
        • 软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的：系统文档描述系统设计、实现和测试等各方面的内容。
        • 可维护性是所有软件都应具有的基本特点，必须在开发阶段保证软件具有可维护的特点。在软件工程的每一个阶段都应考虑并提高软件的可维护性，在每个阶段结束前的技术审查和管理复查中应该着重对可维护性进行复审。
        • 在系统分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注解并指明，并且指出软件的可移植性问题以及可能影响软件维护的系统界而：在系统设计阶段的复审期间，应该从容易修改、模块化和功能独立的目的出发，评价软件的结构和过程：在系统实施阶段的复审期间，代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。在完成了每项维护工作之后，都应该对软件维护本身进行认真的复审。

      • 3)软件文档的修改

        • 维护应该针对整个软件配置，不应该只修改源程序代码。如果对源程序代码的修改没有反秋在设计文档或用户手册中，可能会产生严重的后果。每当对数据、软件结构、模块过程或任何其他有关的软件特点做了改动时，必须立即修改相应的技术文档。不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。在以后的维护工作中，用户很可能因文档不完全符合实际而不能正确地理解软件，从而在维护中引入过多的错误。

    • 1)硬件维护

      • 硬件维护应由专职的硬件维护人员来负责，主要有两种类型的维护活动：一种是定期的设备保养性维护，保养周期可以是一周或一个月不等，维护的主要内容是进行例行的设备检查与保养，易耗品的更换与安装等：另一种是突发性的故障维护，即当设备出现突发性故障时，由专职的维修人员或请厂方的技术人员来排除故障，这种维修活动所花的时间不能过长，以免影响系统的正常运行。

    • 2)软件维护

      • 软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部修改。修改时应充分利用源程序，修改后要填写程序修改登记表，并在程序变更通知书上写明新旧程序的不同之处。

        • (1)正确性维护

          • 正确性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。这方面的维护工作量要占整个维护工作量的17%一21%。所发现的错误有的不太重要，不影响系统的正常运行，其维护工作可随时进行：而有的错误非常重要，甚至会影响整个系统的正常运行，其维护工作必须制定计划，进行修改，并且要进行复查和控制。

        • (2)适应性维护

          • 适应性维护是指使应用软件适应信总技术变化和管理需求变化而进行的修改。这方面的维护工作量占整个维护工作量的18%~25%。由于目前计算机硬件价格不断下降，各类系统软件层出不穷，人们常常为改善系统硬件环境和运行环境而产生系统更新换代的需求；企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。这些因素都将导致适应性维护工作的产生。进行这方面的维护工作也要像系统开发一样，有计划、有步骤地进行。

        • (3)完善性维护

          • 这是为扩充功能和改善性能而进行的修改，主要是指对己有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。另外，它还包括对处理效率和编写程序的改进，这方面的维护占整个维护工作的50%~60%,比重较大，也是关系到系统开发质量的重要方面。这方面的维护除了要有计划、有步骤地完成外，还要注意将相关的文档资料加入到前面相应的文档中。

        • (4)预防性维护

          • 为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。例如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。这方面的维护工作量占整个维护工作量的4%左右。

    • 3)数据维护

      • 数据维护工作主要是由数据库管理员来负责，主要负责数据库的安全性和完整性以及进行并发性控制。数据库管理员还要负责维护数据库中的数据，当数据库中的数据类型、长度等发生变化时，或者需要添加某个数据项、数据库时，要负责修改相关的数据库、数据字典，并通知有关人员。另外，数据库管理员还要负责定期出版数据字典文件及一些其他数据管理文件，以保留系统运行和修改的轨迹。当系统出现硬件故障并得到排除后，要负责数据库的恢复工作。
      • 数据维护中还有一项很重要的内容，那就是代码维护。不过代码维护发生的频率相对较小。代码的维护应由代码管理小组进行。变更代码应经过详细讨论，确定之后要用书面形式贯彻。代码维护的困难往往不在于代码本身的变更，而在于新代码的贯彻。为此，除了成立专门的代码管理小组外，各业务部门要指定专人进行代码管理，通过他们贯彻使用新代码。这样做的目的是要明确管理职责，有助于防止和更正错误。

• 软件项目管理

  • 软件项目估算

    • COCOMO估算模型

      • COCOMO模型是一种精确的、易于使用的成本估算模型。COCOMO模型按其详细程度分为基本COCOMO模型、中级COCOMO模型和详细COCOMO模型。

        • 1)基本COCOMO模型

          • 基本COCOMO模型是一个静态单变量模型，用于对整个软件系统进行佔算。其公式如下：
          • E=a(L)^b
          • D=c(E)^d
          • 其中，E表示工作量，单位是人月：D表示开发时间，单位是月：L是项目的源代码行估计值，
          • 不包括程序中的注释及文档，其单位是千行代码：a、b、c、d是常数。
          • 基本COCOMO模型可通过估算代码行的值L,然后计算开发工作量和开发时间的估算值。

        • 2)中级COCOMO模型

          • 中级C0C0M0模型是一个静态多变量模型，它将软件系统模型分为系统和部件两个层次，
          • 系统由部件构成，它把软件开发所需的人力（成木）看作是程序大小和一系列“成木驱动属性”的函数。
          • 中级COCOMO模型以基本COCOMO模型为基础，并考虑了15种影响软件工作量的因素，
          • 通过工作量调节因子(EAF)修正对工作量的估算，从而使估算更合理。其公式如下：
          • E-a(L)^b*EAF
          • 其中，L是软件产品的目标代码行数，单位是千行代码数：a、b是常数。

        • 3)详细COCOMO模型

          • 它将软件系统模型分为系统、子系统和模块3个层次，除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响。

    • COCOMOⅡ模型

      • 最初的COCOMO模型是得到产业界最广泛应用和讨论的软件成本估算模型之一，现在它已经演化成更全面的估算模型，称为COCOMOⅡ。和其前身一样，COCOMOII也是一种层次结构的估算模型，被分为3个阶段性模型。

        • (1)应用组装模型

          • 在软件工程的前期阶段使用，这时用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的。

        • (2)早期设计阶段模型

          • 在需求己经稳定并且基本的软件体系结构己经建立时使用。

        • (3)体系结构阶段模型

          • 在软件的构造过程中使用。

        • 和所有的软件估算模型一样，COCOMOⅡ模型也需要使用规模估算信息，在模型层次结构中有3种不同的规模估算选择：对象点、功能点和代码行。应用组装模型使用的是对象点：早期设计阶段模型使用的是功能点，功能点可以转换为代码行。

        • 对象点也是一种间接的软件测量。计算对象点时使用如下的计数值：（用户界面的）屏幕书：报表数；构造应用系统可能需要的构件数。

  • 进度管理

    • Gantt图（甘特图）

      • Gantt图是一种简单的水平条形图，它以日历为基准描述项目任务。水平轴表示日历时间线(如时、天、周、月和年等)，每个条形表示个任务，任务名称垂直地列在左边的列中，图中水平条的起点和终点对应水平轴上的时间，分别表示该任务的开始时间和结束时间，水平条的长度表示完成该任务所持续的时间。当日历中同一时段存在多个水平条时，表示任务之间的并发。

        • 图5-12所示的Gantt图描述了3个任务的进度安排。任务1首先开始，完成它需要6个月时间：任务2在1个月后开始，完成它需要9个月时间：任务3在6个月后开始，完成它需要5个月时间。

      • Gantt图能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性。但是它不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。

    • 项目计划评审技术（Program Evaluation&Review Technique,PERT图)

      • 概念

        • PERT图是一个有向图，图中的箭头表示任务，它可以标上完成该任务所需的时间。图中的结点表示流入结点的任务的结束，并开始流出结点的任务，这里把结点称为事件。只有当流入该结点的所有任务都结束时，结点所表示的事件才出现，流出结点的任务才可以开始。事件本身不消耗时间和资源，它仅表示某个时间点。
        • 一个事件有一个事件号和出现该事件的最早时刻和最迟时刻。最早时刻表示在此时刻之前从该事件出发的任务不可能开始：最迟时刻表示从该事件出发的任务必须在此时刻之前开始，否则整个工程就不能如期完成。
        • 每个任务还可以有一个松弛时间(Slack Time),表示在不影响整个工期的前提下完成该任务有多少机动余地。为了表示任务间的关系，在图中还可以加入一些空任务（用虚线箭头表示），完成空任务的时间为0。

      • 实例

      • PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系，即哪些任务完成后才能开始另外一些任务，以及如期完成整个工程的关键路径。图中的松弛时间则反映了完成某些任务时可以推迟其开始时间或延长其所需完成的时间。

        • 最早出现时刻

          • 顺着算

            • 流入箭头取最大

        • 最晚出现时刻

          • 倒着算

            • 流出箭头取最小

        • 松弛时间

          • 摸鱼时间

          • 多流出箭头特殊考虑

            • 分别计算

        • 关键路径

          • 松弛时间一直为0

      • 但是，PERT图不能反映任务之间的并行关系。

  • 配置管理

    • 在软件开发过程中变更是不可避免的，而变更时由于没有进行变更控制，可能加剧了项目中的混乱，为了协调软件开发使得混乱减到最小，使用配置管理技术，使变更所产生的错误达到最小并最有效地提高生产率。

    • 软件配置管理(Software Configure Management,SCM)用于整个软件工程过程。SCM是一组管理整个软件生存周期中各阶段变更的活动。

    • 主要目标

      • 标识变更
      • 控制变更
      • 版本控制
      • 确保变更正确地实现
      • 报告有关变更

    • 基线

      • 基线是软件生存周期中各开发阶段的一个特定点，它的作用是使各开发阶段的工作划分更加明确，使本来连续的工作在这些点上断开，以便于检查与肯定阶段成果。因此，基线可以作为一个检查点，在开发过程中，当采用的基线发生错误时可以知道所处的位置，返回到最近和最恰当的基线上。

    • 软件配置项

      • 软件配置项(Software Configure Item,SCI)是软件工程中产生的信息项，它是配置管理的基本单位，对于已经成为基线的SCI,虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。以下的SCI是SCM的对象，并可形成基线。

        • (1)系统规格说明书
        • (2)软件项目实施计划
        • (3)软件需求规格说明书
        • (4)设计规格说明书(数据设计、体系结构设计、模块设计、接口设计、对象描述（使用面向对象技术时)）
        • (5)源代码清单
        • (6)测试计划和过程、测试用例和测试结果记录
        • (7)操作和安装手册
        • (8)可执行程序(可执行程序模块、连接模块)
        • (9)数据库描述(模式和文件结果、初始内容)
        • (10)用户手册
        • (11)维护文档(软件问题报告、维护请求、工程变更次序)
        • (12)软件工程标准
        • (13)项目开发小结

    • 版本控制

      • 软件配置实际上是一个动态的概念，它一方面随着软件生存周期向前推进，SCI的数量在不断增多，一些文档经过转换生成另一些文档，并产生一些信息：另一方面又随时会有新的变更出现，形成新的版本。

      • 可以采用图5-14所示的演变图来表达系统的不同版本，在图中各个结点是一个完全的软件版本。软件的每一个版本都是SCI(源代码、文档、数据)的一个汇集，而且各个版本都可能由不同的变种组成。

    • 变更控制

      • 软件工程过程中某一阶段的变更均要引起软件配置的变更，这种变更必须严格地加以控制和管理，保持修改信息，并把精确、清晰的信息传递到软件工程过程的下一步骤。

      • 对于一个大型软件来说，不加控制的变更很快就会引起混乱。因此，变更控制是一项最重要的软件配置任务。为了有效地实现变更控制，需借助于配置数据库和基线的概念。

        • (1)开发库

          • 专供开发人员使用，其中的信总可能做频繁修改，对其控制相当宽松。

        • (2)受控库

          • 在生存期某一阶段工作结束时发布的阶段产品，这些是与软件开发工作相关的计算机可读信息和人工可读信息。软件配置管理正是对受控库中的各个软件项进行管理，受控库也称为软件配置库。

        • (3)产品库

          • 在开发的软件产品完成系统测试后，作为最终产品存入产品库，等待交付用户或现场安装。

  • 风险管理

    • 分类

      • 分类1

        • 项目风险

          • 项目风险威胁到项目计划。也就是说，如果项目风险发生，就有可能拖延项目的进度和增加项目的成本。项目风险是指预算、进度、人员（聘用职员及组织）、资源、利益相关者、需求等方面的潜在问题以及它们对软件项目的影响。项目复杂度、规模及结构不确定性也属于项目风险因素。

        • 技术风险

          • 技术风险威胁到要开发软件的质量及交付时间。如果技术风险发生，开发工作就可能变得很困难或根本不可能。技术风险是指设计、实现、接口、验证和维护等方面的潜在问题。此外，规格说明的歧义性、技术的不确定性、技术陈旧以及“前沿”技术也是技术风险因素。技术风险的发生是因为问题比我们所设想的更加难以解决。

        • 商业风险

          • 商业风险威胁到要开发软件的生存能力，且常常会危害到项目或产品。

            • (1)市场风险

              • 开发了一个没有人真正需要的优良产品或系统。

            • (2)策略风险

              • 开发的产品不再符合公司的整体商业策略。

            • (3)销售风险

              • 开发了一个销售部门不知道如何去销售的产品。

            • (4)管理风险

              • 由于重点的转移或人员的变动而失去了高级管理层的支持。

            • (5)预算风险

              • 没有得到预算或人员的保证。

      • 分类2（Charette提出）

        • 己知风险

          • 己知风险是通过仔细评估项目计划、开发项目的商业和技术环境以及其他可靠的信息来源(如不现实的交付时间、没有文档化需求或文档化软件范围、恶劣的开发环境)之后可以发现的那些风险。

        • 可预测风险

          • 可预测风险能够从过去项目的经验中推断出来(如人员变动、与客户缺乏沟通、由于正在进行维护而使开发人员精力分散)。

        • 不可预测风险

          • 不可预测风险可能会真的出现，但很难事先识别。

    • 1.风险识别

      • 概念

        • 风险识别试图系统化地指出对项目计划(估算、进度、资源分配等)的威胁。识别出已知风险和可预测风险后，项目管理者首先要做的是在可能时回避这些风险，在必要时控制这些风险。

      • 风险条目检查表

        • 识别风险的一种方法是建立风险条目检查表。该检查表可用于风险识别，并且主要用来识别下列几种类型中的一些已知风险和可预测风险。

          • (1)产品规模。与要开发或要修改的软件的总体规模相关的风险。
          • (2)商业影响。与管理者或市场所施加的约束相关的风险。
          • (3)客户特性。与客户的素质以及开发者和客户定期沟通的能力相关的风险。
          • (4)过程定义。与软件过程定义的程度以及该过程被开发组织遵守的程度相关的风险。
          • (5)开发环境。与用来开发产品的工具的可得性及质量相关的风险。
          • (6)开发技术。与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。
          • (7)人员才干及经验。与软件工程师的总体技术水平及项目经验相关的风险。

        • 风险条目检查表可以采用不同的方式来组织。与上述每个主题相关的问题可以针对每一个软件项目来回答。根据这些问题的答案，项目管理者就可以估计风险产生的影响。

        • 当然，也可以采用另一种风险条目检查表格式，即仅仅列出与每一种类型有关的特性，最终给出一组风险因素和驱动因子以及它们发生的概率。风险因素包括性能、成本、支持和进度。

      • 风险因素定义

        • (1)性能风险。产品能够满足需求且符合其使用目的的不确定程度。
        • (2)成本风险。能够维持项目预算的不确定程度。
        • (3)支持风险。开发出的软件易于纠错、修改及升级的不确定程度。
        • (4)进度风险。能够维持项目进度且按时交付产品的不确定程度。

    • 2.风险预测

      • 概念

        • 风险预测又称风险估计，它试图从两个方面评估一个风险：风险发生的可能性或概率：如果风险发生了所产生的后果。

      • 1)风险预测活动

        • 通常，项目计划人员与管理人员、技术人员一起进行以下4步风险预测活动。

          • (1)建立一个尺度或标准，以反映风险发生的可能性。
          • (2)描述风险产生的后果。
          • (3)估算风险对项目和产品的影响。
          • (4)标注风险预测的整体精确度，以免产生误解。

        • 一种简单的风险预测技术是建立风险表。风险表的第1列列出所有的风险（由风险识别活动得到），第2~4列列出每个风险的种类、发生的概率以及所产生的影响。风险所产生的影响可用一个数字来表示：“1”表示灾难性的：“2”表示严重的：“3”表示轻微的：“4”表示可忽略的。

      • 2)评估风险影响

        • 如果风险真的发生，有3个因素可能会影响风险所产生的后果，即风险的本质、范围和时间。

          • 本质

            • 风险的本质是指当风险发生时可能带来的问题。
            • 例如，一个定义很差的与客户硬件的外部接口（技术风险）会妨碍早期的设计和测试，也有可能导致项目后期阶段的系统集成问题。

          • 范围

            • 风险的范围包括风险的严重性（即风险有多严重）及风险的整体分布情况（即项目中有多少部分受到影响或有多少客户受到损害）。

          • 时间

            • 风险的时间是指何时能够感受到风险的影响及风险的影响会持续多长时间。在大多数情况下，项目管理者希望“坏消总”越早出现越好，但在某些情况下则是越迟越好。

        • 整体的风险显露度(Risk Exposure.,RE)可由下面的关系确定：

          • RE=P*C
          • 其中，P是风险发生的概率，C是风险发生时带来的项目成本。

    • 3.风险评估

      • 概念

        • 在进行风险评估时，建立了如下形式的三元组：

          • (ri,li,xi)

        • 其中，ri表示风险，li表示风险发生的概率，xi表示风险产生的影响。

      • 一种对风险评估很有用的技术就是定义风险参照水准。对于大多数软件项目来说，成本、进度和性能就是3种典型的风险参照水准。也就是说，对于成本超支、进度延期、性能降低（或它们的某种组合），有一个表明导致项目终止的水准。

      • 步骤

        • (1)定义项目的风险参考水平值。
        • (2)建立每一组(ri,li,xi)与每一个参考水平值之间的关系。
        • (3)预测一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域所界定。
        • (4)顶测什么样的风险组合会影响参考水平值。

    • 4.风险控制

      • 风险控制的目的是辅助项目组建立处理风险的策略。一个有效的策略必须考虑以下3个问题。

        • 1)风险避免

          • 应对风险的最好办法是主动地避免风险，即在风险发生前分析引起风险的原因，然后采取措施，以避免风险的发生。

          • 例如项目风险片：表示“频繁的人员流动”，根据历史经验可知，该风险发生的概率：大约为70%，该风险产生的影响x是第2级（严重的）。为了避免该风险，可以采取以下策略。

            • (1)与现有人员一起探讨人员流动原因(如恶劣的工作条件、低报酬、竞争激烈的劳动力市场等)。
            • (2)在项目开始之前采取行动，设法缓解那些能多控制的起因。
            • (3)项目启动之后，假设会发生人员流动，当有人员离开时，找到能够保证工作连续性的方法。
            • (4)组织项目团队，使得每一个开发活动的信息都能被广泛传播和交流。
            • (5)制定工作产品标准，并建立相应机制以确保能够及时创建所有的模型和文档。
            • (6)同等对待所有工作的评审。
            • (7)给每一个关键的技术人员都指定一个后备人员。

        • 2)风险监控

          • 项目管理者应监控某些因素，这些因素可以提供风险是否正在变高或变低的指示。在频繁的人员流动的例子中，应该监测团队成员对项目压力的普遍态度、团队的凝聚力、团队成员彼此之间的关系、与报酬和利益相关的潜在问题、在公司内及公司外工作的可能性。

        • 3)RMMM计划(风险缓解、监控和管理计划)
          （Risk mitigation, monitoring and management，即RMMM）

          • 风险管理策略可以包含在软件项目计划中，或者风险管理步骤也可以组织成一个独立的风险缓解、监控和管理计划(RMMM计划)。RMMM计划将所有风险分析工作文档化，并由项目管理者作为整个项目计划中的一部分来使用。

          • 建立了RMMM计划，而且项目已经启动之后，风险缓解及监测步骤也就开始了。风险缓解是一种问题规避活动，而风险监测是一种项目跟踪活动.

          • 这种监测活动有3个主要目的：

            • 评估所顶测的风险是否真的发生了
            • 保证正确地实施了各风险的缓解步骤
            • 收集能够用于今后风险缝隙的信息

          • 在很多情况下，项目中发生的问题可以追溯到不止一个风险，所以风险监测的另一个任务就是试图找到“起源”（在整个项目中是哪些风险引起了哪些问题）。

• 软件质量

  • 概念

    • 软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指对软件开发过程进行独立的检查活动，由质量保证、质量规划和质量控制3个主要活动构成。软件质量保证是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的软件。

  • 软件质量特性

    • ISO/IEC 9126软件质量模型

      • ISO/IEC 9126软件质量模型由3个层次组成：第一层是质量特性，第二层是质量子特性，第三层是度量指标。

        • (1)功能性(Functionality)

          • 与一组功能及其指定的性质的存在有关的一组属性，功能是指满足规定或隐含需求的那些功能。

            • 适应性(Suitability)

              • 与对规定任务能否提供一组功能以及这组功能是否适合有关的软件属性。

            • 准确性(Accurateness)

              • 与能够得到正确或相符的结果或效果有关的软件属性。

            • 互用性(nteroperability)

              • 与其他指定系统进行交互操作的能力相关的软件属性。

            • 依从性(Compliance)

              • 使软件服从有关的标准、约定、法规及类似规定的软件属性。

            • 安全性(Security)

              • 与避免对程序及数据的非授权故意或意外访问的能力有关的软件属性。

        • (2)可靠性(Reliability)

          • 与在规定的一段时间内和规定的条件下软件维持在其性能水平有关的能力。

            • 成熟性(Maturity)

              • 与由软件故障引起失效的频度有关的软件属性。

            • 容错性(Fault tolerance)

              • 与在软件错误或违反指定接口的情况下维持指定的性能水平的能力有关的软件属性。

            • 易恢复性(Recoverability)

              • 与在故障发生后，重新建立其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需的时间和努力有关的软件属性。

        • (3)易使用性(Usability)

          • 与为使用所需的努力和由一组规定或隐含的用户对这样使用所做的个别评价有关的一组属性。

            • 易理解性(Understandability)

              • 与用户为理解逻辑概念及其应用所付出的劳动有关的软件属性。

            • 易学性(Learnability)

              • 与用户为学习其应用(例如操作控制、输入、输出)所付出的努力相关的软件属性。

            • 易操作性(Operability)

              • 与用户为进行操作和操作控制所付出的努力有关的软件属性。

        • (4)效率(Efficiency)

          • 在规定条件下，与软件的性能水平与所用资源量之间的关系有关的软件属性。

            • 时间特性(Time behavior)

              • 与响应和处理时间以及软件执行其功能时的吞吐量有关的软件属性。

            • 资源特性(Resource behavior)

              • 与软件执行其功能时，所使用的资源量以及使用资源的持续时间有关的软件属性。

        • (5)可维护性(Maintainability)

          • 与进行规定的修改所需要的努力有关的一组属性。

            • 易分析性(Analyzability)

              • 与为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的软件属性。

            • 易改变性(Changeability)

              • 与进行修改、排错或适应环境变换所需努力有关的软件属性。

            • 稳定性(Stability)

              • 与修改造成未预料效果的风险有关的软件属性。

            • 易测试性(Testability)

              • 为确认经修改软件所需努力有关的软件属性。

        • (6)可移植性(Portability)

          • 与软件可从某一环境转移到另一环境的能力有关的一组属性。

            • 适应性(Adaptability)

              • 与软件转移到不同环境时的处理或手段有关的软件属性。

            • 易安装性(nstallability)

              • 与在指定环境下安装软件所需努力有关的软件属性。

            • 一致性(Conformance)

              • 使软件服从与可移植性有关的标准或约定的软件属性。

            • 易替换性(Replaceability)

              • 与一软件在该软件环境中用来替代指定的其他软件的可能和努力有关的软件属性。

    • Mc Call软件质量模型

      • Me Call软件质量模型从软件产品的运行、修正和转移3个方面确定了11个质量特性(如图5-16所示)。McCall也给出了一个三层模型框架，第一层是质量特性，第二层是评价准则，第三层是度量指标。

  • 软件质量评审

    • 通常，把“质量”理解为“用户满意程度”。为了使得用户满意，有以下两个必要条件。

      • 设计质量

        • (1)设计的规格说明书符合用户的要求

      • 程序质量

        • (2)程序按照设计规格说明所规定的情况正确执行

    • 软件的规格说明

      • 外部规格说明

        • 外部规格说明是从用户角度来看的规格，包括硬件软件系统设计、功能设计；

          • 设计质量说明

      • 内部规格说明

        • 内部规格说明是从开发者角度来看的规格说明，为了实现外部规格的更详细的规格，即软件模块结构与模块处理过程的设计。

          • 程序质量说明

    • 1)设计质量的评审内容

      • 设计质量评审的对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明，以及在软件概要设计阶段产生的软件概要设计说明书等。通常从以下几个方面进行评审。

        • (1)评价软件的规格说明是否合乎用户的要求

          • 即总体设计思想和设计方针是否明确：需求规格说明是否得到了用户或单位上级机关的批准：需求规格说明与软件的概要设计规格说明是否一致等。

        • (2)评审可靠性

          • 即是否能避免输入异常（错误或超载等）、硬件失效及软件失效所产生的失效，一旦发生应能及时采取代替手段或恢复手段。

        • (3)评审保密措施实现情况

          • 即是否对系统使用资格进行检查：是否对特定数据、特定功能的使用资格进行检查：在检查出有违反使用资格的情况后，能否向系统管理人员报告有关信息；是否提供对系统内重要数据加密的功能等。

        • (4)评审操作特性实施情况

          • 即操作命令和操作信息的恰当性；输入数据与输入控制语句的恰当性：输出数据的恰当性：应答时间的恰当性等。

        • (5)评审性能实现情况

          • 即是否达到所规定性能的目标值。

        • (6)评审软件是否具有可修改性、可扩充性、可互换性和可移植性。

        • (7)评审软件是否具有可测试性。

        • (8)评审软件是否具有复用性。

    • 2)程序质量的评审内容

      • 程序质量评审通常是从开发者的角度进行评审，与开发技术直接相关。它是着眼于软件本身的结构、与运行环境的接口以及变更带来的影响而进行的评审活动。

        • (1)功能结构

          • 在软件的各种结构中，功能结构是用户唯一能见到的结构。因此，功能结构是联系用户与开发者的规格说明，它在软件的设计中占有极其重要的地位。在评审软件的功能结构时，必须明确软件的数据结构。需要检查的项目如下。

            • 数据结构

              • 包括数据名和定义：
              • 构成该数据的数据项；
              • 数据与数据之间的关系。

            • 功能结构

              • 包括功能名和定义：
              • 构成该功能的子功能；
              • 功能与子功能之间的关系。

            • 数据结构和功能结构之间的对应关系

              • 包括数据元素与功能元素之间的对应关系；
              • 数据结构与功能结构的一致性。

        • (2)功能的通用性

          • 在软件的功能结构中，某些功能有时可以作为通用功能反复出现多次。从功能便于理解、增强软件的通用性及降低开发的工作量等观点出发，希望尽可能多地使功能通用化。另外，需检查的项日包括抽象数据结构(抽象数据的名称和定义、抽象数据组成元素的定义)、抽象功能结构。

        • (3)模块的层次

          • 模块的层次是指程序模块结构。由于模块是功能的具体体现，所以模块层次应当根据功能层次来设计。

        • (4)模块结构

          • 上述的模块层次结构是模块的静态结构，现在要检查模块的动态结构。模块分为处理模块和数据模块两类，模块间的动态结构也与这些模块分类有关。对这样的模坎结构进行检查的项目如下。

            • 控制流结构

              • 规定了处理模块与处理模块之间的流程关系，检查处理模块之间的控制转移关系与控制转移形式（调用方式）。

            • 数据流结构

              • 处理模块与数据模块之间的存取关系。
              • 模块结构与功能结构之间的对应关系
              • 包括功能结构与控制流结构的对应关系

            • 功能结构与数据流结构的对应关系

              • 每个模块的定义(功能、输入/输出数据)。

        • (5)处理过程的结构

          • 处理过程是最基木的加工逻辑过程。

            • 对它的检查项目有模块的功能结构与实现这些功能的处理过程的结构应明确对应
            • 控制流应是结构化的
            • 数据的结构与控制流之间的对应关系应是明确的，并且可根据这种对应关系来明确数据流程的关系
            • 用于描述的术语标准化

    • 3)与运行环境的接口

      • 运行环境包括硬件、其他软件和用户，主要的检查项目如下。

        • (1)与硬件的接口

          • 包括与硬件的接口约定，即根据硬件的使用说明等所做出的规定：硬件故障时的处理和超载时的处理。

        • (2)与用户的接口

          • 包括与用户的接口约定，即输入数据的结构：输出数据的结构：异常输入时的处理，超载输入时的处理；用户存取资格的检查等。

  • 软件容错技术

    提高软件质量和可靠性的技术大致可分为两类，一类是避开错误，即在开发的过程中不让差错潜入软件的技术：另一类是容错技术，即对某些无法避开的差错，使其影响减至最小的技术。

    • 1)容错软件的定义

      • 在一定程度上对自身错误的作用（软件错误）具有屏枝能力，则称该软件为具有容错功能的软件，即容错软件。
      • 在一定程度上能从错误状态自动恢复到正常状态，则称该软件为容错软件。
      • 在因错误发生错误时仍然能在一定程度上完成预期的功能，则称该软件为容错软件。
      • 在一定程度上具有容错能力，则称该软件为容错软件。

    • 2)容错的一般方法

      实现容错的主要手段是冗余。
      冗余是指对于实现系统规定功能是多余的那部分资源，包括硬件、软件、信息和时间。由于加入了这些资源，有可能使系统的可靠性得到较大的提高。通常，冗余技术分为4类。

      • (1)结构冗余

        结构冗余是通常采用的冗余技术，按其工作方法可以分为静态、动态和混合冗余3种。

        • ①静态冗余

          • 常用的有三模冗余(Triple Module Redundancy,TMR)和多模冗余。
          • 静态冗余通过表决和比较来屏蔽系统中出现的错误。如三模冗余是对3个功能相同但由不同的人采用不同的方法开发出来的模块的运行结果通过表决，以多数结果作为系统的最终结果。即如果模块中有一个出错，这个错误能够被其他模块的正确结果“屏蔽”。由于无须对错误进行特别的测试，也不必进行模块的切换就能实现容错，故称之为静态容错。

        • ②动态冗余。

          • 动态冗余的主要方式是多重模块待机储备。当系统测试到某工作模块出现错误时，就用一个备用模块来顶替它并重新运行。这里包括检测、切换和恢复过程，故称其为动态冗余。每当一个出错模块被其他备用模块顶替后，冗余系统相当于进行了一次重构。各备用模块在其待机时可与主模块一同工作，也可不工作。前者称为热备份系统，后者称为冷备份系统。在热备份系统中，备用模块在待机过程中的失效率为0。

        • ③混合冗余

          • 它兼有静态冗余和动态冗余的长处。

      • (2)信息冗余

        • 为检测或纠正信息在运算或传输中的错误需外加一部分信息，这种现象称为信息冗余。在通信和计算机系统中，信息常以编码的形式出现。采用奇偶码、循环码等冗余码制式就可以发现甚至纠正这些错误。为了达到此目的，这些码（统称为误差校验码）的码长远远大于不考虑误差校正时的码长，增加了计算量和信道占用的时间。

      • (3)时间冗余

        • 时间冗余是指以重复执行指令或程序来消除瞬时错误带来的影响。对于重复执行不成功的情况，通常的处理办法是发出中断，转入错误处理程序，或对程序进行复算，或重新组合系统，或放弃程序处理。在程序复算中比较常用的方法是程序滚回（Program Rollback)技术。

      • (4)冗余附加技术

        冗余附加技术是指为实现上述冗余技术所需的资源和技术，包括程序、指令、数据、存放和调动它们的空间和通道等。

        • 在屏蔽软件错误的容错系统中，冗余附加技术的构成包括：

          • ①冗余备份程序的存储及调用。
          • ②实现错误检测和错误恢复的程序。
          • ③实现容错软件所需的固化程序。

        • 在屏蔽硬件错误的容错技术中，冗余附加技术包括：

          • ①关键程序和数据的冗余存储及调用。
          • ②检测、表决、切换、重构、纠错和复算的实现。

• 软件工具

  用来辅助软件开发、运行、维护、管理和支持等过程中的活动的软件称为软件工具。

  早期的软件工具主要用来辅助程序员编程，如编辑程序、编译程序和排错程序等。

  在提出了软件工程的概念以后，又出现了软件生存周期的概念，出现了许多开发模型和开发方法，并且软件管理也开始受到人们的重视。

  与此同时，出现了一批软件工具来辅助软件工程的实施，这些软件工具涉及软件开发、维护、管理过程中的各项活动，并辅助这些活动高效、高质量地进行。

  • 1.软件开发工具

    • (1)需求分析工具

      • 用于辅助软件需求分析活动的软件称为需求分析工具，它辅助系统分析员从需求定义出发，生成完整的、清晰的、一致的功能规范(Functional Specification)。功能规范是软件所要完成功能的准确而完整的陈述，它描述该软件要做什么以及只做什么。
      • 按照需求定义的方法可将需求分析工具分为基于自然语言或图形描述的工具和基于形式化需求定义语言的工具。

    • (2)设计工具

      • 用于铺助软件设计活动的软件称为设计工具，它辅助设计人员从软件功能规范出发，得到相应的设计规范(Design Specification)。对应于概要设计活动和详细设计活动，设计工具通常可分为概要设计工具和详细设计工具。
      • 概要设计工具用于辅助设计人员设计目标软件的体系结构、控制结构和数据结构，详细设计工具用于辅助设计人员设计模块的算法和内部实现细节。除此之外，还有基于形式化描述的设计工具和面向对象的分析与设计工具。

    • (3)编码与排错工具

      • 编码工具辅助程序员用某种程序设计语言编写源程序，并对源程序进行翻译，最终转换成可执行的代码。因此，编码工具通常与编码所使用的程序语言密切相关。
      • 排错工具用来辅助程序员寻找源程序中错误的性质和原因，并确定其出错的位置。

    • (4)测试工具

      • 用于支持软件测试的工具称为测试工具，它分为数据获取工具、静态分析工具、动态分析工具、模拟工具以及测试管理工具。

        • 静态分析工具通过对源程序的程序结构、数据流和控制流进行分析，得出程序中函数（过程）的调用与被调用关系、分支和路径、变量定义和引用等情况，发现语义错误。
        • 动态分析工具通过执行程序检查语句、分支和路径覆盖，测试有关变量值的断点，即对程序的执行流进行探测。

  • 2.软件维护工具

    • (1)版本控制工具

      • 在软件开发和维护过程中，一个软件往往有多个版本，版本控制工具用来存储、更新、恢复和管理一个软件的多个版本。

    • (2)文档分析工具

      • 文档分析工具用来对软件开发过程中形成的文档进行分析，给出软件维护活动所需的维护信息。例如，基于数据流图的需求文档分析工具可以给出对数据流图的某个成分（如加工）进行维护时的影响范围及被影响范围，以便在修改该成分的同时考虑其影响范围内的其他成分是否也要修改。除此之外，利用文档分析工具还可以得到被分析文档的有关信息，例如文档各种成分的个数、定义及引用情况等。

    • (3)开发信息库工具

      • 开发信息库工具用来维护软件项目的开发信息，包括对象、模块等。它记录每个对象的修改信息（己确定的错误及重要改动）和其他变形（如抽象数据结构的多种实现），还必须维护对象和与之有关信息之间的关系。

    • (4)逆向工程工具

      • 逆向工程工具辅助软件人员将某种形式表示的软件（源程序）转换成更高抽象形式表示的软件。这种工具力求恢复源程序的设计信息，使软件变得更容易理解。逆向工程工具分为静态的和动态的两种。

    • (5)再工程工具

      • 再工程工具用来支持軍构一个功能和性能更为完善的软件系统。目前的再工程工具主要集中在代码重构、程序结构重构和数据结构重构等方面。

  • 3.软件管理和软件支持工具

    • (1)项目管理工具

      • 项目管理工具用来捕助软件的项目管理活动。通常，项目管理活动包括项目的计划、调度、通信、成本估算、资源分配及质量控制等。一个项目管理工具通常把重点放在某一个或某几个特定的管理环节上，而不提供对管理活动包罗万象的支特。

    • (2)配置管理工具

      • 配置管理工具用来辅助完成软件配置项的标识、版本控制、变化控制、审计和状态统计等基本任务，使得各配置项的存取、修改和系统生成易于实现，从而简化审计过程，改进状态统计，减少错误，提高系统的质量。

    • (3)软件评价工具

      • 软件评价工具用来辅助管理人员进行软件质量保证的有关活动。它通常可以按照某个软件质量模型(如McCl软件质量模型、ISO软件质量度量模型等)对被评价的软件进行度量，然后得到相关的软件评价报告。软件评价工具有助于软件质量控制，对确保软件质量有重要的作用。