软件工程第4章
软件工程第四章 结构化分析

软件需求分析阶段的工作,可以分成以下四个方面 :对问题的识别、分析与综合、制定规格说明以及 ( )。 A.总结 B.实践性报告 C.需求分析评审 D.以上答案都不正确
答案:C
需求验证应该从下述几个方面进行验证:(C ) A 可靠性、可用性、易用性、重用性 B可维护性、可移植性、可重用性、可测试性 C一致性、现实性、完整性、有效性 D 功能性、非功能性
3、需求分析步骤
1、需求获取
3、亲身实践:观察用户工作流程
优点: 1. 通过直接观察提取用户或系统的特性; 2. 有助于理解难以用语言描述清楚的复杂业务。 3. 更加准确和真实 缺点:
1. 观察可能使用户紧张,从而表现与往常不同。 2. 比较费时间
3、需求分析步骤
1、需求获取
3、需求分析步骤
3、需求分析步骤
3 需求描述
1. 又叫:需求规约
2. 是分析任务的最终产物,给出对目标软件的 各种需求。
3. 需求规约作为用户和开发者之间的一个协议 (需求规格说明书),在之后的软件工程各 个阶段发挥重要作用
软件需求分析阶段的目的是澄清用户的要求 ,并把双方共同的理解明确地表达成一份书 面文档——(软件需求规格说明书)。
经调查,系统分析员给出有问题的初略陈述, 其中部分描述如下:某商场的采购部门要求每 天开出定购清单,交采购员输入系统;仓库管 理员还要将库存信息此输入系统,经库存业务 (进贷或出贷)处理后输出。从这段描述可知 该部分数据流图中的外部项为:
A.采购员、仓库管理员 B.定购清单、库存业务 C.库存业务 D.定购清单、采购员 答案A
3、需求分析步骤
4、需求验证
1. 进行需求评审
2. 验证需求的一致性
3. 验证需求的现实性
软件工程 第4章 形式化说明技术

行为建模
1)
2)
3)
系统的需求规格说明通常是用自然语言来叙 述的,但是用自然语言描述往往会出现二义 性。 为了直观地分析系统的动作,从特定的视点 出发描述系统的行为,需要采用动态分析的 方法。 最常用的动态分析方法
有穷状态机
时序图 Petri网
状态迁移图
状态迁移图是通过描述系统的
状态及引起系统状态转换的事 件来表示系统的行为。
形式化方法
形式化方法是建立在严格数学基础上、具有精确数学语义 的开发方法,即就是用数学语言来描述软件的设计规约。 形式化方法可以分为形式化描述和建立在形式化描述基础之 上的形式化开发 形式化的描述:用形式化的语言(具有严格的语法语义定 义的语言)描述描述软件系统及其行为模式,以更好地刻 画软件系统的性质。 形式化的开发:用形式化的语言来描述软件需求和特征, 并且通过推理验证来保证最终的软件产品是否满足这些需 求和具备这些特征,符合给定的行为模式。
应用形式化方法的准则
应该选用适当的形式化方法:主要包括有限状态机、时 序图、Petri网、Z、VDM等。 应该形式化,但不要过分形式化 应该估算成本 应该有形式化方法顾问随时提供咨询 不应该放弃传统的开发方法 应该建立详尽的文档 不应该放弃质量标准 不应该盲目依赖形式化方法 应该测试、测试再测试 应该重用
半形式化方法
软件工程使用方法可分成:非形式化、半形式化和形式化 半形式化: 结构化分析(SA)方法 利用图形等半形式化的描述方式表达需求:用数据流图、 状态转换图或实体-联系图建立数据、行为和功能模型, 形成需求说明书中的主要部分。 利用结构化语言描述加工逻辑:结构化语言是介于自然 语言和形式语言之间的一种半形式语言。加工逻辑结构 可分成外层和内层两层:外层用来描述控制结构,采用 顺序、选择、重复三种基本结构;内层对于顺序执行和 循环执行的动作,用结构化语言描述。 缺点:可能存在矛盾、二义性、含糊性、不完整性及抽 象层次混乱等问题。
软件工程第4章 软件设计

5. 设计软件结构 通常程序中的一个模块完成一个适当的子功能。应 该把模块组织成良好的层次系统,顶层模块调用它 的下层模块以实现程序的完整功能,每个下层模块 再调用更下层的模块,从而完成程序的一个子功能, 最下层的模块完成最具体的功能。
6. 设计数据库 对于需要使用数据库的那些应用系统,软件工程师 应该在需求分析阶段所确定的系统数据需求的基础 上,进一步设计数据库。
高内聚也有两类:如果一个模块内的处理元素和同 一个功能密切相关,而且这些处理必须顺序执行 (通常一个处理元素的输出数据作为下一个处理元 素的输入数据),则称为顺序内聚。根据数据流图 划分模块时,通常得到顺序内聚的模块,这种模块 彼此间的连接往往比较简单。如果模块内所有处理 元素属于一个整体,完成一个单一的功能,则称为 功能内聚。功能内聚是最高程度的内聚。
(2) 用户手册根据总体设计阶段的结果,修改更正 在需求分析阶段产生的初步的用户手册。
(3) 测试计划包括测试策略,测试方案,预期的测 试结果,测试进度计划等等。 (4) 详细的实现计划 (5) 数据库设计结果
9. 审查和复审 最后应该对总体设计的结果进行严格的技术审查, 在技术审查通过之后再由使用部门的负责人从管理 角度进行复审。
为什么模块的独立性很重要呢?主要有两条理由: 第一,有效的模块化(即具有独立的模块)的软件比 较容易开发出来。这是由于能够分割功能而且接口 可以简化,便于多人分工合作开发同一个软件。
第二,独立的模块比较容易测试和维护。这是因为 相对说来,修改设计和程序需要的工作量比较小, 错误传播范围小,需要扩充功能时能够“插入”模块。
(2)详细设计。详细设计阶段的根本目标是确定 应该怎样具体地实现所要求的系统,也就是说,经 过这个阶段的设计工作,应该得出对目标系统的精 确描述,从而在编码阶段可以把这个描述直接翻译 成用某种程序设计语言书写的程序。 详细设计阶段的任务还不是具体地编写程序,而是 要设计出程序的“蓝图”,结果基本上决定了最终 的程序代码的质量。
软件工程 第四章 概要设计

第4章
4.4 模块的独立性
15
4.4.1 耦合性(Coupling)
5.外部耦合 一组模块都访问同一全局简单变量,而且不通过参数表传递该全局变量的信息,则称之为 外部耦合。 6.公共耦合
若一组模块都访问同一全局数据结构,则称之为公共耦合。公共数据环境可以是全局数据
4
4.2.1 概要设计的任务
概要设计的基本任务是: (1)设计软件系统结构; (2)数据结构及数据库设计; (3)编写概要设计文档;
(4)评审概要设计文档。
第4章
4.2 概要设计的任务与步骤
5
4.2.2 概要设计的步骤
概要设计的一般步骤如下: 1.选定体系结构 2.确定设计方案 3.设计软件结构
4.数据结构及数据库设计
(2)一个模块不通过正常入口而直接转入到另一个模块的内部;
(3)两个模块有一部分代码重叠(该部分代码具有一定的独立功能); (4)一个模块有多个入口。
第4章
4.4 模块的独立性
17
4.4.2 内聚性(Cohesion)
一个模块内各个元素彼此结合的紧密程度用内聚(或称聚合)来度量。一个理想的模块只
完成一个功能,模块设计的目标之一是尽可能高内聚。
第4章
4.4 模块的独立性
21
4.4.2 内聚性(Cohesion)
5.通信内聚
指模块内所有处理功能都通过公用数据而发生关系。即模块内各个组成部分都使用相同的 输入数据或产生相同的输出结果。
第4章
4.4 模块的独立性
22
4.4.2 内聚性(Cohesion)
软件工程第4章

4-5 试用Petri网说明第4题所述图书馆中一本书的循 环过程。在规格说明中应该包括操作H、C及R。
4-6 试用Z语言对第4题所述图书馆图书流通系统做一 个完整的规格说明。
•
生 活 中 的 辛 苦阻挠 不了我 对生活 的热爱 。20.12.2820.12.28Monday, December 28, 2020
第二条和第三条规则,分别对应于电梯即将下降 或者没有待处理的请求的情况。
4.2.3 评价
有穷状态机方法采用了一种简单的格式来描述规 格说明:
当前状态+事件+
这种形式的规格说明易于书写、易于验证,而且 可以比较容易地把它转变成设计或程序代码。
有穷状态机方法比数据流图技术更精确
4.3 Petri网
4.3.1 概念
所有按钮的集合,因此,Z规格说明开始于: 〔Button〕 2. 状态定义 一个Z规格说明由若干个“格(schema)”组成,每个 格含有变量说明和限定变量取值范围的谓词。例如, 格S的格式如图4.12所示。
图4.12 Z格S的格式
3. 初始状态 对于电梯问题来说,抽象的初始状态为:
ˆ Button_Init Button_State|pushed=Φ〕
第4章 形式化说明技术
4.1 概述 4.2 有穷状态机 4.3 Petri网 4.4 Z语言 4.5 小结 习题
按照形式化的程度,可以把软件工程使用的方 法划分成非形式化、半形式化和形式化3类:
• 用自然语言描述需求规格说明,是典型的非形式 化方法。
• 用数据流图或实体-联系图建立模型,是典型的 半形式化方法。
有穷状态机对本产品进行规格说明: 这个问题中有两个按钮集。
《软件工程》第4章软件总体设计

《软件工程》第4章软件总体设计软件总体设计是软件工程的一个重要环节,它涉及到软件系统的整体结构和架构的定义,以及软件模块之间的关系和接口的设计。
软件总体设计的目标是确保软件系统能够满足用户需求,并且具有高性能和可扩展性,同时保证系统的可维护性和可测试性。
软件总体设计的过程包括以下几个步骤:1.确定系统的功能需求:根据用户需求和系统分析的结果,定义系统应该具备的功能和特性。
2.划分系统结构:将系统划分为多个模块和子系统,确定各个模块之间的关系和层次结构。
3.定义模块接口:对每个模块定义清晰的接口,包括输入参数、输出参数和功能描述,以便模块之间的协作和集成。
4.设计系统架构:选择合适的架构风格和模式,确定系统的整体结构和组成,包括数据流、控制流和模块之间的通信。
5.设计数据结构和算法:根据系统需求和性能要求,设计合适的数据结构和算法,以满足系统的功能和性能要求。
6.设计系统界面:设计系统与用户和外部系统的界面,包括图形界面、命令行界面和数据交换接口。
7.考虑系统安全性和可靠性:在设计阶段考虑系统的安全性和可靠性需求,设计对应的安全和可靠性机制。
8.进行评审和验证:对软件总体设计进行评审和验证,确保设计的可行性和完整性。
软件总体设计的核心是系统架构设计,系统架构设计要考虑系统的功能需求、性能要求、可扩展性、可维护性、可测试性等因素。
常用的软件架构风格包括层次架构、客户端-服务器架构、分布式架构、面向服务的架构等。
选择合适的架构风格可以提高系统的灵活性和可维护性。
在软件总体设计过程中,还需要考虑到软件的适应性和可移植性。
软件应该能够适应不同平台和操作系统的要求,并能够方便地移植到其他环境中。
为了提高软件的可移植性,可以采用标准化的接口和协议,避免使用具体的硬件和操作系统依赖。
此外,软件总体设计还需要考虑到系统的可维护性和可测试性。
软件系统通常需要进行修改和维护,因此设计时需要考虑到系统的可扩展性和模块之间的解耦。
软件工程第4章习题解答

说明:1,每一笔交易有3种属性:“交易金额”、“每股售价”、“股数”。
2,“交易总额”有3种值;“每股售价”有3种值;“股数”有2种值。所以每笔交易有18种状态。(表有19列,第1列是说明列)
3,每种状态有一个决策公式。判定表中的决策方案有18行。
4,每个计算公式中只有一个变量“交易金额”,设为a。
教师的工资档案存储在行政办公室的磁带上,档案中有目前的年工资、赡养的人数、雇佣日期等信息。需要写一个计算程序计算并印出每名教师的原有工资和调整后的新工资。要求:
⑴画出此系统的数据流图;
⑵写出需求说明;
⑶设计上述的工资调整程序(要求用判断表描述),设计时请分别采用下述两种算法,并比较这两种算法的优缺点;
set START to (I+1)
else if TABLE(I) > ITEM then
set FINISH to (I-1)
endif
enddo
if TABLE(I) = ITEM or TABLE(START) = ITEM or TABLE(FINISH) = ITEM then
set FLAG to 1
解:
⑴ 系统的数据流图
⑵ 需求说明:(略)
⑶ 程序框图:
算法说明:1 此算法是先找出工资少于$26,000的人, 再进行工资调整,属算法a
2 算法a适于数据库的记录不太多的情况,在数据库中查找较费时。
但是,调整系统的主要部分少一个判断,结构清晰一些。
3 算法b适于数据库的记录较多的情况,利用数据库的排序功能可很快地将教师的档案数据按工资大小排好序,调整程序只对前若干个记录进行操作。这个算法对于修改数据库回更便捷些。
交易
软件工程导论第四章 概要设计

模式4:共享数据模式
共享数据系统以一个或多个数据库 / 数据仓库为中心进行 组织,其它部件可以从中读写存储的数据。共享数据系统还 提供并发访问、容错处理、访问权限控制等功能。 典型的共享数据系统包括: a. 数据库 b. 知识库 c. 源代码控制程序
模式5:信息系统模式
现代信息系统平台模式,主要考虑B/S模式。 B/S模式的三层:表示层(presentation),业务 层(business),和数据存储层(data access) 。 B/S模式的优点: a. 架构简化了客户端。它无需象C/S模式那样在 不同的客户机上安装不同的客户应用程序,而只需安 装通用的浏览器软件。 b. 简化了系统的开发和维护。 c. 使用户的操作变得更简单。 d. 特别适用于网上信息发布 。
第四章 概要设计
•4.1软件体系结构 •4.2概要设计任务与步骤 •4.3软件设计的基本概念 •4.4面向数据流的设计方法 •4.5面向数据结构的分析设计方法 •4.6概要设计文档评审
概要设计
一是要覆盖《需求规格说明书》的全部内容, 二是要作为指导详细设计的依据。
概要设计注重于宏观上和框架上的设计,它是软 件系统的总体结构设计、全局数据库(包括数据结 构)设计、外部接口设计、功能部件分配设计、部 件之间的接口设计。 概要设计又称为架构设计。 • 用于描述系统最顶的结构和组织形式,标识出软 件的各个组成部分。
2.子系统和模块的区别 (1)一个子系统独立一个构成系统,不依赖 于其他子系统提供的服务。 (2)一个模块通常是一个能提供一个或多个 服务的系统组件。 3.体系结构设计的结果 体系结构设计过程的结果是一个体系结构 的设计文档。
4.1软件体系结构 4.1.1概述
4.体系结构模型 (1)静态结构模型 将子系统或组件作为一个个独立的单元来开发 (2)动态过程模型 给出系统在运行时的过程组成。它与静态模型不 同。 (3)接口模型 定义每个子系统从他们的公共接口能得到的服务。 (4)关系模型 关系模型给出子系统间的数据流的关系。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
《实用软件工程》陆惠恩主编
19
图4.8 求平均值过程的流图
V(G)=17(边数)-13(结点数)+2=6 V(G)=5(判定结点数)+1=6 V(G)=6(有向环数)
路径1:1-2-10-11-13; 路径2:1-2-10-12-13; 路径3:1-2-3-10-11-13; 路径4:1-2-3-4-5-8-9-2.... 路径5:1-2-3-4-5-6-8-9-2.... 路径6:1-2-3-4-5-6-7-8-9-2.... 4.设计可强制执行基本集合中每 条路径的测试用例
第4章 软件编码和软件测试
本章内容: l 结构化程序设计 程序设计语言的选择 程序设计风格 l 软件测试目标 l 软件测试方法 l 软件测试步骤 l 软件设计测试方案 l 软件测试原则和测试策略 l 软件调试、验证与确认 l 软件测试文档 重点: l 程序设计风格 l 设计软件测试方案
回目录
《实用软件工程》陆惠恩主编
《实用软件工程》陆惠恩主编
7
4.5 设计测试方案
测试方案包括三个内容: 要测试的功能 输入的数据 对应的预期输出结果
《实用软件工程》陆惠恩主编
8
4.5.1 等价类划分法 4.5.2 边界值分析法 4.5.3 错误推测法 4.5.4 逻辑覆盖法 1. 语句覆盖 2. 判定覆盖 3. 条件覆盖 4. 判定/条件覆盖 5. 条件组合覆盖 6. 点覆盖 7. 边覆盖 8 . 路径覆盖
《实用软件工程》陆惠恩主编
17
例4.3的因果图
例4.3的判定表
《实用软件工程》陆惠恩主编
18
4.5.7 用基本路径覆盖法设计测试用例
1: i=1; total.input=total.valid=0; sum=0; 2:DO WHILE value〔i〕<>-999 3:AND total.input<100 4:increment total.input by 1; 5:IF value〔i〕>=minimum 6:AND value〔i〕<=maximum 7:THEN increment totalvalid by 1; sum=sum+value〔i〕; 8:ENDIF increment i by 1; 9:ENDDO 10:IF totalvalid>0 11:THEN average=sum/totalvalid; 12:ELSE average=-999; 13:ENDIF
《实用软件工程》陆惠恩主编
15
3. 因果图约束符号
《实用软件工程》陆惠恩主编
16
【例4.3】用因果图法设计测试用例
某规格说明规定: 输入的第一列字符必须是A或B, 第二列字符必须是一个数字。 第一、二列都满足条件时执行操作H; 如果第一列字符不正确,则给出信息L; 如果第二列字符不正确,则给出信息R。 根据上述要求画出因果图,并设计测试用例。
《实用软件工程》陆惠恩主编
20
4.6 软件测试原则和策略 4.6.1软件测试原则 4.6.2.实用测试策略
用等价类划分法设计测试方案。 (2) 使用边界值分析方法,既测试输入数据的边界情况又包括输出 数据的边界情况。 (3) 如果含有输入条件的组合情况,覆盖法检查现有测试方案,若没有达到逻辑覆盖标准, 再补充一些测试用例。
(1)
《实用软件工程》陆惠恩主编
21
4.7 软件调试、验证与确认
4.7.1 软件调试 软件调试也称纠错。 首先进行软件测试,第二步是纠错 4.7.2 程序正确性验证(软件验证) 是确定软件开发周期中的一个给定阶段的产品是否达到需求 的过程。 4.7.3 软件确认 软件确认的方法: 1.系统功能和性能满足需求说明书中的全部要求,得到用户 认可。 2.完成测试计划中的所有要求,并书写测试分析报告和开发 总结。 3.按用户手册和操作手册进行软件实际运行。
《实用软件工程》陆惠恩主编
2
4.1.1 程序设计语言的选择
1. 程序设计语言的分类 (1)面向机器语言:机器语言和汇编语言。 (2)高级程序设计语言 2. 高级语言选用的实用标准 (1)项目的应用领域 (2)软件开发环境 (3)根据系统用户的要求来选择 (4)软件开发人员的知识
《实用软件工程》陆惠恩主编
3
4.1.2 程序设计风格
源程序文档编写规则 1.源程序文档编写时,其标识符名称、注解和 程序布局等要合理。 2. 数据说明 3. 语句构造要简单直接 4. 输入输出语句 5. 程序效率
程序设计主要应考虑的是程序的正确性、
可理解性、可测试性和可维护性。
《实用软件工程》陆惠恩主编
4
4.2 软件测试目标
《实用软件工程》陆惠恩主编
12
程序流程图
《实用软件工程》陆惠恩主编
13
程序图
《实用软件工程》陆惠恩主编
14
计算程序的环行复杂度:
图中有4个线性无关的有向环:R1、R2、R3、R4。 在图4.4(b)中,实线弧数为14,节点数为12。因此, 环行复杂度为 V(G)=14-12+2=4 图4.4(b)中,判定结点的个数为3,3+1=4。 三种计算方法的结果相同。
1
4.1 结构化程序设计
结构化程序设计(Structured Programming ,SP) 仅采用顺序、选择、重复三种基本控制结构; 每种基本结构只有一个入口、一个出口; 将这三种基本控制结构根据程序的逻辑,嵌套或组合成结构 化程序,完成预定的功能。 结构化程序设计的特点 源程序有清晰性,并能较好地适合自顶向下或自底向上的程 序设计技术。 在详细设计阶段,使系统结构具有模块化和清晰性的特性。 在软件编码阶段,使软件易于理解、修改,便于重复使用。
1、软件测试是为了发现程序中的错误而执行程序的过程; 2、好的测试方案能够发现尚未发现的错误; 3、成功的测试是发现了尚未发现的错误的测试。 软件测试的目的是通过人工或计算机执行程序来有意识地发 现程序中的设计错误和编码错误。
《实用软件工程》陆惠恩主编
5
4.3.1 静态分析与动态测试 1. 静态分析 2. 动态测试:以执行程序并分析程序来查错。 为了进行软件测试,需要预先准备好两种数据: ①输入数据; ②预期的输出结果。 我们把以发现错误为目标的用于软件测试的输入数据及与之对应的预期 输出结果叫测试用例。 4.3.2 黑盒法与白盒法 1. 黑盒法 (Black.Box Testing) 又称功能测试,其测试用例完全是根据程序的功能说明 来设计的。 2. 白盒法 (White Box Testing) 又称结构测试,其测试用例是根据程序内部的逻辑结构 和执行路径来设计的。 • 常把黑盒法和白盒法联合起来进行,这也称为灰盒法。
《实用软件工程》陆惠恩主编
22
4.8 软件测试文档
1.软件测试计划 2.测试说明文件 测试设计说明 测试用例说明 测试规程说明 3.软件测试分析报告
《实用软件工程》陆惠恩主编
23
第4章小结
优先选用高级程序设计语言。 结构化程序设计将顺序、选择、重复三种基本控制结构进行组合和嵌套。 软件设计风格直接影响软件的质量,软件的可维护性和可移植性。 软件编码阶段应进行静态分析和模块测试。 软件测试是由人工或计算机,执行或评价系统过程,验证是否满足需求。 测试的根本任务是发现软件中的错误。 测试的早期用白盒法,后期用黑盒法。 设计测试方案要选用尽可能少的高效测试数据,尽可能多地发现错误。 1.边界值分析方法,包括输入数据和输出数据的边界情况。 2.用等价类划分法补充测试方案。 3.必要时用错误推断法补充测试方案。 4.用逻辑覆盖法检查测试方案。 软件调试是查找、分析和纠正程序中错误的过程。 调试不仅修改软件产品还应改进软件过程,避免今后出现错误。 测试和调试常常交替进行。 软件确认是在软件开发过程结束时,对软件进行评价,确定是否和软件需 求相一致的过程 。
回第4章首 返回目录
《实用软件工程》陆惠恩主编
24
《实用软件工程》陆惠恩主编
9
【例4.2】按不同逻辑覆盖法设计测试数据
测试数据的条件组合及对应的执行路径
《实用软件工程》陆惠恩主编
10
4.5.6 因果图法•
1. 因果图法测试用例设计步骤 2. 因果图法基本符号
《实用软件工程》陆惠恩主编
11
4.5.5 程序结构复杂程度的度量
McCabe方法首先画出程序图,然后计算程序的环行复杂度。 程序环行复杂度的计算方法有三种: 1、 强连通图中线性无关有向环的个数。 2、 V(G)=m-n+2 其中,m是程序图G中的弧数,n是有向图G中的节点数。 3、 如果P是流图中判定结点的个数,V(G)=P+1。 【例4.2】计算程序环行复杂度。 现有对计算机应用能力考试成绩进行统计的程序。连续输入考试成绩, 最后以输入0分或负分为结束。规定成绩在60分以下的不及格、 60分以上的及格、80分以上的属于优秀。该程序统计并分别输出 成绩不及格、及格、优秀的人数及总人数。算出此程序的环行复 杂度。
4.3 软件测试方法
《实用软件工程》陆惠恩主编
6
4.4 软件测试步骤
4.4.1 模块测试 也称单元测试,其目的是检查每个模块是否能独立、正确地运行。 模块测试通常在程序设计时进行。 驱动程序代替主程序,用来测试子程序。 存根程序也称“虚拟子程序”,测试主模块。 4.4.2 集成测试 子系统的组装称为集成化。 集成测试分为子系统测试和系统测试两种。 渐 • 增式测试、非渐增式测试 1、自顶向下集成 2、自底向上集成 4.4.3 程序审查会和人工运行 4.4.4 确认测试 1. 确认测试必须有用户积极参与,或以用户为主进行。 2. 软件配置复审 3. Alpha测试和Beta测试 4.4.5 平行运行