【教学课件】第十章传统的软件开发方法.ppt

《【教学课件】第十章传统的软件开发方法.ppt》由会员分享，可在线阅读，更多相关《【教学课件】第十章传统的软件开发方法.ppt（112页珍藏版）》请在三一办公上搜索。

1、第 1 页,第十章 传统的软件开发方法,10.1 结构化开发方法概述10.2 系统分析与定义10.3 系统设计10.4 系统编程10.5 系统测试10.6 系统维护,第 2 页,10.1 结构化开发方法,基本思想：把一个复杂问题的求解过程分阶段进行，每个阶段处理的问题都控制在人们容易理解和处理的范围内。基本要点：自顶向下逐步求精模块化设计结构化编码主程序员组织结构化设计SD,第 3 页,“自顶向下”,是将复杂的大问题，分解为小问题，找出问题的关键、重点所在，同时找出技术难点来。然后用精确的思维定性、定量地描述问题。,第 4 页,“逐步求精”,将现实世界的问题经抽象转化为逻辑空间或求解空间的问题

2、。复杂问题经抽象化处理变为相对较简单的问题。经几次抽象（精化）处理，最后到求解域中只是非常简单的编程问题。求解（抽象）过程可以划分为若干个阶段，在不同阶段用不同工具来描述。实现细则在前期阶段可以不去管它。在每个阶段有不同的规划和标准，产生出不同阶段的文档资料。求解问题不是一下子就用计算机语言却描述问题，而是分阶段；先用自然语言、DFD（数据流程图）等工具一步步地去抽象、描述，最后用计算机语言却实现。,第 5 页,模块化处理,把程序划分为若干个模块，而每个模块完成一个子功能，把这些模块汇总起来构成一个有机整体，完成指定的功能。模块化的目的是为了降低软件复杂度，使软件设计，调试和维护等操作变得简易

3、。,第 6 页,结构化编码,SP编码的方法强调清晰简洁，它是一种构造程序的技术，有利于提高软件生产率及降低软件维护代价。1966年Bohm和Jacopin就证明了只要用三中基本结构，就足以表示所有形式的程序控制结构。1978年Kernihan和Plauger对一些编码风格进行归纳，提出了16种具体方法。,第 7 页,主程序员组织,主程序员 组织负责人,全权负责,包括解决技术难题,有时一些关键性技术问题,主程序员应亲自动手遍程去解决；他必须是技术高手，是程序生产过程中的总体设计师。程序员 按任务书要求编程；是程序生产线上的“工人”。测试工程师 具有较高遍程水准和经验，负责系统测试；是程序生产过程

4、中的检验员。文档人员 自始至终参加程序生产活动，负责编写一切有关文档资料。,第 8 页,结构化方法的体系结构,结构化方法的体系结构是:结构化分析（SAStructure Analysis）结构化设计（SDStructure Design）结构化程序设计（SPStructure Programing）,第 9 页,结构化分析SA,SA方法是建立在自顶向下、逐步求精思想基础上的分析方法，它的要点是分解和抽象：把复杂问题自顶向下逐层分解，再从分解出的对象中抽象出相对简单的子问题。经过一系列分解和抽象，到最底层的问题已经是很容易求解的了。,第 10 页,结构化设计SD,SD方法是由IBM公司的Cons

5、tentine等人花了十几年时间研究出来的一种程序设计方法，发表于1974年。SD是一种用于概要设计的方法，与SA方法配合使用。其目标：建立一个结构良好的软件系统。SD方法的基础是数据流程图，因此也称为面向数据流的设计方法。,第 11 页,结构化程序设计SP,SP的思想最早是由著名计算机科学家E.W.Dijkstra提出的。1966年Bohm和Jacopin证明了只用三种基本结构就能实现任何一个入口，一个出口的程序；1977年IBM公司的Mills又进一步提出：“程序应该只有一个入口和一个出口。在长期程序设计的实践中，SP方法不断得以完善，使之成为开发传统应用领域应用系统的主要方法之一。,第

6、12 页,10.2 软件需求定义,软件需求分析 就是明确软件系统将来达到的目标。目标 规定项目必须满足的总目标；确定项目的可行性；拟定完成项目各个目标的策略，制定项目资源成本和进度。,第 13 页,1、软件需求定义的任务,理解和表达用户要求，制定软件开发计划，编写要求说明书。收集、理解、明确用户的要求，明确系统做什么？建立系统的逻辑模型，写出开发计划和需求分析报告。,第 14 页,软件需求定义的工作流程,系统定义,用户要求,软件功能,范围,功能说明书,软件计划,软件定义,软件功能,费用、资源进度,第 15 页,2、需求分析过程,基本过程示意图沿数据流回溯用户复查细化数据流图修改开发计划书写文档

7、资料审查和复审,第 16 页,需求分析的基本过程,用户,分析员,程序员,软件开发计划,软件需求说明书,分析追踪数据流图,用户复查,细化数据流图,无补充修改,需要分解,不要分解,有补充修改,交换意见作出贡献,第 17 页,沿数据流回溯,通常从数据流图的输出端着手分析，要搞清楚：数据元素从哪儿来？每个输出数据元素又是从哪儿来的？有时对用户具体的数据元素还搞不清楚，则需要和用户探讨、商量解决。通常把分析过程中得到的有关部门数据元素信息记录到数据字典DD中。把对算法的简明描述记录在IPO（输入|处理|输出图）图中。通过分析而补充的数据流、数据存储和处理，应该添加到DFD的适当位置上。,第 18 页,用

8、户复查,经分析将在数据流图回溯过程中找出的数据元素，并由此定义的DD和算法是否正确？这只能由最有发言权的用户来复查。在复查过程中反映出新的问题，应及时修改、补充DFD、DD和IPO图，并将对系统的新认识及时记录下来。实际上，追踪DFD和复查系统的逻辑模型这两个步骤是交替进行的循环过程。,第 19 页,细化数据流图,在反复循环的分析过程中，不断细化DFD（即把数据流图扩展到更低的层次）。通过功能分解可以完成DFD的细化，即将一些处理比较复杂的功能再划分为若干个子功能。,第 20 页,修改开发计划,在分析过程中可能会不断地修改原拟定的开发计划，这是正常的。,第 21 页,书写文档资料,在软件生命周

9、期的各个阶段，作为阶段成果的组成部分文档资料，其作用如何强调都不过份。本阶段应完成4份文档资料：系统规格说明 描述目标系统的概貌、功能要求、性能、运行及将来可能提出的要求。用户系统描述 从用户角度描述系统，类似一份用户手册初稿。数据要求 包括DD、数据结构的层次框图等。修改的开发计划 包括成本估计、进度计划表、资源使用计划等。,第 22 页,说明,需求说明书主要内容：概述 开发系统的意义、目的、背景及技术术语；现性系统的概况 业务流程、范围、存在的问题等；需求说明 功能描述信息描述：DFD、DD、DS、IPO、接口等性能描述运行环境系统限制用户系统描述系统功能和性能的描述使用系统的主要步骤和方

10、法系统用户的责任等,第 23 页,审查和复审,分析阶段最后一步是按结束标准对该阶段的工作成果进行正式的技术审查和管理审查。,第 24 页,3、需求分析的原则,1能够表达和理解问题的信息域 2要建立描述系统信息、功能和行为的模型3能够对所建模型按一定形式进行分解 4分清系统的逻辑视图和物理视图,第 25 页,4、需求分析的图形工具,常用的描述工具数据流程图（DFD）数据字典（DD）结构化语言判定表和判定树,第 26 页,数据流图DFD,数据流图以图形的方式表达数据处理系统中信息的变换和传递过程。它有四种基本符号：,S,P,X,数据源及数据终点,加工 对数据进行的加工或变换，指向加工的数据流是输入

11、数据；离开的是输出数据。,数据流 具有名字且有流向的数据,文件 存放数据的场所,第 27 页,数据流图的结构,一个实际问题的数据加工流程是非常复杂的。如果绘制在一个平面图上就显的太乱了。因此，通常采用分层次结构。把一个复杂的问题，分解为一些相互独立的子问题，再绘出分层DFD。,第 28 页,数据字典DD（Data Directory）,DD对数据流程图中出现的所有元素给出逻辑定义。内容 1)数据流：编号、名称、简述、别名、构成、来源、去向、流量 2)数据项目：编号、名称、简述、别名、类型、长度、位数 3)数据文件：编号、名称、简述、别名、构成、关键字、存取要求 4)处理 编号、名称、简述、别名

12、、处理条件、I/O内容、处理逻辑,第 29 页,结构化语言,例如:DO CASE CASE 时间12 AND 时间18 R-rent=rent;,第 30 页,判定表,判定表把加工逻辑表示的更加清楚。表中纵向各列给出的不同的条件，横向各行则表示在任何条件下相应的处理。,条件 结 帐 时 间 12点前 1218点 18点后,处理,不收费,收半费,收全费,第 31 页,判定树,判定树用来描述具有多个条件的数据加工更容易被用户接受。树状的分枝表示多种不同的条件。,结帐时间=？,12点前 1218点间 18点后,不收费 收半费 收全费,下一页,第 32 页,5、用于需求分析的软件工具,为保证软件需求的

13、正确性和需求的一致性，需要采用适当的软件工具支持需求分析工作。软件工具应满足下列要求：必须有形式化的语法（可让计算机自动处理）能够导出详细的文档必须提供分析（测试）规格说明书的不一致性和冗余性的手段，并能产生指明对完整性分析结果的报告。能够改进通信状况,第 33 页,6、结构分析方法(SA方法),结构化分析方法的背景(形成)早期无系统分析方法(凭经验)60年代美国的科学家提出一种理论:SP SD SA目前研究的新热点是:OOP OOD OOA 即面向对象的程序设计技术(OO-Object Oriented),第 34 页,SA的一般步骤,1建立当前系统的物理模型2建立当前系统的逻辑模型 3、建

14、立目标系统的逻辑模型,第 35 页,三、系统设计（软件的设计）,系统设计概述目标和任务设计方法和步骤文档设计复审,第 36 页,软件设计流程图,概要设计,复审,要求说明书,软件结构,可接收,详细设计,模块描述,设计说明书,复审,修改,修改,第 37 页,1、软件设计概述,目标和任务任务 依据分析结果，明确系统“如何做？”，建立实现方案。目标 提高软件系统的：可维护性 可扩充、可修改可理解性 对软件人员要易读易理解；对用户要易使用、易维护可靠性 包括正确性和健壮性,第 38 页,2、设计方法和步骤,概要设计 定义系统的逻辑结构，包括：系统的模块划分、建立模块的层次结构、逻辑关系、设计全局DS及D

15、B；详细设计 根据每个模块的功能描述，设计模块内部的实现算法、模块所需要的局部数据结构。,第 39 页,设计方法和步骤设计方法：,概要设计方法 早期：模块化方法、功能分解法；典型：面向数据流、面向数据结构（SP）的 设计方法 近期：面向对象（OO）的设计方法详细设计方法 主要是结构化程序设计方法详细设计的表示工具图形工具和语言工具；图形工具 程序流程图、程序分析图（PAD）和NS图语言工具 伪吗和程序设计语言（PDL）,第 40 页,文档资料,设计阶段要交付的文档是设计说明书。它可对编程和测试提供指南服务，还可在系统交付使用后，为维护人员提供帮助。,第 41 页,3、软件设计原则,要有分层的组

16、织结构，便于对软件各个构件进行控制；应形成具有独立功能特征的模块（模块化）应有性质不同、可区分的数据和过程描述（表达式）应使模块间和与外部环境间接口的复杂性尽量地减小应利用软件需求分析中得到的信息和可重复的方法。,第 42 页,4、软件设计准则,软件结构准则模块化准则模块独立性准则模块的耦合性模块的内聚性,第 43 页,软件结构准则,结构形态准则 即顶部宽度最小，中间宽度最大，底部宽度小于中间的宽度。换句话说，在顶部有较高的扇出数（一个模块直接下属的子模块数），在底部有较高的扇入数（模块的直接上属模块的个数）。判断的影响范围应该是控制范围的一个子集 影响范围 指在一个模块中有一个判别条件，所有

17、受该判别条件影响的模块的集合称为影响范围；控制范围 指一个模块本身及所有下属模块构成的集合。,第 44 页,结构形态准则示意图,深度,宽度,扇出,扇入,第 45 页,模块化准则,软件分解为若个模块后,总的工作量减少，但并不是说，模块分解的越多，工作量就一定越少。因为分解到一定程度后，模块之间的接口工作量就上升，从而使总的代价上升。,第 46 页,5、模块独立性准则,模块独立性是指开发具有功能专一、模块之间无过多相互作用的模块。具有独立性的模块，开发容易、能减少错误的传播，使模块重组、分解方便，容易调试和维护。度量模块的独立性标准：内聚性 模块内部各部分之间联系紧密程度的度量；藕合性 模块之间联

18、系紧密程度的度量。显然，独立性强的模块，藕合性越小越好，内聚性越大越好。,第 47 页,关于藕合的讨论,设计时应：尽量使用数据藕合，少用控制藕合，限制公用藕合的范围，完全不用内容藕合。,第 48 页,内聚性问题,一个程序主要由两部分组成：数据和对数据的加工处理。内聚性是指一个模块内部各种数据和各种处理之间联系的紧密程度。它是模块执行任务的整体统一性的度量，是模块相对功能强弱的度量。在理想的系统中，每个模块执行一个明确、单一的任务。但现实情况是一个模块往往执行若干个结合在一起的任务，这些任务组合方式不同就构成不同的内聚性。,第 49 页,内聚性问题的讨论,从使用角度分析，能否用一个短句完整地描述

19、该模块做什么；若这个短句是复合句，或有若干个动词，则该模块是非功能性模块。在设计时，尽量采用功能性模块。,第 50 页,6、概要设计,概要设计是为软件系统定义一个逻辑上一致的结构：进行模块划分，建立模块层次结构、调用关系，设计全局数据结构及数据库，设计系统接口及人机界面等。概要设计的方法有许多种：在早期有模块化方法、功能分解方法，这都是人们一般常用的方法；在60年代后期提出了面向数据流的设计方法、面向数据结构的设计方法；近年来又提出面向对象的设计方法等。,第 51 页,概要设计主要步骤,1）精细化数据流程图，确定数据流程图的类型；2）指出各种信息流的流界；3）将数据流程图映射为软件结构；4）精

20、细化软件结构；5）开发接口描述和全程数据描述。,第 52 页,数据流程图分类,变换流,加工中心,输入加工,输出加工,输入,输出,内部结果,内部数据,输入流,输出流,变换流,加工结果,第 53 页,事物流,事物中心 T,数据流,事物中心,t1,t2,t3,t4,事物路径,事物流,一个数据流经过某个加工后，有若干个平行的数据流流出，将这种变换称为事物流。,当事物流中的事物流到事物中心后，事物中心分析每个事物，确定其类型；并根据事物类型选择一个事物路径继续进行处理。,第 54 页,变换分析技术,变换分析技术是从典型的变换型数据流程图（DFD）中推导出相应的结构图。变换分析是一组设计步骤，可把DFD映

21、射为一种标准结构。有了标准结构，再根据软件结构度量、模块化度量、模块独立性度量来精细改善结构图，从而得到良好的软件结构。,第 55 页,变换分析的步骤,确定DFD及其类型确定输入流、中心加工、输出流的流界；第一级分解；设计上层模块；第二级分解，设计中、下层模块；进一步精细化。,第 56 页,事务分析技术,事务分析技术也是将相应的数据流程图（DFD）映射为对应的的软件结构图。事务分析的组设计步骤同变换分析：确定数据流图的类型确定流界第1级分解第2级分解设计后处理,第 57 页,7、详细设计方法,详细设计是根据每个模块的功能设计其逻辑描述、实现其法以及实现这些算法的逻辑控制流程，并设计这些模块所需

22、的局部数据结构。详细设计的方法主要是用结构程序设计SP方法，详细设计的表示工具有图形工具和语言工具。图形工具有程序流程图、PAD图、NS图，语言工具有伪码和 PDL等。,第 58 页,SP中的基本结构,顺序结构选择结构IF THEN ELSE 结构IF THEN 结构IF OR IF ELSE 结构CASE 结构重复结构当型结构直到型结构出口结构,第 59 页,SP中的优点,自顶向下，逐步求精方法符合人们解决复杂问题的普遍规律。用先全局后局部，先整体后细节，先抽象后具体的逐步求精过程开发的程序有清晰的层次结构，容易理解和阅读。不使用GOTO语句，使程序静态结构和程序动态执行情况一致，容易理解和

23、阅读，开发出的程序容易修改和维护。程序只采用三种基本结构，有确定的逻辑结构，可读性好。共用模块可重用。,第 60 页,SP中的缺点,SP方法是面向过程的设计方法，对于非数值应用问题，明显地“力不从心”。SP方法对大问题的描述有很大的局限性。SP方法的模块化设计的子程序、函数的可重用性很小。数据和过程的分离。程序员在编程时必须随时考虑要处理的数据的格式,第 61 页,四、程序编码,程序设计语言的特点选择语言写程序的风格程序设计方法论,第 62 页,程序设计语言的特点,软件工程师应该了解程序设计语言各方面的特点，以及这些特点对软件质量的影响，以便在一个特定的开发项目选择语言时，能够作出合理的选择。

24、程序设计语言的特点是：名字说明类型说明初始化程序对象的局部性程序模块循环控制结构分支控制结构异常处理独立编译,第 63 页,选择语言,根据实际情况选择使用的程序设计语言。程序设计语言分“汇编语言”和“高级语言”；汇编语言的程序执行效率高，但生产效率低；高级语言的程序执行效率不如汇编语言，但编程效率则要高得多，同时还有可读性、可维护性好等优点。选择语言时，不仅要考虑理论上的标准，还必须同时考虑使用方面的各种限制。,第 64 页,写程序的风格,指程序员在编程时所表现出来的特点、逻辑思路、结构等。可以体现在下列各个方面：源代码文件（程序内部的文档）数据说明语句构造输入|输出提高程序质量的技巧效率,第

25、 65 页,源代码文件（程序内部的文档）,包括程序中使用的标识符，适当的注释以及程序的视觉组织。标识符 命名要有一定的规则；用拼音或英文字符。注释行 通常在源程序中用大量篇幅（最多占到1/3）加入注释行，在开发者和读者间进行钩通，说明程序的功能、标识符的含义、主要算法等。特别在维护阶段，对理解程序提供了指导。程序书写格式 各控制结构的层次应呈锯齿形，同一层次对齐，下一层退缩几格。,第 66 页,数据说明,为使数据定义更容易看懂、更容易维护，要建立一些指导原则：数据说明顺序标准化，最好按照类型说明、公用变量、局部变量、文件说明的顺序；一个语句说明若干个变量时，名字最好按字典排序；对复杂的DS，要

26、加注释，说明固有特性。,第 67 页,语句构造,语句构造的原则是：简单直接 不应追求效率而使代码复杂化；为了便于阅读和理解，不要一行写多个语句，不同层次的语句应呈锯齿形；不用复杂的测试条件，不用或少用“非条件”；避免使用大量嵌套循环及条件循环；使用条件来简化表达式。,第 68 页,输入/输出,在编码时要考虑下列I/O风格的规则：对所有的输入数据进行检验检查重要的输入项组合的合法性保持输入格式的简单使用数据结束标记，不要要求用户指定数据的数目明确提示交互式输入的请求，详细说明可用的选择或边界数值；当程序设计语言对格式有严格要求时，保持输入格式一致设计良好的输出报表给所有的输出加标志,第 69 页

27、,提高程序质量的技巧,避免使用过于相似的变量名变量名中尽量不含数字同一变量名不要具有多种意义显式说明所有变量注意浮点运算的误差注意整数运算的特点避免不必要的GOTO语句尽量少用语句标号,第 70 页,效率,程序运行时间 源程序的效率由算法的效率决定，但写程序的风格也能对程序的执行速度和存储器要求产生影响，可应用下述规则：写程序前先简化算术和逻辑表达式尽量避免使用多维数组，尽量避免使用指针和复杂的表使用时间短的算术运算不要混合使用不同的数据类型尽量使用整数运算和布尔表达式,第 71 页,程序设计方法论,通常有两种方法：自顶向下和自底向上自顶向下（特点）：程序可读性好可靠性较高自底向上（特点）程序

28、往往局部是优化的，系统整体结构较差；可极早发现关键算法是否可行，可较好地避免较大的返工。,第 72 页,五、系统测试,软件测试概述测试用例的设计测试实施方法软件的调试,第 73 页,软件测试概述,目的 发现软件中隐藏的各种差错。,第 74 页,测试基本概念,测试 为了发现错误而执行程序的过程调试 找出程序中的错误原因、位置并加以纠正可靠性 在给定时间内，软件不发生错误的概率黑盒测试法 不考虑程序的内部结构和处理过程的测试，也称为功能测试。只检查程序功能是否满足系统功能和规格说明书的要求，不管内部如何处理和如何实现。白盒测试法 按程序的内部逻辑结构和处理过程进行的测试，称为结构测试。,第 75

29、页,测试用例,测试用例的组成：测试用例=指定功能+测试数据+预期效果测试的基本原则：1）在执行程序前应该对期望的结果有明确的描述，测试后应对输出进行仔细的检查。2）不仅要选择合理的输入数据作为测试用例，还应选用不合理的输入数据作为测试用例。3）除了检查程序是否做了应做的工作之外，还应检查程序是否做了不应做的事。4）应该长期保留所有的测试用例，直到该系统被废弃不用为止。,第 76 页,测试用例的设计,设计测试用例的基本目标是：确定一组最有可能发现某个错误或某类错误的测试数据。通常的做法是用黑盒法设计基本的测试用例，再用白盒法设计一些补充用例。测试方法：逻辑覆盖语句覆盖判定覆盖条件覆盖判定/条件覆

30、盖条件组合覆盖等价类划分边值分析,第 77 页,逻辑（路径）覆盖（白盒法）,按程序的内部逻辑结构进行测试，为了衡量测试的覆盖程度，建立下列标准（从低到高）：语句覆盖判定覆盖条件覆盖判定/条件覆盖条件组合覆盖,第 78 页,举例,有一要测试的程序如下：sub（a，b，）float a，b，；float y;if（a1 if(a=2|x1）；,结束,程序逻辑结构图,开始,a1&b=0？,a=2|x1?,y=x/a,x=x+1,A,B,C,D,E,第 79 页,逻辑覆盖分析语句覆盖,执行程序中的每个语句。为使程序中的每个语句都至少执行一次，只需设计一个通过路径的输入数据即可。选择输入数据为：，就可达

31、到“语句覆盖”的标准。,第 80 页,逻辑覆盖分析判定覆盖,对判别语句的每个分支至少要经过一次，为达到”判定覆盖“的标准，则要经过路径：C和B，为此，选用输入数据为：，走路径，走路径判定覆盖比语句覆盖严格。但还比较弱，例如，ABD路径就没走到。若把“X1”错写成“X1”,还是检查不出来，它只有50%的机会去检查X的值。,第 81 页,逻辑覆盖分析条件覆盖,使判别中每个条件可能的值至少出现一次，及条件表达式中各个条件取两个不同的值。程序中有4个条件:A1,B=0,A=2,X1。为达到“条件覆盖”标准，需选用数据,使得 在A点有 A1,A0 在B点有 A=2,A2,X1,X=1 为此选择下列两组测

32、试数据：，走路径，走路径,第 82 页,“条件覆盖”比“判定覆盖”强,因为要使每个条件都取到两个不同的结果,而判定覆盖不能保证这一点。有时判定覆盖和条件覆盖不能互为包含。,第 83 页,逻辑覆盖分析判别条件覆盖,使判定的”真“、”假“各执行一次，还要使判定中每个条件取两种不同的值。选择下列输入数据可满足这一标准：，走路径，走路径在含有AND和OR的逻辑表达式中,某些条件将抑制其它条件;例如,表达式 A AND B,如果A为假,则就不再检查B了。因此在实际应用中要设计更多的用例来测试未走过、而可能隐藏错误的路径。,第 84 页,逻辑覆盖分析判别组合覆盖,使每个判定中的条件的各种组合都出现一次。满

33、足条件组合覆盖的测试数据一定满足判定、条件、条件判定覆盖。各种可能的组合共有八种：，=,注：这组数据并不能覆盖程序中的每条路径，就没执行。说明条件组合覆盖标准仍不彻底。,第 85 页,下面组测试数据可以覆盖上面种条件组合：，覆盖，覆盖，覆盖，覆盖,第 86 页,等价类划分（黑盒法）,把所有可能的输入数据（有效和无效）划分为若干个等价类，每类中一个典型数据在测试中起的作用和这一类数据的作用是相同的。因此，可以从每个等价类中只选取一组数据作为测试数据。使用等价类划分法首先要划分输入数据的等价类，确定输入数据的有效等价类和无效等价类。,第 87 页,等价类划分（黑盒法）,例如，若规定输入数据为整数，

34、等价类划分表为：,输入条件有效等价类无效等价类,整数,正整数到零负整数到,符合规则,不符合规则,正整数大于零非法负整数小于,第 88 页,边界值分析法,经验证明，在边界处，程序最容易出问题。例如，在下标、数据结构、数组、循环等的边界附近。使用边值分析方法设计测试用例首先应确定边界情况，这需要经验和创造性。选取测试数据应刚好等于、刚好小于和刚好大于边界值。通常设计测试用例总是将等价法和边值法结合使用。,第 89 页,模块测试,可先用白盒法测试模块的内部逻辑，再用黑盒法测试外部预期的结果。程序交出后，由测试工程师再以黑盒法为主进行测试。测试评价模块的下述特征：模块接口局部数据结构重要的执行通路出错

35、处理通道影响上述各方面特征的边界条件,第 90 页,组装测试,组装测试分为：渐增式和非渐增式。渐增式逐渐将要测试的下一个模块加进到已测试好的模块中进行的测试。非渐增式先测试每个模块，再把所有模块按设计要求组装在一起的测试。,第 91 页,渐增方法的使用方式,(1)自顶向下从主控模块开始，沿软件控制层自上而下、逐渐把各个模块组装到已测试结构中的一种方法。优缺点：优点：不要驱动模块，能较早地实现并验证系统的主要功能，较早的发现接口错误。缺点：需要存根模块，可能遇到与此相联系的测试困难，底层关键模块中的错误发现较晚。(2)自底向上从底层模块开始测试和组装的一种策略。优缺点正好与自顶向下相反。,第 9

36、2 页,确认测试,测试的目的是验证系统是否能满足用户的需要。平行运行即手工系统和计算机系统同时运行，用对比的方法验证新系统的正确性。,第 93 页,程序调试,程序调试的任务经过测试暴露出问题，还必须进一步诊断错误的原因和位置，进而改正程序中的错误。要讨论三方面的问题：调试技术调试策略调试的启发性原则,第 94 页,调试技术,输出存储器内容 特点：效率低、难定位、输出的是静止状态的程序内容。加打印语句 特点：显示的是程序的动态信息，大量的输出，时间慢，可能引出新的问题。用调试工具 特点：动态调试，可自动执行，是现代程序调试的有效工具。,第 95 页,调试策略,试探法大概分析、估计错误的位置；回溯

37、法确定最先出现”症状“的地方，然后沿程序的控制流程往回追踪源程序，直到找出错误源为止。对分查找法若已知程序中若干个关键点的正确值，然后用调试工具在关键点附近处输入正确值；若输出正确，则故障在前半部分；否则，再查后半部分。归纳法从线索出发，通过分析线索之间的关系而找出故障。主要步骤为：收集有关数据，组织数据，导出假设，证明假设。,第 96 页,六、软件维护,软件交付使用后的变更称为维护。维护是软件生存周期最后一个阶段,由于维护工作的重要性往往被人们忽视，这更增加了维护工作的困难。学习软件工程学的主要目的之一就是研究如何减少花费在软件维护上的工作量，降低维护成本。,第 97 页,维护活动的类型,（

38、1）校正性维护。把诊断、校正软件错误的过程称之为校正性维护。（2）适应性维护。由于计算机技术的飞速发展，外部设备和其他系统元素经常改进和变化，为适应变化的环境而修改软件的活动称之为适应性维护。它占总维护活动的18%25%。（3）完善性维护。指在使用软件系统的过程中为满足用户提出的新功能和性能要求而进行的维护活动。它约占总维护活动的50%60%。（4）预防性维护。为进一步改进可维护性、可靠性而进行的维护活动，约占4%。,第 98 页,维护的代价,70年代用于维护软件的费用只占软件总预算的35%40%，80年代上升为40%60%，到了90年代则上升为70%80%。软件维护的代价包括有形和无形两个部

39、分：有形代价就是上面所提到的那些统计数字；无形代价包括：当看起来合理的有关变更要求不能及时满足时，将引起用户的不满；由于维护时的改动，在软件中引入潜在的故障，从而降低了软件的质量；当必须把软件开发工程师调去从事维护工作时，对开发过程造成的影响。,第 99 页,软件的可维护性,软件可维护性定义为：维护人员理解、修改该软件的难易程度。软件生存周期每个阶段的工作都和软件的可维护性有密切的关系，实际上，软件的可维护性是软件开发各个阶段的关键目标。软件的可维护性：可维护性因素提高可维护性方法文档,第 100 页,1可维护性因素,（1）可理解性。（2）可测试性。（3）可修改性。（4）可靠性。（5）可使用性

40、。,第 101 页,2提高可维护性的方法,软件生存周期每个阶段的工作都和软件可维护性有密切的关系。提高软件的可维护性必须从软件生存周期各个阶段的工作入手。,第 102 页,（1）问题定义阶段,为得到可维护的系统模型，就要使开发人员、用户和使用单位管理人员对问题的性质、工程的目标和规模取得完全一致的看法。考虑到开始时，双方对要求解的问题相互不太了解，这就要求系统必须是易于扩充、完善的系统。,第 103 页,（2）可性行研究阶段,可行性研究实质上是在高层以抽象方式进行的系统分析和设计的过程。该过程必然会对未来系统的可维护性产生巨大影响。这是因为：被推荐的系统是已经实现的、经过实用检验的系统，具有较

41、好的可维护性；选用的技术是成熟的技术，同时要求这些技术要有较强的维护手段。,第 104 页,（3）需求分析阶段,该阶段的任务是准确地描述系统“做什么”。同时，还要确定系统的运行环境，要考虑系统将来可能的变化，对系统的可扩充性和可修改性预先做好准备，从而提高系统的可维护性。,第 105 页,（4）概要设计阶段,该阶段的目的是用比较抽象概括的方式描述系统“怎样做”，确定系统的物理配置以及系统的软件结构和模块结构。在制定方案时，要充分考虑组成系统的各个物理元素（如程序、数据库、文档等）对可维护性的影响。在设计系统的软件结构和模块化时，要充分运用结构化设计技术和模块技术，尽量减小模块间的耦合性、提高模

42、块的内聚性，获得较高的模块独立性。这是影响可维护性的基本要素。,第 106 页,（5）详细设计阶段,该阶段的目标是具体实现系统“怎样做”，在该阶段结束时，应得到目标系统精确的模块描述和实现算法。为使未来系统便于维护，模块设计不仅要求逻辑上的正确性，还必须强调可理解性。设计实现过程中要采用结构化程序设计技术，使设计出的模块突出结构化特征，这样的程序具有统一的静态结构和动态状况，程序结构清晰，便于阅读理解，同时也便于程序的调试和测试。这些措施都将对软件的可维护性起巨大的作用。,第 107 页,（6）编码阶段,在该阶段要具体实现模块描述和算法，选择PL和编程风格都会对软件的可维护性产生极大的影响。选

43、择PL时，特别注重所选语言对软件可维护性的影响。一般来说，选用高级语言而不用汇编语言；所选语言要具有良好的模块化机制、可读性好的控制结构和数据结构、应用自动生成和报表自动生成功能、功能强大的开发工具和开发环境等。现在流行的OOPL具有上述要求的性能，用这种语言开发的程序具有较好的可维护性。,第 108 页,（7）测试阶段,在该阶段必须保持实际系统和软件配置中描述系统的完全一致性。测试过程必须置于可控操作规程和操作范围之内，以保证错误确实被消除、修改的副作用在允许的范围内，软件配置的版本更新与软件一致，从而保证软件的可维护性。,第 109 页,（8）维护阶段,维护过程本质上是集修改、系统定义和开

44、发为一体的过程，对于适应性维护和完善性维护来说更是如此。要严格按照有关规程进行维护活动，在完成每一项维护工作之后，都要对维护工作进行仔细认真的复查，要采取有效措施避免和减少修改代码、数据结构和有关文档可能带来的副作用，以保证维护后的软件仍具有较好的可维护性。,第 110 页,3文档,文档是影响软件可维护性的决定因素。由于需要维护的系统一般都是经过长期实际运行考验的系统，人们感兴趣的并不是系统可运行否，而是在特殊情况下如何使系统也能正常地运行，所以对于维护人员来说文档比程序代码更为重要。文档分为用户文档和系统文档两类；前者主要描述系统功能和使用方法；而后者则是描述系统设计、实现和测试等各方面的内容。,第 111 页,（1）用户文档,用户最初往往是通过用户文档了解系统功能，它包括下述五方面的内容：功能描述。安装手册。使用手册。参考手册。操作员指南。,第 112 页,（2）系统文档,系统文档描述的是从问题定义、需求说明、模块算法说明、系统设计、实现到系统测试用例、测试方案等软件配置的所有系统内部特征的文档。系统文档中应该更详细地说明系统各部分实现之间的联系、使用的方法和算法、错误恢复方法、系统主要参数的范围等与系统具体实现有关的一切技术方面的信息数据。,