5000字掌握《软件工程：实践者的研究方法》重点

一、软件过程

1.软件过程的概念

1. 软件过程是一个为创建高质量软件所需要完成的活动、动作和任务的框架，框架活动包括沟通、策划、建模、构建、部署。

2.经典软件过程模型的特点

1. 瀑布模型

   1. 瀑布模型又称经典生命周期，它提出一个系统的顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供完整的软件支持。

   2. 瀑布模型特点：

      1. 采用线性过程流，可控、系统、顺序性
      2. 需求必须是准确定义和相对稳定的**（适用于需求定义清楚且稳定的软件开发）

   3. 人们运用瀑布模型遇到的问题：

      1.实际的项目很少遵守瀑布模型提出的顺序。

      2.客户通常难以清楚的描述所有的需求。

      3.客户必须有耐心，因为只有在项目接近尾声的时候，他们才能得到可执行的程序。

2. 增量模型

   1. 采用了迭代的方式工作，综合了线性过程流和并行过程流的特点，
   2. 随着时间的推移，增量模型在每个阶段都运用线性序列。
   3. 每个线性序列生产出软件的可交付增量。
   4. 第一个增量往往为核心产品。

3. 演化模型

   1. 演化模型是迭代的过程模型，能逐步开发出更完整的版本，设计目的是为了适应变更，包括原型开发和螺旋模型。
   2. 当需求不确定时，原型开发沟通后快速策划建模，快速设计产生原型，部署原型后由利益相关者评估。根据利益相关者的反馈信息，进一步精炼软件的需求。原型开发提供了定义软件需求的一种机制。
   3. 螺旋模型是一种演进式软件过程模型，结合了原型的迭代性质和瀑布模型的可控性和系统性的特点，具有快速开发越来越完善的软件版本的潜力。
   4. 螺旋模型两个特点，一是采用循环的方式逐步加深系统定义和实现的深度，同时降低风险，二是确定一系列里程碑作为支撑点，确保利益相关者认可是可行的且令各方满意的系统解决方案。

4. 统一过程模型

   1. 用例驱动
   2. 以架构为核心
   3. 建立了迭代、增量的过程流，提供了演进的特性
   4. 分为起始、细化、构建、转换、生存五个阶段，阶段是并发进行的。

3.过程评估和CMM/CMMI的基本概念

1. 过程评估即对过程的一系列的评价活动，评估的目的是揭示组织以某种方式应用现有软件过程及构成此过程的软件工程实践的优势和劣势。
2. 评估以改进为目标，评估力求理解软件过程的当前状态。过程评估应关注一致、成熟、认可、承诺等问题。
3. 软件过程评估和改进方法包括用于过程改进的CMMI标准评估方法提供了五步的过程评估模型：启动、诊断、建立、执行、学习。用于组织内部过程改进的CMM评估用以分析软件开发机构的相对成熟度。
4. CMMI（能力成熟度模型集成）是一个综合的过程元模型，以一组系统工程和软件工程能力为基础，能够表示组织可以达到的过程能力及成熟度的不同等级。
5. CMMI有两种方式表示过程元模型：连续式、分级式。连续式用过程域和能力等级两个维度描述，能力等级0不完全级、能力等级1已执行级、能力等级2已管理级、能力等级3已定义级、能力等级4定量管理级、能力等级5优化级。
6. 阶段性模型定义了和持续性模型相同的过程域、目标和实践，区别在于阶段性模型定义了5个成熟度等级，达到某个等级就必须实现与一组过程域相关的特定目标和特定实践，

等级	焦点
优化级	持续过程改进
定量管理级	定量管理
已定义级	过程标准化
已管理级	基本的项目管理
初始级

4.敏捷宣言与敏捷过程的特点

1. 敏捷宣言声明：

   1. 个人和他们之间的交流胜过了开发过程和工具
   2. 可运行的软件胜过了宽泛的文档
   3. 客户合作胜过了合同谈判
   4. 对变更的良好适应胜过了按部就班地遵循计划

2. 敏捷过程能够降低变更的成本是因为软件产品以增量的形式发布，而且在增量内部变更能得到较好的控制。问题在于过程的不可预测性，所以敏捷过程必须具有以下特点：

   1. 可适应性
   2. 必须增量地适应
   3. 应使用增量式开发策略，在很短时间间隔交付软件增量来适应变更的步伐

3. 这种迭代方式允许客户：

   1. 周期性地评价软件增量
   2. 向软件项目组提供必要的反馈
   3. 影响为适应反馈而对过程进行的适应性修改

二、软件需求

1. 软件需求是指用户对目标软件在功能、行为、性能、设计约束等方面的期望。

2. 需求工程是指致力于不断理解需求的大量任务和技术。基本过程有7个步骤：起始、获取、细化、协商、规格说明、确认、需求管理。

3. 分层数据流模型

   1. 用例和场景建模及其UML表达（用例图、活动图、泳道图、顺序图）
   2. 数据模型建模及其UML表达（类图）
   3. 行为模型建模及其UML表达（状态机图）

三、软件设计与构造

1.软件体系结构及体系结构风格的概念

1. 软件体系结构是指系统的一个或多个结构，它包括软件构件、构件的外部可见属性以及它们之间的相互关系。

2. 体系结构风格是施加在整个系统设计上的一种变换，目的是为系统的所有构件建立一个结构。

3. 体系结构风格可分为

   1. 以数据为中心的体系结构
   2. 数据流体系结构
   3. 调用和返回体系结构
   4. 面向对象体系结构
   5. 层次体系结构等

2.设计模式的概念

1. 设计模式是用来描述问题以及解决方案的规范化方法。
2. 设计模式具有以下特点：
   1. 设计模式可以解决问题
   2. 设计模式是已经得到验证的概念
   3. 解决方案并不明显
   4. 设计模式描述关系
   5. 模式具有显著的人性化元素

3.模块化设计的基本思想及概念

1. 模块化设计将设计划分成许多模块，以降低构建软件所需的成本，

2. 模块化设计（以及由其产生的程序）的意义

   1. 使开发工作更易于规划
   2. 可以定义和交付软件增量
   3. 更容易实施变更
   4. 能够更有效地展开测试和调试
   5. 可以进行长期维护而没有严重的副作用

3. 抽象能够说明内部过程和数据，但对外部隐藏了底层细节，可分为过程抽象和数据抽象

   1. 过程抽象是指具有明确和有限功能的指令序列
   2. 数据抽象是描述数据对象的具体数据集合
   3. 抽象提供了一种创造可重用软件构件的方法

4. 封装即把对象的属性和操作结合起来组成一个独立的对象，并隐藏对象的实现细节。

5. 分解表明任何复杂问题如果被分解为可以独立解决或优化的若干块，该复杂问题便能够更容易地得到处理。

6. 模块化，软件被划分为独立命名的、可处理的构件。

7. 模块化是关注点分离最常见的表现，可以使软件更易理解，更易测试以及更易维护。

8. 信息隐藏指每个模块对其他所有模块都隐蔽自己的设计决策，即模块应被特别说明并设计，使信息（算法和数据）都包含在模块内，其他模块无需对这些信息进行访问。当错误发生是能减少负面影响的传播。

9. 功能独立是指模块具有“专一”功能和“避免”与其他模块过多交互，功能独立是构件有效模块的标准。

4.软件重构的概念

1. 软件重构即不改变代码（设计）的外部行为而是改进其内部结构。
2. 重构是一种重新组织的技术，可以简化为构件的设计（或代码）而无需改变其功能或行为。目的是优化已导出的设计。

5.接口的概念

1. 接口是类、构件或其他分类符（包括子系统）的外部可见的（公共的）操作说明，而没有内部结构的规格说明，
2. 简单说，接口是一组描述类的部分行为的操作，并提供了这些操作的访问方法。
3. 在UML图中，接口被表示为一组输入和输出的数据对象或者数据项的集合。

6.面向对象设计原则

1. 依赖倒置原则，**依赖于抽象而非具体实现。**高层模块不应当直接依赖于底层模块，两者都应当依赖于抽象。抽象不应当依赖于细节，细节应当依赖于抽象
2. 开闭原则，模块（构件）应该对外延具有开放性，对修改具有封闭性，简单说，无需对构件自身内部（代码或者内部逻辑）做修改就可以进行扩展。
3. Liskov替换原则，子类可以替换它们的基类。
4. 接口隔离原则，多个客户专用接口比一个通用接口要好。

7.内聚和耦合的概念及常见的内聚和耦合类型

1. 内聚性是一个模块对于一件事情侧重程度的定性指标，显示了某个模块相关功能的强度，是信息隐蔽概念的自然扩展。可描述为构件的“专一性”。

2. 内聚类型可分为功能内聚、分层内聚、通信内聚。

   1. 功能内聚（高/好）通过操作来体现，当一个模块完成一组且只有一组操作并返回结构时，就称此模块是功能内聚的。

   2. 分层内聚由包、构件和类来体现。高层能访问低层的服务，但低层不能访问高层的服务。

   3. 通信内聚（低），访问相同数据的所有操作被定义在一个类中。

3. 耦合是类之间彼此联系程度的一种定性度量，显示了模块间的互相依赖性，表明软件结构中多个模块之间的互相连接。

4. 耦合类型可分为内容耦合、控制耦合、外部耦合。

   1. 内容耦合（高/差），一个构件暗中修改其他构件的内部数据，违背信息隐蔽原则。

   2. 控制耦合发生在操作A给操作B传递控制标记时

   3. 外部耦合（低/好）发生在当一个构件和基础设施构件进行通信和协作时。

四、软件测试

1.软件测试及测试用例的概念

1. 软件测试是软件投入运行之前对软件需求分析，设计规格说明和编码的最终复查，是软件质量保证的关键步骤。目的是为了发现程序中的错误，

2. 测试用例是为测试设计的数据，设计测试用例的原则是尽可能暴露错误。

3. 单元测试是检查程序模块是否正确实现了规定的功能，目的是保证每个模块作为一个单元能正确运行。

4. 集成测试是构建软件体系结构的系统化技术，同时也是进行一些旨在发现与接口相关的错误的测试。其目标是利用已通过单元测试的构件建立设计中描述的程序结构。分为自顶向下集成测试和自底向上集成测试。

5. 确定测试集中于用户可见的动作和用户可识别的系统输出，应检查是否满足软件需求规格说明书中的确认准则部分，确认测试验证软件需求的可追溯性。验收测试可分为α测试和β测试。

6. 系统测试在软件集成为较大的系统时对软件进行确认，包括恢复测试、安全测试、压力测试、性能测试、部署测试。

7. 回归测试是重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。回归测试有助于保证变更（由于测试或其他原因）不引入无意识行为或额外的错误。

2.调试的概念、调试与测试的关系

1. 调试是追踪错误的原因，使错误消除的过程，是一种技术。

2. 调试不是测试，但总是发生在测试之后。

3. 测试和调试是不同的活动，但任何测试策略都必须包括调试。

4. 有三种调试方法：

   1. 蛮干法
   2. 回溯法
   3. 原因排除法。

3.测试覆盖度的概念

1. 测试覆盖度是用来度量测试完整性的一个手段，同时也是测试技术有效性的一个度量，覆盖率=（至少被执行一次的item数）/item的总数，白盒覆盖率中使用的最常见的就是逻辑覆盖率，逻辑覆盖包括：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

4.白盒测试、黑盒测试的概念

1. 白盒测试，是基于过程细节的封闭检查，侧重于程序控制结构。

2. 白盒测试通过提供检查特定条件集或循环的测试用例，测试将贯穿软件的逻辑路径和构件间的协作。

3. 白盒测试采用内部视角，包括基本路径测试、条件测试、数据流测试、循环测试（简单循环、串接循环、嵌套循环和非结构化循环）。

4. 黑盒测试，指在软件接口处执行测试，侧重于软件的功能需求。

5. 黑盒测试检查系统的功能方面，不考虑软件的内部结构。

6. 黑盒测试采用外部视角，包括基于图的测试方法（事务流建模、有限状态建模、数据流建模、时间建模）、等价类划分、边界值分析、正交数组测试、基于模型测试等。

5.代码圈复杂度的计算方法

1. 计算**代码圈复杂度V(G)**的3种方法：

   ① V(G)=R-N+2，E为流图的边数，N为流图的节点数；

   ② V(G)=P+1，P为判断节点数；

   ③ V(G)=域的个数；

6.白盒测试中的基本路径测试方法

1. 基本路径测试方法允许测试用例设计者计算出过程设计的逻辑复杂性测量，并以这种测量为指导原则来定义执行路径的基本集。执行该基本集导出的测试用例保证程序中的每一条语句至少执行一次，即利用程序图（或图矩阵）生成保证覆盖率的线性无关的测试集。
2. 操作步骤如下：

   1. 以设计或源代码为基础，画出相应的流图。

   2. 确定所得流图的环复杂度。

   3. 确定线性独立路径的基本集合。

   4. 准备测试用例，强制执行基本集合中的每条路径。

7.黑盒测试中的等价类划分方法

1. 等价类划分法的用例设计是基于对输入条件的等价类进行评估，将输入域划分为有可能检查软件特定功能的数据类，可以为每个输入域数据对象设计测试用例并执行。

2. 可以根据以下原则指导原则定义等价类：

   1. 指定范围，可定义一个有效等价类和两个无效等价类。
   2. 指定特定值，可定义一个有效等价类和两个无效等价类。
   3. 指定集合的某个元素，可定义一个有效等价类和一个无效等价类。
   4. 指定布尔值，可定义一个有效等价类和一个无效等价类。