软件工程学习整理

第一部分

软件的定义 P4

1. 指令的集合（计算机程序），通过执行这些指令可以满足预期的特征、功能和性能需求
2. 数据结构，使得程序可以合理利用信息
3. 文档，用来描述程序的操作和使用

软件退化 P4

软件不会“磨损”，但软件退化的确存在。

若希望降低软件退化，需改进软件设计。

软件工程方法目的：降低变更突变的幅度，及实际失效曲线斜率

软件工程 P6

将系统化的、规范化的、可量化的方法应用于软件的开发、运行和维护，即将工程化的方法应用于软件。

软件过程 P7-9

软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。

• 活动：实现宽泛的目标
• 动作：产生主要工作产品
• 任务：关注小而明确的目标（产生实际产品）

通用的框架活动：沟通、策划、建模、构建和部署

常用过程模型的特点 P26

瀑布模型

优点：

1. 容易理解和计划
2. 适用于充分了解的小型项目
3. 分析和测试时顺序线性的

缺点：

1. 不能很好地适应变化
2. 测试在过程的后期进行
3. 客户确认在最后阶段

原型模型

优点：

1. 变更需求对后续设计影响较小
2. 客户很早并频繁地参与其中
3. 对小型项目来说效果好
4. 产品失败的可能性降低

缺点：

1. 客户的参与可能会造成进度延误
2. “提交”一个原型，可能造成初步完成的假象
3. 原型被抛弃导致工作白干了
4. 很难计划和管理

螺旋模型

优点：

1. 有持续不断的客户参与
2. 开发风险得到控制
3. 适用于大型复杂项目
4. 适用于可扩展的项目

缺点：

1. 风险分析失败可能导致项目失败
2. 项目可能难于管理
3. 需要一个专家开发团队

统一过程模型

优点：

1. 重视质量文档
2. 有持续不断的客户参与
3. 适合需求变更的情况
4. 对维护项目非常有效

缺点：

1. 用例并不总是精确的
2. 具有复杂的软件增量集成
3. 阶段的重叠可能会带来问题
4. 需要一个专家开发团队

敏捷概念的理解 P29

• 有效（快速且适应）地响应变更
• 有效地与利益相关者（客户）沟通
• 将客户作为开发团队的一员
• 组织管理团队，使其能够控制所执行的工作
• 快速且增量地交付软件

敏捷过程基本特征 P31

什么是敏捷过程：

1. 由客-±户的需求描述（场景）驱动
2. 客户频繁反馈，并且得到落实
3. 认识的“计划时短暂的”
4. 迭代开发，强调构建
5. 多次交付“软件增量”作为可执行原型
6. 随着项目或技术的变化，实时调整

第二部分

分析模型的作用和元素 P77~78

分析模型的作用时为基于计算机的系统提供必要的信息、功能和行为域的说明。

元素：

1. 基于场景的元素
2. 基于类的元素
3. 行为元素

两种需求建模的方法和模型元素

结构化分析

其中处理过程将数据作为独立实体加以转换。数据对象建模定义了对象的属性和关系，操作数据对象的处理建模应表明当数据对象在系统内流动时处理过程将如何转换数据。

面向对象分析

这种方法关注类的定义和影响客户需求的类之间的协作方式。

模型元素

需求建模

用例描述 P86～P91、用例图 P90、类图 P96、顺序图 P100、状态图 P102、活动图 P103、泳道图 P104
流图 P225

设计基本概念 P111

• 抽象
• 体系结构
• 模式
• 关注点分离
• 模块化
• 信息隐蔽
• 功能独立
• 逐步求精
• 重构
• 设计类

设计模型元素 P119

• 数据设计元素
• 体系结构设计元素
• 接口设计元素
• 构建级设计元素
• 部署级设计元素

基本设计原则 P148

• 开闭原则
• Liskov替换原则
• 依赖倒置原则
• 接口分离原则
• 发布/复用等价性原则
• 共同封装原则
• 共同复用原则

第三部分

传统软件的测试策略 P217

特征：

• 为完成有效的测试，应该进行有效的、正式的技术评审。通过评审，许多错误可以在测试开始之前排除。
• 测试开始与构件层，然后向外“延伸”到整个基于计算机系统的集成中。
• 不同的测试技术适用于不同的软件工程方法和不同的时间点。
• 测试由软件开发人员和（对大型项目而言）独立的测试组进行。
• 测试和调试时不同的活动，但任何测试策略都必须包括调试。

白盒测试 P224

利用构建级描述的控制结构，生成测试用例

白盒测试导出的测试用例，可以：

1. 保证一个模块中的所有独立路径至少被执行1次
2. 对所有的逻辑判定均需测试取真（true）和取假（false）两个方面
3. 在上下边界及可操作范围内，执行所有循环
4. 检验内部数据结构，以确保其有效性

基本路径测试 P225

流程图 -> 流图

独立路径

独立路径时任何贯穿程序的、至少引入一组新处理语句或一个新条件的路径。

如上图，独立路径为

路径1： 1-11
路径2： 1-2-3-4-5-10-1-11
路径3： 1-2-3-6-8-9-10-1-11
路径4： 1-2-3-6-7-9-10-1-11

其中每条路径引入一条新边。路径1，2，3，4组成流图的基本集合，可以保证程序中的每条语句至少执行一次。

环复杂性

环复杂性时一种软件度量，它为程序的逻辑复杂度提供了一个量化的测度。
用在基本路径测试方法的环境下，环复杂性的值定义了程序基本集合中的独立路径数。

计算方法：

1. 流图中域的数量与环复杂性相对应。
2. 对应流图G，环复杂性V(G)定义如下：

$$V(G) = E - N + 2$$

其中E为流图的边数，N为流图的节点数。
3. 对于流图G，环复杂性V(G)也可以定义如下：

$$V(G) = P + 1$$

其中P为包含在流图G中的判定节点数。

黑盒测试 P227

也称为行为测试，或功能测试
不考虑控制结构，侧重于软件的功能需求

尝试发现的错误：

1. 不正确或遗漏的功能
2. 接口错误
3. 数据结构或外部数据库访问错误
4. 行为或性能错误
5. 初始化和终止错误

等价类划分

黑盒测试中，测试输入域划分为一个有效等价类与若干个无效等价类，测试用例时从每个等级类的元素组合中派生出来的，无需对所有输入域值进行穷举测试。

有效等价类：有意义、合理的输入数据集合。

无效等价类：无意义、不合理的输入数据集合。

指导原则：若输入条件

• 指定一个范围：1个有效 & 2个无效等价类
• 需要特定值：1个有效 & 2个无效等价类
• 指定集合的某个元素：1个有效 & 1个无效等价类
• 为布尔值：1个有效 & 1个无效等价类

边界值分析

边界值分析（BVA）时一种测试用例设计技术，是对“等价划分”的补充。BVA不是选择等价类的任何元素，而是在等价类”边缘“上选择测试用例。BVA不是仅仅侧重于输入条件，它也从输出域中导出测试用例。

BVA指导原则：

1. 若输入条件指定为以a和b为边界的范围，用例应包括a和b，略大于和略小于a和b，如：成绩，日期函数的年月日。
2. 若输入条件指定为一组值，用例应执行其最大值和最小值，及略大于和略小于最大值和最小值的值。
3. 指导原则1和2也适用于输出条件。如：工程分析程序要求输出温度和压强的对照表，应该设计测试用例创建输出报告，输出报告可生成所允许的最大（和最小）数目的表项。
4. 若内部程序数据结构由预定义的边界值（例如，表具有100项的定义限制），则一定要设计测试用例，在其边界处测试数据结构。

基线 P248

已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制规程才能修改它。

变更控制 P253

变更控制过程：

1. 评估变更请求，向CCA（变更控制机构）提交变更报告，CCA最终决定变更的状态和优先级
2. 每个批准的变更，生成一个ECO（工程变更单）
3. 根据访问控制参数，从项目数据库中检出要更改的SCI
4. 修改后的SCI将进行SQA（软件质量保证），并检入到项目数据库
5. 遵循版本控制过程，生成软件的下一个版本，采用同步控制，确保不同人员的并行更改不会相互覆盖

第四部分

软件项目管理范围4P P279

有效的软件项目管理集中于 4P，即人员、产品、过程和项目，他们的顺序不是任意的。

W⁵HH原则 P287

• 为什么（Why）要开发这个系统？ 所有利益相关者都应该了解软件工作的商业理由是否有效。该系统的商业目的值得花费这些人力、时间和金钱吗？
• 将要做什么（What）？ 定义项目所需的任务集。
• 什么时候（When）做？ 团队制定项目进度，标识出何时开展项目任务以及何时到达里程碑。
• 某功能由谁（Who）负责？ 规定软件团队每个成员的角色和责任。
• 他们的机构组织位于何处（Where）？ 并非所有角色和责任均属于软件团队，客户、用户和其他利益相关者也有责任。
• 如何（How）完成技术工作和管理工作？ 一旦确定了产品范围，就必须定义项目的管理策略和技术策略。
• 每种资源需要多少（How much）？ 对这个问题，需要在对前面问题回答的基础上通过估算而得到。