软件工程考试大纲

软件工程考试大纲

1.1.1 定义软件

软件定义：

1. 指令的集合，通过执行这些指令可以满足预期的特性，功能和性能需求。
2. 数据结构，使得程序可以合理利用信息
3. 软件描述信息，以硬拷贝和虚拟形式存在，用来描述程序的操作和使用。

软件是逻辑的而非物理的系统元素，软件不会磨损。

不断的变更是软件退化的根本原因。

1.3.1 过程框架

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

活动	含义
沟通	目的是理解利益相关者的项目目标，收集需求以定义软件特性和功能。
策划	定义和描述了软件工程工作，包括需要执行的技术任务，可能的风险，资源需求，工作产品和工作进度计划。
建模	利用模型理解软件需求，完成符合需求的软件设计
构建	对所做的设计进行构建，包括编码和测试。
部署	交付给用户，用户进行评测并基于评测给出反馈意见。

1.3.2 普适性活动

1. 软件项目跟踪和控制
2. 风险管理
3. 软件质量保证
4. 技术评审
5. 测量
6. 软件配置管理
7. 可复用性管理
8. 工作产品的准备和生产

2.4 惯用过程模型

惯用过程模型定义一组预定义的过程元素和一个可预测的过程工作流。

1.瀑布模型（线性顺序模型）

• 提出一种系统的顺序的软件开发方法，从用户需求规格说明开始，通过策划，建模，构建和部署的过程，最终提供完整的软件支持。

• 缺点：实际很少遵循瀑布模型顺序，客户通常难以清晰描述所以需求，项目尾声才能的到可执行程序，在评审程序之前无法检测重大错误。

• 需求必须是准确定义和相对稳定的

2.原型开发过程模型

• 循环回溯和迭代：非线性模型

• 使用快速开发工具

3.演化过程模型 螺旋模型

• 把软件看作一系列相互联系的增量，每次迭代完成一个增量。
• 采用渐增式或迭代式的开发方法。
• 风险驱动型模型

4.统一过程模型（增量模型）

• 起始阶段包含沟通和策划活动。
• 细化阶段包括沟通和建模活动。（软件的5种视图：用例模型，分析模型，设计模型，实现模型，部署模型）
• 构建阶段，构建活动。对每个构件设计并实施单元测试和其他的集成活动。
• 转换阶段包含构建活动的后期和部署活动的第一部分。
• 生产阶段，部署活动。

5个阶段是阶段性的并发进行。

基本特征是用例驱动、以架构为中心的和受控的迭代式增量开发

3.5.1 极限编程（XP框架）

• 策划
• 设计 保持简洁原则
• 编码 结对编程：两个人面对同一台计算机共同为同一个故事开发代码。 持续集成：开发的代码和其他人的工作集成起来。重构：不改变代码的外部行为而改进其内部结构的技术。
• 测试 客户测试

• 12个核心实践：完整团队、计划对策、测试、简单设计、结对编程、小软件版本、设计改进、持续集成、代码共有、编码标准、系统比喻、可持续的速度

5.3 软件团队

• 目的意识
• 参与意识
• 信任意识
• 进步意识
• 多样化
• 责任机制

5个有害团队环境因素：

1. 混乱的工作氛围
2. 造成团队成员分裂的挫败
3. 软件过程支离破碎
4. 对软件团队角色的模糊定义
5. 持续且重复的失败

5.4团队结构

小型并充满动力的项目团队可称为敏捷团队。

敏捷过程

• 一种以人为核心、迭代、循序渐进的开发方法，其软件开发过程称为“敏捷过程”

敏捷过程价值观：

• 个人和交互胜过过程和工具
• 可以运行的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

6.1 需求工程

• 需求工程是致力于不断理解需求的大量任务和技术
• 需求工程在设计和构建之间建立起联系的桥梁
• 需求模型主要目标：
  1. 描述客户需要什么
  2. 为软件设计奠定基础
  3. 定义在软件完成后可以被确认的一组需求
• 需求工程包括七项任务：起始，获取，细化，协商，规格说明，确认，管理。

任务	解释
起始	建立基本理解，包括存在的问题，谁需要解决方案，期望的解决方案的性质
获取	建立业务目标，目标应精确定义，为需求细化，验证确认，冲突管理，协商解释和发展提供基础
细化	开发一个精确的需求模型，说明软件功能，特征和信息的各个方面
协商	调节冲突，使用迭代方式给需求排序，评估风险成本。
规格说明	使用场景，写好的文档或者是一套图形化的模型
确认	质量评估，确保产品的一致性
管理	帮助项目组在项目进程中标识，控制和跟踪需求以及需求变更的活动

6.5 构建分析模型

• 基于场景的元素
• 基于类的元素
• 行为元素

7.3.4 类-职责-协作者建模 CRC

CRC建模提供了一个可以识别和组织与系统或产品需求相关的类的方法。左侧为职责，右侧为协作者。

7.4.2 UML

1.类图

类(class)：一类或一组具有类似属性和共同行为的事物。

类图是以类为中心来组织的，类图中的其他元素或属于某个类或与类相关联

2.用例图

用例(use case)：从用户的观点对系统行为的一个描述。

用例图是从用户角度描述系统功能， 是用户能观察到的系统功能的模型图，用例是系统中的一个功能单元

3.对象图

对象图是类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。

4.状态图

状态图主要表现一个对象所经历的状态序列，引起状态或活动转移的事件，以及因状态或活动转移而伴随的动作。

5.顺序图

顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互。

6.协作图

协作图通过对象之间的连接和它们相互发送的消息来显示参与交互的对象，表示一个类操作的实现

协作图描述对象间的协作关系，协作图跟顺序图相似，除显示信息交换外，协作图还显示对象以及它们之间的关系。

7.活动图

活动图实质上是一种流程图，只不过表现的是从一个活动到另一个活动的控制流。

8.构件图

构件图为系统的构件模型，包括各构件之间的依赖关系。

构件即构造应用的软件单元

9.部署图

部署图描述位于结点实例上的运行构件实例的安排。

10.UML关系

• 依赖
  依赖(dependency)是两个事物之间的语义关系，其中一个事物(独立事物)发生变化，会影响到另一个事物(依赖事物)的语义。
• 关联
  关联(association)是一种结构关系，它指明一个事物的对象与另一个事物的对象间的联系。
• 泛化
  泛化(generalization)是一种特殊/一般的关系。也可以看作是常说的继承关系。在面向对象中一般称为继承关系，存在于父类与子类、父接口与子接口之间。
• 实现
  实现(realization)是类元之间的语义关系，其中的一个类元指定了由另一个类元保证执行的契约

11.用例图的关系与解释：

用例图基本要素：参与者，用例，系统。

参与者与用例的关系：关联

关联扩展：

常规关联:

• “0…1”：表示“零或1”；
• “0…*”或“*”：表示“0”或“多”；
• “1…*”：表示“1或多”；
• “5…11”：表示“5至11”；
• “1，3，8”：是枚举型，表示“1或3或8”。

关联包括两种较强的关联

• 聚合关系 特殊关联关系，指明一个聚集（整体）和组成部分之间的关系
• 组合关系 语义更强的聚合，部分和整体具有相同的生命周期

参与者与参与者的关系：泛化（泛化关系是一般和特殊关系，发出箭头的一方代表特殊的一方，箭头指向的一方代表一般一方）

用例之间的关系

• 继承 父类与子类、父接口与子接口
• 扩展 扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。（可选）
• 包含 包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的行为。（必选）
• 使用

8.3.4 关注点分离

关注点分离是一个设计概念，表明任意复杂问题如果被分解为可以独立解决或优化的若干块，复杂问题更容易得到处理。

关注点是一个特征或以一个行为，被指定为软件需求模型的一部分。

分而治之策略：把一个复杂问题分解为若干可管理的块来求解会更容易。

关注点分离体现在模块化，功能独立，求精。

8.3.10 设计类

• 完整性和充分性
• 原始性
• 高内聚性
• 低耦合性

9.3.1 体系结构风格的简单分类

• 以数据为中心的体系结构 数据存储区为体系中心，其他构建频繁访问该存储区，实现curd操作。
• 数据流体系结构 应用于输入数据需要经过一系列计算或操作构件以转换为输出数据的情况。（管道-过滤器模式）
• 调用和返回体系结构 相对易于修改和扩展
• 面向对象的体系结构 构建封装数据和必须用于该数据的操作。
• 层次体系结构（模型-视图-控制器）

10.2.1基本设计原则

• 开闭原则 模块应该对外延具有开放性，对修改具有封闭性
• 替换原则 （LSP） 子类可以替换他们的基类
• 依赖倒置原则 依赖抽象，而非具体实现
• 接口分离原则 多个用户专用接口比一个通用接口要好
• 发布/复用等价性原则
• 共同封装原则
• 共同复用原则

11.2黄金法则

• 把控制权交给用户
• 减轻用户的记忆负担
• 保持界面一致

11.3 用户界面的分析和设计

• 界面分析和建模
• 界面设计
• 界面构建
• 界面验证

12.3.2 质量的成本

• 预防成本
• 评估成本
• 失效成本（内部和外部）

12.4实现软件质量

• 软件工程方法
• 项目管理技术
• 质量控制活动
• 软件质量保证

FURPS：

• 功能性
• 易用性
• 可靠性
• 性能
• 可支持性

15.1软件测试的策略性方法

发现软件分析、设计和实现过程中的疏忽所造成的错误。

任何测试策略都必须包含测试计划、测试用例设计、测试执行以及测试结果数据的收集与评估。

验证与确认：正式技术评审，质量和配置审核，性能监控，仿真…

测试策略：

• 以渐进观点对待测试
• 以个别程序单元测试为起点，逐步转移到方便于单元的集成测试，之后为确认测试，最后以实施整个系统测试而告终。

单元测试侧重于构件中的内部处理逻辑和数据结构。

集成测试侧重于软件体系结构的设计和构建。

17.1软件配置管理概述

软件配置管理是一组用于计算机软件的整个生命周期内管理变更的活动。

配置管理系统的元素：

• 构件元素
• 过程元素
• 构建元素
• 人员元素

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

19.6 W5HH原则

• why

• what

• when

• who

• where

• how