软件工程个人复习用笔记

复习

个人复习用，范围确定型复习笔记，配套软件工程:实践者的研究方法

---

1. 2.3.3 演化过程模型（螺旋模型）

螺旋模型结合了原型的迭代性质和瀑布模型的系统性和可控性特点。随着演进过程的开始，从圆心开始顺势针方向，执行螺旋上的一圈表示的活动。每次演进都要考虑风险，每个演进过程都要标记里程碑。螺旋模型应用在计算机软件的整个生命周期。是开发大型系统的理想方法，可以有效的应对风险。

螺旋模型的特点：

• 可应用在计算机软件的整个生命周期
• 是开发大型系统和软件的理想方法
• 把原型开发作为降低风险的机制

---

2. 2.3.3 演化过程模型（原型开发模型）

过程：

沟通 → 快速策划 → 建模快速设计 → 构建原型 → 部署交付及反馈 → 沟通... 

快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。

---

3. 6.1.1 总体目标和原理（需求模型的主要目标）

三个主要目标：

1. 描述客户需要什么
2. 为软件射击奠定基础
3. 定义在软件完成后可以被确认的一组需求

---

4. 6.3 补充用例的UML模型

开发活动图

• UML活动图在特定场景内通过提供迭代流的图形化表示来补充用例。
• 使用两端半圆的矩形、箭头、菱形表示。

泳道图

• 可以使用垂直实线将活动图划分为泳道。每条泳道代表整个工作流程的某个部分的职责，该职责由组织的某个部门来执行。

---

5. 8.3.7 功能独立性

• 通过开发具有“专一”功能和“避免” 与其他模块过多交互的模块，可以实现功能独立。
• 独立性可以使用内聚性（显示模块相关功能的强度）和耦合性（显示模块间的相互依赖性）两条定性的标准评估。

---

6. 11.2.1 用户界面分析和设计模型

要考虑四种模型：

• 工程师创建的用户模型
• 软件工程师创建的设计模型
• 最终用户对界面产生的映像，心理模型
• 系统实现后得到的实现模型

四种模型可能相差甚远，界面设计人员的任务就是消除这些差距，导出一致的界面表示。

---

7. 17.1.2 软件测试的组织

• 独立测试组的作用是避免开发人员进行测试所引发的固有问题。
• 有一定程度的独立性。

---

8. 17.3.2 集成测试（回归测试）

• 集成测试通常采用增量方式。
• 回归测试是对已测试过的子集的重新执行，以确保对程序的改变和修改，没有传播不期望的副作用。

回归测试集（已经过测试的子集）包括三种不同类型的测试用例：

• 能测试软件所有功能的代表性测试用例
• 专门针对可能会被修改影响的软件功能的额外测试
• 注重于修改过的软件模块的测试

---

9. 17.7 系统测试（系统测试概念）

• 系统测试是对整个基于计算机的系统进行的一系列不同考验的测试。
• 常用的系统测试主要包括：恢复测试、安全测试、压力测试和性能测试。

---

10. 5.1 需求工程（需求工程的7个活动）

需求工程过程通过执行起始、导出、精化、协商、规格说明、确认和管理七个不同的活动来完成。

• 在起始阶段，建立基本理解。
• 导出需求，面临范围问题、理解问题和易变问题。
• 精化阶段开发精确的技术模型用以说明软件的功能、特征和约束。
• 通过协商过程来调解客户/最终用户提出的过高要求和需求冲突。
• 规格说明是需求工程师完成的最终工作产品。
• 在确认阶段将对需求工程的工作产品进行质量评估。正式技术评审是最主要的需求确认机制。
• 需求管理用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一组活动。

---

11. 11.1 黄金规则

1. 用户操纵控制 
   
   • 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
   • 允许用户交互可以被中断和撤消
   • 技能级别增加时可以使交互流水化并允许定制交互使用户隔离内部技术细节
   • 设计应允许用户和出现在屏幕上的对象直接交互
   • 使用户与内部技术细节隔离开来
2. 减少用户记忆负担 
   
   • 减少用户对短期记忆的要求
   • 建立有意义的缺省
   • 定义直观的快捷方式
   • 界面的视觉布局应该基于真实世界的象征
   • 以不断的方式揭示信息
3. 保持界面一致 
   
   • 允许用户将当前任务放入有意义的语境
   • 在应用系列内保持一致性
   • 如过去的交互模型已建立起了用户期望,除非有不得已的理由,不要改变它

---

12. 1.4 软件过程（软件工程过程框架）

• 软件过程是为工作产品构建时所执行的一系列活动、动作和任务的集合。
• 过程框架定义了若干个框架活动，为实现完整的软件工程过程建立了基础。

一个通用的软件工程过程框架通常包含以下5个活动：

1. 沟通
2. 策划
3. 建模
4. 构建
5. 部署

典型的普适性活动：

• 软件项目跟踪和控制
• 风险管理
• 软件质量保证
• 技术评审
• 测量
• 软件配置管理
• 可复用管理
• 工作产品的准备和生产

---

13. 15.6 正式技术评审（目标. 评审会议. 评审指导原则）

目标：

• 发现任何形式表现的软件功能、逻辑或实现方面的错误；
• 验证软件的需求；
• 保证软件符合预先定义的标准；
• 获得以统一的方式开发的软件；
• 使项目更容易管理。

评审会议

1. 召开评审会议：司评审委员组织，会前每个参加者做好准备。
2. 会议结束后必需有结果：接受该产品，不需做修改；由于错误严重，拒绝接受；暂时接受该产品。
3. 评审报告与记录：所提出的问题都要进行记录，在评审会结束前产生一个评审问题清单，另外必须完成评审总结报告。

评审指导原则

1. 评审产品，而不是评审设计者
2. 指定并遵守日程表
3. 限制争论与反驳
4. 阐明问题，而不是识图解决所有问题
5. 做笔记
6. 限制会议人数,坚持事先准备
7. 为每个被评审的产品要建立评审清单
8. 为FTR分配资源和时间
9. 对所有评审员进行有意义的培训
10. 评审以前做的评审

---

14. 11.1.2 减轻用户记忆负担

• 减少用户对短期记忆的要求
• 建立有意义的缺省
• 定义直观的快捷方式
• 界面的视觉布局应该基于真实世界的象征
• 以不断的方式揭示信息

---

15. 11.3.1 用户分析

途径：

• 用户访谈
• 销售输入
• 市场输入
• 支持输入

---

16. 17.6.3 α测试与β测试

α测试和β测试是确认测试的两种常用方法

• α测试是由用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。经α测试后的软件称为β版软件。
• β测试是由软件的最终用户在一个或多个用户场所进行的，与α测试不同，开发者通常不在测试现场。