软件工程复习

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：

1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。

2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。

3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。

4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。

5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。

6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。

7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。

8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。

耦合：

1、内容耦合：A模块实际上修改了B模块，B模块完全依赖于A模块。

2、公共耦合：不同模块可以从公共数据存储区来访问和修改数据。

3、控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。

4、标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。

5、数据耦合：模块间传递的是数据值，是最受欢迎的耦合。

6、非耦合：模块相互之间没有信息传递，但是不太现实。

什么是设计模式？

设计模式：

一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。

面向对象设计模式分为：

模板方法模式 抽象类定义模板方法来实现一个操作中共同的步骤，并声明抽象的原语操 作来表示变化的部分

工厂方法模式 封装创建对象的代码

策略模式 在运行时选择算法。运行结束根据结果选择最好的算法

装饰者模式 运行时扩展对象的功能。给对象添加的新功能放入装饰者类

观察者模式 类似于管程思想

组合模式 异构的对象的汇集

访问者模式 将组合对象的新功能集中并封装于自身的类中

OO设计的基本原则？

1、单一职责原则

2、重用原则

3、开闭原则

4、里氏替换原则

5、依赖倒转原则

6、接口隔离原则

7、迪米特法则

OO开发有何优势？

1、语言的一致性：

采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案。

2、软件开发过程的一致性：

从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。

OO开发过程有几个步骤？

1、面向对象需求分析。

2、面向对象高层设计。

3、面向对象底层设计。

4、面向对象编程。OOP

5、面向对象测试。

Chapter 7 编写程序

1. 一般性的编程原则应该从哪三个方面考虑？

编程原则应该从控制结构，算法和数据结构三方面来考虑。

控制结构：程序如何传递数据。

算法：程序如何处理数据。

数据结构：程序如何储存数据。

（1）控制结构：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
（2）算法：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
（3）数据结构：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。

2. 在编写程序内部文档时，除了HCB头注释块header comment block外，还应添加什么注释信息？注意什么？

（1） 头注释块（header comment block，HCB）
将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。

（2） 其他程序注释——

• 解释性注释：本段源代码是在做什么的注释。
• 分解性注释：通过注释将代码分解成多个段。
• 版本注释：随着时间进行修改的记录。

（3） 有意义的变量名和语句标记
命名时尽量用有意义的变量名进行命名

（4） 排版格式以增强理解
注意缩进和间隔来反映基本的控制结构。

（5）文档化数据

注意的问题：

1、分段注释

2、注释和代码要一并更改。

3、注释要有意义。

4、一边写代码一边写注释，不要写完代码回过头来添加注释。

3. 什么是极限编程(XP)? 以及派对编程？

极限编程：

极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。

主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。

它将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈等方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

派对编程：

主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8 测试程序

1. 产生缺陷的原因

(1)软件本身：错误的设计、错误的代码、错误的设计实现。

(2)客户不清晰的需求：需求错误、Missing需求、不可实现的需求；

(3)其他原因，如项目的规模，众多的参与者导致的复杂性。

2. 有几种主要的缺陷类型？

1、算法缺陷

算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

2、计算和精度缺陷

算法或公式在实现时出现错误，或计算结果的精度达不到要求。

3、文档缺陷

文档和实际实现程序不一致。

4、过载缺陷/压力缺陷

程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

5、能力缺陷/边界缺陷

程序活动到达极限时，系统性能会变得不可接受。

6、计时缺陷/协调缺陷

多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

7、硬件和系统软件缺陷

提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

8、代码的标准和过程缺陷。

代码没有遵循组织机构的标准和过程。

3. 什么是正交缺陷分类？

被分类的任何一项故障都只属于一个类别，则分类方案是正交的。如果故障属于不止一个类，则失去了度量的意义。

4. 测试的各个阶段及其任务？

1、单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

2、集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

3、功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

4、性能测试：测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

5、验收测试：确定系统是按照用户的期望运转的。

6、安装测试：确保系统在实际环境中按照应有的方式运转。

7、系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

5.黑盒、白盒测试

（1）黑盒测试：将测试的对象看作是一个密闭的黑盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每种输入，观察到的输出与预期的输出相匹配。黑盒测试参考的文档是系统设计和程序设计阶段的文档。

优点：偏向于功能性的测试。不受内部逻辑约束。

缺点：不完备。黑盒法以 SRS 为依据，有一定的盲目性和不确定性，不可能揭示所有的错误。

黑盒测试方法：

1、等价分类法：将输入域划分为若干等价类。每个测试用例都代表了一类与它等价的其他例子。

2、边界值分析法：把测试值选在等价类的边界上进行测试。

3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。

4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合的情况。

（2）白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

优点：测试面广，可以测试一个模块的细节。

缺点：工作量大。

白盒测试方法:

• 语句覆盖 + 判定(分支)覆盖一个判断 + 条件覆盖：要求判定中的每个条件均按照“真”、“假”两种结果至少执行一次。
• 条件组合覆盖：要求所有条件结果的组合都至少出现一次(比如 A&&B，两个条件，那么就有四种条件的组合)。
• 路径测试法

6. 测试用例

测试用例(Test Case)，是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

是一组四元偶**<输入数据、前置条件、测试步骤、预期输出>**。

7.传统测试和OO测试有何不同

（1）需求分析与验证不同

（2）测试用例的生成不一样

（3）源代码分析不一样

（4）覆盖分析不一样

8.集成测试及其主要方法的分类？

1、自底向上集成

先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。

2、自顶向下集成

先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。

3、一次性集成

先测试每一个模块，之后将所有模块一并集成。

4、三明治集成

将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。

课件例题：

某城市的电话号码由 3 部分组成。这 3 个部分的名称与内容分别是:
地区码：空白或 3 位数字；前缀：非’0’或’1’开头的 3 位数字；后缀：4 位数字。
假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，请使用等价类的思路设计测试用例。

驱动，桩的概念

驱动程序：调用特定构件并向其传递测试用例的程序，即代替上层模块的调用程序。

桩：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。

什么是单元测试？ 什么是走查和检查？

将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

走查：不正式的的代码评审。

检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。

Chapter 9 系统测试

1. 系统测试的主要步骤及各自含义？

1、功能测试：根据SRS测试系统功能。

2、性能测试：根据SRS测试系统性能。

3、验收测试：根据客户的需求定义，由客户和用户一起测试。

4、安装测试：在用户环境下进行测试。

2. 什么是回归测试？

回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本相比，软件是否仍然以同样的方式执行同样的功能。

3.确认测试概念，确认测试分类？（基准测试、引导测试、并行测试）

确认测试：由用户检查软件系统是否满足了他们的需求的测试。

Pilot test: install on experimental basis
Alpha test: in-house test
Beta test: customer pilot
Parallel testing: new system operates in parallel with old system

1、基准测试：

由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。

2、引导测试：

在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。

4. 什么是alpha测试？β测试？

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1. α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；

目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

2. β测试

用户在不同场所进行测试。

β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

考试题型

1.名词解释（10/20分）

2.判断题（10/10分）

3.选择题（20/20分）

4.综合题（2/20分）

5.简述题（5/30分根据理解解释）

考试时间 17周考试

老师联系地址：科研楼 215

名词解释

Chapter 1

软件工程（Software Engineering）：在将有关软件开发与利用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件理论和技术工程的方法学。以及开发和维护软件的方法、过程、原则等。它是一个系统过程，既有对技术问题的综合分析，也有对开发过程和参与者的管理。

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。

软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。

重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。

测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。

工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。

Chapter 2

过程（Process）：软件开发过程中产生期望结果的一系列有序任务，设计活动、约束、资源等

软件生命周期：软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

原型： 一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

演化型原型：该原型的开发是用于了解问题，并作为将来实际提交系统的一部分。

抛弃型原型：仅用于了解问题、探索可行性，并不打算作为将来实际提交系统的一部分，而是用完就抛弃。

分阶段开发模型：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

螺旋模型：

RUP:迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

Chapter 3

项目进度：项目进度是对特定项目软件开发周期的刻画，包括对项目阶段、步骤、活动的分解。对各个离散活动交互关系的描述，对各个活动完成时间和整个项目完成时间的初步规划。

Chapter 4

需求：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

Chapter 5

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

Chapter 6

面向对象

内聚：软件内部组成成分的关联程度。

耦合：软件模块之间的关联程度。

Chapter 7

极限编程：极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。适应环境变化和需求变化，充分发挥开发人员的主动精神。

派对编程：主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8

算法缺陷:算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

计算和精度缺陷:算法或公式在实现时出现错误，或计算结果的精度达不到要求。

文档缺陷 : 文档和实际实现程序不一致。

过载缺陷/压力缺陷:程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

能力缺陷/边界缺陷:程序活动到达极限时，系统性能会变得不可接受。

计时缺陷/协调缺陷:多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

硬件和系统软件缺陷:提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

代码的标准和过程缺陷:代码没有遵循组织机构的标准和过程。

单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

黑盒测试：将测试的程序看作是一个不了解其内容的闭盒，我们提供输入并记录输出。测试的目标是实际的输出与预期一致。

白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

测试用例：是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

Chapter 9

系统测试 : 功能测试、性能测试、验收测试和安装测试统称为系统测试。

1、功能测试：根据SRS测试系统功能。对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

2、性能测试：根据SRS测试系统性能。测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

3、验收测试：确定系统是按照用户的期望运转的。

4、安装测试：在用户环境下进行测试。确保系统在实际环境中按照应有的方式运转。

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：

1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。

2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。

3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。

4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。

5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。

6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。

7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。

8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。

耦合：

1、内容耦合：A模块实际上修改了B模块，B模块完全依赖于A模块。

2、公共耦合：不同模块可以从公共数据存储区来访问和修改数据。

3、控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。

4、标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。

5、数据耦合：模块间传递的是数据值，是最受欢迎的耦合。

6、非耦合：模块相互之间没有信息传递，但是不太现实。

什么是设计模式？

设计模式：

一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。

面向对象设计模式分为：

模板方法模式 抽象类定义模板方法来实现一个操作中共同的步骤，并声明抽象的原语操 作来表示变化的部分

工厂方法模式 封装创建对象的代码

策略模式 在运行时选择算法。运行结束根据结果选择最好的算法

装饰者模式 运行时扩展对象的功能。给对象添加的新功能放入装饰者类

观察者模式 类似于管程思想

组合模式 异构的对象的汇集

访问者模式 将组合对象的新功能集中并封装于自身的类中

OO设计的基本原则？

1、单一职责原则

2、重用原则

3、开闭原则

4、里氏替换原则

5、依赖倒转原则

6、接口隔离原则

7、迪米特法则

OO开发有何优势？

1、语言的一致性：

采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案。

2、软件开发过程的一致性：

从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。

OO开发过程有几个步骤？

1、面向对象需求分析。

2、面向对象高层设计。

3、面向对象底层设计。

4、面向对象编程。OOP

5、面向对象测试。

Chapter 7 编写程序

1. 一般性的编程原则应该从哪三个方面考虑？

编程原则应该从控制结构，算法和数据结构三方面来考虑。

控制结构：程序如何传递数据。

算法：程序如何处理数据。

数据结构：程序如何储存数据。

（1）控制结构：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
（2）算法：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
（3）数据结构：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。

2. 在编写程序内部文档时，除了HCB头注释块header comment block外，还应添加什么注释信息？注意什么？

（1） 头注释块（header comment block，HCB）
将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。

（2） 其他程序注释——

• 解释性注释：本段源代码是在做什么的注释。
• 分解性注释：通过注释将代码分解成多个段。
• 版本注释：随着时间进行修改的记录。

（3） 有意义的变量名和语句标记
命名时尽量用有意义的变量名进行命名

（4） 排版格式以增强理解
注意缩进和间隔来反映基本的控制结构。

（5）文档化数据

注意的问题：

1、分段注释

2、注释和代码要一并更改。

3、注释要有意义。

4、一边写代码一边写注释，不要写完代码回过头来添加注释。

3. 什么是极限编程(XP)? 以及派对编程？

极限编程：

极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。

主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。

它将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈等方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

派对编程：

主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8 测试程序

1. 产生缺陷的原因

(1)软件本身：错误的设计、错误的代码、错误的设计实现。

(2)客户不清晰的需求：需求错误、Missing需求、不可实现的需求；

(3)其他原因，如项目的规模，众多的参与者导致的复杂性。

2. 有几种主要的缺陷类型？

1、算法缺陷

算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

2、计算和精度缺陷

算法或公式在实现时出现错误，或计算结果的精度达不到要求。

3、文档缺陷

文档和实际实现程序不一致。

4、过载缺陷/压力缺陷

程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

5、能力缺陷/边界缺陷

程序活动到达极限时，系统性能会变得不可接受。

6、计时缺陷/协调缺陷

多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

7、硬件和系统软件缺陷

提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

8、代码的标准和过程缺陷。

代码没有遵循组织机构的标准和过程。

3. 什么是正交缺陷分类？

被分类的任何一项故障都只属于一个类别，则分类方案是正交的。如果故障属于不止一个类，则失去了度量的意义。

4. 测试的各个阶段及其任务？

1、单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

2、集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

3、功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

4、性能测试：测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

5、验收测试：确定系统是按照用户的期望运转的。

6、安装测试：确保系统在实际环境中按照应有的方式运转。

7、系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

5.黑盒、白盒测试

（1）黑盒测试：将测试的对象看作是一个密闭的黑盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每种输入，观察到的输出与预期的输出相匹配。黑盒测试参考的文档是系统设计和程序设计阶段的文档。

优点：偏向于功能性的测试。不受内部逻辑约束。

缺点：不完备。黑盒法以 SRS 为依据，有一定的盲目性和不确定性，不可能揭示所有的错误。

黑盒测试方法：

1、等价分类法：将输入域划分为若干等价类。每个测试用例都代表了一类与它等价的其他例子。

2、边界值分析法：把测试值选在等价类的边界上进行测试。

3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。

4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合的情况。

（2）白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

优点：测试面广，可以测试一个模块的细节。

缺点：工作量大。

白盒测试方法:

• 语句覆盖 + 判定(分支)覆盖一个判断 + 条件覆盖：要求判定中的每个条件均按照“真”、“假”两种结果至少执行一次。
• 条件组合覆盖：要求所有条件结果的组合都至少出现一次(比如 A&&B，两个条件，那么就有四种条件的组合)。
• 路径测试法

6. 测试用例

测试用例(Test Case)，是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

是一组四元偶**<输入数据、前置条件、测试步骤、预期输出>**。

7.传统测试和OO测试有何不同

（1）需求分析与验证不同

（2）测试用例的生成不一样

（3）源代码分析不一样

（4）覆盖分析不一样

8.集成测试及其主要方法的分类？

1、自底向上集成

先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。

2、自顶向下集成

先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。

3、一次性集成

先测试每一个模块，之后将所有模块一并集成。

4、三明治集成

将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。

课件例题：

某城市的电话号码由 3 部分组成。这 3 个部分的名称与内容分别是:
地区码：空白或 3 位数字；前缀：非’0’或’1’开头的 3 位数字；后缀：4 位数字。
假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，请使用等价类的思路设计测试用例。

驱动，桩的概念

驱动程序：调用特定构件并向其传递测试用例的程序，即代替上层模块的调用程序。

桩：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。

什么是单元测试？ 什么是走查和检查？

将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

走查：不正式的的代码评审。

检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。

Chapter 9 系统测试

1. 系统测试的主要步骤及各自含义？

1、功能测试：根据SRS测试系统功能。

2、性能测试：根据SRS测试系统性能。

3、验收测试：根据客户的需求定义，由客户和用户一起测试。

4、安装测试：在用户环境下进行测试。

2. 什么是回归测试？

回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本相比，软件是否仍然以同样的方式执行同样的功能。

3.确认测试概念，确认测试分类？（基准测试、引导测试、并行测试）

确认测试：由用户检查软件系统是否满足了他们的需求的测试。

Pilot test: install on experimental basis
Alpha test: in-house test
Beta test: customer pilot
Parallel testing: new system operates in parallel with old system

1、基准测试：

由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。

2、引导测试：

在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。

4. 什么是alpha测试？β测试？

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1. α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；

目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

2. β测试

用户在不同场所进行测试。

β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

考试题型

1.名词解释（10/20分）

2.判断题（10/10分）

3.选择题（20/20分）

4.综合题（2/20分）

5.简述题（5/30分根据理解解释）

考试时间 17周考试

老师联系地址：科研楼 215

名词解释

Chapter 1

软件工程（Software Engineering）：在将有关软件开发与利用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件理论和技术工程的方法学。以及开发和维护软件的方法、过程、原则等。它是一个系统过程，既有对技术问题的综合分析，也有对开发过程和参与者的管理。

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。

软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。

重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。

测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。

工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。

Chapter 2

过程（Process）：软件开发过程中产生期望结果的一系列有序任务，设计活动、约束、资源等

软件生命周期：软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

原型： 一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

演化型原型：该原型的开发是用于了解问题，并作为将来实际提交系统的一部分。

抛弃型原型：仅用于了解问题、探索可行性，并不打算作为将来实际提交系统的一部分，而是用完就抛弃。

分阶段开发模型：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

螺旋模型：

RUP:迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

Chapter 3

项目进度：项目进度是对特定项目软件开发周期的刻画，包括对项目阶段、步骤、活动的分解。对各个离散活动交互关系的描述，对各个活动完成时间和整个项目完成时间的初步规划。

Chapter 4

需求：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

Chapter 5

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

Chapter 6

面向对象

内聚：软件内部组成成分的关联程度。

耦合：软件模块之间的关联程度。

Chapter 7

极限编程：极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。适应环境变化和需求变化，充分发挥开发人员的主动精神。

派对编程：主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8

算法缺陷:算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

计算和精度缺陷:算法或公式在实现时出现错误，或计算结果的精度达不到要求。

文档缺陷 : 文档和实际实现程序不一致。

过载缺陷/压力缺陷:程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

能力缺陷/边界缺陷:程序活动到达极限时，系统性能会变得不可接受。

计时缺陷/协调缺陷:多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

硬件和系统软件缺陷:提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

代码的标准和过程缺陷:代码没有遵循组织机构的标准和过程。

单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

黑盒测试：将测试的程序看作是一个不了解其内容的闭盒，我们提供输入并记录输出。测试的目标是实际的输出与预期一致。

白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

测试用例：是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

Chapter 9

系统测试 : 功能测试、性能测试、验收测试和安装测试统称为系统测试。

1、功能测试：根据SRS测试系统功能。对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

2、性能测试：根据SRS测试系统性能。测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

3、验收测试：确定系统是按照用户的期望运转的。

4、安装测试：在用户环境下进行测试。确保系统在实际环境中按照应有的方式运转。

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：

1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。

2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。

3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。

4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。

5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。

6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。

7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。

8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。

耦合：

1、内容耦合：A模块实际上修改了B模块，B模块完全依赖于A模块。

2、公共耦合：不同模块可以从公共数据存储区来访问和修改数据。

3、控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。

4、标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。

5、数据耦合：模块间传递的是数据值，是最受欢迎的耦合。

6、非耦合：模块相互之间没有信息传递，但是不太现实。

什么是设计模式？

设计模式：

一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。

面向对象设计模式分为：

模板方法模式 抽象类定义模板方法来实现一个操作中共同的步骤，并声明抽象的原语操 作来表示变化的部分

工厂方法模式 封装创建对象的代码

策略模式 在运行时选择算法。运行结束根据结果选择最好的算法

装饰者模式 运行时扩展对象的功能。给对象添加的新功能放入装饰者类

观察者模式 类似于管程思想

组合模式 异构的对象的汇集

访问者模式 将组合对象的新功能集中并封装于自身的类中

OO设计的基本原则？

1、单一职责原则

2、重用原则

3、开闭原则

4、里氏替换原则

5、依赖倒转原则

6、接口隔离原则

7、迪米特法则

OO开发有何优势？

1、语言的一致性：

采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案。

2、软件开发过程的一致性：

从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。

OO开发过程有几个步骤？

1、面向对象需求分析。

2、面向对象高层设计。

3、面向对象底层设计。

4、面向对象编程。OOP

5、面向对象测试。

Chapter 7 编写程序

1. 一般性的编程原则应该从哪三个方面考虑？

编程原则应该从控制结构，算法和数据结构三方面来考虑。

控制结构：程序如何传递数据。

算法：程序如何处理数据。

数据结构：程序如何储存数据。

（1）控制结构：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
（2）算法：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
（3）数据结构：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。

2. 在编写程序内部文档时，除了HCB头注释块header comment block外，还应添加什么注释信息？注意什么？

（1） 头注释块（header comment block，HCB）
将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。

（2） 其他程序注释——

• 解释性注释：本段源代码是在做什么的注释。
• 分解性注释：通过注释将代码分解成多个段。
• 版本注释：随着时间进行修改的记录。

（3） 有意义的变量名和语句标记
命名时尽量用有意义的变量名进行命名

（4） 排版格式以增强理解
注意缩进和间隔来反映基本的控制结构。

（5）文档化数据

注意的问题：

1、分段注释

2、注释和代码要一并更改。

3、注释要有意义。

4、一边写代码一边写注释，不要写完代码回过头来添加注释。

3. 什么是极限编程(XP)? 以及派对编程？

极限编程：

极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。

主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。

它将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈等方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

派对编程：

主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8 测试程序

1. 产生缺陷的原因

(1)软件本身：错误的设计、错误的代码、错误的设计实现。

(2)客户不清晰的需求：需求错误、Missing需求、不可实现的需求；

(3)其他原因，如项目的规模，众多的参与者导致的复杂性。

2. 有几种主要的缺陷类型？

1、算法缺陷

算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

2、计算和精度缺陷

算法或公式在实现时出现错误，或计算结果的精度达不到要求。

3、文档缺陷

文档和实际实现程序不一致。

4、过载缺陷/压力缺陷

程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

5、能力缺陷/边界缺陷

程序活动到达极限时，系统性能会变得不可接受。

6、计时缺陷/协调缺陷

多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

7、硬件和系统软件缺陷

提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

8、代码的标准和过程缺陷。

代码没有遵循组织机构的标准和过程。

3. 什么是正交缺陷分类？

被分类的任何一项故障都只属于一个类别，则分类方案是正交的。如果故障属于不止一个类，则失去了度量的意义。

4. 测试的各个阶段及其任务？

1、单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

2、集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

3、功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

4、性能测试：测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

5、验收测试：确定系统是按照用户的期望运转的。

6、安装测试：确保系统在实际环境中按照应有的方式运转。

7、系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

5.黑盒、白盒测试

（1）黑盒测试：将测试的对象看作是一个密闭的黑盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每种输入，观察到的输出与预期的输出相匹配。黑盒测试参考的文档是系统设计和程序设计阶段的文档。

优点：偏向于功能性的测试。不受内部逻辑约束。

缺点：不完备。黑盒法以 SRS 为依据，有一定的盲目性和不确定性，不可能揭示所有的错误。

黑盒测试方法：

1、等价分类法：将输入域划分为若干等价类。每个测试用例都代表了一类与它等价的其他例子。

2、边界值分析法：把测试值选在等价类的边界上进行测试。

3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。

4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合的情况。

（2）白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

优点：测试面广，可以测试一个模块的细节。

缺点：工作量大。

白盒测试方法:

• 语句覆盖 + 判定(分支)覆盖一个判断 + 条件覆盖：要求判定中的每个条件均按照“真”、“假”两种结果至少执行一次。
• 条件组合覆盖：要求所有条件结果的组合都至少出现一次(比如 A&&B，两个条件，那么就有四种条件的组合)。
• 路径测试法

6. 测试用例

测试用例(Test Case)，是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

是一组四元偶**<输入数据、前置条件、测试步骤、预期输出>**。

7.传统测试和OO测试有何不同

（1）需求分析与验证不同

（2）测试用例的生成不一样

（3）源代码分析不一样

（4）覆盖分析不一样

8.集成测试及其主要方法的分类？

1、自底向上集成

先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。

2、自顶向下集成

先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。

3、一次性集成

先测试每一个模块，之后将所有模块一并集成。

4、三明治集成

将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。

课件例题：

某城市的电话号码由 3 部分组成。这 3 个部分的名称与内容分别是:
地区码：空白或 3 位数字；前缀：非’0’或’1’开头的 3 位数字；后缀：4 位数字。
假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，请使用等价类的思路设计测试用例。

驱动，桩的概念

驱动程序：调用特定构件并向其传递测试用例的程序，即代替上层模块的调用程序。

桩：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。

什么是单元测试？ 什么是走查和检查？

将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

走查：不正式的的代码评审。

检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。

Chapter 9 系统测试

1. 系统测试的主要步骤及各自含义？

1、功能测试：根据SRS测试系统功能。

2、性能测试：根据SRS测试系统性能。

3、验收测试：根据客户的需求定义，由客户和用户一起测试。

4、安装测试：在用户环境下进行测试。

2. 什么是回归测试？

回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本相比，软件是否仍然以同样的方式执行同样的功能。

3.确认测试概念，确认测试分类？（基准测试、引导测试、并行测试）

确认测试：由用户检查软件系统是否满足了他们的需求的测试。

Pilot test: install on experimental basis
Alpha test: in-house test
Beta test: customer pilot
Parallel testing: new system operates in parallel with old system

1、基准测试：

由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。

2、引导测试：

在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。

4. 什么是alpha测试？β测试？

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1. α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；

目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

2. β测试

用户在不同场所进行测试。

β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

考试题型

1.名词解释（10/20分）

2.判断题（10/10分）

3.选择题（20/20分）

4.综合题（2/20分）

5.简述题（5/30分根据理解解释）

考试时间 17周考试

老师联系地址：科研楼 215

名词解释

Chapter 1

软件工程（Software Engineering）：在将有关软件开发与利用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件理论和技术工程的方法学。以及开发和维护软件的方法、过程、原则等。它是一个系统过程，既有对技术问题的综合分析，也有对开发过程和参与者的管理。

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。

软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。

重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。

测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。

工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。

Chapter 2

过程（Process）：软件开发过程中产生期望结果的一系列有序任务，设计活动、约束、资源等

软件生命周期：软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

原型： 一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

演化型原型：该原型的开发是用于了解问题，并作为将来实际提交系统的一部分。

抛弃型原型：仅用于了解问题、探索可行性，并不打算作为将来实际提交系统的一部分，而是用完就抛弃。

分阶段开发模型：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

螺旋模型：

RUP:迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

Chapter 3

项目进度：项目进度是对特定项目软件开发周期的刻画，包括对项目阶段、步骤、活动的分解。对各个离散活动交互关系的描述，对各个活动完成时间和整个项目完成时间的初步规划。

Chapter 4

需求：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

Chapter 5

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

Chapter 6

面向对象

内聚：软件内部组成成分的关联程度。

耦合：软件模块之间的关联程度。

Chapter 7

极限编程：极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。适应环境变化和需求变化，充分发挥开发人员的主动精神。

派对编程：主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8

算法缺陷:算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

计算和精度缺陷:算法或公式在实现时出现错误，或计算结果的精度达不到要求。

文档缺陷 : 文档和实际实现程序不一致。

过载缺陷/压力缺陷:程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

能力缺陷/边界缺陷:程序活动到达极限时，系统性能会变得不可接受。

计时缺陷/协调缺陷:多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

硬件和系统软件缺陷:提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

代码的标准和过程缺陷:代码没有遵循组织机构的标准和过程。

单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

黑盒测试：将测试的程序看作是一个不了解其内容的闭盒，我们提供输入并记录输出。测试的目标是实际的输出与预期一致。

白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

测试用例：是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

Chapter 9

系统测试 : 功能测试、性能测试、验收测试和安装测试统称为系统测试。

1、功能测试：根据SRS测试系统功能。对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

2、性能测试：根据SRS测试系统性能。测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

3、验收测试：确定系统是按照用户的期望运转的。

4、安装测试：在用户环境下进行测试。确保系统在实际环境中按照应有的方式运转。

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：

1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。

2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。

3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。

4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。

5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。

6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。

7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。

8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。

耦合：

1、内容耦合：A模块实际上修改了B模块，B模块完全依赖于A模块。

2、公共耦合：不同模块可以从公共数据存储区来访问和修改数据。

3、控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。

4、标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。

5、数据耦合：模块间传递的是数据值，是最受欢迎的耦合。

6、非耦合：模块相互之间没有信息传递，但是不太现实。

什么是设计模式？

设计模式：

一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。

面向对象设计模式分为：

模板方法模式 抽象类定义模板方法来实现一个操作中共同的步骤，并声明抽象的原语操 作来表示变化的部分

工厂方法模式 封装创建对象的代码

策略模式 在运行时选择算法。运行结束根据结果选择最好的算法

装饰者模式 运行时扩展对象的功能。给对象添加的新功能放入装饰者类

观察者模式 类似于管程思想

组合模式 异构的对象的汇集

访问者模式 将组合对象的新功能集中并封装于自身的类中

OO设计的基本原则？

1、单一职责原则

2、重用原则

3、开闭原则

4、里氏替换原则

5、依赖倒转原则

6、接口隔离原则

7、迪米特法则

OO开发有何优势？

1、语言的一致性：

采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案。

2、软件开发过程的一致性：

从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。

OO开发过程有几个步骤？

1、面向对象需求分析。

2、面向对象高层设计。

3、面向对象底层设计。

4、面向对象编程。OOP

5、面向对象测试。

Chapter 7 编写程序

1. 一般性的编程原则应该从哪三个方面考虑？

编程原则应该从控制结构，算法和数据结构三方面来考虑。

控制结构：程序如何传递数据。

算法：程序如何处理数据。

数据结构：程序如何储存数据。

（1）控制结构：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
（2）算法：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
（3）数据结构：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。

2. 在编写程序内部文档时，除了HCB头注释块header comment block外，还应添加什么注释信息？注意什么？

（1） 头注释块（header comment block，HCB）
将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。

（2） 其他程序注释——

• 解释性注释：本段源代码是在做什么的注释。
• 分解性注释：通过注释将代码分解成多个段。
• 版本注释：随着时间进行修改的记录。

（3） 有意义的变量名和语句标记
命名时尽量用有意义的变量名进行命名

（4） 排版格式以增强理解
注意缩进和间隔来反映基本的控制结构。

（5）文档化数据

注意的问题：

1、分段注释

2、注释和代码要一并更改。

3、注释要有意义。

4、一边写代码一边写注释，不要写完代码回过头来添加注释。

3. 什么是极限编程(XP)? 以及派对编程？

极限编程：

极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。

主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。

它将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈等方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

派对编程：

主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8 测试程序

1. 产生缺陷的原因

(1)软件本身：错误的设计、错误的代码、错误的设计实现。

(2)客户不清晰的需求：需求错误、Missing需求、不可实现的需求；

(3)其他原因，如项目的规模，众多的参与者导致的复杂性。

2. 有几种主要的缺陷类型？

1、算法缺陷

算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

2、计算和精度缺陷

算法或公式在实现时出现错误，或计算结果的精度达不到要求。

3、文档缺陷

文档和实际实现程序不一致。

4、过载缺陷/压力缺陷

程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

5、能力缺陷/边界缺陷

程序活动到达极限时，系统性能会变得不可接受。

6、计时缺陷/协调缺陷

多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

7、硬件和系统软件缺陷

提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

8、代码的标准和过程缺陷。

代码没有遵循组织机构的标准和过程。

3. 什么是正交缺陷分类？

被分类的任何一项故障都只属于一个类别，则分类方案是正交的。如果故障属于不止一个类，则失去了度量的意义。

4. 测试的各个阶段及其任务？

1、单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

2、集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

3、功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

4、性能测试：测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

5、验收测试：确定系统是按照用户的期望运转的。

6、安装测试：确保系统在实际环境中按照应有的方式运转。

7、系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

5.黑盒、白盒测试

（1）黑盒测试：将测试的对象看作是一个密闭的黑盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每种输入，观察到的输出与预期的输出相匹配。黑盒测试参考的文档是系统设计和程序设计阶段的文档。

优点：偏向于功能性的测试。不受内部逻辑约束。

缺点：不完备。黑盒法以 SRS 为依据，有一定的盲目性和不确定性，不可能揭示所有的错误。

黑盒测试方法：

1、等价分类法：将输入域划分为若干等价类。每个测试用例都代表了一类与它等价的其他例子。

2、边界值分析法：把测试值选在等价类的边界上进行测试。

3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。

4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合的情况。

（2）白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

优点：测试面广，可以测试一个模块的细节。

缺点：工作量大。

白盒测试方法:

• 语句覆盖 + 判定(分支)覆盖一个判断 + 条件覆盖：要求判定中的每个条件均按照“真”、“假”两种结果至少执行一次。
• 条件组合覆盖：要求所有条件结果的组合都至少出现一次(比如 A&&B，两个条件，那么就有四种条件的组合)。
• 路径测试法

6. 测试用例

测试用例(Test Case)，是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

是一组四元偶**<输入数据、前置条件、测试步骤、预期输出>**。

7.传统测试和OO测试有何不同

（1）需求分析与验证不同

（2）测试用例的生成不一样

（3）源代码分析不一样

（4）覆盖分析不一样

8.集成测试及其主要方法的分类？

1、自底向上集成

先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。

2、自顶向下集成

先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。

3、一次性集成

先测试每一个模块，之后将所有模块一并集成。

4、三明治集成

将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。

课件例题：

某城市的电话号码由 3 部分组成。这 3 个部分的名称与内容分别是:
地区码：空白或 3 位数字；前缀：非’0’或’1’开头的 3 位数字；后缀：4 位数字。
假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，请使用等价类的思路设计测试用例。

驱动，桩的概念

驱动程序：调用特定构件并向其传递测试用例的程序，即代替上层模块的调用程序。

桩：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。

什么是单元测试？ 什么是走查和检查？

将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

走查：不正式的的代码评审。

检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。

Chapter 9 系统测试

1. 系统测试的主要步骤及各自含义？

1、功能测试：根据SRS测试系统功能。

2、性能测试：根据SRS测试系统性能。

3、验收测试：根据客户的需求定义，由客户和用户一起测试。

4、安装测试：在用户环境下进行测试。

2. 什么是回归测试？

回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本相比，软件是否仍然以同样的方式执行同样的功能。

3.确认测试概念，确认测试分类？（基准测试、引导测试、并行测试）

确认测试：由用户检查软件系统是否满足了他们的需求的测试。

Pilot test: install on experimental basis
Alpha test: in-house test
Beta test: customer pilot
Parallel testing: new system operates in parallel with old system

1、基准测试：

由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。

2、引导测试：

在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。

4. 什么是alpha测试？β测试？

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1. α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；

目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

2. β测试

用户在不同场所进行测试。

β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

考试题型

1.名词解释（10/20分）

2.判断题（10/10分）

3.选择题（20/20分）

4.综合题（2/20分）

5.简述题（5/30分根据理解解释）

考试时间 17周考试

老师联系地址：科研楼 215

名词解释

Chapter 1

软件工程（Software Engineering）：在将有关软件开发与利用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件理论和技术工程的方法学。以及开发和维护软件的方法、过程、原则等。它是一个系统过程，既有对技术问题的综合分析，也有对开发过程和参与者的管理。

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。

软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。

重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。

测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。

工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。

Chapter 2

过程（Process）：软件开发过程中产生期望结果的一系列有序任务，设计活动、约束、资源等

软件生命周期：软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

原型： 一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

演化型原型：该原型的开发是用于了解问题，并作为将来实际提交系统的一部分。

抛弃型原型：仅用于了解问题、探索可行性，并不打算作为将来实际提交系统的一部分，而是用完就抛弃。

分阶段开发模型：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

螺旋模型：

RUP:迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

Chapter 3

项目进度：项目进度是对特定项目软件开发周期的刻画，包括对项目阶段、步骤、活动的分解。对各个离散活动交互关系的描述，对各个活动完成时间和整个项目完成时间的初步规划。

Chapter 4

需求：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

Chapter 5

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

Chapter 6

面向对象

内聚：软件内部组成成分的关联程度。

耦合：软件模块之间的关联程度。

Chapter 7

极限编程：极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。适应环境变化和需求变化，充分发挥开发人员的主动精神。

派对编程：主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8

算法缺陷:算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

计算和精度缺陷:算法或公式在实现时出现错误，或计算结果的精度达不到要求。

文档缺陷 : 文档和实际实现程序不一致。

过载缺陷/压力缺陷:程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

能力缺陷/边界缺陷:程序活动到达极限时，系统性能会变得不可接受。

计时缺陷/协调缺陷:多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

硬件和系统软件缺陷:提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

代码的标准和过程缺陷:代码没有遵循组织机构的标准和过程。

单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

黑盒测试：将测试的程序看作是一个不了解其内容的闭盒，我们提供输入并记录输出。测试的目标是实际的输出与预期一致。

白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

测试用例：是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

Chapter 9

系统测试 : 功能测试、性能测试、验收测试和安装测试统称为系统测试。

1、功能测试：根据SRS测试系统功能。对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

2、性能测试：根据SRS测试系统性能。测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

3、验收测试：确定系统是按照用户的期望运转的。

4、安装测试：在用户环境下进行测试。确保系统在实际环境中按照应有的方式运转。

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：

1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。

2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。

3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。

4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。

5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。

6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。

7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。

8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。

耦合：

1、内容耦合：A模块实际上修改了B模块，B模块完全依赖于A模块。

2、公共耦合：不同模块可以从公共数据存储区来访问和修改数据。

3、控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。

4、标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。

5、数据耦合：模块间传递的是数据值，是最受欢迎的耦合。

6、非耦合：模块相互之间没有信息传递，但是不太现实。

什么是设计模式？

设计模式：

一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。

面向对象设计模式分为：

模板方法模式 抽象类定义模板方法来实现一个操作中共同的步骤，并声明抽象的原语操 作来表示变化的部分

工厂方法模式 封装创建对象的代码

策略模式 在运行时选择算法。运行结束根据结果选择最好的算法

装饰者模式 运行时扩展对象的功能。给对象添加的新功能放入装饰者类

观察者模式 类似于管程思想

组合模式 异构的对象的汇集

访问者模式 将组合对象的新功能集中并封装于自身的类中

OO设计的基本原则？

1、单一职责原则

2、重用原则

3、开闭原则

4、里氏替换原则

5、依赖倒转原则

6、接口隔离原则

7、迪米特法则

OO开发有何优势？

1、语言的一致性：

采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案。

2、软件开发过程的一致性：

从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。

OO开发过程有几个步骤？

1、面向对象需求分析。

2、面向对象高层设计。

3、面向对象底层设计。

4、面向对象编程。OOP

5、面向对象测试。

Chapter 7 编写程序

1. 一般性的编程原则应该从哪三个方面考虑？

编程原则应该从控制结构，算法和数据结构三方面来考虑。

控制结构：程序如何传递数据。

算法：程序如何处理数据。

数据结构：程序如何储存数据。

（1）控制结构：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
（2）算法：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
（3）数据结构：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。

2. 在编写程序内部文档时，除了HCB头注释块header comment block外，还应添加什么注释信息？注意什么？

（1） 头注释块（header comment block，HCB）
将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。

（2） 其他程序注释——

• 解释性注释：本段源代码是在做什么的注释。
• 分解性注释：通过注释将代码分解成多个段。
• 版本注释：随着时间进行修改的记录。

（3） 有意义的变量名和语句标记
命名时尽量用有意义的变量名进行命名

（4） 排版格式以增强理解
注意缩进和间隔来反映基本的控制结构。

（5）文档化数据

注意的问题：

1、分段注释

2、注释和代码要一并更改。

3、注释要有意义。

4、一边写代码一边写注释，不要写完代码回过头来添加注释。

3. 什么是极限编程(XP)? 以及派对编程？

极限编程：

极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。

主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。

它将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈等方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

派对编程：

主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8 测试程序

1. 产生缺陷的原因

(1)软件本身：错误的设计、错误的代码、错误的设计实现。

(2)客户不清晰的需求：需求错误、Missing需求、不可实现的需求；

(3)其他原因，如项目的规模，众多的参与者导致的复杂性。

2. 有几种主要的缺陷类型？

1、算法缺陷

算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

2、计算和精度缺陷

算法或公式在实现时出现错误，或计算结果的精度达不到要求。

3、文档缺陷

文档和实际实现程序不一致。

4、过载缺陷/压力缺陷

程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

5、能力缺陷/边界缺陷

程序活动到达极限时，系统性能会变得不可接受。

6、计时缺陷/协调缺陷

多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

7、硬件和系统软件缺陷

提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

8、代码的标准和过程缺陷。

代码没有遵循组织机构的标准和过程。

3. 什么是正交缺陷分类？

被分类的任何一项故障都只属于一个类别，则分类方案是正交的。如果故障属于不止一个类，则失去了度量的意义。

4. 测试的各个阶段及其任务？

1、单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

2、集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

3、功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

4、性能测试：测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

5、验收测试：确定系统是按照用户的期望运转的。

6、安装测试：确保系统在实际环境中按照应有的方式运转。

7、系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

5.黑盒、白盒测试

（1）黑盒测试：将测试的对象看作是一个密闭的黑盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每种输入，观察到的输出与预期的输出相匹配。黑盒测试参考的文档是系统设计和程序设计阶段的文档。

优点：偏向于功能性的测试。不受内部逻辑约束。

缺点：不完备。黑盒法以 SRS 为依据，有一定的盲目性和不确定性，不可能揭示所有的错误。

黑盒测试方法：

1、等价分类法：将输入域划分为若干等价类。每个测试用例都代表了一类与它等价的其他例子。

2、边界值分析法：把测试值选在等价类的边界上进行测试。

3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。

4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合的情况。

（2）白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

优点：测试面广，可以测试一个模块的细节。

缺点：工作量大。

白盒测试方法:

• 语句覆盖 + 判定(分支)覆盖一个判断 + 条件覆盖：要求判定中的每个条件均按照“真”、“假”两种结果至少执行一次。
• 条件组合覆盖：要求所有条件结果的组合都至少出现一次(比如 A&&B，两个条件，那么就有四种条件的组合)。
• 路径测试法

6. 测试用例

测试用例(Test Case)，是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

是一组四元偶**<输入数据、前置条件、测试步骤、预期输出>**。

7.传统测试和OO测试有何不同

（1）需求分析与验证不同

（2）测试用例的生成不一样

（3）源代码分析不一样

（4）覆盖分析不一样

8.集成测试及其主要方法的分类？

1、自底向上集成

先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。

2、自顶向下集成

先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。

3、一次性集成

先测试每一个模块，之后将所有模块一并集成。

4、三明治集成

将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。

课件例题：

某城市的电话号码由 3 部分组成。这 3 个部分的名称与内容分别是:
地区码：空白或 3 位数字；前缀：非’0’或’1’开头的 3 位数字；后缀：4 位数字。
假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，请使用等价类的思路设计测试用例。

驱动，桩的概念

驱动程序：调用特定构件并向其传递测试用例的程序，即代替上层模块的调用程序。

桩：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。

什么是单元测试？ 什么是走查和检查？

将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

走查：不正式的的代码评审。

检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。

Chapter 9 系统测试

1. 系统测试的主要步骤及各自含义？

1、功能测试：根据SRS测试系统功能。

2、性能测试：根据SRS测试系统性能。

3、验收测试：根据客户的需求定义，由客户和用户一起测试。

4、安装测试：在用户环境下进行测试。

2. 什么是回归测试？

回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本相比，软件是否仍然以同样的方式执行同样的功能。

3.确认测试概念，确认测试分类？（基准测试、引导测试、并行测试）

确认测试：由用户检查软件系统是否满足了他们的需求的测试。

Pilot test: install on experimental basis
Alpha test: in-house test
Beta test: customer pilot
Parallel testing: new system operates in parallel with old system

1、基准测试：

由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。

2、引导测试：

在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。

4. 什么是alpha测试？β测试？

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1. α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；

目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

2. β测试

用户在不同场所进行测试。

β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

考试题型

1.名词解释（10/20分）

2.判断题（10/10分）

3.选择题（20/20分）

4.综合题（2/20分）

5.简述题（5/30分根据理解解释）

考试时间 17周考试

老师联系地址：科研楼 215

名词解释

Chapter 1

软件工程（Software Engineering）：在将有关软件开发与利用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件理论和技术工程的方法学。以及开发和维护软件的方法、过程、原则等。它是一个系统过程，既有对技术问题的综合分析，也有对开发过程和参与者的管理。

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。

软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。

重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。

测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。

工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。

Chapter 2

过程（Process）：软件开发过程中产生期望结果的一系列有序任务，设计活动、约束、资源等

软件生命周期：软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

原型： 一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

演化型原型：该原型的开发是用于了解问题，并作为将来实际提交系统的一部分。

抛弃型原型：仅用于了解问题、探索可行性，并不打算作为将来实际提交系统的一部分，而是用完就抛弃。

分阶段开发模型：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

螺旋模型：

RUP:迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

Chapter 3

项目进度：项目进度是对特定项目软件开发周期的刻画，包括对项目阶段、步骤、活动的分解。对各个离散活动交互关系的描述，对各个活动完成时间和整个项目完成时间的初步规划。

Chapter 4

需求：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

Chapter 5

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

Chapter 6

面向对象

内聚：软件内部组成成分的关联程度。

耦合：软件模块之间的关联程度。

Chapter 7

极限编程：极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。适应环境变化和需求变化，充分发挥开发人员的主动精神。

派对编程：主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8

算法缺陷:算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

计算和精度缺陷:算法或公式在实现时出现错误，或计算结果的精度达不到要求。

文档缺陷 : 文档和实际实现程序不一致。

过载缺陷/压力缺陷:程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

能力缺陷/边界缺陷:程序活动到达极限时，系统性能会变得不可接受。

计时缺陷/协调缺陷:多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

硬件和系统软件缺陷:提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

代码的标准和过程缺陷:代码没有遵循组织机构的标准和过程。

单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

黑盒测试：将测试的程序看作是一个不了解其内容的闭盒，我们提供输入并记录输出。测试的目标是实际的输出与预期一致。

白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

测试用例：是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

Chapter 9

系统测试 : 功能测试、性能测试、验收测试和安装测试统称为系统测试。

1、功能测试：根据SRS测试系统功能。对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

2、性能测试：根据SRS测试系统性能。测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

3、验收测试：确定系统是按照用户的期望运转的。

4、安装测试：在用户环境下进行测试。确保系统在实际环境中按照应有的方式运转。

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：

1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。

2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。

3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。

4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。

5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。

6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。

7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。

8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。

耦合：

1、内容耦合：A模块实际上修改了B模块，B模块完全依赖于A模块。

2、公共耦合：不同模块可以从公共数据存储区来访问和修改数据。

3、控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。

4、标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。

5、数据耦合：模块间传递的是数据值，是最受欢迎的耦合。

6、非耦合：模块相互之间没有信息传递，但是不太现实。

什么是设计模式？

设计模式：

一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。

面向对象设计模式分为：

模板方法模式 抽象类定义模板方法来实现一个操作中共同的步骤，并声明抽象的原语操 作来表示变化的部分

工厂方法模式 封装创建对象的代码

策略模式 在运行时选择算法。运行结束根据结果选择最好的算法

装饰者模式 运行时扩展对象的功能。给对象添加的新功能放入装饰者类

观察者模式 类似于管程思想

组合模式 异构的对象的汇集

访问者模式 将组合对象的新功能集中并封装于自身的类中

OO设计的基本原则？

1、单一职责原则

2、重用原则

3、开闭原则

4、里氏替换原则

5、依赖倒转原则

6、接口隔离原则

7、迪米特法则

OO开发有何优势？

1、语言的一致性：

采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案。

2、软件开发过程的一致性：

从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。

OO开发过程有几个步骤？

1、面向对象需求分析。

2、面向对象高层设计。

3、面向对象底层设计。

4、面向对象编程。OOP

5、面向对象测试。

Chapter 7 编写程序

1. 一般性的编程原则应该从哪三个方面考虑？

编程原则应该从控制结构，算法和数据结构三方面来考虑。

控制结构：程序如何传递数据。

算法：程序如何处理数据。

数据结构：程序如何储存数据。

（1）控制结构：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
（2）算法：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
（3）数据结构：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。

2. 在编写程序内部文档时，除了HCB头注释块header comment block外，还应添加什么注释信息？注意什么？

（1） 头注释块（header comment block，HCB）
将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。

（2） 其他程序注释——

• 解释性注释：本段源代码是在做什么的注释。
• 分解性注释：通过注释将代码分解成多个段。
• 版本注释：随着时间进行修改的记录。

（3） 有意义的变量名和语句标记
命名时尽量用有意义的变量名进行命名

（4） 排版格式以增强理解
注意缩进和间隔来反映基本的控制结构。

（5）文档化数据

注意的问题：

1、分段注释

2、注释和代码要一并更改。

3、注释要有意义。

4、一边写代码一边写注释，不要写完代码回过头来添加注释。

3. 什么是极限编程(XP)? 以及派对编程？

极限编程：

极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。

主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。

它将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈等方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

派对编程：

主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8 测试程序

1. 产生缺陷的原因

(1)软件本身：错误的设计、错误的代码、错误的设计实现。

(2)客户不清晰的需求：需求错误、Missing需求、不可实现的需求；

(3)其他原因，如项目的规模，众多的参与者导致的复杂性。

2. 有几种主要的缺陷类型？

1、算法缺陷

算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

2、计算和精度缺陷

算法或公式在实现时出现错误，或计算结果的精度达不到要求。

3、文档缺陷

文档和实际实现程序不一致。

4、过载缺陷/压力缺陷

程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

5、能力缺陷/边界缺陷

程序活动到达极限时，系统性能会变得不可接受。

6、计时缺陷/协调缺陷

多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

7、硬件和系统软件缺陷

提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

8、代码的标准和过程缺陷。

代码没有遵循组织机构的标准和过程。

3. 什么是正交缺陷分类？

被分类的任何一项故障都只属于一个类别，则分类方案是正交的。如果故障属于不止一个类，则失去了度量的意义。

4. 测试的各个阶段及其任务？

1、单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

2、集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

3、功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

4、性能测试：测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

5、验收测试：确定系统是按照用户的期望运转的。

6、安装测试：确保系统在实际环境中按照应有的方式运转。

7、系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

5.黑盒、白盒测试

（1）黑盒测试：将测试的对象看作是一个密闭的黑盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每种输入，观察到的输出与预期的输出相匹配。黑盒测试参考的文档是系统设计和程序设计阶段的文档。

优点：偏向于功能性的测试。不受内部逻辑约束。

缺点：不完备。黑盒法以 SRS 为依据，有一定的盲目性和不确定性，不可能揭示所有的错误。

黑盒测试方法：

1、等价分类法：将输入域划分为若干等价类。每个测试用例都代表了一类与它等价的其他例子。

2、边界值分析法：把测试值选在等价类的边界上进行测试。

3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。

4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合的情况。

（2）白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

优点：测试面广，可以测试一个模块的细节。

缺点：工作量大。

白盒测试方法:

• 语句覆盖 + 判定(分支)覆盖一个判断 + 条件覆盖：要求判定中的每个条件均按照“真”、“假”两种结果至少执行一次。
• 条件组合覆盖：要求所有条件结果的组合都至少出现一次(比如 A&&B，两个条件，那么就有四种条件的组合)。
• 路径测试法

6. 测试用例

测试用例(Test Case)，是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

是一组四元偶**<输入数据、前置条件、测试步骤、预期输出>**。

7.传统测试和OO测试有何不同

（1）需求分析与验证不同

（2）测试用例的生成不一样

（3）源代码分析不一样

（4）覆盖分析不一样

8.集成测试及其主要方法的分类？

1、自底向上集成

先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。

2、自顶向下集成

先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。

3、一次性集成

先测试每一个模块，之后将所有模块一并集成。

4、三明治集成

将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。

课件例题：

某城市的电话号码由 3 部分组成。这 3 个部分的名称与内容分别是:
地区码：空白或 3 位数字；前缀：非’0’或’1’开头的 3 位数字；后缀：4 位数字。
假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，请使用等价类的思路设计测试用例。

驱动，桩的概念

驱动程序：调用特定构件并向其传递测试用例的程序，即代替上层模块的调用程序。

桩：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。

什么是单元测试？ 什么是走查和检查？

将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

走查：不正式的的代码评审。

检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。

Chapter 9 系统测试

1. 系统测试的主要步骤及各自含义？

1、功能测试：根据SRS测试系统功能。

2、性能测试：根据SRS测试系统性能。

3、验收测试：根据客户的需求定义，由客户和用户一起测试。

4、安装测试：在用户环境下进行测试。

2. 什么是回归测试？

回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本相比，软件是否仍然以同样的方式执行同样的功能。

3.确认测试概念，确认测试分类？（基准测试、引导测试、并行测试）

确认测试：由用户检查软件系统是否满足了他们的需求的测试。

Pilot test: install on experimental basis
Alpha test: in-house test
Beta test: customer pilot
Parallel testing: new system operates in parallel with old system

1、基准测试：

由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。

2、引导测试：

在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。

4. 什么是alpha测试？β测试？

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1. α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；

目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

2. β测试

用户在不同场所进行测试。

β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

考试题型

1.名词解释（10/20分）

2.判断题（10/10分）

3.选择题（20/20分）

4.综合题（2/20分）

5.简述题（5/30分根据理解解释）

考试时间 17周考试

老师联系地址：科研楼 215

名词解释

Chapter 1

软件工程（Software Engineering）：在将有关软件开发与利用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件理论和技术工程的方法学。以及开发和维护软件的方法、过程、原则等。它是一个系统过程，既有对技术问题的综合分析，也有对开发过程和参与者的管理。

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。

软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。

重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。

测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。

工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。

Chapter 2

过程（Process）：软件开发过程中产生期望结果的一系列有序任务，设计活动、约束、资源等

软件生命周期：软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

原型： 一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

演化型原型：该原型的开发是用于了解问题，并作为将来实际提交系统的一部分。

抛弃型原型：仅用于了解问题、探索可行性，并不打算作为将来实际提交系统的一部分，而是用完就抛弃。

分阶段开发模型：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

螺旋模型：

RUP:迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

Chapter 3

项目进度：项目进度是对特定项目软件开发周期的刻画，包括对项目阶段、步骤、活动的分解。对各个离散活动交互关系的描述，对各个活动完成时间和整个项目完成时间的初步规划。

Chapter 4

需求：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

Chapter 5

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

Chapter 6

面向对象

内聚：软件内部组成成分的关联程度。

耦合：软件模块之间的关联程度。

Chapter 7

极限编程：极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。适应环境变化和需求变化，充分发挥开发人员的主动精神。

派对编程：主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8

算法缺陷:算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

计算和精度缺陷:算法或公式在实现时出现错误，或计算结果的精度达不到要求。

文档缺陷 : 文档和实际实现程序不一致。

过载缺陷/压力缺陷:程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

能力缺陷/边界缺陷:程序活动到达极限时，系统性能会变得不可接受。

计时缺陷/协调缺陷:多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

硬件和系统软件缺陷:提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

代码的标准和过程缺陷:代码没有遵循组织机构的标准和过程。

单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

黑盒测试：将测试的程序看作是一个不了解其内容的闭盒，我们提供输入并记录输出。测试的目标是实际的输出与预期一致。

白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

测试用例：是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

Chapter 9

系统测试 : 功能测试、性能测试、验收测试和安装测试统称为系统测试。

1、功能测试：根据SRS测试系统功能。对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

2、性能测试：根据SRS测试系统性能。测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

3、验收测试：确定系统是按照用户的期望运转的。

4、安装测试：在用户环境下进行测试。确保系统在实际环境中按照应有的方式运转。

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：

1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。

2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。

3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。

4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。

5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。

6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。

7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。

8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。

耦合：

1、内容耦合：A模块实际上修改了B模块，B模块完全依赖于A模块。

2、公共耦合：不同模块可以从公共数据存储区来访问和修改数据。

3、控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。

4、标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。

5、数据耦合：模块间传递的是数据值，是最受欢迎的耦合。

6、非耦合：模块相互之间没有信息传递，但是不太现实。

什么是设计模式？

设计模式：

一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。

面向对象设计模式分为：

模板方法模式 抽象类定义模板方法来实现一个操作中共同的步骤，并声明抽象的原语操 作来表示变化的部分

工厂方法模式 封装创建对象的代码

策略模式 在运行时选择算法。运行结束根据结果选择最好的算法

装饰者模式 运行时扩展对象的功能。给对象添加的新功能放入装饰者类

观察者模式 类似于管程思想

组合模式 异构的对象的汇集

访问者模式 将组合对象的新功能集中并封装于自身的类中

OO设计的基本原则？

1、单一职责原则

2、重用原则

3、开闭原则

4、里氏替换原则

5、依赖倒转原则

6、接口隔离原则

7、迪米特法则

OO开发有何优势？

1、语言的一致性：

采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案。

2、软件开发过程的一致性：

从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。

OO开发过程有几个步骤？

1、面向对象需求分析。

2、面向对象高层设计。

3、面向对象底层设计。

4、面向对象编程。OOP

5、面向对象测试。

Chapter 7 编写程序

1. 一般性的编程原则应该从哪三个方面考虑？

编程原则应该从控制结构，算法和数据结构三方面来考虑。

控制结构：程序如何传递数据。

算法：程序如何处理数据。

数据结构：程序如何储存数据。

（1）控制结构：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
（2）算法：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
（3）数据结构：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。

2. 在编写程序内部文档时，除了HCB头注释块header comment block外，还应添加什么注释信息？注意什么？

（1） 头注释块（header comment block，HCB）
将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。

（2） 其他程序注释——

• 解释性注释：本段源代码是在做什么的注释。
• 分解性注释：通过注释将代码分解成多个段。
• 版本注释：随着时间进行修改的记录。

（3） 有意义的变量名和语句标记
命名时尽量用有意义的变量名进行命名

（4） 排版格式以增强理解
注意缩进和间隔来反映基本的控制结构。

（5）文档化数据

注意的问题：

1、分段注释

2、注释和代码要一并更改。

3、注释要有意义。

4、一边写代码一边写注释，不要写完代码回过头来添加注释。

3. 什么是极限编程(XP)? 以及派对编程？

极限编程：

极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。

主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。

它将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈等方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

派对编程：

主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8 测试程序

1. 产生缺陷的原因

(1)软件本身：错误的设计、错误的代码、错误的设计实现。

(2)客户不清晰的需求：需求错误、Missing需求、不可实现的需求；

(3)其他原因，如项目的规模，众多的参与者导致的复杂性。

2. 有几种主要的缺陷类型？

1、算法缺陷

算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

2、计算和精度缺陷

算法或公式在实现时出现错误，或计算结果的精度达不到要求。

3、文档缺陷

文档和实际实现程序不一致。

4、过载缺陷/压力缺陷

程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

5、能力缺陷/边界缺陷

程序活动到达极限时，系统性能会变得不可接受。

6、计时缺陷/协调缺陷

多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

7、硬件和系统软件缺陷

提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

8、代码的标准和过程缺陷。

代码没有遵循组织机构的标准和过程。

3. 什么是正交缺陷分类？

被分类的任何一项故障都只属于一个类别，则分类方案是正交的。如果故障属于不止一个类，则失去了度量的意义。

4. 测试的各个阶段及其任务？

1、单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

2、集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

3、功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

4、性能测试：测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

5、验收测试：确定系统是按照用户的期望运转的。

6、安装测试：确保系统在实际环境中按照应有的方式运转。

7、系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

5.黑盒、白盒测试

（1）黑盒测试：将测试的对象看作是一个密闭的黑盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每种输入，观察到的输出与预期的输出相匹配。黑盒测试参考的文档是系统设计和程序设计阶段的文档。

优点：偏向于功能性的测试。不受内部逻辑约束。

缺点：不完备。黑盒法以 SRS 为依据，有一定的盲目性和不确定性，不可能揭示所有的错误。

黑盒测试方法：

1、等价分类法：将输入域划分为若干等价类。每个测试用例都代表了一类与它等价的其他例子。

2、边界值分析法：把测试值选在等价类的边界上进行测试。

3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。

4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合的情况。

（2）白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

优点：测试面广，可以测试一个模块的细节。

缺点：工作量大。

白盒测试方法:

• 语句覆盖 + 判定(分支)覆盖一个判断 + 条件覆盖：要求判定中的每个条件均按照“真”、“假”两种结果至少执行一次。
• 条件组合覆盖：要求所有条件结果的组合都至少出现一次(比如 A&&B，两个条件，那么就有四种条件的组合)。
• 路径测试法

6. 测试用例

测试用例(Test Case)，是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

是一组四元偶**<输入数据、前置条件、测试步骤、预期输出>**。

7.传统测试和OO测试有何不同

（1）需求分析与验证不同

（2）测试用例的生成不一样

（3）源代码分析不一样

（4）覆盖分析不一样

8.集成测试及其主要方法的分类？

1、自底向上集成

先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。

2、自顶向下集成

先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。

3、一次性集成

先测试每一个模块，之后将所有模块一并集成。

4、三明治集成

将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。

课件例题：

某城市的电话号码由 3 部分组成。这 3 个部分的名称与内容分别是:
地区码：空白或 3 位数字；前缀：非’0’或’1’开头的 3 位数字；后缀：4 位数字。
假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，请使用等价类的思路设计测试用例。

驱动，桩的概念

驱动程序：调用特定构件并向其传递测试用例的程序，即代替上层模块的调用程序。

桩：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。

什么是单元测试？ 什么是走查和检查？

将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

走查：不正式的的代码评审。

检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。

Chapter 9 系统测试

1. 系统测试的主要步骤及各自含义？

1、功能测试：根据SRS测试系统功能。

2、性能测试：根据SRS测试系统性能。

3、验收测试：根据客户的需求定义，由客户和用户一起测试。

4、安装测试：在用户环境下进行测试。

2. 什么是回归测试？

回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本相比，软件是否仍然以同样的方式执行同样的功能。

3.确认测试概念，确认测试分类？（基准测试、引导测试、并行测试）

确认测试：由用户检查软件系统是否满足了他们的需求的测试。

Pilot test: install on experimental basis
Alpha test: in-house test
Beta test: customer pilot
Parallel testing: new system operates in parallel with old system

1、基准测试：

由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。

2、引导测试：

在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。

4. 什么是alpha测试？β测试？

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1. α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；

目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

2. β测试

用户在不同场所进行测试。

β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

考试题型

1.名词解释（10/20分）

2.判断题（10/10分）

3.选择题（20/20分）

4.综合题（2/20分）

5.简述题（5/30分根据理解解释）

考试时间 17周考试

老师联系地址：科研楼 215

名词解释

Chapter 1

软件工程（Software Engineering）：在将有关软件开发与利用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件理论和技术工程的方法学。以及开发和维护软件的方法、过程、原则等。它是一个系统过程，既有对技术问题的综合分析，也有对开发过程和参与者的管理。

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。

软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。

重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。

测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。

工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。

Chapter 2

过程（Process）：软件开发过程中产生期望结果的一系列有序任务，设计活动、约束、资源等

软件生命周期：软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

原型： 一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

演化型原型：该原型的开发是用于了解问题，并作为将来实际提交系统的一部分。

抛弃型原型：仅用于了解问题、探索可行性，并不打算作为将来实际提交系统的一部分，而是用完就抛弃。

分阶段开发模型：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

螺旋模型：

RUP:迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

Chapter 3

项目进度：项目进度是对特定项目软件开发周期的刻画，包括对项目阶段、步骤、活动的分解。对各个离散活动交互关系的描述，对各个活动完成时间和整个项目完成时间的初步规划。

Chapter 4

需求：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

Chapter 5

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

Chapter 6

面向对象

内聚：软件内部组成成分的关联程度。

耦合：软件模块之间的关联程度。

Chapter 7

极限编程：极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。适应环境变化和需求变化，充分发挥开发人员的主动精神。

派对编程：主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8

算法缺陷:算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

计算和精度缺陷:算法或公式在实现时出现错误，或计算结果的精度达不到要求。

文档缺陷 : 文档和实际实现程序不一致。

过载缺陷/压力缺陷:程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

能力缺陷/边界缺陷:程序活动到达极限时，系统性能会变得不可接受。

计时缺陷/协调缺陷:多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

硬件和系统软件缺陷:提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

代码的标准和过程缺陷:代码没有遵循组织机构的标准和过程。

单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

黑盒测试：将测试的程序看作是一个不了解其内容的闭盒，我们提供输入并记录输出。测试的目标是实际的输出与预期一致。

白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

测试用例：是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

Chapter 9

系统测试 : 功能测试、性能测试、验收测试和安装测试统称为系统测试。

1、功能测试：根据SRS测试系统功能。对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

2、性能测试：根据SRS测试系统性能。测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

3、验收测试：确定系统是按照用户的期望运转的。

4、安装测试：在用户环境下进行测试。确保系统在实际环境中按照应有的方式运转。

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：

1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。

2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。

3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。

4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。

5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。

6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。

7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。

8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。

耦合：

1、内容耦合：A模块实际上修改了B模块，B模块完全依赖于A模块。

2、公共耦合：不同模块可以从公共数据存储区来访问和修改数据。

3、控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。

4、标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。

5、数据耦合：模块间传递的是数据值，是最受欢迎的耦合。

6、非耦合：模块相互之间没有信息传递，但是不太现实。

什么是设计模式？

设计模式：

一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。

面向对象设计模式分为：

模板方法模式 抽象类定义模板方法来实现一个操作中共同的步骤，并声明抽象的原语操 作来表示变化的部分

工厂方法模式 封装创建对象的代码

策略模式 在运行时选择算法。运行结束根据结果选择最好的算法

装饰者模式 运行时扩展对象的功能。给对象添加的新功能放入装饰者类

观察者模式 类似于管程思想

组合模式 异构的对象的汇集

访问者模式 将组合对象的新功能集中并封装于自身的类中

OO设计的基本原则？

1、单一职责原则

2、重用原则

3、开闭原则

4、里氏替换原则

5、依赖倒转原则

6、接口隔离原则

7、迪米特法则

OO开发有何优势？

1、语言的一致性：

采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案。

2、软件开发过程的一致性：

从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。

OO开发过程有几个步骤？

1、面向对象需求分析。

2、面向对象高层设计。

3、面向对象底层设计。

4、面向对象编程。OOP

5、面向对象测试。

Chapter 7 编写程序

1. 一般性的编程原则应该从哪三个方面考虑？

编程原则应该从控制结构，算法和数据结构三方面来考虑。

控制结构：程序如何传递数据。

算法：程序如何处理数据。

数据结构：程序如何储存数据。

（1）控制结构：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
（2）算法：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
（3）数据结构：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。

2. 在编写程序内部文档时，除了HCB头注释块header comment block外，还应添加什么注释信息？注意什么？

（1） 头注释块（header comment block，HCB）
将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。

（2） 其他程序注释——

• 解释性注释：本段源代码是在做什么的注释。
• 分解性注释：通过注释将代码分解成多个段。
• 版本注释：随着时间进行修改的记录。

（3） 有意义的变量名和语句标记
命名时尽量用有意义的变量名进行命名

（4） 排版格式以增强理解
注意缩进和间隔来反映基本的控制结构。

（5）文档化数据

注意的问题：

1、分段注释

2、注释和代码要一并更改。

3、注释要有意义。

4、一边写代码一边写注释，不要写完代码回过头来添加注释。

3. 什么是极限编程(XP)? 以及派对编程？

极限编程：

极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。

主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。

它将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈等方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

派对编程：

主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8 测试程序

1. 产生缺陷的原因

(1)软件本身：错误的设计、错误的代码、错误的设计实现。

(2)客户不清晰的需求：需求错误、Missing需求、不可实现的需求；

(3)其他原因，如项目的规模，众多的参与者导致的复杂性。

2. 有几种主要的缺陷类型？

1、算法缺陷

算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

2、计算和精度缺陷

算法或公式在实现时出现错误，或计算结果的精度达不到要求。

3、文档缺陷

文档和实际实现程序不一致。

4、过载缺陷/压力缺陷

程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

5、能力缺陷/边界缺陷

程序活动到达极限时，系统性能会变得不可接受。

6、计时缺陷/协调缺陷

多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

7、硬件和系统软件缺陷

提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

8、代码的标准和过程缺陷。

代码没有遵循组织机构的标准和过程。

3. 什么是正交缺陷分类？

被分类的任何一项故障都只属于一个类别，则分类方案是正交的。如果故障属于不止一个类，则失去了度量的意义。

4. 测试的各个阶段及其任务？

1、单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

2、集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

3、功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

4、性能测试：测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

5、验收测试：确定系统是按照用户的期望运转的。

6、安装测试：确保系统在实际环境中按照应有的方式运转。

7、系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

5.黑盒、白盒测试

（1）黑盒测试：将测试的对象看作是一个密闭的黑盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每种输入，观察到的输出与预期的输出相匹配。黑盒测试参考的文档是系统设计和程序设计阶段的文档。

优点：偏向于功能性的测试。不受内部逻辑约束。

缺点：不完备。黑盒法以 SRS 为依据，有一定的盲目性和不确定性，不可能揭示所有的错误。

黑盒测试方法：

1、等价分类法：将输入域划分为若干等价类。每个测试用例都代表了一类与它等价的其他例子。

2、边界值分析法：把测试值选在等价类的边界上进行测试。

3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。

4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合的情况。

（2）白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

优点：测试面广，可以测试一个模块的细节。

缺点：工作量大。

白盒测试方法:

• 语句覆盖 + 判定(分支)覆盖一个判断 + 条件覆盖：要求判定中的每个条件均按照“真”、“假”两种结果至少执行一次。
• 条件组合覆盖：要求所有条件结果的组合都至少出现一次(比如 A&&B，两个条件，那么就有四种条件的组合)。
• 路径测试法

6. 测试用例

测试用例(Test Case)，是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

是一组四元偶**<输入数据、前置条件、测试步骤、预期输出>**。

7.传统测试和OO测试有何不同

（1）需求分析与验证不同

（2）测试用例的生成不一样

（3）源代码分析不一样

（4）覆盖分析不一样

8.集成测试及其主要方法的分类？

1、自底向上集成

先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。

2、自顶向下集成

先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。

3、一次性集成

先测试每一个模块，之后将所有模块一并集成。

4、三明治集成

将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。

课件例题：

某城市的电话号码由 3 部分组成。这 3 个部分的名称与内容分别是:
地区码：空白或 3 位数字；前缀：非’0’或’1’开头的 3 位数字；后缀：4 位数字。
假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，请使用等价类的思路设计测试用例。

驱动，桩的概念

驱动程序：调用特定构件并向其传递测试用例的程序，即代替上层模块的调用程序。

桩：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。

什么是单元测试？ 什么是走查和检查？

将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

走查：不正式的的代码评审。

检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。

Chapter 9 系统测试

1. 系统测试的主要步骤及各自含义？

1、功能测试：根据SRS测试系统功能。

2、性能测试：根据SRS测试系统性能。

3、验收测试：根据客户的需求定义，由客户和用户一起测试。

4、安装测试：在用户环境下进行测试。

2. 什么是回归测试？

回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本相比，软件是否仍然以同样的方式执行同样的功能。

3.确认测试概念，确认测试分类？（基准测试、引导测试、并行测试）

确认测试：由用户检查软件系统是否满足了他们的需求的测试。

Pilot test: install on experimental basis
Alpha test: in-house test
Beta test: customer pilot
Parallel testing: new system operates in parallel with old system

1、基准测试：

由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。

2、引导测试：

在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。

4. 什么是alpha测试？β测试？

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1. α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；

目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

2. β测试

用户在不同场所进行测试。

β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

考试题型

1.名词解释（10/20分）

2.判断题（10/10分）

3.选择题（20/20分）

4.综合题（2/20分）

5.简述题（5/30分根据理解解释）

考试时间 17周考试

老师联系地址：科研楼 215

名词解释

Chapter 1

软件工程（Software Engineering）：在将有关软件开发与利用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件理论和技术工程的方法学。以及开发和维护软件的方法、过程、原则等。它是一个系统过程，既有对技术问题的综合分析，也有对开发过程和参与者的管理。

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。

软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。

重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。

测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。

工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。

Chapter 2

过程（Process）：软件开发过程中产生期望结果的一系列有序任务，设计活动、约束、资源等

软件生命周期：软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

原型： 一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

演化型原型：该原型的开发是用于了解问题，并作为将来实际提交系统的一部分。

抛弃型原型：仅用于了解问题、探索可行性，并不打算作为将来实际提交系统的一部分，而是用完就抛弃。

分阶段开发模型：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

螺旋模型：

RUP:迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

Chapter 3

项目进度：项目进度是对特定项目软件开发周期的刻画，包括对项目阶段、步骤、活动的分解。对各个离散活动交互关系的描述，对各个活动完成时间和整个项目完成时间的初步规划。

Chapter 4

需求：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

Chapter 5

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

Chapter 6

面向对象

内聚：软件内部组成成分的关联程度。

耦合：软件模块之间的关联程度。

Chapter 7

极限编程：极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。适应环境变化和需求变化，充分发挥开发人员的主动精神。

派对编程：主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8

算法缺陷:算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

计算和精度缺陷:算法或公式在实现时出现错误，或计算结果的精度达不到要求。

文档缺陷 : 文档和实际实现程序不一致。

过载缺陷/压力缺陷:程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

能力缺陷/边界缺陷:程序活动到达极限时，系统性能会变得不可接受。

计时缺陷/协调缺陷:多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

硬件和系统软件缺陷:提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

代码的标准和过程缺陷:代码没有遵循组织机构的标准和过程。

单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

黑盒测试：将测试的程序看作是一个不了解其内容的闭盒，我们提供输入并记录输出。测试的目标是实际的输出与预期一致。

白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

测试用例：是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

Chapter 9

系统测试 : 功能测试、性能测试、验收测试和安装测试统称为系统测试。

1、功能测试：根据SRS测试系统功能。对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

2、性能测试：根据SRS测试系统性能。测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

3、验收测试：确定系统是按照用户的期望运转的。

4、安装测试：在用户环境下进行测试。确保系统在实际环境中按照应有的方式运转。

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：

1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。

2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。

3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。

4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。

5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。

6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。

7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。

8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。

耦合：

1、内容耦合：A模块实际上修改了B模块，B模块完全依赖于A模块。

2、公共耦合：不同模块可以从公共数据存储区来访问和修改数据。

3、控制耦合：一个模块通过传递参数或返回代码来控制另一个模块的活动。

4、标记/特征耦合：使用一个复杂的数据结构进行模块间传递消息，并且传递的是该数据结构本身。比如将一个数组传递给另一个模块，数组仅用于计算而非控制。

5、数据耦合：模块间传递的是数据值，是最受欢迎的耦合。

6、非耦合：模块相互之间没有信息传递，但是不太现实。

什么是设计模式？

设计模式：

一种针对软件模块给出的一般性解决方案，提供较低层次的设计决策。

面向对象设计模式分为：

模板方法模式 抽象类定义模板方法来实现一个操作中共同的步骤，并声明抽象的原语操 作来表示变化的部分

工厂方法模式 封装创建对象的代码

策略模式 在运行时选择算法。运行结束根据结果选择最好的算法

装饰者模式 运行时扩展对象的功能。给对象添加的新功能放入装饰者类

观察者模式 类似于管程思想

组合模式 异构的对象的汇集

访问者模式 将组合对象的新功能集中并封装于自身的类中

OO设计的基本原则？

1、单一职责原则

2、重用原则

3、开闭原则

4、里氏替换原则

5、依赖倒转原则

6、接口隔离原则

7、迪米特法则

OO开发有何优势？

1、语言的一致性：

采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案。

2、软件开发过程的一致性：

从需求分析和定义、高层设计、底层设计到编码和测试等，所有的过程都采用相同的语义结构。

OO开发过程有几个步骤？

1、面向对象需求分析。

2、面向对象高层设计。

3、面向对象底层设计。

4、面向对象编程。OOP

5、面向对象测试。

Chapter 7 编写程序

1. 一般性的编程原则应该从哪三个方面考虑？

编程原则应该从控制结构，算法和数据结构三方面来考虑。

控制结构：程序如何传递数据。

算法：程序如何处理数据。

数据结构：程序如何储存数据。

（1）控制结构：当设计转变成代码时，我们希望保留组件的控制结构，在隐含调用的面向对象设计中，控制是基于系统状态和变量而变化的。
（2）算法：在编写代码时，程序设计通常会制定一类算法，用于编写组件。
（3）数据结构：编写程序时，应该安排数据的格式并进行存储，这样的数据管理和操作才能简明易懂。

2. 在编写程序内部文档时，除了HCB头注释块header comment block外，还应添加什么注释信息？注意什么？

（1） 头注释块（header comment block，HCB）
将一组注释信息放在每个构件的开始部分，包含构件名，作者，配置在整个系统设计的哪个部分上，何时编写和修改的，为什么要有该构件，构件是如何使用数据结构，算法和控制的。

（2） 其他程序注释——

• 解释性注释：本段源代码是在做什么的注释。
• 分解性注释：通过注释将代码分解成多个段。
• 版本注释：随着时间进行修改的记录。

（3） 有意义的变量名和语句标记
命名时尽量用有意义的变量名进行命名

（4） 排版格式以增强理解
注意缩进和间隔来反映基本的控制结构。

（5）文档化数据

注意的问题：

1、分段注释

2、注释和代码要一并更改。

3、注释要有意义。

4、一边写代码一边写注释，不要写完代码回过头来添加注释。

3. 什么是极限编程(XP)? 以及派对编程？

极限编程：

极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。

主要特征：适应环境变化和需求变化，充分发挥开发人员的主动精神。

它将复杂的开发过程分解为一个个相对比较简单的小周期，通过交流、反馈等方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

派对编程：

主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8 测试程序

1. 产生缺陷的原因

(1)软件本身：错误的设计、错误的代码、错误的设计实现。

(2)客户不清晰的需求：需求错误、Missing需求、不可实现的需求；

(3)其他原因，如项目的规模，众多的参与者导致的复杂性。

2. 有几种主要的缺陷类型？

1、算法缺陷

算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

2、计算和精度缺陷

算法或公式在实现时出现错误，或计算结果的精度达不到要求。

3、文档缺陷

文档和实际实现程序不一致。

4、过载缺陷/压力缺陷

程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

5、能力缺陷/边界缺陷

程序活动到达极限时，系统性能会变得不可接受。

6、计时缺陷/协调缺陷

多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

7、硬件和系统软件缺陷

提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

8、代码的标准和过程缺陷。

代码没有遵循组织机构的标准和过程。

3. 什么是正交缺陷分类？

被分类的任何一项故障都只属于一个类别，则分类方案是正交的。如果故障属于不止一个类，则失去了度量的意义。

4. 测试的各个阶段及其任务？

1、单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

2、集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

3、功能测试：对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

4、性能测试：测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

5、验收测试：确定系统是按照用户的期望运转的。

6、安装测试：确保系统在实际环境中按照应有的方式运转。

7、系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

5.黑盒、白盒测试

（1）黑盒测试：将测试的对象看作是一个密闭的黑盒，我们的测试就是向闭盒提供输入的数据，并记录产生的输出。测试的目标是确保针对每种输入，观察到的输出与预期的输出相匹配。黑盒测试参考的文档是系统设计和程序设计阶段的文档。

优点：偏向于功能性的测试。不受内部逻辑约束。

缺点：不完备。黑盒法以 SRS 为依据，有一定的盲目性和不确定性，不可能揭示所有的错误。

黑盒测试方法：

1、等价分类法：将输入域划分为若干等价类。每个测试用例都代表了一类与它等价的其他例子。

2、边界值分析法：把测试值选在等价类的边界上进行测试。

3、错误猜测法：猜测程序中哪些地方容易出错，并据此设计测试用例。

4、因果图法：适用于被测试程序有很多输入条件，程序的输出又依赖输入条件的各种组合的情况。

（2）白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

优点：测试面广，可以测试一个模块的细节。

缺点：工作量大。

白盒测试方法:

• 语句覆盖 + 判定(分支)覆盖一个判断 + 条件覆盖：要求判定中的每个条件均按照“真”、“假”两种结果至少执行一次。
• 条件组合覆盖：要求所有条件结果的组合都至少出现一次(比如 A&&B，两个条件，那么就有四种条件的组合)。
• 路径测试法

6. 测试用例

测试用例(Test Case)，是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

是一组四元偶**<输入数据、前置条件、测试步骤、预期输出>**。

7.传统测试和OO测试有何不同

（1）需求分析与验证不同

（2）测试用例的生成不一样

（3）源代码分析不一样

（4）覆盖分析不一样

8.集成测试及其主要方法的分类？

1、自底向上集成

先测试系统最底层的模块，接着测试调用这些底层模块的模块，直到测试完毕。

2、自顶向下集成

先测试系统最上层的模块，接着测试顶层模块调用的下层模块，直到测试完毕。

3、一次性集成

先测试每一个模块，之后将所有模块一并集成。

4、三明治集成

将系统分成三层，目标层处于中间、目标层上有一层，目标层下有一层。在顶层采用自顶向下的方式集成，在较低层采用自底向上的方式集成，测试集中于目标层。

课件例题：

某城市的电话号码由 3 部分组成。这 3 个部分的名称与内容分别是:
地区码：空白或 3 位数字；前缀：非’0’或’1’开头的 3 位数字；后缀：4 位数字。
假定被测程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，请使用等价类的思路设计测试用例。

驱动，桩的概念

驱动程序：调用特定构件并向其传递测试用例的程序，即代替上层模块的调用程序。

桩：一种专用程序，用于模拟测试时缺少构件时的活动。桩应答调用序列，并传回输出数据，使测试能够正常的进行下去，即代替下级模块的仿真程序。

什么是单元测试？ 什么是走查和检查？

将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

走查：不正式的的代码评审。

检查：正式的代码评审，事先准备问题清单，依据清单比对代码和文档的一致性。

Chapter 9 系统测试

1. 系统测试的主要步骤及各自含义？

1、功能测试：根据SRS测试系统功能。

2、性能测试：根据SRS测试系统性能。

3、验收测试：根据客户的需求定义，由客户和用户一起测试。

4、安装测试：在用户环境下进行测试。

2. 什么是回归测试？

回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本相比，软件是否仍然以同样的方式执行同样的功能。

3.确认测试概念，确认测试分类？（基准测试、引导测试、并行测试）

确认测试：由用户检查软件系统是否满足了他们的需求的测试。

Pilot test: install on experimental basis
Alpha test: in-house test
Beta test: customer pilot
Parallel testing: new system operates in parallel with old system

1、基准测试：

由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。

2、引导测试：

在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。

4. 什么是alpha测试？β测试？

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1. α测试

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；

目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。

2. β测试

用户在不同场所进行测试。

β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

考试题型

1.名词解释（10/20分）

2.判断题（10/10分）

3.选择题（20/20分）

4.综合题（2/20分）

5.简述题（5/30分根据理解解释）

考试时间 17周考试

老师联系地址：科研楼 215

名词解释

Chapter 1

软件工程（Software Engineering）：在将有关软件开发与利用的概念科学体系化的基础上，研究如何有计划、有效率、经济的开发和利用能在计算机上正确运行的软件理论和技术工程的方法学。以及开发和维护软件的方法、过程、原则等。它是一个系统过程，既有对技术问题的综合分析，也有对开发过程和参与者的管理。

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。

软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。

重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。

测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。

工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。

Chapter 2

过程（Process）：软件开发过程中产生期望结果的一系列有序任务，设计活动、约束、资源等

软件生命周期：软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

原型： 一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

演化型原型：该原型的开发是用于了解问题，并作为将来实际提交系统的一部分。

抛弃型原型：仅用于了解问题、探索可行性，并不打算作为将来实际提交系统的一部分，而是用完就抛弃。

分阶段开发模型：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

螺旋模型：

RUP:迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

Chapter 3

项目进度：项目进度是对特定项目软件开发周期的刻画，包括对项目阶段、步骤、活动的分解。对各个离散活动交互关系的描述，对各个活动完成时间和整个项目完成时间的初步规划。

Chapter 4

需求：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

Chapter 5

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

Chapter 6

面向对象

内聚：软件内部组成成分的关联程度。

耦合：软件模块之间的关联程度。

Chapter 7

极限编程：极限编程（XP）是一种轻量级的软件开发方法，属于敏捷开发方法。适应环境变化和需求变化，充分发挥开发人员的主动精神。

派对编程：主要的敏捷开发方法之一，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

Chapter 8

算法缺陷:算法的某些处理步骤或逻辑有问题，以至于软件部件对给定的输入数据无法产生正确的输出。

计算和精度缺陷:算法或公式在实现时出现错误，或计算结果的精度达不到要求。

文档缺陷 : 文档和实际实现程序不一致。

过载缺陷/压力缺陷:程序运行时，对数据结构的使用超过了其承载能力。（数组越界、缓冲区溢出等）

能力缺陷/边界缺陷:程序活动到达极限时，系统性能会变得不可接受。

计时缺陷/协调缺陷:多个同时执行或者一个仔细定义的顺序执行的进程之间（管理）协调不当。

硬件和系统软件缺陷:提供的硬件或者系统软件并没有按照文档中的操作条件或步骤运作。

代码的标准和过程缺陷:代码没有遵循组织机构的标准和过程。

单元测试：将每个程序构件与系统中的其他构件隔离，对其本身进行测试。

集成测试：验证系统构件是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程。

黑盒测试：将测试的程序看作是一个不了解其内容的闭盒，我们提供输入并记录输出。测试的目标是实际的输出与预期一致。

白盒测试：将测试对象看作一个白盒，然后根据测试对象的结构用不同的方式进行测试。（已知结构）

测试用例：是以测试程序为目标而挑选的输入数据，包括对应的期望结果。以便测试某个程序路径或核实是否满足某个特定需求。

Chapter 9

系统测试 : 功能测试、性能测试、验收测试和安装测试统称为系统测试。

1、功能测试：根据SRS测试系统功能。对系统进行评估，以确定集成的系统是否确实执行了需求规格说明中描述的功能，其结果是一个可运转的系统。

2、性能测试：根据SRS测试系统性能。测试系统的软硬件性能是否符合需求规格说明文档。 其结果是一个确认的系统。

3、验收测试：确定系统是按照用户的期望运转的。

4、安装测试：在用户环境下进行测试。确保系统在实际环境中按照应有的方式运转。

α测试：内部测试。客户进行实际的测试前，先自己组织团队（或者委托其他团队）测试这个系统。

β测试：公测。客户实际进行的测试。

1、偶然内聚：模块各部分不相关，只为方便或偶然性原因放入同一模块。比如强行放入一个类中没有任何关系的方法。

2、逻辑内聚：模块中各部分只通过代码的逻辑结构相关联，会共享程序状态和代码结构，但相对于数据、功能和目标的内聚比较弱。 比如因为有相同的某个计算步骤而放在?一起的两个没有关系的计算。

3、时间内聚：部件各部分要求在同一时间完成或被同一任务使用而形成联系。比如初始化模块中需要完成变量赋值、打开某文件等工作。

4、过程内聚：要求必须按照某个确定的顺序执行一系列功能，模块内功能组合在一起只是为了确保这个顺序。其与时间性内聚相比优点在于其功能总是涉及相关活动和针对相关目标，如写数据->检查数据->操作数据这一过程。

5、通讯内聚：各部分访问和操作同一数据集，如来自于同一传感器的所有不相干数据。

6、顺序内聚 ：各部分有输入输出关系，操作同一数据集，并且操作有顺序。

7、功能内聚：理想情况，各部分组成单一功能，且每个处理元素对功能都是必须的，每个元素执行且只执行设计功能，如一个简单的输出程序。

8、信息内聚：在功能内聚的基础上，进行数据抽象化和基于对象的设计。

耦合：

[TOC]

参考资料

友链

山东大学软件工程期末复习知识点总结-CSDN博客

2022软件工程期末复习笔记_Stephen Haw King的博客-CSDN博客

山东大学软件学院2020-2021 软件工程考试纲要与考题回忆_山东大学软件学院考试大纲-CSDN博客

UML一一 类图关系 (泛化、实现、依赖、关联、聚合、组合)_uml类图关系-CSDN博客

Chapter 1 软件工程概述

1.软件工程的定义、目标、方法

定义：两个关键词

理解问题的本质（nature），并给出解决方案（solution）。

也就是说，用系统科学的方法解决问题（problem-solution）。

目标：设计和开发高质量的软件。（付出较低开发成本；达到要求的功能；取得较好的性能；开发的软件易于移植；只需较低的维护费用；能按时完成开发任务，及时交付使用）

方法：面向过程、面向对象等

2.错误（error）、缺陷（fault）、失效/故障（Failure）

错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。

故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。

失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。

联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。

A fault: occurs when a human makes a mistake, called an error, in performing some software activities （误解需求>与意图不符>其他故障）
A failure: is a departure from the system’s required behavior（交付前/交付后/测试/维护）

3.软件质量从哪几个方面进行评价？什么是好的软件

软件质量（quality of software）

• The quality of the product 软件产品的质量(用户、开发者)
• The quality of the process 过程的质量(CMM和ISO9000)
• The quality of the product in the context of the business environment 商业环境下的质量 (RoI)

从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3.1 产品(product)的质量

用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。

3.2 过程(process)的质量

有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）

3.3 商业(business)环境背景下的质量

(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。

4.现代软件工程包含的阶段：

现代软件工程大致包含的几个阶段及各个阶段文档：

（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。

（2）系统设计：包括用户界面的设计【《SAD》即《软件体系结构文档》】与复审（开发者与客户）。

（3）程序设计：包括模块功能算法与数据描述设计【算法与数据描述文档】与复审（开发者）。

（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。

（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）。

（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。

（7）系统测试：系统级功能的正确性。按《SRS》对系统总体功能进行测试【测试报告】与复审（开发者与客户）。

（8）系统交付：直接交付/逐渐交付。交付产品【用户手册和操作手册】与复审。

（9）系统维修：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。

5.使现代软件工程变化的关键因素：

1.Time to market 软件交付市场的紧迫性
2.计算成本的下降
3.桌面计算机性能的提高
4.网络技术的发展
5.面向对象技术的发展
6.用户图形界面系统的普及
7.软件开发瀑布模型的不可预测性

◆使现代软件工程实践发生变化的七个关键因素(by Wasserman)
（1）商用产品投入市场时间的紧迫性
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本
（3）功能强大的桌面计算的可用性
（4）广泛的局域网和广域网
（5）面向对象技术的采用及其有效性
（6）使用窗口、图标、菜单和指示器的图形用户界面
（7）软件开发瀑布模型的不可预测性
说明（了解）：瀑布模型沿袭了传统系统工程的大规模批发制造的理念，假定生产活动为线性，这与现代软件的生产方式相矛盾。不再是有足够的灵活性和适应性来满足并行开发或并行运行这样的商业软件需求，因此不可预测。
结论（了解）：对一个系统进行划分，以便并行地开发其子系统，需要一个与瀑布模型有很大不同的开发模型。

6.软件工程的 Wasserman 规范解决软件工程面临的挑战

(1) 抽象(abstraction)：基于某种概念层次上对问题的描述。它使我们将注意力集中在问题的关键方面而非细节。
(2) 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
(3) 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
(4) 软件体系结构：定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法
（以下了解）
（1）基于功能的模块化分解: 基于指派到模块的功能。（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
(5) 软件过程：软件开发活动中的各种组织及规范方法。
（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。

(6) 重用或复用(reuse)：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
(7) 测度或度量(measurement)：通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
(8) 工具和集成环境：通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。
（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。
总结：以上八个概念将软件工程作为一门科学学科，也是本书的八个线索。

Chapter 2 建模过程和生命周期

1.软件过程：

什么是过程（process）？软件过程的重要性是什么？软件生命周期？

过程：软件开发过程中产生某种期望结果的一组有序任务，涉及活动、约束和资源使用的一系列步骤。

重要性：

1、通用性：软件过程可以让一系列开发活动保持一致性和结构性，因而具有了通用性。

2、指导性：软件过程使我们开发人员分析、检查、理解、控制和改善软件开发活动。

3、可以把获得的经验传递给其他人。

2.软件生命周期：

软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。

3.软件过程模型：

3.1 瀑布模型：

定义：线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。

过程：

优点：

1、简单性：很容易向用户解释。

2、基础性：是其他更复杂模型的基础（通过加入额外的开发活动和循环）。

3、过程可观，方便监控。每一个过程活动都有与其相关联的里程碑和可交付产品，便于评估项目进度。

缺点：
（1）用户可能并不清楚所有的需求。
（2）没有迭代。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（3）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。

原型

• 概念: 一种部分开发的产品，用来让用户和开发者共同研究，探索可行性，为最终产品定型

3.2 阶段化开发模型

定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

产品 -> 分阶段/分功能 -> 一部分一部分的交付

特点：
（1）大幅度缩短开发周期。从需求到系统交付的时间短 快速抢占市场 早些获得反馈，可以对产品进行修改。

（2）因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。

分类：增量开发和迭代开发

①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体框架，但是各部分功能都不够完善，后续版本会完善各部分的功能。

3.3 螺旋模型

定义：有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。将开发活动与风险管理结合起来, 以降低和控制风险。

适用范围于较大型软件工程项目。

第一轮迭代产生操作概念，第二轮是需求，后面依次是设计和测试。
每轮都进行风险分析，评估不同选择，通过原型验证可行性，并决定如何消除或降低风险。
一圈代表一次迭代 。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。

*螺旋模型四个象限的任务及四重循环的含义？*

螺旋模型每次迭代有四个任务，依次是（四个象限）：

计划、目标/可选方案、风险评估、 开发与测试。

螺旋模型共有四次迭代，依次是（每个象限的四重循环）：

操作概念、软件需求、软件设计、开发与测试。

3.4 敏捷开发

敏捷方法的四条原则：
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。

强调敏捷方法的四个特性：交流、简单性、勇气以及反馈

敏捷开发过程的几种方法：
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主要的流派。（稍后有详细介绍）
②Crystal （水晶球法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)

3.5 统一软件开发过程（Rational Unified Process,RUP)

迭代开发的一种变体模型。描述了如何有效利用商业的、可靠的方法开发和deploy，是一种重量级的过程。

什么是UP， RUP，进化式迭代等市场流行的过程模型?

• up: 统一过程, 一种现代的软件开发模型, 基于构件, 系统是由构件通过接口相互链接而成, 使用 UML 来指定系统的所有蓝图
• RUP: 统一软件开发过程, 兼容 UP, 提供开发组织中分派任务和责任的纪录化方法, 目标是在可预见的日程和预算下, 确保满足用户
• 进化式迭代: 是统一开发过程的关键实践, 开发被组织为一系列固定的短期项目, 每次迭代都产生经过测试集成并可执行的局部系统, 每次迭代都有各自的需求分析, 设计, 实现和测试, 随着迭代系统增量式完善

UP模型即统一过程模型，是一种用例驱动的，以基础架构为中心的，迭代式，增量式的软件开发模型。

该模型的四个阶段：

开始阶段、确立阶段、构建阶段和移交阶段。

该模型的六道核心工序：

业务模型工序、需求工序、分析设计工序、实现工序、测试工序和部署工序。

RUP模型是IBM提出的提供支持和包装的UP模型。

迭代开发是统一过程模型（RUP）的关键实践。

开发被组织成一系列固定的短期小项目。

每次迭代都产生经过测试、集成并可执行的局部系统。

每次迭代都具有各自的需求分析、设计、实现和测试。

随着时间和一次次迭代，系统增量式完善。

Chapter 3 计划和管理项目

1.关键概念介绍

项目进度（Project Schedule）

列举项目各个阶段 -> 分解成离散的任务或者活动，来描述特定项目的软件开发周期。以及对各个活动完成时间及整个项目完成时间的初步估算。

活动

是项目的一部分，在一段时间内发生。

里程碑

指特定的时间点, 标志着活动的结束, 伴随着提取物 (如一般性文档，功能模块的说明，子系统的说明和展示，精确度的说明和展示，可靠性，安全性，性能说明或展示文档)，向开发人员和客户指明项目已经进展到了可测量的级别

按照活动和里程碑的概念，可以把开发分为阶段，阶段包含步骤，步骤包含活动。
每个活动都是一个可测量事件，这样我们可以确定活动完成的客观标准。
任何一个活动的终止都可以是一个里程碑。

2.项目活动图

含义：描述了不同活动之间的依赖性，表明了活动的执行顺序。

• Real time (actual time) 真实时间：完成活动所需要的时间

• Available time 可用时间：完成活动可用的时间量

关键路径：从起点到终点花费最长时间的路径。

冗余时间：在不耽误总体进度的前提下，最早开始工作和最晚开始工作时间的差值。

求关键路径：先求每个结点的最早开始时间，求出整个项目的最长花费时间。再用最长花费时间倒退，从最后一个结点开始，求每个结点的最晚开始时间。用最晚开始时间减去最短开始时间得到时间差，时间差为0的在关键路径上。

3.团队组织的构成

(1) 主程序员负责制（Chief Programmer Team）
由一个主程序员负责系统设计和开发，其他的成员向其汇报，主程序员对每一个决定有绝对决策权。

优势：
使交流最小化
迅速做出决定

缺点：
创造性低
对主程序员要求高，个人主观性强

(2) 忘我方法（Egoless Approach）
每个成员平等的承担责任，而且过程与个人是分开的；批评是针对产品和结果的，不针对个人的。

4.工作量估算

COCOMO 模型的三个阶段的基本工作原理和含义：

构建成本模型。COCOMO 模型的关键在于针对项目开发的不同阶段来设置工作量的衡量标准，逐步细化，逐渐准确。: E = bSc m(X)

阶段一：应用组合/组装。用原型化项目来解决高风险相关的活动。通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。在阶段一，COCOMOⅡ用应用点来估算规模。
阶段二：早期设计阶段。探索几种可选的体系结构和操作的概念。在阶段二，COCOMOⅡ使用功能点对规模进行测量。
阶段三：即后体系结构阶段，开发已经开始，而且已经知道了更多的信息。在这个阶段，可以根据功能点或代码行来进行规模估算，而且可以较为轻松地估算很多成本因素。

5.软件风险

概念：软件生产过程中不希望看到的，有负面结果的事件

方面：风险损失，风险概率（相乘为风险暴露（Risk Exposure），即数学期望）

风险管理

风险评估：风险识别（checklist），风险分析，风险优先级分配

风险控制：风险降低，风险管理计划，风险化解

降低风险的策略：

1、避免风险：改变功能和性能需求，使风险没机会发生。

2、转移风险：通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失。

3、假设风险：用项目资源，接受并控制风险。比如在开发时主动有意识地进行测试。

典型例题：

a.名词解释：
项目进度（Project Schedule）
b. 简述题：
COCOMO2 模型的工作原理
主程序员负责制的优缺点
c. 综合应用题：
找出关键路径，最早，最晚开始时间（解析见重点内容解析部分）

Chapter 4 需求获取

1.需求的含义

定义：需求是对来自用户的关于软件系统的期望行为的综合描述，涉及系统的对象、状态、 约束、功能等。

任务：理解客户的问题和需求，针对的是客户和问题，不是问题和实现

2.需求过程

①原始需求获取：客户给出的需求

②问题分析：理解需求并通过建模或模型化方式进行描述

③规格说明草稿：利用符号描述系统将定义规范化表示

④需求核准：开发人员与客户进行核准

⑤形成正式的软件需求规格说明文档（SRS）

3.需求的优先级划分

*举例说明获取需求时，若有冲突发生时，如何考虑*

当进行需求的引出时，可能会碰到大家对“需求是什么”存在分歧，此时采用对需求进行优先级划分的方法是有效的

①必须要被满足的需求

②非常值得做但是不是必须的需求

③可选的需求（可做可不做）

4.需求的分类

①功能需求：描述系统内部功能或系统与外部功能的交互作用，涉及系统输入应对、实体状态变化、输出结果、设计约束、过程约束等。

②设计约束：已经做出的设计决策或限制问题解决方案集的设计决策。涵盖物理环境、接口、用户等方面。

③过程约束：对用于构建系统的技术和资源的限制，涵盖资源、文档等方面。

④非功能需求：描述软件方案必须具备的某些质量特征，例如系统性能、安全性、响应时间等。

5.需求文档分类

(1) 需求定义
完整罗列了客户期望的需求

(2) 需求规格说明（SRS）
将需求重述为关于要构建的系统将如何运转的规格说明。

6. UML图

1.数据流图

数据流图（DFD）：
目标：描述数据进入、转换、离开系统，重点在于数据流，而不是控制流

图符：

椭圆表示一个加工或功能，它转换数据。

单箭头表示数据流，其中，进入椭圆的箭头表示其功能的输入，从椭圆输出的箭头表示其功能的输出。

双横线 持久性数据保存在数据存储中，它是一个正式的库或信息库，表示为两个平行线。

矩形 数据源或者数据接收器表示为矩形，称为参与者，提供输入数据或接受输出结果的实体。

2.UML活动图

用于系统功能建模，强调的是对象间的控制流。

3. UML类图

强调系统结构的图形表示范型，对系统的词汇建模，简单协作以及对逻辑数据库模式进行建模

4. UML状态图

展示对象可能的状态，以及由于各种原因的状态转移。

对接口、类、协作行为进行建模。

5.掌握用例图的组成和画法，用例的几个要素的含义。 //掌握用例图的实例解析方法

用例图：表示一个用户、外部系统或其他实体和在开发系统的关系
①用例
描述系统提供的特定功能，用椭圆表示：
②执行者
和系统交互的实体（用户、设备或其他），用小人表示：
③包含
对已定义用例的复用，用以提取公共行为，用带箭头的实线表示：
④扩展
对一个用例的扩展使用，用以下图标

依赖关系

短暂的非结构画的使用关系。只有在调用方法时才存在依赖关系，也就是说其生命周期在软件运行期间才存在。

• 依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。一般而言，依赖关系在Java语言中体现为成员变量、局域变量、方法的形参、方法返回值，或者对静态方法的调用。

对象约束语言（OCL）
定义：表述对象模型（例如，ER 图）上的约束
示例：此处 OCL 要求 pno>=0

Chapter 5 设计体系结构

1. 软件体系结构

软件体系结构：一种软件的解决方案，用于将系统分解为单元子系统，以及这些单元如何相互关联，还包括这些单元所有的外部特性。

IEEE610. 12—1990：体系结构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织以及指导上述内容设计与演化的原理，即*软件体系结构={构件，连接件，环境，原理}

Bass的定义：系统的一个或多个结构，包括*软件构件、构件的外部可视属性和构件之间的关系

*国内普遍认可的看法：可以将体系结构定义为构件、连接件和约束。软件体系结构指可预制和可重构的软件框架结构。
体系结构(Architecture)=构件(Components)+连接件(Connectors)+约束(Constraints)

2. 设计模式？设计公约？设计？

设计：将需求中的问题转变成软件解决方案的创造性过程。

设计模式：针对单个软件模块给出的一般性解决方案，提供较低层次的设计决策。

设计公约：一系列设计和决策的集合，用于提高系统某方面的设计质量。

创造性设计：脑海中突然闪现的idea

设计原则：对好的设计的特征描述，而不是如何进行设计的说明性建议。

3. 软件设计过程模型的几个阶段

1、建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构。

2、分析：分析初步的体系结构，主要关注系统级别的决策，如软件的质量、性能等。

3、文档化：确定各个不同的模型视图。

4、复审：检查文档是否满足了所有需求。（意义：大幅降低软件开发的维修成本）

5、最终产出：软件体系结构文档，即SAD。用来和开发团队中其他人员交流系统级别设计决策的有力工具。

软件过程中复审的概念，设计复审的重要性。

复审定义：检查文档是否满足所有功能及质量需求。

(1) 验证 verification：确保设计遵循良好的设计原则，设计文档满足阅读者的需要。验证检查某样东西是否符合之前已定好的标准，就是要用数据证明我们是不是在正确的制造产品。更注重过程正确性，强调做得正确

(2)确认 validation：确认设计能够满足用户需求。确认检查软件在最终的运行环境上是否达到预期的目标，就是要用数据证明我们是不是制造了正确的产品。更注重结果正确性，强调做的东西正确。

(3) 验证更多是从开发商角度来做评审、测试来验证产品需求、架构设计等方面是否和用户要求一致，确认更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。

重要性：

(1) 复审中批评和讨论是“忘我”的，能将开发人员更好地团结在一起，提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易，成本还不高，在这时候发现故障和问题会使每一个人受益。

重要性：

1、可以和用户一起检查软件的概要设计。

2、可以向开发者呈现并明确软件的技术设计。

3、程序员通过复审可以在下一阶段的工程实施前得到本阶段工作的反馈。

4. 论述设计用户界面应考虑的问题。

设计界面要注意解决的要素:

1、隐喻：可识别和学习的基本术语、图像和概念等。

2、思维模型：数据、功能、任务的组织与表示。

3、模型的导航规则：怎样在数据、功能、活动和角色中移动及切换。

4、外观：系统向用户传输信息的外观特征。

5、感觉：向用户提供有吸引力的体验的交互技术。

文化问题：

设计界面时需要考虑使用系统的用户的信仰、价值观、道德规范和传统等因素。

1、使用国际设计/无偏见设计，排除特定的文化参考或偏见。

2、采用定制界面，使不同用户看到不同的界面 。

用户偏好：

为具有不同偏好的人选择备选界面。

Chapter 6 模块设计

1. 面向对象设计的基本原则

• Modularity 模块化（耦合、内聚）
• Interfaces 接口
• Information hiding 信息隐藏
• Incremental development 增量式开发
• Abstraction 抽象
• Generality 通用性

2.模块独立性、耦合与内聚的概念及各个层次划分？

模块的独立性取决于两个部分：内聚和耦合，我们追求的是高内聚低耦合。

内聚是软件内部组成成分的关联程度。

耦合指的是两个软件间的关联程度。

3.举例说明耦合与内聚的基本分类。以及各个分类的含义与特征

内聚：