毛明志老师软件工程期末总结 - 内容填充版(over) - 图文

第一章： 1.1

补充一下1.1

计算机软件：指计算机系统中的程序及其文档。程序是计算任务的处理对象和处理规则的描述。

1.1.2

软件的特点：

1 软件是一种逻辑实体，开发成本和进度难以准确估算；

2 软件是被开发或被设计的，没有明显的制造过程，一旦开发成功，只需复制，但维护的工作量大

3 软件使用没有硬件的机械磨损和老化问题，但使用过程有维护问题，维护修改程序的时候可能引入副作用，使故障率升高。

1.1.3

软件的分类

1 系统软件：操作系统、编译程序等

2 支撑软件：数据库管理系统、网络软件等 3 应用软甲：各类特定应用程序 1.2 1.2.1

软件工程定义

IEEE：软件工程是：

①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；

②在①中所述方法的研究。

1.2.2

软件工程框架：概括为目标、过程和原则

目标：生产具有正确性，可用性和开销合宜的产品。

过程：生产一个最终满足需求且达到工程目标的软件产品所需要的步骤。 原则：

① 选取适宜的开发模型 ② 采用合适的设计方法 ③ 提供高质量的工程支撑 ④ 重视软件工程的管理 1.2.3

软件生存周期：六阶段

① 计算机系统工程：确定软件开发的要求和范围，估算成本，安排进度，可行性分析。

② 需求分析：要“做什么”，确定软件功能、性能、数据、界面等要求，生成软件需求规约。

③ 设计：要“怎么做”，分为系统(总体)设计和详细设计。

前者设计软件系统的体系结构，包括软件系统的组成部分，各成分的功能和接口，成分间的连接和通信，同时设计全局数据结构；

后者设计各个组成成分的实现细节，包括局部数据和算法

④ 编码：用某种程序设计语言，将设计结果转换为可执行代码。

⑤ 测试：任务是发现并纠正软件中的错误和缺陷。主要包括单元测试、集成测试、确认测试和系统测试。

⑥ 运行和维护：软件测试完成即可交付使用。在软件运行期间，需对投入运行的软件进行维护，即当发现软件中潜藏错误或需要增加功能或适应新外部环境变化等，对软件进行修改。 1.3 1.3.1 了解

ISO/IEC 12207软件工程生存周期过程

该标准把软件生存周期中可以开展的活动分为5个基本过程，8个支持过程和4个组织过程。每一个过程划分为一组活动，每项活动又进一步划分为一组任务。

（内容坑爹，无视，P9~P12约3页的表格，有兴趣的自己看 （话说了解比知道要轻..现在我这么觉得 1.3.2

能力成熟度模型CMM 5级：

初始级：无秩序或混乱，成功依赖个人或小组的努力

可重复级：建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目的成功。

已定义级：以将管理和工程活动两方面的软件过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。

已管理级：收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制。

优化级：过程的量化反馈和先进的新思想、新技术促使过程不断改进 CMM的结构 P14 有兴趣的..

1.3.3 知道

能力成熟度模型集成 CMMI 两种表示法：

① 阶段式模型：同CMM，关注组织成熟度，5级

初始的、已管理的、已定义的、定量管理的、优化的。 ② 连续式模型：关注每个过程域的能力，分为6级： CL0：未完成的：未执行或未达到CL1定义的所有目标

CL1：已执行的：共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。

CL2：已管理的：共性目标集中于已管理的过程的制度化。 CL3：已定义级的：共性目标集中于以定义过程的制度化。

CL4：定量管理的：共性目标集中于可定量管理的过程的制度化。

CL5：优化的使用量化（统计学）手段改变和优化过程域，以对付客户要求的该百年和持续改进计划中的过程域的功效。 1.4 常见模型的种类，特点，优缺点，不同模型间对比

瀑布模型：一路向下，可倒流回到上一级，7级

系统工程->需求分析与规约->设计与规约->编码与单元测试-> 集成测试系统测试->运行与维护

演化模型：先做原型给用户，根据使用意见逐步改造，最终得到令客户满意的产品。典型的模型有：增量模型、原型模型、螺旋模型（..居然这模型和后面这三种在同一级的标题

增量模型：将开发过程分成若干个日程时间交错的线性序列，每个线性序列都产生软件的一个可发布“增量版本”。（越看越像流水线

原型模型：快速计划->快速设计方式建模->构建原型->部署交付和反馈->交流->快速计划??不断循环。根据原型目的不同可分为：探索型、实验型、演化型。使用策略分为废弃策略、追加策略。

螺旋模型：制定计划->风险分析->工程实施->客户评估 不断循环。风险太大则可能终止

喷泉模型：支持面向对象开发的过程模型，开发各个活动没有明显边界，各个活动经常重复、迭代地进行。“喷泉”体现了面向对象方法的迭代和无间隙特性。六个活动：

演化，集成，测试，编码，设计，分析

1.5 敏捷软件开发基本概念，XP开发特点

敏捷软件开发概念：

书上没有，自由发挥。

简单而言就是软件工程用了，质量提高了，但工作量太大以至于难以准时交付，于是快节奏开发软件的需求就来了，方法也出来了，这些方法就是敏捷软件开发。 敏捷软件开发价值观：

① 个人和交互高于过程和工具 ② 可运行软件高于详尽的文档 ③ 与客户协作高于合同(契约)谈判 ④ 对变更及时作出反应高于遵循计划

敏捷软件开发原则：12条 P27 有兴趣的话..

XP:extreme programming极限编程。四个价值观：交流，简单，反馈，勇气（追加第5个 谦虚）。

XP适用于软件需求模糊且挥发性（今天要求明天可能就不需要了）强，开发团队人数在10人以下，开发地点集中的场合。 （这是特点么..?

XP方法的12个核心实践 P29-30 怎么都是这种.. 1. 完整的团队 2. 计划对策 3. 系统比喻 4. 小发布 5. 测试

6. 简单设计 7. 结对编程 8. 设计改进 9. 持续集成 10. 代码全体共享 11. 编码标准 12. 可持续步调

第二章 2.1

计算机系统的概念，内容

基于计算机的系统：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程。

软件：计算机程序、数据结构和相关的工作产品，以实现所需要的逻辑方法、规程和控制；

硬件：指提供计算能力的电子设备、支持数据流的互连设备、提供外部世界功能的电子机械设备（传感器，马达等）。

人员：硬件和软件的用户和操作者。

数据库：通过软件访问并持久存储的大型的有组织的信息集合。 文档：描绘系统使用或操作的描述性信息。

规程：指定义每个系统元素的特定使用或系统所处的过程性语境的步骤。 一个基于计算机的系统可以是另一个更大的基于计算机的系统的一个宏元素（组成部分）。 2.3

可行性分析的概念，分类 可行性分析：

一个基于计算机的系统通常受到资源和时间上的限制，可行性分析主要从经济、技术、法律等方面分析给出的解决方案是否可行，能否在规定的资源和时间约束下完成。

可行性分析分类：

① 经济可行性：从成本、效益、货币的时间价值（通常可用年利率来表示）、投资回收期、纯收入来分析。

② 技术可行性：分为风险分析、资源分析、技术分析。 ③ 法律可行性。 第三章 需求工程的角色及其各个阶段 //好吧，其实就是全部

3.1 概述

需求工程是应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题，评估可行性，协商合理的解决方案、无歧义地规约方案、确认规约以及将规约转换到可运行的系统时的管理要求，需求工程通过合适的工具和符号系统地描述开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

分为6阶段：

① 需求获取：通过与用户交流，对已有系统的观察及对任务的分析，确定系统或产品范围等。

② 需求分析与协商：对需求进行分类组织，分析每个需求与其他需求的关系以检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求排序。

③ 系统建模：通过合适的工具和符号地描述需求。分析和建模方法有：面向数据流方法、面向数据结构方法和面向对象方法。

④ 需求规约：需求规约是分析任务的最终产品，建立完整的信息描述、详细功能

和行为描述、性能需求和设计约束说明、合适的验收标准，给出对目标软件的各种需求。

⑤ 需求验证：对功能的正确性、完整性和清晰性以及其他需求给予评价。 ⑥ 需求管理：对需求工程所有相关活动的规划和控制。 3.2 需求获取 3.2.1 软件需求

① 功能需求：系统要做什么，在何时做，在何时及如何修改或升级 ② 性能需求：软件开发的技术性指标 ③ 用户或人的因素：用户类型

④ 环境需求：软件应用的环境，包括硬件和软件。

⑤ 界面需求：考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定，对数据存储介质的规定。

⑥ 文档需求：需要什么文档，针对哪些读者

⑦ 数据需求：考虑输入、输出数据的格式，接受、发送数据的频率，数据的准确性和精度，数据流量，数据需保持的时间。

⑧ 资源使用需求：考虑软件运行时所需要的数据、其他软件、内存空间等资源；软件开发、维护所需人力、支撑软件、开发设备等。

⑨ 安全保密要求。 ⑩ 可靠性需求

①①软件成本消耗与开发进度需求 ①②其他非功能性要求。 3.2.2 需求获取方法与策略

① 建立顺畅的通信途径 ② 访谈与调查

③ 观察用户操作路程 ④ 组成联合小组 ⑤ 用况

3.3 需求分析、协商与建模

3.3.1 需求分析原则

·必须能够表示和理解问题的信息域 ·必须能够定义软件将完成的功能

·必须能够表示软件的行为（作为外部事件的结果）

·必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节。 ·分析过程应该从要素信息移向细节信息。

3.3.2 信息域 信息域包括： 信息内容：表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。 信息流：表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息（数据或控制），然后进一步被变换为输出。

信息结构：表示了各种数据和控制项的内部组织形式，比如数据或控制项将被组织为n维表还是树形结构..?等

3.3.3 抽象、分解与多视点分析

问题抽象方法要求分析人员在分析过程中捕捉用户描述或问题本身固有的一般-特

殊关系，首先关注一般问题的解决途径，进而指导特殊问题的解决方法。

问题分解的目的是要能以层次化的方式对问题进行分解和不断细化。

分析人员在整理用户描述的过程中应注意用户视角上的变化，避免由于视角不全引起的需求遗缺。

3.3.4 需求协商

复杂的系统又许多项目相关人员，他们之间的需求必定会出现冲突，协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案。

通常会议是解决冲突最快的方式。冲突解决会议应当只关注与冲突相关的需求问题。

通常会议分为3个阶段：叙述阶段、讨论阶段和决策阶段。

3.3.5 需求建模

在需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做。目标软件的需求模型不应涉及软甲你的实现细节。

常用的分析方法有以下几种：

面向数据流的结构化分析方法（SA） 面向数据结构的分析方法 面向对象的分析方法（OOA）

3.4 需求规约与验证

3.4.1 需求规约的原则 ① 从现实中分离功能

② 使用面向处理的规约语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应。

③ 如果被开发软件知识一个基于计算机的系统中的一个元素，那么整个大系统也应包括在规格说明的描述中

④ 规约必须包括系统运行环境。

⑤ 规约必须是一个认识模型，而不是设计或实现的模型。

⑥ 规约必修是可操作的，利用它能够通过测试用例判断已提出的解决方案是否都能满足规约。

⑦ 规约必须允许不完备性并允许扩充。 ⑧ 规约必须局部化和松散耦合。

3.4.2 需求规约

软件需求规约的框架 IEEE/ANSI 830-1993标准： 1 引言

2 信息描述 3 功能描述 4 行为描述 5 检验标准 6 参考书目 7 附录

3.4.3 需求验证

需求验证的目的是要检验需求是否能够反映用户的意愿。 评审人员评审时往往需要检查以下内容： ① 系统定义的目标是否与用户的要求一致

② 系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求。

③ 被开发项目的数据流与数据结构是否确定且充足。

④ 主要功能是否已包括在规定的软件范围之内，是否都已充分说明 ⑤ 设计的约束条件或限制条件是否符合实际。 ⑥ 开发的技术风险是什么。

⑦ 是否制定了详细的检验标准，它们能否对系统定义进行确认。

3.5 需求管理

需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动。

在需求管理中，每个需求被赋予唯一的标识符，一旦标识出需求，就可以为需求建立跟踪表，每个跟踪表标识需求和其他需求或设计文档、代码、测试用例的不同版本间的关系。

需求跟踪有两种方式：正向跟踪以用户需求为切入点，检查《需求规约》中的每个需求是否能在后继工作中找到对应点；逆向跟踪检查设计文档、代码、测试用例等工作产品是否都能在《需求规约》中找到出处。

第四章

4.1 软件设计工程概述

软件设计是把软件需求变换成软件表示的过程，主要包含两个阶段：软件体系结构(概要)设计阶段和部件级设计阶段。

软件体系结构设计：将软件需求转化为数据结构和软件的系统结构。

部件级设计：将软件体系结构中的结构性元素转化为软件部件的过程性描述，得到软件详细的数据结构与算法。

4.1.1 软件设计的任务

软件设计的输入的软件分析模型。使用一种设计方法，软件分析模型中通过数据、功能和行为模型所展示的软件需求的信息被传送给设计阶段，产生数据/类设计、体系结构设计、接口设计、部件级设计。

① 数据/类设计：将分析类模型变换成类的实现和软件实现所需要的数据结构。 ② 体系结构设计：定义了软件的整体结构，由软件部件、外部可见的属性和它们之间的关系组成。

③ 接口设计：描述了软件内部、软件和协作系统之间以及软件同人之间的通信方式。

主要包括3方面内容：设计软件模块间的接口，设计模块与其他非人的信息生产者和消费者之间的外部接口以及设计人与计算机间的人机接口。

④ 部件级设计：将软件体系结构的结构性元素变换为对软件部件的过程性描述。

4.1.2 软件设计的目标

① 设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式

需求。

② 设计必须是可读，可理解的，使得将来易于编程、易于测试、易于维护。 ③ 设计应从实现角度出发，给出与数据、功能、行为相关的软件全貌。

为达到目标所建立的设计的技术标准：

① 设计出来的结构应是分层结构，从而建立软件成分之间的控制。

② 设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的部件。 ③ 设计应该既包含数据抽象，也包含过程抽象。 ④ 设计应当建立具有独立功能特征的模块。

⑤ 设计应当建立能够降低模块与外部环境之间复杂连接的接口。

⑥ 设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。

4.1.3 软件设计的过程

软件设计是一个把软件需求编程软件表示的过程，通常软件设计过程分为6个步骤： ① 制定规范

② 体系结构与接口设计 ③ 数据/类设计

④ 部件级（过程）设计 ⑤ 编写设计文档 ⑥ 设计评审 4.2 软件设计原则

在将软件的需求规约转换为软件设计的过程中，软件的设计人员通常采用抽象与逐步求精、模块化和信息隐藏等原则。

4.2.1 抽象与逐步求精

① 抽象：将注意力集中在某一层次上考虑问题，忽略低层次的细节。软件工程的每一步都是对较高一级抽象的解作一次具体化的描述。

软件设计的主要抽象手段有：

过程抽象：任何一个完成明确定义功能的操作都可被使用者当做单个实体看待，尽管这个操作实际上是由一系列更低级的操作完成的（类似函数的概念

数据抽象：指定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察数据（类似类的概念。 ② 逐步求精：把问题的求解过程分解成若干步骤或阶段，每一步都比上一步更精化，更接近问题的解法。

抽象和逐步求精是一对互补的该你那，抽象使设计者能够描述过程和数据而忽略底层的细节，而求精有助于设计者在设计过程中揭示底层的细节。

4.2.2 模块化

模块化，即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件。模块化实际上是系统分解和抽象的过程。

在软件工程中，模块是数据说明、可执行语句等程序对象的集合，是单独命名的，并且是可以通过名字来访问的。例如，对象类、构件、过程、函数、子程序、宏等都可以作为模块。

模块具有名字、参数、功能等外部特征以及完成模块功能的程序代码和模块内部数

据等内部特征。

假设C(x)是描述问题x复杂性的函数，E(x)是解决问题x所需工作量（按时间算）的函数，则有：

①若C(p1)>C(p2) 则 E(p1)>E(p2) ②C(p1+p2)>C(p1)+C(p2) 由①、②可推出

③E(p1+p2)>E(p1)+E(p2)

但虽然有③式存在，模块划分并非越多越好，因为还存在着将模块联接起来的工作量。

4.2.3 信息隐藏

每个模块的实现细节对于其他模块来说应该是隐蔽的，即模块中包含的信息（包括数据和过程）不允许其他不需要这些信息的模块使用。

4.2.4 模块独立

所谓的模块独立指：模块完成独立的功能并且与其他模块的接口简单，符合信息隐蔽，模块间关联和依赖程度尽可能小。模块独立性是模块化、信息隐藏和局部化等概念的直接结果。

模块的独立性很重要，体现在：

① 功能被划分，并且接口被简化，所以具有有效模块化的软件更易于开发。 ② 由于因设计和编码修改引起的副作用受到局限，错误传播被减少，并且模块复用成为可能，所以独立的模块更易于测试和维护。

模块的独立性可以由两项指标来衡量：内聚度和耦合度。

内聚度：衡量同一个模块内部的各个元素彼此结合的紧密程度。 耦合度：衡量不同模块彼此间相互依赖的紧密程度。

4.2.4.1 内聚 一般模块内聚性分为7种类型，由低到高分别是：

① 巧合内聚：将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块。

② 逻辑内聚：完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制型参数来确定该模块应执行哪一种功能。

③ 时间内聚：一个模块中的所有任务必须在同一时间段内执行，例如初始化模块和终止模块。

④ 过程内聚：一个模块完成多个任务，这些任务必须按指定的过程执行。 ⑤ 通信内聚：一个模块内所有处理元素都集中在某个数据结构的一块区域中。 ⑥ 顺序内聚：一个模块完成多个功能，这些功能又必须顺序执行。

⑦ 功能内聚：一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割。

4.2.4.2 耦合

一般模块之间的可能的耦合方式有7种，由高到低分别是：

① 内容耦合：一个模块直接访问另一个模块的内部数据；或一个模块不通过正常入口转到另一模块内部；或两个模块有一部分代码重叠；或一个模块有多个入

口。

② 公共耦合：一组模块都访问同一个公共数据环境。公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

③ 外部耦合：模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时。

④ 控制耦合：一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用于控制接受模块中的执行逻辑。

⑤ 标记耦合：两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的子结构）。

⑥ 数据耦合：两个模块之间仅通过参数表传递简单数据。

⑦ 非直接耦合：两个模块之间没有直接关系，即它们中的任何一个都不依赖于另一个而能够独立工作。

强耦合->低内聚 强内聚->低耦合

耦合和内聚都是模块独立性的定性标准，都反映了模块独立性的良好程度，但耦合是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量。 4.3 软件体系结构设计

4.3.2 软件体系结构的风格 一些软件体系结构风格：

① 数据为中心的体系结构：一些数据保存在整个结构中心，并且被其他部件频繁地使用、添加、删除、修改。

② 数据流风格的体系结构：适用于输入数据被一系列的计算或者处理部件变换成输出数据。由管道和过滤器组成，过滤器之间由传送数据的管道联通。

③ 调用和返回风格的体系结构：包含主程序/子程序风格体系结构和远程过程调用风格的体系结构。前者把功能分解成控制层次，顶层调用下层，下层调用下下层，最下层完成最具体的功能；后者是前者的扩展，这种结构中被主程序调用的部件分布在网络上不同的计算机中。

④ 面向对象风格的体系结构系统部件封装数据和操作数据的方法，部件之间的交互和协调通过消息来传递。

⑤ 层次式风格的体系结构：圆环套圆环，最外面层部件向用户提供接口操作，最内层部件使用系统接口，每个中间层都是对内层接口的封装。 4.4 部件级设计技术

在部件设计阶段，主要完成如下工作： ① 为每个部件确定采用的算法，选择某种适当的工具表达算法的过程，编写部件的详细过程性描述。

② 确定每一部件内部使用的数据结构。

③ 在部件级设计结束时，应该把上述结果写入部件级设计说明书，并通过复审形成正式文档，作为下一阶段（编码阶段）的工作依据。

4.4.1 结构化程序设计方法

如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。

结构化程序设计方法能提高程序的可读性、可维护性和可验证性，从而提高软件的

生产率。

4.4.2 图形表示法

4.4.2.1 程序流程图

入口出口：圆角矩形 顺序语句：矩形 条件分支：菱形

只允许5种基本控制结构：顺序型，选择型、先判定型循环、后判定型循环、多情况选择型，如下所示：

4.4.2.2 N-S图 懒的画了

4.4.2.3 PAD

PAD = problem analysis diagram

4.4.3 判定表

简单而言就是列出所有条件可能组合以及对应的操作。

4.4.4 设计性语言PDL

某种伪代码，关键字一律大写，其他单词一律小写。

PROCEDURE spellcheck IS 查找错拼的单词 BEGIN

split document into single words 把整个文档分离成单词 lood up words in dictionary 在字典中查这些单词 display words which are not in dictionary 显示字典中查不到的单词 create a new dictionary 造一新字典 END spellcheck

P85课后题，第2,4,5,8题 以下问题答案不保证正确性

4.2 软件设计和软件质量的关系是怎么样的

答：在进行软件设计的过程中，我们要密切关注软件的质量因素。 同时软件质量也很大程度依赖于软件设计。

4.4 简述模块、模块化及模块化设计的概念 答：

模块是数据说明、可执行语句等程序对象的集合，它是单独命名的，并且可以通过名字来访问 。

模块化，即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件，实际上是系统分解和抽象的过程。

模块化设计，即利用模块化的思想进行软件设计。

4.5 举例说明每种类型的模块契合度和每种类型的模块内聚度，作业

4.8 什么是模块的独立性？设计中为什么模块要独立？如何度量独立性？模块功能独立有何优点？ 答：

所谓的模块独立指：模块完成独立的功能并且与其他模块的接口简单，符合信息隐蔽，模块间关联和依赖程度尽可能小。模块独立性是模块化、信息隐藏和局部化等概念的直接结果。

模块的独立性很重要，体现在：

① 功能被划分，并且接口被简化，所以具有有效模块化的软件更易于开发。 ② 由于因设计和编码修改引起的副作用受到局限，错误传播被减少，并且模块复用成为可能，所以独立的模块更易于测试和维护。

模块的独立性可以由两项指标来衡量：内聚度和耦合度。

第五章 结构化分析与设计//重点。 /*极度混乱，MMZ想到什么说什么，不保证全都记下了，因为有些说得很含糊*/

数据流的分析方法，数据字典，数据流图，UML，UML视图，面向对象的设计步骤 /*个人整理如下，实在太混乱，而且感觉他没讲全，仅供参考*/ 5.1 结构化方法概述

一种面向数据流的传统软件开发方法

以数据流为中心构建软件的分析模型和设计模型 分为：

结构化分析(Structured Analysis 简称SA) 结构化设计(Structuresd Design 简称SD)

结构化程序设计(Structured Programmin 简称SP) 5.1.1 抽象和分解

抽象：在每个抽象层次上忽略问题的内部复杂性，只关注整个问题与外界的联系

分解：将问题不断分解为较小的问题，直到每个最底层的问题都足够简单为止 5.1.2 结构化分析过程

① 理解当前的现实环境，获得当前系统的具体模型(物理模型) ② 从当前系统的具体模型抽象出当前系统的逻辑模型

③ 分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型 ④ 为目标系统的逻辑模型作补充 5.1.3 结构化分析模型的描述

5.2 数据流图（这货毫无疑问的是重点啊

Data Flow Diagram(简称DFD)：描述输入数据流到输出数据流的变换(即加工)过程，用于对系统的功能建模。

5.2.1 数据流图的图形表示

5.2.1.1 数据流图的基本图形元素

① 源或宿：存在于软件系统之外的人员或组织，表示软件系统输入数据的来源和输出数据的去向，因此也称为源点和终点

源或宿用相同的图形符号表示

当数据流从该符号流出时表示是源 当数据流流向该符号时表示是宿 当两者皆有时表示既是源又是宿

② 加工：描述输入数据流到输出数据流的变换

每个加工用一个定义明确的名字标识 至少有一个输入数据流和一个输出流

可以有多个输入数据流和多个输出数据流 ③ 文件：保存数据信息的外部单元

每个文件用一个定义明确的名字标识 由加工进行读写

DFD中称为文件，但在具体实现时可以用文件系统实现也可以用数据库系统等实现

④ 数据流：每个数据流用由一组固定成分的数据组成并拥有一个定义明确的名字 标识

数据流的流向

从一个加工流向另一个加工 从加工流向文件(写文件) 从文件流向加工(读文件) 从源流向加工 从加工流向宿

5.2.1.2 数据流图中的扩充符号

描述一个加工的多个数据流之间的关系

① 星号(＊)：表示数据流之间存在“与”关系

所有输入数据流同时存在时，才能进行加工处理 或加工处理的结果是同时产生所有输出数据流 ② 加号(＋)：表示数据流之间存在“或”关系

至少存在一个输入数据流时才能进行加工处理 或加工处理的结果是至少产生一个输出数据流

③ 异或(⊕)：表示数据流之间存在“异或”(互斥)关系

必须存在且仅存在一个输入数据流时，才能进行加工处理 或加工处理的结果是产生且仅产生一个输出数据流

5.2.1.3 数据流图的层次结构

顶层图只有代表整个软件系统的1个加工，描述了软件系统与外界(源或宿)之间的数据流

顶层图中的加工经分解后的图称为0层图(只有1张)

中间层图中至少有一个加工(也可以有多个)在下层图中分解成一张子图

处于最底层的图称为底层图，其中所有的加工不再分解成新的子图 顶层图只有一个代表整个软件系统的加工，该加工不必编号。 0层图中的加工编号分别为1，2，3，?

子图号：若父图中的加工号x分解成某一子图，则该子图号记为“图x”

子图中加工的编号：若父图中的加工号为x的加工分解成某一子图，则该子图中的加工编号分别为x.1、x.2、x.3?

小技巧：对于层次较多的DFD，较底层加工号可能很长，则可以在图

中先标上图号，然后其中的加工号则可写作：.1，.2，.3?? 5.2.2 分层数据流图的画法 这例子是某考务处理系统 ① 画出系统的输入和输出

确定源或宿：考生、阅卷站和考试中心 它们都既是源又是宿

顶层图唯一的加工：软件系统(考务处理系统) 确定数据流：系统的输入/输出信息

输入数据流：报名单(来自考生)、成绩清单(来自阅卷站)、合格标准(来自考试中心)

输出数据流：准考证(送往考生)、考生名单(送往阅卷站)、考生通知书(送往考生)、统计分析表(送往考试中心)

额外的输出流(考虑系统的健壮性)：不合格报名单(返回给考生)，错误成绩清单(返回给阅卷站)

顶层图通常没有文件 于是得到了：

② 画出系统内部

以下确定加工、数据流、文件、源或宿的一般方法适用于0层图及其各层子图

确定加工：将父图中某加工分解而成的子加工

根据功能分解来确定加工：将一个复杂的功能分解成若干个较小的功能，较多应用于高层DFD中的分解

根据业务处理流程确定加工：分析父图中待分解加工的业务处理流程，业务流程中的每一步都可能是一个子加工

特别要注意在业务流程中数据流发生变化或数据流的值发生变化的地方，应该存在一个加工，例如：

1

确定数据流

在父图中某加工分解而成的子图中，父图中相应加工的输入/输出数据流都是且仅是子图边界上的输入/输出数据流

分解后的子加工之间应增添相应的新数据流表示加工过程中的中间数据 如果某些中间数据需要保存以备后用，那么可以成为流向文件的数据流 同一个源或加工可以有多个数据流流向一个加工，如果它们不是一起到达和一起加工的，那么可以将它们分成若干个数据流。 2 确定文件

如果父图中该加工存在读写文件的数据流，则相应的文件和数据流都应画在子图中

在分解子图中，如果需要保存某些中间数据以备后用，则可以将这些数据组成一个新的文件

新文件(首次出现的文件)至少应有一个加工为其写入记录，同时至少存在另一个加工来读该文件的记录

注意：从父图中继承下来的文件在子图中可能只对其进行读，或只进行写 3 确定源和宿

0层图和其它子图中通常不必画出源和宿

有时为了提高可读性，可以将顶层图中的源和宿画在0层图中 4 最终得到考务处理系统0层图

根据功能分解方法识别出两个加工：考试报名、统计成绩 数据流

继承顶层图中的输入数据流和输出数据流

定义二个加工之间的数据流：由于这二个加工分别在考试前后进行，因此登记报名单所产生的结果“考生名册”应作为文件保存以便考试后由统计成绩加工引用

③ 画出加工内部

复杂的加工可以继续分解成1张DFD子图 分解方法

将该加工看作一个小系统，该加工的输入/输出数据流就是这个假设的小系统的输入/输出数据流

然后采用画0层图的方法，画出该加工的子图

④ 重复第3步，直至每个尚未分解的加工都足够简单(即不必再分解)

总结：画分层数据流图的步骤

1．画系统的输入和输出 2．画系统内部 3．画加工内部

4．重复第3步，直至每个尚未分解的加工都足够简单(即不必再分解)

5.4 数据字典

数据流图与数据字典是密不可分的，两者结合起来构成软件的逻辑模型(分析模型)

5.4.1 字典条目的种类及描述符号

数据字典由字典条目组成，每个条目描述DFD中的一个元素 ① 字典条目的种类

数据字典条目包括：数据流、文件、数据项(组成数据流和文件的数据)、加工、源或宿

② 数据字典使用的描述符号

5.4.2 字典条目

不同的开发组织或团队可以根据项目的需要定义字典条目的描述内容 字典条目中的描述内容主要包括

DFD元素的基本信息(名称、别名、简述、注解) 定义(数据类型、数据组成)

使用特点(取值范围、使用频率、激发条件) 控制信息(来源、去向、访问权限)等

下面的条目内容太多，忽略。 ① 数据流条目 ② 文件条目 ③ 数据项条目

④ 加工条目 ⑤ 源或宿条目

⑥ 别名条目：为有必要补充说明的别名给出 5.4.3 字典条目实例

培训报名单＝姓名＋单位＋课程

运动员报名单＝队名＋姓名＋性别＋｛参赛项目｝

5.4.4 数据字典的实现

提倡采用专用的软件工具或者常用的实用程序(如，正文编辑程序、电子表格)来建立数据字典的电子文档，其好处是便于字典条目的检索，字典的管理和维护。

如果数据字典由辅助绘制DFD的工具自动产生的话，那么可以利用数据字典来检查DFD的一致性和完整性，并保持数据字典与DFD的一致。

如果数据字典是由人工制作的，我们可以为每个字典条目制作一张卡片，所有卡片按字典条目的种类(数据流、文件、加工等)分类成册，每类卡片按某种约定排序。

以下小节在提纲中未出现，但有过作业，所以也加进来了 5.7 数据流图到软件体系结构的映射

结构化设计是将结构化分析的结果(数据流图)映射成软件的体系结构(结构图) 将数据流图分为变换型数据流图和事务型数据流图，对应的映射分别称为变换分析和事务分析

5.7.1 信息流可分为变换流和事务流

① 变换流

特征：数据流图可明显地分成输入、变换、输出三部分

信息沿着输入路径进入系统，并将输入信息的外部形式经过编辑、格式转换、合法性检查、预处理等辅助性加工后变成内部形式

内部形式的信息由变换中心进行处理

然后沿着输出路径经过格式转换、组成物理块、缓冲处理等辅助性加工后变成输出信息送到系统外

② 事务流

特征：数据流沿着输入路径到达一个事务中心，事务中心根据输入数据的类型在若干条动作路径中选择一条来执行

事务中心的任务是：接收输入数据(即事务)；分析每个事务的类型；根据事务类型选择执行一条动作路径。 5.7.2 数据流图映射到结构图的步骤

① 复审和精化数据流图

② 确定数据流图的类型(变换型、事务型)

③ 将DFD映射成初始结构图：采用变换分析(5.7.3节)或事务分析(5.7.4节)技术。

④ 改进初始结构图(5.8节)

5.7.3 变换分析

变换分析的任务是将变换型的DFD映射成初始的结构图，步骤如下：

① 划定输入流和输出流的边界，确定变换中心

② 进行第一级分解：将DFD映射成变换型的程序结构

③ 进行第二级分解：将DFD中的加工映射成结构图中的一个适当的模块 ④ 标注输入输出信息：根据DFD，在初始结构图上标注模块之间传递的输入信息和输出信息

5.7.4 事务分析

事务分析的任务是将事务型的DFD映射成初始的结构图，步骤如下： 确定事务中心：事务中心位于数条动作路径的起点，这些动作路径呈幅射状从该点流出

① 将DFD映射成事务型的结构图 ② 分解每条动作路径所对应的结构图

③ 接收模块的分解：从事务中心开始，沿着输入路径向外移动，把输入路径上的每个加工映射成结构图中受接收模块控制的一个低层模块

④ 动作路径控制模块的分解：首先确定每条动作路径的流类型(变换流或事务流)，然后，运用变换分析或事务分析，将每条动作路径映射成与其流特性相对应的以动作路径控制模块为根模块的结构图

5.8 初始结构图的改进

5.8.2 结构图改进技巧 ① 减少模块间的耦合度 ② 消除重复功能 ③ 消除“管道”模块 ④ 模块大小适中 ⑤ 避免高扇出

⑥ 应尽可能研究整张结构图，而不是只考虑其中一部分。

第七章 面向对象的分析和设计 //重点

7.2 面向对象的分析和设计过程

7.2.1 面向对象分析过程（OOA）

7.2.1.1 面向对象分析的任务

目标是完成对所解问题的分析，确定待建的系统要做什么，并建立系统模型。

7.2.1.2 面向对象分析的步骤

① 获取客户对系统的需求，建造需求模型；

② 用基本的需求为指南来选择类和对象（包括属性和操作） ③ 定义类的结构和层次 ④ 建造对象-行为模型

⑤ 利用用况/场景来复审分析模型 7.2.2 面向对象设计过程（OOD）

OOD是将OOA所创建的分析模型转化为设计模型。

与传统方法不同,OOD和OOA没有明确的分界线，往往反复迭代进行。OOA主要考虑系统做什么，OOD则考虑系统怎么做，因此需要在OOA的模型上增加一些类或者在原有类中补充一些属性和操作。

OOD同样应该遵循抽象、信息隐蔽、功能独立、模块化等设计原则。

7.2.2.1 OOD的一般步骤 ① 系统设计 ② 对象设计 ③ 消息设计 ④ 复审

内容各种多..有兴趣自行P155~157 7.2.3 设计模式

在许多面向对象系统中，存在一些类和通信对象重复出现的模式。这些模式求解特定的设计问题，使面向对象设计更灵活，并最终可复用。

一个设计模式通常可用4个信息来描述

① 模式名

② 模式的环境和条件 ③ 设计模式的特征 ④ 应用设计模式的结果

7.3 UML概述

用于对软件密集型系统的制品进行可视化、祥述、构造和文档化的图形语言，是一种描绘系统蓝图的标准方法。

PPT和课本的UML视图和图的分类不同..统一建模语言不统一了怎么办！ 这里以PPT为准，因为懒得打字。

图形化的表示机制，十多种视图，分4类： 用例图：用户角度：功能、执行者 静态图：系统静态结构

类图：概念及关系

对象图：某种状态或时间段内，系统中活跃的对象及其关系 包图：描述系统的分解结构 行为图：系统的动态行为

交互图：描述对象间的消息传递

顺序图：强调对象间消息发送的时序 合作图：强调对象间的动态协作关系

状态图：对象的动态行为。状态-事件-状态迁移-响应动作 活动图：描述系统为完成某功能而执行的操作序列 实现图：描述系统的组成和分布状况

构件图：组成部件及其关系

部署图：物理体系结构及与软件单元的对应关系

以下是各种图 ① 用例图：

② 类图

③ 顺序图

④ 协作图

⑤ 状态图

7.4 用况建模（这里只描述用例图怎么画

用例：从外部用户的角度看，一个用例是执行者与软件系统间的一次典型的交互作用。从系统内部看：一个用例代表系统执行的一系列动作，且动作结果被外部执行者察觉。

用例的描述包括：名称、参与执行者、前置条件、一个主事件流、零到多个辅事件流程和后置条件。

用例主要来源于对场景的分类和抽象，可略过场景，直接描述用例。 系统：大矩形，所有用况都在里面 用况：椭圆形 执行者：小人 用况图的关系： ① 关联：直线

② 扩展：虚箭头+《extend》；指向被扩展对象 ③ 包含：虚箭头+《include》，在PPT貌似画作《use》；指向被包含对象 ④ 用况泛化：空三角箭头；特殊指向一般。

类图神马的不管了

第八章 基于构件的软件开发 过程和步骤 //一句带过，key word就是这个，具体什么意思没懂。

大概是这些.. 8.1 概述

8.1.2 基于构件的软件开发过程

8.1.2.1 领域工程的步骤 ① 领域分析

② 建立领域特定的基准体系结构模型。 ③ 标识候选构件

④ 泛化和可变性分析 ⑤ 构件重构。 ⑥ 构件的测试。 ⑦ 构件的包装。 ⑧ 构件入库

8.1.2.2 应用系统工程的步骤

① 建立应用系统的体系结构模型。 ② 寻找候选构件。

③ 评价和选择合适的构件。 ④ 构件的修改和特化。 ⑤ 开发未被复用的部分。 ⑥ 构件的组装。 ⑦ 集成测试。

⑧ 评价被复用的构件，并推荐可能的新构件。

第九章 人的因素，人机界面风格，黄金3原则 /*个人整理*/ 9.1 人的因素

人的因素主要包括:

① 人对感知过程的认识 ② 用户的技能和行为方式

③ 用户所要求完成的整个任务以及用户对人机界面部分的特殊要求

主要的可测的人性因素 ：

1. 用户时间：在系统面向的使用者集合中，选择一些具有代表性的典型用户，统计其使用系统完成一系列特定任务所需要使用的时间。

2. 基准时间：统计系统正确完成基准任务需要的时间。

3. 基准出错率：在系统面向的使用者集合中，选择一些具有代表性的典型用户，统计其在完成基准任务时所犯的错误情况。

4. 任务出错率：在系统面向的使用者集合中，选择一些具有代表性的典型用户，统计其使用系统完成一系列特定任务时所犯的错误情况。

5. 学习能力：在系统面向的使用者集合中，选择一些具有代表性的典型用户，统计其学习使用系统的时间。

6. 记忆能力：在系统面向的使用者集合中，选择一些具有代表性的典型用户，统计其在使用系统后的记忆保持时间。

7. 主观看法：在系统面向的使用者集合中，选择一些具有代表性的典型用户，统计其使用系统后的主观满意情况。

9.2 人机界面风格

第一代：命令和询问方式的界面

正文形式的通信，通过用户命令和用户对系统询问的响应来完成。由于使用正文通信，因此用户容易出错，界面不友善，难以学习。

第二代：简单的菜单式界面

与第一代界面相比不易出错，但使用起来乏味，逐层进行不能一步到位。 第三代：窗口、图标、菜单、指示器四位一体的界面

能同时显示不同种类的信息，可在多个工作环境（窗口）中切换，窗口使用户能自如地执行许多通信型和认知型任务

通过下拉式菜单可方便地执行控制型和对话型任务

引入图标、下拉式菜单、按钮和滚动杆技术，可大大减少键盘输入，提高交互效率

第四代：第三界面与超文本、多任务概念相结合的界面，用户可同时执行多个任务。

9.2.1 语言界面

根据语言的特点命令语言界面可分为：

形式语言。这是一种人工语言，特点是简洁、严密、高效，不仅是操纵计算机的语言，而且是处理语言的语言；

自然语言。特点是具有多义性、微妙、丰富； 类自然语言。这是计算机语言的一种特例。

命令语言要求惊人的记忆和大量的训练，并且容易出错，使入门者望而生畏，但比较灵活和高效，适合于专业人员使用。 9.2.2 图形用户界面

图形用户界面(GUI-Graphics User Interface)是当前用户界面的主流，广泛应用于各档台式微机和图形工作站

当前各类图形用户界面的共同特点是以窗口管理系统为核心，使用键盘和鼠标器作为输入设备。窗口管理系统除基于可重叠多窗口管理技术外，广泛采用的另一核心技术是事件驱动(Event-Driven)技术。

图形用户界面和人机交互过程极大地依赖视觉和手动控制的参与，因此具有强烈的直接操作特点。 9.2.3 直接操纵用户界面

直接操纵(Direct manipulation)用户界面是Shneiderman首先提出的概念，直接操纵用户界面更多地借助物理的、空间的或形象的表示，而不是单纯的文字或数字的表示。

从用户界面设计者角度看：

设计图形比较因难，需大量的测试和实验； 复杂语义、抽象语义表示比较困难；

不容易使用户界面与应用程序分开独立设计。

总之，直接操纵用户界面不具备命令语言界面的某些优点。 9.2.4 多媒体用户界面

多媒体用户界面被认为是在智能用户界面和自然交互技术取得突破之前的一种过渡技术。

多媒体技术引入了动画、音频、视频等动态媒体，特别是引入了音频媒体，从而大大丰富了计算机表现信息的形式，拓宽了计算机输出的带宽，提高了用户接受信息的效率。

多媒体用户界面丰富了信息的表现形式，但基本上限于信息的存储和传输方面，并没有理解媒体信息的含义，这是其不足之处，从而也限制了它的应用场合。

9.2.5 多通道用户界面

80年代后期以来，多通道用户界面(Multimodal User Interface)成为人机交互技术研究的崭新领域，在国际上受到高度重视。

多通道用户界面综合采用视线、语音、手势等新的交互通道、设备和交互技术，使用户利用多个通道以自然、并行、协作的方式进行人机对话，通过整合来自多个通道的精确的和不精确的输入来捕捉用户的交互意图，提高人机交互的自然性和高效性。

9.4 界面设计活动 9.4.3 黄金原则

① 让用户拥有控制权 ② 减少用户的记忆负担 ③ 保持界面一致

第十章 //常用语言及其特点

也许是这些

COBOL适用于商业领域

FORTRAN适用于工程和科学计算领域 Prolog、Lisp适用于人工智能领域 Smalltalk、C++适用于OO系统的开发 有些语言适用于多个应用领域，如C 第十一章 11.1 软件测试基础 11.1.1 软件测试的目的

“程序测试是证明程序正确地执行了预期的功能”。实际上，一个程序不仅要完成它所需完成的功能，而且不应完成它不该做的事。如不能把边长为0、0、0的三条边判断为等边三角形。

Glen Myers给出的软件测试目的：

① 测试是一个为了发现错误而执行程序的过程

② 一个好的测试用例是指很可能找到迄今为至尚未发现的错误的测试用例 ③ 一个成功的测试是指揭示了迄今为至尚未发现的错误的测试 根据这个测试目的，我们应该排除对测试的错误观点，设计合适的测试用例，用尽可能少的测试用例，来发现尽可能多的软件错误。

11.1.2 软件测试的原则

Davis提出了一组指导软件测试的基本原则：

1.所有的测试都应可追溯到客户需求

2.应该在测试工作真正开始前的较长时间就进行测试计划

3. Pareto原则：测试中发现的80%的错误可能来自于20%的程序代码 4.测试应从“小规模”开始，逐步转向“大规模” 5.穷举测试是不可能的

6.为了达到最有效的测试，应由独立的第三方来承担测试

11.1.3 黑盒测试和白盒测试

测试用例的设计是软件测试的关键所在

设计尽可能少的测试用例来发现尽可能多的错误

设计最有可能发现软件错误的测试用例，同时避免使用发现错误效果相同的测试用例

测试用例的设计方法大体可分为两类：白盒测试和黑盒测试，也称白箱测试和黑箱测试

白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。

白盒测试主要用于对模块的测试，包括： ① 程序模块中的所有独立路径至少执行一次 ② 对所有逻辑判定的取值（“真”与“假”）都至少测试一次 ③ 在上下边界及可操作范围内运行所有循环 ④ 测试内部数据结构的有效性等

黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求。

黑盒测试可用于各种测试，它试图发现以下类型的错误： ① 不正确或遗漏的功能

② 接口错误，如输入/输出参数的个数、类型等

③ 数据结构错误或外部信息(如外部数据库)访问错误 ④ 性能错误

⑤ 初始化和终止错误 /*11.1.3是我猜的，因为在11.2前。另外不知道是指黑盒的概念还是黑盒

*测试的概念*/ 黑盒白盒概念

11.2 白盒测试

11.2.1 逻辑覆盖测试

① 语句覆盖：让每条可执行语句都至少执行一次 ② 判定覆盖：让每个判定可能结果都至少出现一次

③ 条件覆盖：让每个判定的每个条件的所有可能结果都至少出现一次。 ④ 判定/条件覆盖：以上两个都满足

⑤ 条件组合覆盖：每个判定中条件结果的所有可能组合都至少出现一次 ⑥ 路径覆盖：每条可能执行到的路径都至少经过一次

11.2.3 基本路径测试

在实际问题中，一个不太复杂的程序，特别是包含循环的程序，其路径数可能非常大。因此测试常常难以做到覆盖程序中的所有路径，为此，我们希望把测试的程序路径数压缩到一定的范围内。

基本路径测试是Tom McCabe提出的一种白盒测试技术，这种方法首先根据程序或设计图画出控制流图，并计算其区域数，然后确定一组独立的程序执行路径（称为基本路径），最后为每一条基本路径设计一个测试用例。

流图画法：一个连续的处理框和一个判定框映射成一个结点，箭头映射成边，多个箭头交汇点映射成一个空结点，上述映射前提是判定必须是非复合条件，否则必须转换。

方法：

① 画出控制流图

② 观察控制流图中有几个区域 ③ 则独立路径的数目=区域数

④ 为每个独立路径设计一个测试用例。 11.2.5 循环测试

循环分为4种不同类型：简单循环、嵌套循环、串接循环和非结构循环。

（1）简单循环

按照下列规则设计测试用例：

① 零次循环：从循环入口到出口 ② 一次循环：检查循环初始值 ③ 二次循环：检查多次循环 ④ m次循环： 检查多次循环 ⑤ 最大次数循环

⑥比最大次数多一次的循环 ⑦比最大次数少一次的循环

（2） 按照下列规则设计测试用例：

① 先测试最内层循环：所有外层的循环变量置为最小值，最内层按简单循环测试；

② 由里向外，测试上一层循环：测试时此层以外的所有外层循环的循环变量取最小值，此层以内的所有嵌套内层循环的循环变量取“典型”值，该层按简单循环测试；

③ 重复上一条规则，直到所有各层循环测试完毕；

④对全部各层循环同时取最小循环次数，或者同时取最大循环次数 (3) 串接循环 如果串接的各个循环互相独立，则可以分别用简单循环的方法进行测试；但如果第一个循环的循环变量与第二个循环控制相关，则两个循环不独立，此时，把第一个循环看作外循环，第二个循环看作内循环，然后用测试嵌套循环的办法来处理。

(4) 非结构循环 这一类循环应该先将其结构化，然后再测试。

11.3 黑盒测试 黑盒测试是依据软件的需求规约，检查程序的功能是否符合需求规约的要求。

主要的黑盒测试方法有： ① 等价类划分 ② 边界值分析 ③ 比较测试 ④ 错误猜测 ⑤ 因果图

11.3.1 等价类划分 概念： {

由于不能穷举所有可能的输入数据来进行测试，所以只能选择少量有代表性的输入数据，来揭露尽可能多的程序错误

等价类划分方法将所有可能的输入数据划分成若干个等价类，然后在每个等价类中选取一个代表性的数据作为测试用例

等价类划分方法把输入数据分为有效输入数据和无效输入数据

有效输入数据指符合规格说明要求的合理的输入数据，主要用来检验程序是否实现了规格说明中的功能

无效输入数据指不符合规格说明要求的不合理或非法的输入数据，主要用来检验程序是否做了规格说明以外的事

在确定输入数据等价类时，常常还要分析输出数据的等价类，以便根据输出数据等价类导出输入数据等价类。

}

11.3.1.1 等价类划分设计测试用例的步骤 ① 确定等价类

根据软件的规格说明，对每一个输入条件（通常是规格说明中的一句话或一个短语）确定若干个有效等价类和若干个无效等价类。

(1) 如果输入条件规定了取值范围，则可以确定一个有效等价类（输入值在此范围内）和两个无效等价类（输入值小于最小值及大于最大值）

(2) 如果输入条件规定了值的个数，则可以确定一个有效等价类（输入值的个数等于规定的个数）和两个无效等价类（输入值的个数小于规定的个数和大于规定的个数）

(3) 如果输入条件规定了输入值的集合（即离散值），而且程序对不同的输入值做不同的处理，那么每个允许的值都确定为一个有效等价类，另外还有一个无效等价类（任意一个不允许的值）

(4) 如果输入条件规定了输入值必须遵循的规则，那么可确定一个有效等价类（符合此规则）和若干个无效等价类（从各个不同的角度违反此规则）。

(5) 如果输入条件规定输入数据是整型，那么可以确定三个有效等价类（正整数、零、负整数）和一个无效等价类（非整数）。

(6) 如果输入条件规定处理的对象是表格，那么可以确定一个有效等价类（表有一项或多项）和一个无效等价类（空表）。 ② 利用等价类设计测试用例

在确定了等价类之后，建立等价类表，列出所有划分出的等价类。并为每个有效等价类和无效等价类编号。

(1) 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止； (2) 为每个无效等价类设计一个新的测试用例。 11.3.2 边界值分析

边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。

人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，其揭露程序中错误的可能性就更大。

边界值分析方法选择测试用例的规则如下：

1．如果输入条件规定了值的范围，则选择刚刚达到这个范围的边界的值以及刚刚超出这个范围的边界的值作为测试输入数据。

2．如果输入条件规定了值的个数，则分别选择最大个数、最小个数、比最大个数多1、比最小个数少1的数据作为测试输入数据。

3．对每个输出条件使用第1条。 4．对每个输出条件使用第2条。

5．如果程序的输入或输出是个有序集合，例如，顺序文件、表格，则应把注意力集中在有序集的第1个元素和最后一个元素上。

6．如果程序中定义的内部数据结构有预定义的边界，例如，数组的上界和下界、栈的大小，则应选择使得正好达到该数据结构边界以及刚好超出该数据结构边界的输入数据作为测试数据。

7．发挥你的智慧，找出其他可能的边界条件。 11.3.3 比较测试

这个大家都懂的，几个团队做一样的事

值得注意的是，比较测试并不能保证软件没有错误，如果规格说明本身有错，那么 所有的版本都可能反映这种错误。

另外，如果各个版本产生相同的但都不正确的结果，那么比较测试也无法发现这种错误。

11.3.4 错误猜测

错误猜测是一种凭直觉和经验推测某些可能存在的错误，从而针对这些可能存在的错误设计测试用例的方法。

这种方法没有机械的执行步骤，主要依靠直觉和经验。

错误猜测法的基本思想是：列举出程序中所有可能的错误和容易发生错误的特殊情况，然后根据这些猜测设计测试用例。

11.3.5 因果图

在等价类划分方法和边界值方法中未考虑输入条件的各种组合，当输入条件比较多时，输入条件组合的数目会相当大

因果图方法是一种帮助人们系统地选择一组高效测试用例的方法，它既考虑了输入条件的组合关系，又考虑了输出条件对输入条件的依赖关系，即因果关系，其测试用例发现错误的效率比较高。

因果图方法的特点是：

① 考虑输入条件的组合关系；

② 考虑输出条件对输入条件的依赖关系，即因果关系； ③ 测试用例发现错误的效率高；

④ 能检查出功能说明中的某些不一致或遗漏。 步骤： 用因果图设计测试用例的步骤： (1) 分割功能说明书

将输入条件分成若干组，然后分别对每个组使用因果图，这样可减少输入条件组合的数目。如测试编译程序时，可以将每个语句作为一组。

(2) 识别“原因”和“结果”，并加以编号

“原因”是指输入条件或输入条件的等价类；“结果”是指输出条件或系统变换。如，更新主文件就是一种系统变换。

每个原因和结果都对应于因果图中的一个结点，当原因或结果成立（或出

现）时，相应的结点的值为1，否则为0。 (3) 根据功能说明中规定的原因与结果之间的关系画出因果图

因果图的基本符号如下：

(图中左边的结点表示原因，右边的结点表示结果 原因和结果之间的关系有：

恒等：若a=1，则b=1；若a=0，则b=0 非：若a=1，则b=0；若a=0，则b=1

或：若a=1或b=1 或c=1 ，则d=1；否则d=0 与：若a=b=c=1 ，则d=1；否则d=0

画因果图时原因在左，结果在右，由上向下排列，并根据功能说明中规定的原因和结果之间的关系，用上述符号连接起来。必要时还可以引入一些中间结点。)

(4) 根据功能说明在因果图中加上约束条件 因果图的约束条件如下图所示：

(图中互斥、包含、唯一、要求是对原因的约束，屏蔽是对结果的约束 互斥：表示a、b、c中至多只有一个为1，即不同时为1 包含：表示a、b、c中至少有一个为1，即不同时为0 唯一：表示a、b、c中有且仅有一个1

要求：表示若a=1 ，则要求b必须为1，即不可出现a=1 且b=0 屏蔽：表示若a=1 ，则b必须为0，即不可出现a=1 且b=1) (5) 根据因果图画出判定表

列出满足约束条件的所有原因组合，写出每种原因组合下的结果（如有的话）

(6)为判定表的每一列设计一个测试用例

某

例

子

：

11.4 测试策略 概念

一种测试策略就是将测试分为单元测试、集成测试、确认测试和系统测试。 单元测试是针对程序中的模块或构件，主要揭露编码阶段产生的错误。 集成测试针对集成的软件系统，主要揭露设计阶段产生的错误。

确认测试是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误。

对于基于计算机系统中的软件，还需将它集成到基于计算机系统中，并进行系统测试，以揭露不符合系统工程中对软件要求的错误。

11.4.1 V模型 就一图

11.4.2 单元测试

单元测试又称模块测试，它着重对软件设计的最小单元（软件构件或模块）进行验证

单元测试根据设计描述，对重要的控制路径进行测试，以发现构件或模块内部的错误

单元测试通常采用白盒测试，并且多个构件或模块可以并行进行测试 这里将构件或模块统一称为模块 11.4.2.1 单元测试的内容

模块接口：确保模块的输入/输出参数信息是正确的。这些信息包括参数的个数、次序、类型等。

局部数据结构：确保临时存储的数据在算法执行的整个过程中都能维持其完整性。如不合适的类型说明、不同数据类型的比较或赋值、文件打开和关闭的遗漏、超越数据结构的边界等。

边界条件：确保程序单元在极限或严格的情况下仍能正确地执行。

所有独立路径：确保模块中的所有语句都至少执行一次。程序执行的路径实际上体现了计算的过程，计算中常见的错误有：不正确的操作优先级、不同类型数据间的操作、不正确的初始化、不精确的精度、不正确的循环中止、不适当地修改循环变量、发散的迭代等。

所有错误处理路径：单元测试应该对所有的错误处理路径进行测试。错误处理部分潜在的错误有：报错信息没有提供足够的信息来帮助确定错误的性质及其发生的位置、报错信息与真正的错误不一致、错误条件在错误处理之前就已引起系统异常、异常条件处理不正确等。

11.4.2.2 单元测试过程

单元测试通常与编码工作结合起来进行。

模块本身不是一个独立的程序，在测试模块时，必须为每个被测模块开发一个驱动(driver)程序和若干个桩(stub)模块。

驱动模块接收测试数据，调用被测模块，把测试数据传送给被测模块，被测模块执行后，驱动模块接收被测模块的返回数据，并打印相关结果。

11.4.3 集成测试

集成测试 也称组装测试、联合测试

经单元测试后，每个模块都能独立工作，但把它们放在一起往往不能正常工作。

11.4.3.1 非增量集成测试和增量集成测试 集成的方式有两种：

非增量式集成：使用“一步到位”的方法来构造程序。先将所有经过单元测试的模块组合在一起，然后对整个程序（作为一个整体）进行测试。这种测试在发现错误时，很难为错误定位。改正错误时容易引入新的错误，新旧错误混在一起，更难定位。

增量式集成：根据程序结构图，按某种次序挑选一个（或一组）尚未测试过的模块，把它集成到已测试好的模块中一起进行测试，每次增加一个（或一组）模块，直至所有模块全部集成到程序中。在增量集成测试过程中发现的错误，往往与新加入的模块有关。

增量又分成两种：自顶向下和自底向上。 11.4.3.2 自顶向下集成

自顶向下集成：从主控模块（主程序）开始，然后按照程序结构图的控制层次，将直接或间接从属于主控模块的模块按深度优先或广度优先的方式逐个集成到整个结构中，并对其进行测试。

自顶向下集成在测试一个模块时，它的上层模块（已测试过）可用作它的驱动模块。

自顶向下集成的步骤：

（1）主控模块（主程序）被直接用作驱动程序，所有直接从属于主控模块的模块用桩模块替换，然后对主控模块进行测试；

（2）根据集成的实现方式（深度优先或广度优先），下层的桩模块一次一个地替换成真正的模块，从属于该模块的模块用桩模块替换，然后对其进行测试；

（3）用回归测试来保证没有引入新的错误；

（4）重复第（2）和第（3）步，直至所有模块都被集成。 自顶向下集成的优点：

不需要驱动模块；能尽早对程序的主要控制和决策机制进行检验，能较

早发现整体性的错误；深度优先的自顶向下集成能较早对某些完整的程序功能进行验证。

自顶向下集成的缺点：

测试时低层模块用桩模块替代，不能反映真实情况；重要数据不能及时回送到上层模块。

11.4.3.3 自底向上集成

自底向上集成：从程序结构的最底层模块（即原子模块）开始，然后按照程序结构图的控制层次将上层模块集成到整个结构中，并对其进行测试。

自底向上集成在测试一个模块时，它的下层模块（已测试过）可用作它的桩模块。

自底向上集成的步骤：

（1）将低层模块组合成能实现软件特定功能的簇； （2）为每个簇编写驱动程序，并对簇进行测试；

（3）移走驱动程序，用簇的直接上层模块替换驱动程序，然后沿着程序结构的层次向上组合新的簇；

（4）凡对新的簇测试后，都要进行回归测试，以保证没有引入新的错误； （5）重复第（2）步至第（4）步，直至所有的模块都被集成。 自底向上集成的优点：

不需要桩模块，所以容易组织测试；将整个程序结构分解成若干个簇，对同一层次的簇可并行进行测试，可提高效率。

自底向上集成的缺点： 整体性的错误发现得较晚。

11.4.3.4 策略的选择

自顶向下集成测试与自底向上集成测试各有优缺点，其中一种策略的优点差不多就是另一种策略的缺点。将这两种策略组合起来可能是一种最好的折衷，这种折衷的策略是：在程序结构的高层使用自顶下向策略，而在低层则使用自底向上策略，这种测试策略也称为三明治测试（sandwich testing）。

集成测试时应特别关注关键模块（critical module）的测试。关键模块是指具有下列一个或多个特征的模块：1）与多个软件需求有关；2）含有高层控制（位于程序结构的高层）；3）本身是复杂的或是容易出错的；4）含有确定的性能需求。关键模块应尽早测试，回归测试时也应集中在关键模块的功能上。 11.4.3.5 回归测试

在集成测试过程中，每当增加一个（或一组）新模块时，原先已集成的软件就发生了改变。新的数据流路径被建立，新的I/O操作可能出现，还可能激活新的控制逻辑，这些改变可能使原本正常的功能产生错误。

当测试时发现错误后，需修改程序；或者在软件维护时也需修改程序。这些对程序的修改也可能使原本正常的功能产生错误。

回归测试就是对已经进行过的测试的子集的重新执行，以确保对程序的改变和修改，没有传播非故意的副作用。

11.4.4 确认测试

11.4.4.1 确认测试标准

确认测试以软件需求规约为依据，以发现软件与需求不一致的错误。主要检查软件是否实现了规约规定的全部功能要求，文档资料是否完整、正确、合理，其他的需求，如可移植性、可维护性、兼容性、错误恢复能力等是否满足。

确认测试的结果可分为两类：

① 满足需求规约要求的功能或性能特性，用户可以接受。 ② 发现与需求规约有偏差，此时需列出问题清单。（就是杯具了吧 11.4.4.2 软件配置评审

软件配置评审也称软件审计（audit），其目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段必需的细节，而且已经编排好分类目录。

软件配置主要包括计算机程序（源代码和可执行程序），针对开发者和用户的各类文档，包含在程序内部或程序外部的数据。

11.4.4.3 α测试和β测试

如果软件是为一个客户开发的，那么，最后由客户进行验收测试（acceptance test），以使客户确认该软件是他所需要的。

如果软件是给许多客户使用的（如市场上销售的各种软件），那么让每个客户做验收测试是不现实的。大多数软件厂商都使用一种称为α测试和β测试的过程，来发现那些似乎只有最终用户才能发现的错误。

α测试是由一个用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。经α测试后的软件称为β版软件。

β测试是由软件的最终用户在一个或多个用户场所进行的，与α测试不同，开发者通常不在测试现场，因此，β测试是软件在一个开发者不能控制的环境中的“活的”应用，用户记录所有在β测试中遇到的（真正的或想象的）问题，并定期把这些问题报告给开发者，在接到β测试的问题报告后，开发者对软件进行最后的修改，然后着手准备向所有的用户发布最终的软件产品。

11.4.5 系统测试 系统测试是对整个基于计算机的系统进行的一系列测试。

系统测试的种类很多，每种测试都有不同的目的，它们从不同的角度测试计算机系统是否被正常地集成，并完成相应的功能。

常用的系统测试包括：

① 恢复测试（recovery testing）

恢复测试是通过各种手段，强制软件发生故障，然后来验证系统能否在指定的时间间隔内恢复正常，包括修正错误并重新启动系统。

如果恢复是由系统自身来完成的，那么，需验证重新初始化、检查点机制、数据恢复和重启动等的正确性。

如果恢复需要人工干预，那么要估算平均修复时间MTTR（mean time to repair）是否在用户可以接受的范围内。

② 安全测试（security testing）

安全测试用来验证集成在系统中的保护机制能否实际保护系统不受非法侵入。

在安全测试过程中，测试者扮演一个试图攻击系统的角色，采用各种方式攻击系统。例如，截取或码译密码；借助特殊软件攻击系统；“制服”系统，使他人无法访问；故意导致系统失效，企图在系统恢复之机侵入系统；通过浏览非保密数据，从中找出进入系统的钥匙等等。

一般来说，只要有足够的时间和资源，好的完全测试一定能最终侵入系统。系统设计者的任务是把系统设计成：攻破系统所付出的代价大于攻破系统后得到信息的价值。

③ 压力测试（stress testing）

压力测试也称强度测试，它是在一种需要非正常数量、频率或容量的方式下执行系统，其目的是检查系统对非正常情况的承受程度。例如：

当系统的中断频率是每秒1或2个时，执行每秒10个中断的测试用例 将输入数据的数量提高一个数量级来测试输入功能如何响应 执行需要最大内存或其它资源的测试用例 执行可能导致大量磁盘驻留数据的测试用例

④ 性能测试（performance testing）

性能测试用来测试软件在集成的系统中的运行性能。它对实时系统和嵌入式系统尤为重要。

性能测试可以发生在测试过程的所有步骤中

单元测试时，主要测试一个独立模块的性能，如算法的执行速度。 软件集成后，进行软件整体的性能测试。

计算机系统集成后，进行整个计算机系统的性能测试。

性能测试常常需要与压力测试结合起来进行，而且常常需要一些硬件和软件测试设备，以监测系统的运行情况。 11.5 面向对象测试 忽略 11.6 测试完成标准

因为无法判定当前查出的错误是否是最后一个错误，所以决定什么时候停止程序测试就成了最困难的问题，但是测试最后一定要停止的。

几种实用的测试完成标准：

Musa和Ackerman提出了一个基于统计标准的答复：“不，我们不能绝对地认定软件永远也不会再出错，但是相对于一个理论上合理的和在试验中有效的统计模型来说，如果一个在按照概率的方法定义的环境中，1000个CPU小时内不出错运行的概率大于0．995的话，那么我们就有95%的信心说，我们已经进行了足够的测试”。

使用指定的测试用例设计方法产生测试用例，运行这些测试用例均未发现错误（包括发现错误后已被纠正的情况），则测试可终止。

观察测试阶段中单位时间内发现错误数目的曲线，若错误仍在不断上升，则继续测试，如果已经下降趋势且不多，则可以停止。

11.7 调试 （这个的概念还是记住比较好，各种意义上

测试的目的是发现错误，调试（也称排错）的目的是确定错误的原因和准确位置，并加以纠正。

调试法分为：蛮力法、回溯法和原因排除法（分为归纳法和演绎法），都很直白。

第十二章 AB班讲过，我们没有，据他说没讲过的不考。

那就不干了 第十三章 13.1.1 软件维护的概念

是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程 国标GB/T 11457-95给出如下定义

在一软件产品交付使用后对其进行修改，以纠正故障、改进其性能和其它属性，或使产品适应改变了的环境

13.1.1.1 软件维护分类 两种错误认识

①软件维护是一次新的开发活动 ②软件维护就是改错

新开发活动强调要在一定的约束条件下从头开始实施

软件维护强调必须在现有系统的限定和约束条件下实施 ；根据起因不同，软件维护可以分为纠错性维护、适应性维护、改善性维护和预防性维护四类

① 纠错性维护：为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而进行的维护

② 适应性维护：为了使软件适应内部或外部环境变化，而去修改软件的过程 ③ 改善性维护：满足使用过程中用户提出增加新功能或修改已有功能的建议维护

④ 预防性维护：为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的活动

13.1.1.2 维护问题

结构化维护：采用软件工程的方法进行软件开发，保证每个阶段都有完整且详细的文档

非结构化维护：如果不采用软件工程方法开发软件，软件只有程序而欠缺文档，则维护工作将变得十分困难

和软件维护有关的部分问题 ：

① 理解别人的代码通常是非常困难的，而且难度随着软件配置成分的缺失而迅速增加

② 需要维护的软件往往没有文档、或文档资料严重不足、或软件的变化未在相应的文档中反映出来

③ 当软件要求维护时，不能指望由原来的开发人员来完成或提供软件的解释。由于维护持续时间很长，因此当需要解释软件时候，往往开发人员已经不在附近了

④ 绝大多数软件在设计时没有考虑到将来的修改问题

⑤ 软件维护这项工作毫无吸引力。一方面是因为软件维护，看不到什么“成果”，但工作量很大，更重要的是维护工作难度大，软件维护人员经常遭受挫折。

13.1.1.3 维护成本

软件维护除费用外的无形代价包括

① 维护活动占用了其他软件开发可用的资源，使资源的利用率降低 ② 一些修复或修改请求得不到及时安排，使得客户满意率下降 ③ 维护的结果把一些新的潜在的错误引入软件，降低了软件质量 ④ 将软件人员抽调到维护工作中，使得其它软件开发过程受到干扰

影响维护工作量的因素主要有以下六种

① 系统的规模：系统规模越大，其功能就越复杂，软件维护的工作量也随之增大

② 程序设计语言：使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性也越好

③ 系统年龄：老系统比新系统需要更多的维护工作量。

④ 数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应用软件的维护工作量

⑤ 先进的软件开发技术：在软件开发过程中，如果采用先进的分析设计技术和程序设计技术，如面向对象技术、复用技术等，可减少大量的维护工作量

⑥ 其它一些因素：如应用的类型、数学模型、任务的难度、IF嵌套深度、索引或下标数等，对维护工作量也有影响

第十四章 软件项目管理 14.1 软件项目管理概述

项目的定义(PMI)：一种被承办的旨在创造某种独特产品或服务的暂时性努力

项目管理是通过项目经理和项目组织的努力，运用系统理论的方法对项目及其资源进行计划、组织、协调、控制，旨在实现项目的特定目标的管理方法体系

(软件)项目管理的基本内容：项目定义、项目计划、项目执行、项目控制、项目结束 14.1.1 软件项目管理的关注点（4P）

① 人员(People)

人员是软件工程项目的基本要素和关键因素

在对人员进行组织时，有必要考虑参与软件过程(及每一个软件项目)的人员类型

② 产品(Product)

定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等

③ 过程(Process)

通常将项目分解为任务—子任务等，其分解准则是基于软件工程的过程

④ 项目(Project)

采用科学的方法及工具对项目基本内容进行管理

14.1.2 软件项目管理的内容 大概分成⑨步 ① 软件项目启动

在软件项目启动前对项目进行可行性分析，以明确项目的目标和范围，从而确定：合理精确的成本分析；实际可行的任务分解；可管理的进度安排

在多个项目方案中选择一个相对完善的方案

考虑交付期限、预算、个人能力、技术界面等限制条件

在正式启动软件项目前组成项目组，并召开项目启动会议，内容包括：项目组的初步交流；进一步对项目目标理解；对组织形式、管理方式、方针的一致认识；明确岗位职责

② 项目组织

在项目经理领导下，组织不同类型的项目组成员共同协作完成软件项目 存在多种可选的项目组织结构，组织结构的选择对项目的成败具有很大影响 规划软件工程项目组织结构时考虑如下因素： 待解决问题的困难程度

目标系统的规模，可用代码行或功能点来度量 项目组的生存期，即项目小组需要共同工作的时间 问题可被分解的程度

对目标系统要求的质量和可靠性

可供开发时间的紧迫性，即交付时间的严格程度

项目组内部的通信的复杂性，即成员(小组)之间正式或非正式通信的机制 ③ 项目计划

项目计划是项目组织根据软件项目的目标及范围，对项目实施中进行的各项活动进行周密的计划

项目计划根据项目目标确定项目的各项任务、安排任务进度、编制完成任务所需的资源预算等

项目计划包括：工作计划、人员组织计划、设备采购计划、变更控制计划、进度控制计划、财务计划、文件控制计划、应急计划等

④ 软件度量

软件度量是指计算机软件范围内的测量，主要是为产品开发的软件过程和产品本身定义相关的测量方法和标度

对软件开发过程度量的目的是为了对过程进行改进 对产品进行度量的目的是为了提高产品的质量， 度量的作用是为了有效地采用定量的方式来进行管理

管理人员利用度量来了解软件工程过程的执行情况和产品质量 需要考虑：

合适的度量是什么

所收集的数据如何使用

用于比较个人、过程或产品的度量是否合理 ⑤ 项目估算

项目估算是制定项目计划的基础

项目所需的人力(以人月为单位)、项目持续时间(以年份或月份为单位)、成本(以元为单位)等

参照以前类似项目中的相关数据进行估算 若存在类似历史项目则可进行类比估算

若缺少可类比的项目数据则采用特定的估算技术(例如功能点估算方法等) 通常采用多种估算技术进行交叉检查 ⑥ 风险管理

风险：人员、经费、进度及需求等方面存在的可能影响项目按计划完成的不确定因素

风险管理：标识软件项目中的风险，预测风险发生的概率以及风险造成的影响，并对风险进行评估，找出那些可能导致项目失败的风险，然后采取相应的措施来缓解风险

风险管理贯彻于整个软件工程过程中 ⑦ 进度安排 进度安排

将项目划分成可管理的子项目、任务和活动

确定任务之间的依赖关系，找出影响项目按期完成的关键任务

为每个任务分配时间、工作量以及指定责任人，定义每个任务的输出结果及其关联的里程碑

在项目实施过程中将在进度计划基础上跟踪实际执行情况，从而及时发现偏差并采取措施加以调整以确保项目按期完成

⑧ 跟踪与控制

跟踪是控制的前提，它实际上是在项目实施过程中对影响项目进展的内外部因素进行及时的、连续的、系统的记录和报告的活动，其核心在于反映项目变化、提供相关信息的报告

控制是通过工具和技术对项目计划与实际执行进行对比，并对项目的未来走向进行预测，再此基础上进行项目的各种调整

⑨ 软件配置管理

Software Confignation Management(SCM)

任务：标识和确定系统中的配置项，在系统整个生命期内控制这些项的发布和变更，记录并报告配置的状态和变更要求，验证配置项的完整性和正确性

SCM存在于整个软件过程中，是一种保护性活动

14.2 软件度量

度量对象：软件产品、软件过程、资源 外部属性：面向管理者和用户的属性

体现了软件产品/软件过程与相关资源和环境的关系，如成本、效益、开发人员的生产率

通常可采用直接测量的办法进行

内部属性：软件产品或过程本身的属性

如软件产品的结构、模块化程度、复杂性、程序长度等

有些内部属性只能用间接测量的方法度量，需要特定的测量方法或模型 软件度量分类：

分类1：

面向规模的度量用于收集与直接度量有关的软件工程输出信息和质量信息 面向功能的度量的则集中在程序的“功能性”和“实用性”

面向人的度量则收集有关人们开发计算机软件所用方式的信息和人员理解有关工具的方法和效率的信息 分类2：

软件生产率度量集中在软件工程过程的输出

软件质量度量可指明软件满足明确的和隐含的用户需求的程度

技术度量主要集中在软件产品的某些特征(如逻辑复杂性、模块化程度)上，而不是软件开发的全过程

14.2.1 面向规模的度量

软件规模通常是指软件的大小(size)，一般用代码行度量 优点：方便、直观

缺点：很大程度上取决于程序设计语言以及软件设计的质量 测量出软件规模后可方便地度量其它软件属性，包括：

14.2.2 面向对象的度量 //公式

一种针对软件的功能特性进行度量的方法 主要考虑软件系统的“功能性”和“实用性”

功能点度量：基于软件信息域的特征(可直接测量)和软件复杂性进行规模度量

功能点度量方法步骤： 计算信息域特征的值CT

计算复杂度调整值Fi

计算功能点FP

FP= CT*(0.65+0.01*F) 也许很重要？

一旦计算出功能点，则用类似代码行的方法来计算软件生产率、质量及其他属性

14.2.3 软件质量模型 软件质量定义 ISO/IEC 9126：与软件产品满足明确或隐含需求的能力有关的特征和特性的总和 GB/T 13423：软件产品中能满足给定需求的性质和特性的总和，例如符合规格说明的程度；软件具有所期望的各种属性的组合程度；客户或用户觉得软件满足其综合期望的程度；软件的综合特性，它确定软件在使用中将满足客户预期要求的程度

典型的软件质量模型：McCall模型、Boehm模型和ISO/IEC 9126质量模型

14.2.3.1 McCall模型

质量要素反映软件的质量，决定产品质量的软件属性用作评价准则，量化

的度量体系可测量软件质量属性的优劣

软件质量要素（11点） 正确性(correctness)：一个程序满足它的需求规约和实现客户任务目标的程度

可靠性(reliability)：一个程序期望以所需的精确度完成它的预期功能的程度 效率(efficiency)：一个程序完成其功能所需的计算资源和代码的数量 完整性(integrity)：对未授权人员访问软件或数据的可控制程度

可用性(usability)：学习、操作、准备输入和解释程序输出所需的工作量 可维护性(maintainability)：定位和修复程序中一个错误所需的工作量 灵活性(flexibility)：修改一个运作的程序所需的工作量

可测试性(testability)：测试一个程序以确保它完成所期望的功能所需的工作量

可移植性(portability)：把一个程序从一个硬件和/或软件系统环境移植到另一个所需的工作量

可复用性(reusability)：一个程序(或一个程序的部分)可以在另外一个应用程序中复用的程度，与程序完成的功能的包装和范围相关

可互操作性(interoperability)：连接一个系统和另一个系统所需的工作量。 14.2.4 软件复杂性度量

软件复杂性是指理解和处理软件的难易程度，包括程序复杂性和文档复杂性，主要体现在程序复杂性中

程序复杂性的6个方面 ① 程序理解的难度

② 纠错、维护程序的难度 ③ 向他人解释程序的难度 ④ 按指定方法修改程序的难度 ⑤ 根据设计文件编写程序的工作量 ⑥ 执行程序时需要资源的程度

典型的程序复杂性度量：McCabe环形复杂性度量、Halstead的复杂性度量

程序复杂性度量的基本原则

1.程序复杂性与程序大小的关系不是线性的 2.控制结构复杂的程序较复杂 3.数据结构复杂的程序较复杂 4.转向语句使用不当的程序较复杂

5.循环结构比选择结构复杂，选择结构又比顺序结构复杂 6.语句、数据、子程序和模块在程序中的次序对复杂性有影响 7.全局变量、非局部变量较多时，程序较复杂 8.参数按地址调用比按值调用复杂 9.函数副作用比显式参数传递难以理解

10.具有不同作用的变量共用一个名字时较难理解 11.模块间、过程间联系密切的程序比较复杂 12.嵌套深度越深，程序越复杂

McCabe环形复杂性度量

一种基于程序图的程序复杂性度量方法

程序图：是一种退化的程序流程图，它将程序流程图中的每个处理符号(包括处理框、判断框、起点、终点等)退化成一个结点(若干个连续的处理框可合并成一个结点)，流程图中连接处理符号的控制流变成程序图中连接结点的有向弧

建立在图论的基础之上

对于一个强连通的有向图G，若e是图中的弧数，n是图中的结点数，p是强连通分量的个数，则图G的环数计算公式为：

14.3

环形复杂性度量反映了程序(或模块)控制结构的复杂性

McCabe发现V(G)=10是一个实际模块的上限，当模块的环复杂度超过10时，要充分测试这个模块变得特别难

14.2.5 软件可靠性度量

软件可靠性是指在规定的条件下和规定的时间内软件按规格说明要求不引起系统失效的概率

软件可靠性通常用下列公式进行计算： MTBF＝MTTF＋MTTR

其中：MTBF(mean time between failer)是平均故障间隔时间，MTTF(mean time to failer)是平均故障时间，MTTR(mean time to repair)是平均修复时间

软件可用性(availability)是指软件在投入使用时能实现其指定的系统功能的概

率。可用下式计算：

14.3 软件项目估算 常用的估算方法：

基于已经完成的类似项目进行估算，这是一种常用的也是有效的估算方法 基于分解技术进行估算

问题分解是将一个复杂问题分解成若干个小问题，通过对小问题的估算得到复杂问题的估算

过程分解指先根据软件开发过程中的活动(分析、设计、编码、测试等)进行估算，然后得到整个项目的估算值。

基于经验估算模型的估算。典型的经验估算模型有IBM估算模型、CoCoMo模型和Putnam模型。

上述方法可以组合使用以提高估算的精度

14.3.1 代码行、功能点和工作量估算

1.请若干名有经验的技术人员或管理人员，采用上述估算办法的一种或多种，分别估算出代码行LOC或功能点FP的乐观值ai，悲观值bi及最有可能的值mi

2.计算出平均值a，b，m

3.LOC或FP的规模估算值：e＝(a＋4m＋b)/6

4.根据以前该组织软件开发的平均生产率(规模/人月数)和平均成本(资金/规模)计算工作量估算值和成本估算值

工作量估算值＝e/平均生产率 成本估算值＝e*平均成本

14.3.2 IBM估算模型

基于代码行LOC的静态单变量模型： 设L为源代码行数(KLOC)，则 工作量E=5.2×L0.91人月 项目持续时间D=4.1×L0.36＝14.47×E0.35 人员数S=0.54×E0.6 文档数量DOC＝49×L1.01

此模型中一条机器指令为一行源代码，不包括程序注释及其它说明

非机器指令编写的程序应转换成机器指令代码行数来考虑，转换关系为：

14.3.3 //重点 Boehm提出的“构造性成本模Constructive Cost Model, CoCoMo

CoCoMo模型按其详细程度分为：基本模型、中间模型和详细模型 将软件项目类型划分为三类：组织性、半独立型和嵌入型 ① 基本CoCoMo模型

型”

其中：

E表示工作量，单位是人月 D表示开发时间，单位是月

L是项目的源代码行估计值，单位是千行代码 a、b、c、d是常数，其取值如下表所示

② 中间CoCoMo模型

在基本CoCoMo模型基础上考虑了15种影响软件工作量的因素 通过工作量调节因子(EAF)修正对工作量的估算，从而使估算更合理 公式如下：

其中：L是软件产品的目标代码行数，单位是千行代码数，a、b是常数，取值如下表所示

工作量调节因子的计算

每个调节因子Fi的取值分为很低、低、正常、高、很高、极高六级，正常情况

下Fi=1

当15个Fi选定，可得：EAF=所有Fi的乘积

③ 详细COCOMO模型

估算公式与中间CoCoMo模型相同，并按分层、分阶段的形式给出其工作量影响因素分级表

针对每一个影响因素，按模块层、子系统层、系统层，有三张工作量因素分级表，供不同层次的估算使用

每一张表中又按开发各个不同阶段给出

例如软件可靠性在子系统层的工作量因素分级表如下所示

14.3.4 Putnam模型

一种软件项目工作量估算的动态多变量模型

他根据一些大型软件项目(30人年以上)的工作量分布情况，推导出软件项目在软件生存周期各阶段的工作量分布，如图所示

图中的工作量分布曲线与著名的Reyleigh-norden曲线相似

本文来源：https://www.bwwdw.com/article/0a6a.html