软件工程第六讲
合集下载
软件工程讲义第六章
hour:=hour+1;
ENDWHILE; 2.1、2.2、2.4已能用程序语言表达，只需对2.3进一步精细化。 为了处理60个数据，又需一循环结构。
引入分钟值变量：minutes，每分钟要做的工作是： 累计：求每小时的平均值 检查违章情况 为了累计，引入变量sum： 在每小时处理前设初值为0。 每小时处理后求平均值。
3、自顶向下的程序验证。
2019年11月26日星期二
西南交通大学信息科学与技术学院
结构化程序设计的核心内容
二、使用三种基本控制结构来构造程序 1、任何程序都由顺序、选择和重复三种基本控制结构构造。 顺序实现了任何算法规约中的核心处理步骤； 条件允许根据逻辑情况选择处理方式； 重复提供了循环。 这些逻辑元素是结构化程序设计的基础。
BEGIN
1. 设置初值；
2. 处理24小时数据；
END
求精步骤1：设置初值。开始时一般不明确为哪些变量赋初值。
求精步骤2：计算结果是以小时为统计单位输出，它是重复执行24次的
循环结构。
局部数据结构设计：数据输入的方案选择：
1、处理前读入所有24小时数据，共1440个，需要大一个大的数组。
2、每次计算输入一个数据，这要保证对先前输入的数据不再使用。
ENDWHILE;
Mean:=sum/60.0; 一次违章出现是指连续5次污染值超过10.00。如果违章分布在两个相间的时 间段上，则把这次违章算在下一小时上。 首先测试当前值是否超过10.00，若是，还将进一步检查是否连续出现5次。 为了实现第二个测试，需要两个计数器： Voilation：计数本小时出现的违章次数。 Infraction:计数连续出现超过正常值的次数。 每次超正常值出现时，Infraction增1。为了保证Infraction表示连续出现超正 常值，必须保证在第一次出现超正常值时其初值为0。为了保证相继两个小时的 Infraction的值能连续被使用，在每小时处理前不能为Infraction置0值，只能在 第一小时处理前置0。另外，在发现一次未超正常值时，也应置它为0，即连续 出现超正常值中断。
ENDWHILE; 2.1、2.2、2.4已能用程序语言表达，只需对2.3进一步精细化。 为了处理60个数据，又需一循环结构。
引入分钟值变量：minutes，每分钟要做的工作是： 累计：求每小时的平均值 检查违章情况 为了累计，引入变量sum： 在每小时处理前设初值为0。 每小时处理后求平均值。
3、自顶向下的程序验证。
2019年11月26日星期二
西南交通大学信息科学与技术学院
结构化程序设计的核心内容
二、使用三种基本控制结构来构造程序 1、任何程序都由顺序、选择和重复三种基本控制结构构造。 顺序实现了任何算法规约中的核心处理步骤； 条件允许根据逻辑情况选择处理方式； 重复提供了循环。 这些逻辑元素是结构化程序设计的基础。
BEGIN
1. 设置初值；
2. 处理24小时数据；
END
求精步骤1：设置初值。开始时一般不明确为哪些变量赋初值。
求精步骤2：计算结果是以小时为统计单位输出，它是重复执行24次的
循环结构。
局部数据结构设计：数据输入的方案选择：
1、处理前读入所有24小时数据，共1440个，需要大一个大的数组。
2、每次计算输入一个数据，这要保证对先前输入的数据不再使用。
ENDWHILE;
Mean:=sum/60.0; 一次违章出现是指连续5次污染值超过10.00。如果违章分布在两个相间的时 间段上，则把这次违章算在下一小时上。 首先测试当前值是否超过10.00，若是，还将进一步检查是否连续出现5次。 为了实现第二个测试，需要两个计数器： Voilation：计数本小时出现的违章次数。 Infraction:计数连续出现超过正常值的次数。 每次超正常值出现时，Infraction增1。为了保证Infraction表示连续出现超正 常值，必须保证在第一次出现超正常值时其初值为0。为了保证相继两个小时的 Infraction的值能连续被使用，在每小时处理前不能为Infraction置0值，只能在 第一小时处理前置0。另外，在发现一次未超正常值时，也应置它为0，即连续 出现超正常值中断。
第六讲 软件维护(Software Maintenance)
新的组件去实现。
维护活动类似于开发活动：分析需求、评估系统和程 序设计、编写和评审代码、测试变化以及更新文档。
维护的类型
维护通常包括四种类型：
纠正性维护——修补系统缺陷的维护，日常维护
的主要工作。
适应性维护——使软件适应不同的操作环境（软
硬件环境）的维护
完善性维护——增加或修改系统功能的维护 预防性维护（再工程）——为预防系统后期可
C 维护的事件流
D 存档及评价
对于维护记录中的内容，Swanson给出了下述的项目表：
（1）程序名称； （2）源程序语句条数； （3）机器代码指令条数； （4）使用的程序设计语言； （5）程序的安装日期； （6）程序安装后的运行次数； （7）与程序安装后运行次数有关的处理故障的次数； （8）程序修改的层次和名称； （9）由于程序修改而增加的源程序语句条数；
1 系统变更与进化
软件系统变更是不可避免的：
软件使用过程中会出现新的需求； 用户的业务环境会发生变化； 可能有未发现的错误； 可能会有新的计算机设备添加到系统中； 系统的性能、可靠性也可能会需要改善。
一个关键的问题就是如何实现和管理现存软件的 变更，软件系统随变更要求不断更新改进的过程 就是系统进化过程。
⑵ 系统文档：即软件生产过程中每一步产生的文档。
3）复审
复审是保证系统可维护性的有效手段，各阶段复审重点 如下：
分析
可靠性 可移植性 可用性
设计
可理解性 可修改性 可测试性
编码
可理解性 可修改性 可移植性 效率
测试
可靠性 效率
验收
配置 复审
第六讲-软件工程详细设计方法课件
二、详细设计的方法
n 采用自顶向下、逐步求精的程序设计方法 n 使用三种基本控制结构构造程序
(顺序、选择、重复) n 主程序员的组织形式
结构化程序设计技术是一种设计程序的技 术，它采用自顶向下逐步求精的设计方法 和单入口单出口的控制结构，并且只包含 顺序、选择和循环三种控制结构。
详细设计的方法
n 使用结构程序设计技术的好处： n 1)提高软件开发工程的成功率和生产率； n 2)系统有清晰的层次结构，容易阅读理解； n 3)单入口单出口的控制结构，容易诊断纠正； n 4)模块化可以使得软件可以重用；
PAD图的符号
PAD图的例子
PAD图
nPAD图的实例见p191页
n特点 : 结构清晰 , 支持结构化的程 计方法,有利于自动生成程序。
例子:
n 输入三个正整数作为边长，判断该三条边 构成的三角形是等边、等腰还是一般三角 形。请画出该程序的流程图、 N-S图、 PAD 图。
例子:
n
例子:
n
例子:
2. N-S图
nN-S图是由Nassi和Shneiderman提出 的一种符合结构化程序设计原则的图 形描述工具。也叫盒图。
N-S图
N-S图特点
(1)功能域(即某一个特定控制结构的作用域)有 明确的规定，并且可以很直观地从N-S图上看出 来； (2)它的控制转移不能任意规定，必须遵守结构化 程序设计的要求；
n
思考:
n 在数据A(1)~A(n)中求最大数和次大数.。
n 在数据A(1)~A(n)中求前m个最大的数。
4. 判定表
n当算法中包含多重条件选择时，用程 序流程图、 N-S图或PAD都不能清晰地 描述。用判定表确可以清晰表达复杂 条件与应做动作之间的关系。
软件工程课件第六章
根据上面的讨论，需要命名的数据有：
20.09.2020
结构化程序设计的核心内容
2、三种基本结构的共同点是单入口、单出口。
单入口单出口的控制理 解，也容易保证程序的正确性。
20前.0一9.页2020
国家软件开发工程规范的规定
国家软件开发工程规范规定“程序单元必须只有唯一的 入口，唯一的出口”有两个不同的概念：
1972年，IBM公司的Mills进一步提出，程 序应该只有一个入口和一个出口。
20.09.2020
结构化程序设计
结构程序设计是按照一组能提高程序 的可读性和易维护性的规则而进行的程序 设计方法，目的是为了使程序具有一种合 理的结构，以使程序易理解和维护，便于 保证和验证程序的正确性。
20.09.2020
扩展的结构程序设计：还允许使用DO_CASE型多分支结 构和DO_UNTIL型循环结构。
修正的结构程序设计：再允许使用BREAK(LEAVE)结构。
20.09.2020
逐步求精算法实例
空气污染物含量数据的统计处理程序
假定某工厂烟囱附近，在24小时中每分钟测量1次空气中
污染物含量。得到的数据以每100单位中所含污染物成分的值
3、自顶向下的程序验证。
20.09.2020
结构化程序设计的核心内容
二、使用三种基本控制结构来构造程序 1、任何程序都由顺序、选择和重复三种基本控制结构构造。
顺序实现了任何算法规约中的核心处理步骤； 条件允许根据逻辑情况选择处理方式； 重复提供了循环。 这些逻辑元素是结构化程序设计的基础。 根据逐步求精的思想，可用三种方式对模块过程进行分解： ①用顺序方式对过程分解，确定各部分的执行顺序； ②用选择方式对过程分解，确定各部分的执行条件； ③用循环方式对过程分解，确定某个部分进行重复的开始和 结束的条件。 对处理过程仍然模糊的部分反复使用以上分解，直到所有细 节确定下来。
软件工程软件工程软件工程6
6.3.4 判定表
例：一图书销售系统，其中一加工为“优惠处理”，条件是：顾客的营业额大于1000元，同时必须信誉好，或者虽然信誉不好，但是20年以上的老主顾。
1 2 3 4
>1000元 Y Y Y N 信誉好 Y N N - >20 年 - Y N - 优 惠 X X 正 常 X X
6.3.6 PDL
PDL语言的主要特点如下： (1) 各种定义语句及控制结构的表达都具有严格的语法形式，使程序结构、数据说明等更加清晰。 (2) 提供了数据说明机制，可用于定义简单及复杂的数据结构。 (3) 提供了模块的定义和调用机制，方便了程序模块化的表达。
6.4 面向数据结构的设计方法
详细设计的任务
详细设计的任务
(4) 为每个模块设计一组测试用例。 由于负责详细设计的软件人员对模块的实现细节十分清楚，因此由他们在完成详细设计后提出模块的测试要求是非常恰当和有效的。 (5) 编写文档，参加复审。 详细设计阶段的成果主要以详细设计说明书的形式保留下来，在通过复审对其进行改进和完善后作为编码阶段进行程序设计的主要依据。
6.3.3 PAD图
6.3.3 PAD图
图6.ቤተ መጻሕፍቲ ባይዱ 使用PAD图提供的定义功能来逐步求精的例子
当算法中包含多重嵌套的条件选择时，用程序流程图、盒图、PAD图或后面即将介绍的过程设计语言(PDL)都不易清楚地描述。然而判定表却能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。 一张判定表由4部分组成，左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。判定表右半部的每一列实质上是一条规则，规定了与特定的条件组合相对应的动作。
6.3.6 PDL
例：一图书销售系统，其中一加工为“优惠处理”，条件是：顾客的营业额大于1000元，同时必须信誉好，或者虽然信誉不好，但是20年以上的老主顾。
1 2 3 4
>1000元 Y Y Y N 信誉好 Y N N - >20 年 - Y N - 优 惠 X X 正 常 X X
6.3.6 PDL
PDL语言的主要特点如下： (1) 各种定义语句及控制结构的表达都具有严格的语法形式，使程序结构、数据说明等更加清晰。 (2) 提供了数据说明机制，可用于定义简单及复杂的数据结构。 (3) 提供了模块的定义和调用机制，方便了程序模块化的表达。
6.4 面向数据结构的设计方法
详细设计的任务
详细设计的任务
(4) 为每个模块设计一组测试用例。 由于负责详细设计的软件人员对模块的实现细节十分清楚，因此由他们在完成详细设计后提出模块的测试要求是非常恰当和有效的。 (5) 编写文档，参加复审。 详细设计阶段的成果主要以详细设计说明书的形式保留下来，在通过复审对其进行改进和完善后作为编码阶段进行程序设计的主要依据。
6.3.3 PAD图
6.3.3 PAD图
图6.ቤተ መጻሕፍቲ ባይዱ 使用PAD图提供的定义功能来逐步求精的例子
当算法中包含多重嵌套的条件选择时，用程序流程图、盒图、PAD图或后面即将介绍的过程设计语言(PDL)都不易清楚地描述。然而判定表却能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。 一张判定表由4部分组成，左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。判定表右半部的每一列实质上是一条规则，规定了与特定的条件组合相对应的动作。
6.3.6 PDL
软件工程 第六讲 结构化分析方法
什么是GOTO语句？
ห้องสมุดไป่ตู้
在以前的程序设计课程中，老师说 goto语句很重要，为什么在这里说不 那么重要呢?
简单明确的概述什么是自顶向下、逐步求 精的思想，它和自底向上的分析方法有什 么不同？？
结构化设计程序的方法在软件工程提出后产生， 主要是提出取消“GOTO“语句的使用。我想问的 是在结构化中的模块之间的接口不就算是 “GOTO”语句吗？ 问题一：书中104在讲到结构化程序设计（SP）中 提到的“只要三种控制结构（顺序、选择、重复） 就是能表达用一个入口和一个出口的流程图所能 表达的任何程序逻辑”该做如何理解？ 问题二：该如何来理解结构化方法的指导思想 （自顶向下、逐步求精）与两个基本原则（抽象、 分解）的联系？
问题六：基本加工是靠自己的经验来确定的，还 是有一定的标准？
返回
数据流
表示数据的流向。 数据流由一组数据项组成。 命名规则和注意事项：
数据流的名字用名词或名词词组 应尽量使用现实系统中已有的名字 把现实环境中传递的一组数据中最重要的那个数据的名字作为数 据流的名字 不要把控制流作为数据流 不要使用意义空洞的名词作为数据流名，如”数据“、“信息 “等。 如果在命名时遇到困难，说明你可能对数据流的分解不恰当，应 进行重新分解。 对流进或流出文件的数据流不需标注名字。
问题P110 怎样准确的判断出父图与子图的平 衡？
父图 与子 图平 衡吗？
父图 与子 图平 衡吗？
问题
110页图8.6为什么平衡不清楚。 P110 对父图与子图的平衡的理解：图8.6中如果 不存在图8.4的情况下，那么这个父图与子图就不 符合自图的平衡了，对吗？ 画数据流图中，父图与子图怎样保持平衡？ P110：第（6）个注意事项第二段第一句：有时考 虑平衡可忽略一些枝节性的数据流。我对本句中 的“枝节性的数据流”不太理解，不知道什么叫 “枝节性的数据流”，枝节性的数据流有何特点？
软件工程课件第6章
第6章 编码
二、存储器效率
采用结构化程序设计，将程序功能合理 分块，使每个模块或一组密切相关模块的程 序体积大小与每页的容量相匹配，可减少页 面调度、减少内外存交换，提高存储器效率。
在微型计算机系统中，存储器的容量对 软件设计和编码的制约比较大。因此要选择 可生成较短目标代码且存储压缩性能优良的 编译程序，有时需要采用汇编语言编程。
第6章 编码
三、程序设计语言的选择
程序设计语言的选择常从以下几个方面考虑：
（1）项目的应用领域 （2）算法与计算的复杂性 （3）数据结构的复杂性 （4）效率 （5）可移植性 （6）程序设计人员的水平 （7）构造系统的模式
第6章 编码
6.2 编码风格
编码风格实际上是一种编码原则。从 20世纪70年代以来，编码的目标从强调效 率转变到强调清晰。与此相应，编码风格 也从追求“聪明”和“技巧”，变为提倡 “简明”和“直接”。人们逐渐认识到， 良好的编码风格能在一定程度上弥补程序 设计语言存在的缺点。反之，如果不注意 编码风格，即使使用了结构化的现代语言， 也很难写出高质量的程序。
（2）好的设计可以提高效率。
（3）代码效率与代码的简单性相关。
第6章 编码
一、代码效率
（1）应先简化算术和逻辑的表达式。 （2）仔细研究嵌套的循环，以确定是否有语 句可以从内层往外移。 （3）尽量避免使用多维数组。 （4）尽量避免使用指针和复杂的列表。 （5）使用执行时间短的算术运算。 （6）即使语言允许，一般也不要采用混合数 据类型。 （7）尽量使用整数表达式和布尔表达式。
第6章 编码
一、代码文档化：指织形式。
二、数据说明：程序或模块在其可执行部分的前面 都集中了一些说明语句 ，出于阅读理解和维护的 要求，最好使其规范化，使说明的先后次序固定 。
软件工程第六章
软件工程第六章在软件工程的广袤领域中，第六章往往聚焦于一些关键且核心的概念与实践。
这一章，或许是关于软件设计原则与模式的深入探讨，或许是对软件测试策略与方法的详细阐述，又或许是围绕软件项目管理中的关键环节展开论述。
当我们谈论软件设计原则时，就不得不提及“单一职责原则”。
这个原则主张一个类或模块应该仅有一个引起它变化的原因。
想象一下，假如一个类承担了过多不同类型的职责，那么当其中一项职责发生改变时，就可能会对整个类的稳定性产生影响，从而引发一系列不必要的修改和潜在的错误。
这就好比一个人同时要兼顾多个完全不同的工作，很容易顾此失彼，导致工作质量下降。
“开闭原则”也是重要的设计原则之一。
它表明软件实体（如类、模块、函数等）应该对扩展开放，对修改关闭。
简单来说，就是在不修改现有代码的基础上，能够通过添加新的代码来实现新的功能或扩展系统的行为。
这使得软件具有更好的可维护性和可扩展性，避免了因为频繁修改现有代码而引入新的错误。
设计模式在软件工程中起着举足轻重的作用。
例如，“工厂模式”常用于创建对象，将对象的创建和使用分离，提高了代码的灵活性和可维护性。
当我们需要根据不同的条件创建不同类型的对象时，工厂模式可以帮助我们轻松地实现这一需求，而无需在每次创建对象时都编写复杂的条件判断代码。
再来说说软件测试。
在第六章中，可能会详细介绍各种测试类型，如单元测试、集成测试、系统测试和验收测试。
单元测试是针对软件中的最小可测试单元（通常是函数或方法）进行的测试，确保每个单元的功能正确无误。
集成测试则着重于检验各个模块之间的接口是否正常工作，是否能够协同完成特定的功能。
系统测试则是从整个系统的角度出发，对软件的功能、性能、兼容性等方面进行全面的测试。
而验收测试则是由用户或客户参与，以确定软件是否满足他们的需求和期望。
在软件测试中，测试用例的设计至关重要。
好的测试用例应该具有较高的覆盖率，能够有效地发现潜在的问题。
同时，测试用例还应该易于维护和更新，以适应软件的不断变化。
软件工程(全套课件)
软件工程(全套课件 )
contents
目录
• 软件工程概述 • 软件开发过程模型 • 需求分析与管理 • 系统设计与实现 • 测试与质量保证 • 项目管理与团队协作 • 软件维护与演化
01
软件工程概述
软件工程定义与发展
软件工程的定义
软件工程是一种系统性的、规范化的、可量化的方法来开发和维护软件，它涉及 到软件开发的全过程，包括需求分析、设计、编码、测试和维护等各个阶段。
需求、成本估算等
设立里程碑和关键任务，以便 监控项目进展
定期评估项目状态，与项目干 系人沟通，确保项目按计划进 行
及时调整项目计划，以应对变 更和不可预见的风险
风险管理策略制定
01 识别项目潜在的风险，包括技术风险、市 场风险、资源风险等
02 评估风险的概率和影响程度，确定风险优 先级
03
制定相应的风险应对策略和措施，如风险 规避、减轻、转移和接受等
软件工程知识体系的核心内容
软件工程知识体系的核心内容包括软件开发过程模型、软件开发方法、软件需 求工程、软件设计、软件测试与维护等。这些内容相互关联、相互支持，构成 了完整的软件工程知识体系框架。
02
软件开发过程模型
瀑布模型
瀑布模型是一种线性的软件开发过程模型，它 按照一系列有序的、相互依赖的阶段进行开发 ，每个阶段都有明确的输入和输出。
版本控制与文档管理
01
使用版本控制工具（如Git）管理 项目代码和文档，确保数据的一 致性和可追溯性
02
制定版本控制规范，包括分支管 理、提交信息、合并策略等
பைடு நூலகம்
定期备份项目数据，以防数据丢 失或损坏
03
编写详细的开发文档和用户手册 ，以便团队成员和最终用户了解
contents
目录
• 软件工程概述 • 软件开发过程模型 • 需求分析与管理 • 系统设计与实现 • 测试与质量保证 • 项目管理与团队协作 • 软件维护与演化
01
软件工程概述
软件工程定义与发展
软件工程的定义
软件工程是一种系统性的、规范化的、可量化的方法来开发和维护软件，它涉及 到软件开发的全过程，包括需求分析、设计、编码、测试和维护等各个阶段。
需求、成本估算等
设立里程碑和关键任务，以便 监控项目进展
定期评估项目状态，与项目干 系人沟通，确保项目按计划进 行
及时调整项目计划，以应对变 更和不可预见的风险
风险管理策略制定
01 识别项目潜在的风险，包括技术风险、市 场风险、资源风险等
02 评估风险的概率和影响程度，确定风险优 先级
03
制定相应的风险应对策略和措施，如风险 规避、减轻、转移和接受等
软件工程知识体系的核心内容
软件工程知识体系的核心内容包括软件开发过程模型、软件开发方法、软件需 求工程、软件设计、软件测试与维护等。这些内容相互关联、相互支持，构成 了完整的软件工程知识体系框架。
02
软件开发过程模型
瀑布模型
瀑布模型是一种线性的软件开发过程模型，它 按照一系列有序的、相互依赖的阶段进行开发 ，每个阶段都有明确的输入和输出。
版本控制与文档管理
01
使用版本控制工具（如Git）管理 项目代码和文档，确保数据的一 致性和可追溯性
02
制定版本控制规范，包括分支管 理、提交信息、合并策略等
பைடு நூலகம்
定期备份项目数据，以防数据丢 失或损坏
03
编写详细的开发文档和用户手册 ，以便团队成员和最终用户了解
软件工程课本讲解第6章软件维护
例如，开发每一行源代码耗资25美 元，维护每一行源代码需要耗资 1000美元。
维护工作量包括生产性活动（如分 析和评价、设计修改和实现）和 “轮转”活动（如力图理解代码在 做什么、试图判明数据结构、接口 特性、性能界限等）。
21
维护工作量的模型
MpKced
M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而导致
复杂性的度量 d是对软件熟悉程度的度量。
22
模型指明，如果使用了不好的软件 开发方法（未按软件工程要求做）， 原来参加开发的人员或小组不能参 加维护，则工作量（及成本）将按 指数级增加。
23
6.2 软件维护实施活动
为了有效地进行软件维护，应事先 就开始做组织工作。 首先建立维护的机构 申明提出维护申请报告的过程及 评价的过程 为每一个维护申请规定标准的处 理步骤 建立维护活动的登记制度以及规 定评价和评审的标准。
3
一、软件维护的定义
在软件运行／维护阶段对软件产品进行的修改就是 所谓的维护。
软件维护是软件生存周期的最后一个阶段,不属于系统开发的过程。
问题
内
容
维护 满足用户对已开发产品的性能与运行环境不断提高的要求，进而
目的 达到延长软件寿命的目的。
改正性 对程序使用期间发现的程序错误进行诊断和改正的过程；
改正性 17—21% 适应性 18—25%
完善性 50—66% 预防性 4%左右
软件的易维护性是软件开发过程中每个步骤的一个关键目标。维护费用占软件总支
出的20-30%到70-80%。而无形的代价更是无法估计的。
4
改正性维护
在软件交付使用后，因开发时测试 的不彻底、不完全，必然会有部分 隐藏的错误遗留到运行阶段。
维护工作量包括生产性活动（如分 析和评价、设计修改和实现）和 “轮转”活动（如力图理解代码在 做什么、试图判明数据结构、接口 特性、性能界限等）。
21
维护工作量的模型
MpKced
M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而导致
复杂性的度量 d是对软件熟悉程度的度量。
22
模型指明，如果使用了不好的软件 开发方法（未按软件工程要求做）， 原来参加开发的人员或小组不能参 加维护，则工作量（及成本）将按 指数级增加。
23
6.2 软件维护实施活动
为了有效地进行软件维护，应事先 就开始做组织工作。 首先建立维护的机构 申明提出维护申请报告的过程及 评价的过程 为每一个维护申请规定标准的处 理步骤 建立维护活动的登记制度以及规 定评价和评审的标准。
3
一、软件维护的定义
在软件运行／维护阶段对软件产品进行的修改就是 所谓的维护。
软件维护是软件生存周期的最后一个阶段,不属于系统开发的过程。
问题
内
容
维护 满足用户对已开发产品的性能与运行环境不断提高的要求，进而
目的 达到延长软件寿命的目的。
改正性 对程序使用期间发现的程序错误进行诊断和改正的过程；
改正性 17—21% 适应性 18—25%
完善性 50—66% 预防性 4%左右
软件的易维护性是软件开发过程中每个步骤的一个关键目标。维护费用占软件总支
出的20-30%到70-80%。而无形的代价更是无法估计的。
4
改正性维护
在软件交付使用后，因开发时测试 的不彻底、不完全，必然会有部分 隐藏的错误遗留到运行阶段。
软件工程导论 (第6版) 学习辅导
软件工程导论 (第6版) 学习辅导软件工程导论是软件工程领域的入门级基础课程，旨在让学生了解和掌握软件工程的基本概念、原则、方法和技术。
本文将从软件工程的定义、软件工程的活动、软件工程的特点及优势等几个方面介绍软件工程导论的学习辅导。
一、软件工程的定义软件工程是指将“工程化”的方式应用于软件开发的过程中，通过系统的、逐步精化的方式进行软件开发、测试、维护和管理，以提高软件开发的效率、质量和可靠性。
软件工程涉及到多个方面，包括系统需求分析、软件设计、编码规范、软件测试、软件维护等，要求软件开发者在整个软件开发的过程中按照规范进行开发，以确保最终的软件质量和用户需求的满足度。
二、软件工程的活动软件工程的活动主要包括以下几个方面：1. 需求分析：对用户需求进行分析、整理和规划。
2. 软件设计：根据需求分析的结果，设计出软件的总体框架、架构等设计方案。
3. 编码：按照软件设计的方案进行编码。
4. 测试：对软件进行各个方面的测试，包括功能测试、性能测试、兼容性测试等。
5. 维护：对软件进行正常运行的维护以及对软件的更新和修改等。
以上活动是整个软件工程过程的主要流程，开发者需要严格按照这些步骤进行开发，在每个阶段都要进行充分的沟通和协作，确保最终的开发结果是按照用户需求和软件工程规范进行开发的。
三、软件工程的特点软件工程作为一个独立的领域存在，具有以下几个特点：1. 复杂性：软件工程涉及到多个方面，包括用户需求、软件设计、编码、测试等各个方面，要求开发者有很高的综合素质和软件开发技能。
2. 长期性：软件工程的开发过程需要一定的时间，并且需要经历多个阶段。
3. 抽象性：软件工程不同于其他工程，它是基于描述和概念建立的。
4. 可定量性：软件工程需要对开发过程进行度量，以评估开发效率和开发成果的质量等。
四、软件工程的优势软件工程的优势主要体现在以下几个方面：1. 提高软件的质量：软件工程通过规范化的开发流程和方法使得软件的开发过程更加严密和规范化，从而提高了软件的开发质量。
软件工程第六讲.ppt
测试充分性
路径测试
条件组合覆盖
判定－条件覆盖 判定覆盖 语句覆盖 条件覆盖
内容进度
逻辑驱动覆盖测试
语句覆盖 判定（分支）覆盖 条件覆盖 判定条件覆盖 条件组合覆盖
循环语句覆盖测试
简单循环 嵌套循环 串接循环
循环测试-简单循环
简单循环：
其中n是允许通过循环的最大次数。 1. 整个跳过循环； 2. 只有一次通过循环； 3. 两次通过循环； 4. m次通过循环，其中m<n； 5. n-1，n次通过循环。
分支－条件测试－设计用例
根据定义只需设计以下两个测试用例便可以覆盖8个条 件值以及4个判断分支。
测试用例 x=4、y=6、z=5 x=2、y=5、z=11 通过路径 abd ace 条件取值 T1、T2、T3、T4 -T1、-T2、-T3、-T4 bd ce 覆盖分支
分析
例如对于条件表达式(x>3)&&(z<10)来说，必须两个条 件都满足才能确定表达式为真。如果（x>3）为假则一 般的编译器不在判断是否z<10了。 对于第二个表达式（x= =4）||（y>5）来说，若x==4测 试结果为真，就认为表达式的结果为真，这时不再检 查（y>5）条件了。
入口 a x>3 && z<10 b 语句块1
c
程序执行的路径是：abd
x==4 || y>5
d e
程序执行的路径是：ace
语句块2 语句块3 出口
条件覆盖概念
设计足够多的测试用例，运行所测程序，使程序 中每个判断的每个条件的每个可能取值至少执行 一次；
条件覆盖－设计用例
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
入口 a x>3 && z<10 b 语句块1
c
程序执行的路径是：abd
x==4 || y>5
d e
程序执行的路径是：ace
语句块2 语句块3 出口
条件覆盖概念
设计足够多的测试用例，运行所测程序，使程序 中每个判断的每个条件的每个可能取值至少执行 一次；
条件覆盖－设计用例
入口 T1和－T1 a x>3 && z<10 b 语句块1 T3和－T3 T4和－T4 T2和－T2
CodeWizard：C/C++代码分析工具
McCabe：软件质量度量方法
TestBed：源代码检查工具
Logiscope：源代码规则检查工具
Logiscope代码检查工具
学习目标
逻辑驱动覆盖测试
语句覆盖 判定（分支）覆盖 条件覆盖 判定条件覆盖 条件组合覆盖 路径测试覆盖
测试用例（2）
假如根据定义设计测试用例如下：
测试用例 x=2、y=6、z=5 x=4、y=5、z=5 acd acd 通过路径 条件取值 -T1、T2、-T3、T4 T1、-T2、T3、-T4 cd cd 覆盖分支
分支－条件测试概念
设计足够的测试用例，使得判断中每个条件的所有可能取 值至少执行一次，同时每个判断的所有可能判断结果至少 执行，即要求各个判断的所有可能的条件取值组合至少执 行一次。
关心程序的外在功能和非功能表 现
确认测试、系统测试阶段进行
白盒测试目的
保证一个模块中的所有独立路径至少被执行一次； 对所有的逻辑值均需要测试真、假两个分支； 在上下边界及可操作范围内运行所有循环； 检查内部数据结构以确保其有效性。
白盒测试的策略
桌前检查（Desk Check） 单元测试（Unit Testing） 同行评审（Peer Review） 代码评审（Code Review） 代码走查（Walkthrough） 静态分析（static analyse）
c
x==4 || y>5
d 语句块2 语句块3 出口 e
测试用例（1）
则可以设计测试用例如下：
测试用例 x=4、y=6、z=5 x=2、y=5、z=5 x=4、y=5、z=15 通过路径 abd ace acd 条件取值 T1、T2、T3、T4 -T1、T2、-T3、-T4 T1、-T2、T3、-T4 覆盖分支 bd ce cd
白盒测试和黑盒测试比较
白盒测试 联系 区 黑盒测试
白盒测试和黑盒测试都是软件测试的一个方面; 两者有时结合起来同时进行测试，“灰盒测试”; 需要源代码 无法检验程序的外部特性， 无法测试遗漏的需求 不需要源代码，需要可执行文件 从用户的角度出发进行测试
别
关心程序内部结构、逻辑以 及代码的可维护性
编码、集成测试阶段进行
循环测试
不规则循环：
不能测试，尽量重新设计给结构化 的程序结构后再进行测试。
总结
逻辑驱动覆盖测试
语句覆盖 判定覆盖 条件覆盖 判定－条件覆盖 条件组合覆盖 路径覆盖
内容进度
设计测试用例
测试用例 x=4、y=6、z=5 通过路径 abd 条件取值 T1、T2、T3、T4 覆盖 组合号 1和5
x=4、y=5、z=15
x=2、y=6、z=5
acd
acd
T1、-T2、T3、-T4
-T1、T2、-T3、T4
2和6
3和7
x=2、y=5、z=15
ace
-T1、-T2、-T3、-T4
嵌套循环举例
举例：
for(i=0; i<num; i++) ｛ while(j>0) { j--; } }
循环测试
串接循环：
如果串接循环的循环都彼此独立， 可是使用嵌套的策略测试。但是 如果两个循环串接起来，而第一 个循环是第二个循环的初始值， 则这两个循环并不是独立的。如 果循环不独立，则推荐使用的嵌 套循环的方法进行测试。
简单循环举例
举例：
...... for(s=0;s<i;s++) fwrite(&prof[s],sizeof(struct ENGINEER),1,fp);
.循环： 1. 从最内层循环开始，将其它循环 设置为最小值； 2. 对最内层循环使用简单循环，而 使外层循环的叠代参数（即循环 计数）最小； 3. 由内向外构造下一个循环的测试， 但其它的外层循环为最小值，并 使其它的嵌套循环为“典型”值； 4. 继续直到测试所有的循环。
分支－条件测试－设计用例
根据定义只需设计以下两个测试用例便可以覆盖8个条 件值以及4个判断分支。
测试用例 x=4、y=6、z=5 x=2、y=5、z=11 通过路径 abd ace 条件取值 T1、T2、T3、T4 -T1、-T2、-T3、-T4 bd ce 覆盖分支
分析
例如对于条件表达式(x>3)&&(z<10)来说，必须两个条 件都满足才能确定表达式为真。如果（x>3）为假则一 般的编译器不在判断是否z<10了。 对于第二个表达式（x= =4）||（y>5）来说，若x==4测 试结果为真，就认为表达式的结果为真，这时不再检 查（y>5）条件了。
程序复杂性：费用、周期、错误
代码行度量法 Halstead软件科学法 结构度量 McCabe度量法
代码度量-代码行度量
代码度量-Halstead软件科学法
程序=运算符化+ 运算元结构度量 Halstead公式
N=N1+N2=n1log2(n1)+n2log2(n2)
N1=运算符出现的总次数 N2=运算元出现的总次数
内容进度
白盒测试
白盒测试的目的 白盒测试和黑盒测试的联系 白盒测试的策略
代码质量
代码度量 使用LogiScope度量代码质量 代码检查工具
白盒测试
又称透明盒测试、逻辑驱动测试 是测试被测单元内部如何工作的一种测试方法 允许测试人员根据程序内部逻辑结构及有关信息来设计和 选择测试用例，对程序的逻辑结构进行测试 可覆盖全部代码、分支、路径和条件等
静态分析报告、代码质量报告
白盒测试对测试人员的要求
了解软件语言 了解软件开发技术 有开发经验最好 掌握白盒测试工具 掌握白盒测试用例设计方法 掌握开发人员编程中容易出现的问题，不断积累经验
内容进度
白盒测试
白盒测试的目的 白盒测试和黑盒测试的联系 白盒测试的策略
代码质量
代码度量 使用LogiScope度量代码质量 代码检查工具
软件质量
软件质量
要求产品中没有BUG
常用指标
缺陷率（缺陷密度 ） 可靠性（运行n小时失效次数） 顾客满意度
软件质量反映的三个方面
软件需求 开发准则 隐含的需求
代码质量对软件质量的贡献
辅助方法－流程图
入口 a x>3 && z<10 画出模块的流程图 c 发现问题 辅助设计测试用例 e
b 语句块1
x==4 || y>5 d 语句块2 语句块3
出口
语句覆盖概念
语句覆盖就是设计若干个测试用例，运行被测试 程序，使得每一条可执行语句至少执行一次。
语句覆盖－设计用例
测试用例输入为： { x=4、y=5、z=5}
如何提高代码质量
培训
审查和监督
业务 工具和语言
技术
编码规范
测试
……..
编码规范和标准
坚持标准和规范的原因
可靠性 可读性/可维护性 移植性
代码审查单
代码审查单
代码审查单
输入/输出错误 数据声明错误 数据引用错误 计算错误 函数参数错误 比较错误 控制流程错误 其它检查
代码质量度量
代码是软件产品中的重要部分 代码质量反映软件质量 其它非代码因素也起着关键作用 文档（设计、帮助、用户手册等）
制约程序员编写高质量代码的因素
对需求和设计的理解不透彻 对软件业务流程不熟悉 没有开发经验 对开发工具或开发语言不熟悉 受情绪因素的影响等因素 其它非代码因素也起着关键作用
c
x==4 || y>5
d 语句块2 语句块3 出口 e
条件覆盖－设计用例
测试用例的输入为： { x=4、y=6、z=5} { x=2、y=5、z=5} { x=4、y=5、z=15}
程序执行的路径是：abd 程序执行的路径是：ace 程序执行的路径是：acd
入口 a x>3 && z<10 b 语句块1
代码度量-结构度量
扇入：调用一给定模块的模块计数； 扇出：给定模块所调用的模块计数； 使用扇入扇出来评价软件设计
具有大扇入和大扇出的模块可能是不良设计。这种模块可能未能正确分解 并需要重新设计。
McCabe度量法
辅助分析工具
对源代码进行分析经常需要辅助分析工具
PC-lint：代码规则走查工具
4和8
丢失了一条路径abe
路径测试
路径测试就是设计足够多的测试用例，覆盖被测试对象中 的所有可能路径。
测试用例
在上面的测试用例中修改一个测试用例则可对程序 进行了全部的路径覆盖。
测试用例 x=4、y=6、z=5 x=4、y=5、z=15 x=2、y=6、z=15 x=5、y=6、z=5 通过路径 abd acd ace abe 覆盖条件 T1、T2、T3、T4 T1、-T2、T3、-T4 -T1、-T2、-T3、-T4 T1、T2、-T3、-T4
c
程序执行的路径是：abd
x==4 || y>5
d e
程序执行的路径是：ace
语句块2 语句块3 出口
条件覆盖概念
设计足够多的测试用例，运行所测程序，使程序 中每个判断的每个条件的每个可能取值至少执行 一次；
条件覆盖－设计用例
入口 T1和－T1 a x>3 && z<10 b 语句块1 T3和－T3 T4和－T4 T2和－T2
CodeWizard：C/C++代码分析工具
McCabe：软件质量度量方法
TestBed：源代码检查工具
Logiscope：源代码规则检查工具
Logiscope代码检查工具
学习目标
逻辑驱动覆盖测试
语句覆盖 判定（分支）覆盖 条件覆盖 判定条件覆盖 条件组合覆盖 路径测试覆盖
测试用例（2）
假如根据定义设计测试用例如下：
测试用例 x=2、y=6、z=5 x=4、y=5、z=5 acd acd 通过路径 条件取值 -T1、T2、-T3、T4 T1、-T2、T3、-T4 cd cd 覆盖分支
分支－条件测试概念
设计足够的测试用例，使得判断中每个条件的所有可能取 值至少执行一次，同时每个判断的所有可能判断结果至少 执行，即要求各个判断的所有可能的条件取值组合至少执 行一次。
关心程序的外在功能和非功能表 现
确认测试、系统测试阶段进行
白盒测试目的
保证一个模块中的所有独立路径至少被执行一次； 对所有的逻辑值均需要测试真、假两个分支； 在上下边界及可操作范围内运行所有循环； 检查内部数据结构以确保其有效性。
白盒测试的策略
桌前检查（Desk Check） 单元测试（Unit Testing） 同行评审（Peer Review） 代码评审（Code Review） 代码走查（Walkthrough） 静态分析（static analyse）
c
x==4 || y>5
d 语句块2 语句块3 出口 e
测试用例（1）
则可以设计测试用例如下：
测试用例 x=4、y=6、z=5 x=2、y=5、z=5 x=4、y=5、z=15 通过路径 abd ace acd 条件取值 T1、T2、T3、T4 -T1、T2、-T3、-T4 T1、-T2、T3、-T4 覆盖分支 bd ce cd
白盒测试和黑盒测试比较
白盒测试 联系 区 黑盒测试
白盒测试和黑盒测试都是软件测试的一个方面; 两者有时结合起来同时进行测试，“灰盒测试”; 需要源代码 无法检验程序的外部特性， 无法测试遗漏的需求 不需要源代码，需要可执行文件 从用户的角度出发进行测试
别
关心程序内部结构、逻辑以 及代码的可维护性
编码、集成测试阶段进行
循环测试
不规则循环：
不能测试，尽量重新设计给结构化 的程序结构后再进行测试。
总结
逻辑驱动覆盖测试
语句覆盖 判定覆盖 条件覆盖 判定－条件覆盖 条件组合覆盖 路径覆盖
内容进度
设计测试用例
测试用例 x=4、y=6、z=5 通过路径 abd 条件取值 T1、T2、T3、T4 覆盖 组合号 1和5
x=4、y=5、z=15
x=2、y=6、z=5
acd
acd
T1、-T2、T3、-T4
-T1、T2、-T3、T4
2和6
3和7
x=2、y=5、z=15
ace
-T1、-T2、-T3、-T4
嵌套循环举例
举例：
for(i=0; i<num; i++) ｛ while(j>0) { j--; } }
循环测试
串接循环：
如果串接循环的循环都彼此独立， 可是使用嵌套的策略测试。但是 如果两个循环串接起来，而第一 个循环是第二个循环的初始值， 则这两个循环并不是独立的。如 果循环不独立，则推荐使用的嵌 套循环的方法进行测试。
简单循环举例
举例：
...... for(s=0;s<i;s++) fwrite(&prof[s],sizeof(struct ENGINEER),1,fp);
.循环： 1. 从最内层循环开始，将其它循环 设置为最小值； 2. 对最内层循环使用简单循环，而 使外层循环的叠代参数（即循环 计数）最小； 3. 由内向外构造下一个循环的测试， 但其它的外层循环为最小值，并 使其它的嵌套循环为“典型”值； 4. 继续直到测试所有的循环。
分支－条件测试－设计用例
根据定义只需设计以下两个测试用例便可以覆盖8个条 件值以及4个判断分支。
测试用例 x=4、y=6、z=5 x=2、y=5、z=11 通过路径 abd ace 条件取值 T1、T2、T3、T4 -T1、-T2、-T3、-T4 bd ce 覆盖分支
分析
例如对于条件表达式(x>3)&&(z<10)来说，必须两个条 件都满足才能确定表达式为真。如果（x>3）为假则一 般的编译器不在判断是否z<10了。 对于第二个表达式（x= =4）||（y>5）来说，若x==4测 试结果为真，就认为表达式的结果为真，这时不再检 查（y>5）条件了。
程序复杂性：费用、周期、错误
代码行度量法 Halstead软件科学法 结构度量 McCabe度量法
代码度量-代码行度量
代码度量-Halstead软件科学法
程序=运算符化+ 运算元结构度量 Halstead公式
N=N1+N2=n1log2(n1)+n2log2(n2)
N1=运算符出现的总次数 N2=运算元出现的总次数
内容进度
白盒测试
白盒测试的目的 白盒测试和黑盒测试的联系 白盒测试的策略
代码质量
代码度量 使用LogiScope度量代码质量 代码检查工具
白盒测试
又称透明盒测试、逻辑驱动测试 是测试被测单元内部如何工作的一种测试方法 允许测试人员根据程序内部逻辑结构及有关信息来设计和 选择测试用例，对程序的逻辑结构进行测试 可覆盖全部代码、分支、路径和条件等
静态分析报告、代码质量报告
白盒测试对测试人员的要求
了解软件语言 了解软件开发技术 有开发经验最好 掌握白盒测试工具 掌握白盒测试用例设计方法 掌握开发人员编程中容易出现的问题，不断积累经验
内容进度
白盒测试
白盒测试的目的 白盒测试和黑盒测试的联系 白盒测试的策略
代码质量
代码度量 使用LogiScope度量代码质量 代码检查工具
软件质量
软件质量
要求产品中没有BUG
常用指标
缺陷率（缺陷密度 ） 可靠性（运行n小时失效次数） 顾客满意度
软件质量反映的三个方面
软件需求 开发准则 隐含的需求
代码质量对软件质量的贡献
辅助方法－流程图
入口 a x>3 && z<10 画出模块的流程图 c 发现问题 辅助设计测试用例 e
b 语句块1
x==4 || y>5 d 语句块2 语句块3
出口
语句覆盖概念
语句覆盖就是设计若干个测试用例，运行被测试 程序，使得每一条可执行语句至少执行一次。
语句覆盖－设计用例
测试用例输入为： { x=4、y=5、z=5}
如何提高代码质量
培训
审查和监督
业务 工具和语言
技术
编码规范
测试
……..
编码规范和标准
坚持标准和规范的原因
可靠性 可读性/可维护性 移植性
代码审查单
代码审查单
代码审查单
输入/输出错误 数据声明错误 数据引用错误 计算错误 函数参数错误 比较错误 控制流程错误 其它检查
代码质量度量
代码是软件产品中的重要部分 代码质量反映软件质量 其它非代码因素也起着关键作用 文档（设计、帮助、用户手册等）
制约程序员编写高质量代码的因素
对需求和设计的理解不透彻 对软件业务流程不熟悉 没有开发经验 对开发工具或开发语言不熟悉 受情绪因素的影响等因素 其它非代码因素也起着关键作用
c
x==4 || y>5
d 语句块2 语句块3 出口 e
条件覆盖－设计用例
测试用例的输入为： { x=4、y=6、z=5} { x=2、y=5、z=5} { x=4、y=5、z=15}
程序执行的路径是：abd 程序执行的路径是：ace 程序执行的路径是：acd
入口 a x>3 && z<10 b 语句块1
代码度量-结构度量
扇入：调用一给定模块的模块计数； 扇出：给定模块所调用的模块计数； 使用扇入扇出来评价软件设计
具有大扇入和大扇出的模块可能是不良设计。这种模块可能未能正确分解 并需要重新设计。
McCabe度量法
辅助分析工具
对源代码进行分析经常需要辅助分析工具
PC-lint：代码规则走查工具
4和8
丢失了一条路径abe
路径测试
路径测试就是设计足够多的测试用例，覆盖被测试对象中 的所有可能路径。
测试用例
在上面的测试用例中修改一个测试用例则可对程序 进行了全部的路径覆盖。
测试用例 x=4、y=6、z=5 x=4、y=5、z=15 x=2、y=6、z=15 x=5、y=6、z=5 通过路径 abd acd ace abe 覆盖条件 T1、T2、T3、T4 T1、-T2、T3、-T4 -T1、-T2、-T3、-T4 T1、T2、-T3、-T4