软件工程笔记

1 软件工程概述

1.1 软件工程概念的提出与发展

软件危机：质量低、成本高、开发周期长

软件工程：计算机科学理论和技术以及工程原则和方法，按预算、进度满足用户要求产品的工程

软件工程的发展

• 60 - 80 年代：开发模型、开发方法、支持工具
• 80 年代末至今：软件复用技术、软件生产管理

1.2 软件开发本质

软件开发目标：映射，将问题域术语映射为解决域的实现

软件开发的本质：不同抽象层术语间的映射，以及不同抽象层处理逻辑的映射

模型的概念：特定意图下所确定的角度和抽象层次上对物理系统的描述（包含对系统边界描述、内部各元素关系间的描述）

模型类别

1. 概念模型：这个软件是什么？
2. 软件模型：实现概念模型的软件解决方案

2 需求与需求规约

2.1 需求获取

需求的定义：一个构造的陈述，描述产品功能、性能、或其他性质

需求的基本性质：必要的、无歧义的、可测的、可跟踪的、可测量的

需求的分类：功能需求（主体）、非功能需求（性能、接口、设计约束、质量属性）

需求发现技术：自悟、交谈、观察、小组会、提炼

2.2 需求规约 SRS

需求规约的定义：软件所有需求陈述的正式文档，表达了软件的概念模型

需求规约的基本性质：重要性和稳定程度（对需求分级）、可修改的、完整的（无遗漏）、一致的（不存在互斥）

2.3 需求规约的格式

IEEE 1998：引言（目的、范围、定义、缩略语、参考文献、概述）、总体描述（描述、功能、用户特性、约束、假设和依赖）、特定需求（技术核心）、附录、索引

需求规约的表达：非形式化（自然语言）、半形式化、形式化

需求规约的作用

1. 开发组织和用户间的技术合同书
2. 管理控制点
3. 对产品设计来说，是一个正式、受控的起点
4. 产品验收和用户指南的基础

3 结构化方法

结构化分析方法：DFD、数据字典、决策树、决策表

结构化分析建模的步骤

1. 建立系统环境图，确定系统语境
2. 自顶向下，逐步求精，建立数据流图
3. 定义数据字典
4. 描述加工

3.1 结构化需求分析

业务需求 -> 用户需求 -> 功能需求

需求分析面临的挑战：问题空间的理解、人与人间的通信、需求的变化

3.1.1 需求技术的基本特征

• 提供方便通信的机制
• 分析人员使用问题空间术语思考问题、编写文档
• 定义系统边界的方法
• 支持抽象的基本机制
• 提供多种选择方案
• 提供特定技术，适应需求变化

3.1.2 需求分析中的基本术语

1. 数据：客观事物的一种表示
2. 信息：具有特定语义的数据；数据是信息的载体
3. 数据流：数据的流动
4. 加工：数据变换单元
5. 数据存储
6. 数据源和数据潭

3.1.3 系统功能模型表示方法

数据流图（DFD）：数据源和数据谭（正方形）、数据流（箭头实线）、加工（圆形）、数据存储（双横线）

数据字典：定义数据流、数据存储的数据结构

• 顺序结构：+
• 选择结构：|
• 重复结构：{}
• 子界：m … n

判定表、判定树、结构化语言：加工描述

IF 工资 <= 4500 
	无需缴税 
ELSE 
	需要缴税

平衡问题

• DFD 图与数字字典一致
• 底层加工与数字字典一致

复杂控制问题

• 上层数据流可以打包
• 下层模块：7 ± 2
• 每个加工数据流不能太多

3.1.4 需求验证

验证：必要性、无歧义性、可测性、可跟踪性、可测量性

错误类型：不正确的事实、遗漏、不一致、歧义等

发现错误的方法：审查、单元测试、评估、集成

3.2 结构化设计

结构化设计任务

1. 定义满足需求所需要的结构
2. 确定怎么做
3. 分为总体设计（以系统为对象）和详细设计（以模块为对象）

模块结构图、层次图、HIPO 图（层次图 + IPO 图）

模块：软件中具有特定标识的独立成分，执行特殊任务的过程以及相关的数据结构，分为模块接口和模块体

模块调用：模块间的关系

3.2.1 总体设计

总体设计步骤

1. DFD 转为初始模块结构图
2. 基于高内聚低耦合，通过模块化，转为最终模块结构图

系统分解成软件模块

1. 分而治之和抽象
2. 自顶向下，逐步求精
3. 形成模块层次结构

两种映射方法

1. 变换设计（数据凝聚）：输入、变换、输出

2. 事务设计（逻辑凝聚）：输入分为许多相互平行的加工路径，根据输入属性选择其中一种路径

耦合：模块间的依赖关系。内容耦合（直接修改其他模块数据）、公共耦合（多模块使用同一个全局数据）、控制耦合（一个模块向另一个模块发送控制信号）、标记耦合（一个模块向多个模块传递公共数据）、数据耦合（通过参数传递数据）

内聚：模块内的关联关系。偶然内聚（无任何关系）、逻辑内聚（逻辑相关）、时间内聚（同一时间段）、过程内聚（特定次序）、通信内聚（操作同一数据）、顺序内聚（一个输出作为另一个输入）、功能内聚（完成单一功能）

启发式规则：高内聚低耦合

1. 改进软件结构，提高软件独立性。模块分解
2. 模块规模适中
3. 深度、宽度、扇出、扇入适中
4. 模块作用域（受影响的模块）在控制域（直接或间接从属模块）内
5. 降低模块接口复杂度
6. 模块功能可以预测

3.2.2 详细设计

设计目标：将总体设计产生的高层结构映射为以相关术语表达的底层结构

结构化程序设计方法：程序的控制流程线性化，实现程序动态执行的顺序符合静态书写结构，提高可读性

基于结构的编程方法：采用顺序结构、选择结构、重复结构进行编程

详细设计工具：程序流程图、盒图、PAD 图、类程序设计语言 PDL

3.2.3 设计规约

描述需求规约所要求的所有功能模块，以及伴随功能模块出现的非功能机制

概要设计规约：指明高层体系结构

1. 系统环境
2. 模块结构
3. 模块描述
4. 逻辑结构
5. 测试需求

详细设计规约：设计人员与程序员交流的媒体

1. 算法
2. 数据结构

4 面向对象

4.1 UML

统一建模语言

作为软件需求规约、设计和实现的工具，给出不同抽象层术语以及模型表达工具

4.1.1 面向对象建模过程

1. 需求获取：建立用况模型和场景
2. 需求分析：活动图、状态图、类图、顺序图
3. 编写规格说明书
4. 需求验证

4.1.2 UML 术语表

客观事物的术语：类和对象、接口、协作（交互各方、交互方式、交互内容）、用况、主动类（至少具有一个线程/进程的类）、组件（通过外部接口，隐藏内部实现）、制品（包含物理信息、可替代的物理部件）、节点（计算机资源）

关系的术语：依赖、关联（聚合、组合）、实现（精化）、泛化

组合关系的术语：包（use/import）

4.2 RUP

统一软件开发过程

用户需求转换为产品所需要的活动

4.2.1 RUP 特点

RUP 特点：以用况驱动、以体系结构为中心的迭代、增量式开发

RUP 设计特点

1. 使用公共思想思考设计，使设计可视化
2. 给出有关子系统、设计类、接口的需求
3. 对底层工作的分解，可由不同开发组同时开发、管理

RUP 设计模型

1. 设计子系统和服务子系统，以及依赖、接口、内容
2. 设计类，以及操作、属性、实现需求
3. 用况细化
4. 设计模型视角下的体系结构描述

4.2.2 RUP 阶段

初始（生命周期目标里程碑） -> 细化（生命周期构造里程碑） -> 构造（初始功能里程碑） -> 交付（产品发布里程碑）

初始阶段目标

1. 获得体系结构轮廓
2. 建立商业案例
3. 确定项目边界
4. 从业务角度指明价值
5. 生命周期目标里程碑

细化阶段目标

1. 分析问题领域，建立健全的体系结构，淘汰高风险项目
2. 生命周期结构里程碑

构造阶段目标

1. 最终的体系结构
2. 开发完整的系统
3. 确保可以向客户交付
4. 初始功能里程碑

交付阶段

1. 确保软件可用
2. 基于用户反馈进行调整

核心过程工作流：商业建模、需求、分析和设计、实现、测试、部署

核心支持工作流：配置和变更管理、项目管理、环境

4.2.3 需求获取

建立用况模型

1. 列出候选需求：特征列表

2. 理解系统语境：业务模型。业务用况模型（参与者、业务用况），业务对象模型（工作人员、工作实体、工作单元）

3. 捕获功能需求：用况模型。发现和描述参与者、用况，确定用况优先级，精化用况，构造用户界面模型，用况模型结构化

4. 捕获非功能需求

4.2.4 需求分析

在用况模型上，建立分析模型及该模型体系结构描述

术语

• 分析类：类的一种，很少有操作和特征。实体类，边界类，控制类

• 用况细化：是一个协作，针对一个用况，其行为可以用多个分析类间协作相互作用细化

• 分析包：把变化限制到一个业务过程、行为、用况

分析模型表达

• 由分析系统决定
• 分析系统包含一组具有层次结构的包
• 一个包可以包含分析类和用况细化

体系结构分析、细化分析、对类分析、对包分析

用况模型	分析模型
客户语言描述	开发者语言描述
系统对外的视图	系统内部的视图
外部视角的结构	内部视角的结构
客户与开发之间的契约	开发者理解系统的基础
需求间可能存在冗余、不一致、冲突	不存在冗余、不一致、冲突
捕获系统功能	细化系统功能
定义进一步分析的用况	定义每一个用况的细化

4.2.5 软件设计

定义满足需求规约的软件结构

设计模型

• 设计类

• 用况细化

• 设计子系统

• 接口

部署模型：描述系统的物理分布

体系结构设计

1. 标识节点和他们的网络配置
2. 标识子系统和他们的接口
3. 标识有意义的设计类和接口
4. 标识一般性的设计机制

用况设计

1. 参与用况细化的设计类
2. 参与用况细化的子系统

类的设计

1. 概括设计类
2. 操作、属性
3. 关联、聚合、组合、泛化关系
4. 描述方法、状态

4.2.6 实现与测试

实现目标

1. 给予设计类和子系统生成构建
2. 对构建进行单元测试
3. 进行集成和链接
4. 可执行的构建映射为部署模型

RUP 测试：内部测试、中间测试、最终测试

5 软件测试

软件过程质量和软件产品质量的基础

是一种动态评估的技术

5.1 软件测试目标

5.1.1 软件测试对象

软件 = 程序 + 文档

测试对象：各个阶段产生的源程序和文档

软件测试目的：尽可能多的发现存在的错误，并精心改正

5.1.2 软件测试定义

软件测试：按照特定规程发现软件错误的过程，检验是否满足对应需求

1. 测试证明错误，调试证明正确
2. 测试以已知条件开始
3. 测试有计划的
4. 测试是发现错误、改正错误、重新测试的过程
5. 测试执行由规程
6. 测试由独立测试小组完成
7. 测试的设计和执行可由工具支持

5.1.3 测试过程模型

1. 测试设计：环境模型、对象模型、错误模型
2. 测试执行
3. 测试结果比较

5.2 软件测试技术

人工测试：个人审查、走查、会审

机器测试：黑盒、白盒

5.2.1 路经测试技术

介绍

1. 白盒测试技术
2. 依据的是程序的逻辑结构
3. 采用控制流程图来表达被测程序模型
4. 合理选择路径，达到某种测试度量

控制流程图

• 程序块：没有被判定或节点分开的语句，如：S1、S2、S3、S4

• 判定：控制流出现分叉，如：1、3

• 节点：多个控制流结合，如：2、4

• 链：过程块、判定、节点的关系

• 路径：链组成，入口开始，出口结束

测试策略

1. 路径覆盖（PX）：执行所有可穿过程序控制路径
2. 语句覆盖（C1）：所有语句执行一次
3. 分支覆盖（P2）：每个分支执行一次
4. 条件覆盖：每个条件执行一遍
5. 条件组合覆盖：每个条件组合执行一遍

路径选取原则：最小强制语句覆盖

1. 选择最简单、具有功能含义的入口/出口
2. 选取最短路径
3. 选取没有明显功能的路径

5.2.2 基于事务流测试

介绍

1. 功能测试
2. 黑盒测试

事务：从用户角度出发见到的工作单元，从生到死

事务由一系列操作组成

事务流：为功能建立程序的动作模式

事务流程图

1. 并生：事务处理产生一个新事务，两个事务继续执行
2. 丝分裂：事务处理产生两个新事务
3. 汇集：事务的不同活动汇集一处
4. 吸收：一个事务一个被另外一个事务吸食

测试步骤

1. 获得事务流程图
2. 浏览、复审
3. 用例设计
4. 测试执行

5.2.3 等价类法

根据程序 I/O 特性，将输入划分为有限个等价类

5.3 软件测试步骤

5.3.1 单元测试

考虑模块特征

1. 模块结构
2. 局部数据结构
3. 重要执行路径
4. 错误执行路径

驱动模块：调用被测试模块的模块

承接模块：被测试模块调用的模块

5.3.2 集成测试

测试模块间接口的正确性，与单元测试平行进行

自顶向下的集成测试：设计承接模块

自底向上的集成测试：设计驱动模块

每加入新的模块还要进行回归测试

5.3.3 有效性测试

目标是发现软件的功能与需求规格说明，采用黑盒测试

6 软件生存周期

过程类 -> 过程 -> 活动 -> 任务

6.1 1995

生存过程分类：基本过程、支持过程、组织过程

6.1.2 基本过程

与软件生产直接相关的活动集

获取过程、供应过程、开发过程、运行过程、维护过程

6.1.3 支持过程

有关各方按目标从事的一系列活动集，提高系统或软件产品质量

文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程、问题解决过程

6.1.4 组织过程

与软件生产组织有关的活动集

管理过程、基础设施过程、培训过程、改进过程

6.2 2008

2 个过程类，7 个过程组，43 个过程

1. 系统语境的过程：协议、项目、技术、项目使能过程组

2. 软件开发的过程：软件实现、软件支持、软件复用过程组

6.2.1 供应过程

为获取方提供需求的产品或服务

活动：机遇标识、供应方投标、合同协商、合同执行

结果：标识获取方、对获取方作出响应、双方建立协议、供应方开发满足需求的产品

6.2.2 软件实现过程

规约的行为、接口、实现约束转换为动作，创建称为软件项的产品和服务

活动：软件实现策略

结果：定义实现策略、标识实现技术约束、实现了软件、按协议打包软件并存储

6.2.3 软件需求过程

建立软件部分的需求

活动：建立软件和需求文档、评估软件需求、需求复审

结果：需求分配给系统的软件元素、分析需求的正确性和和可测性、了解需求对环境的影响、软件需求和系统需求建立一执性和可跟踪性、定义需求的优先级、需求得到批准并按需求整改、需求评估、建立需求基线并于有关部门协商

6.2.4 软件体系结构设计过程

提供设计方案

活动：软件结构设计

结果：开发软件体系结构设计，描述实现软件项、设计每一个软件项的内部接口和外部接口

6.2.5 软件验证过程

证明软件满足需求规约

活动：过程实现、验证

结果：实现验证策略、标识验证准则、执行验证活动、记录缺点、给出验证结果

6.2.6 软件确认过程

证实软件产品是否满足客户需求

活动：过程实现、确认

结果：实现确认策略、标识确认准则、执行确认活动、记录问题、提供证据证明能按照客户所期望方式使用、给出验证结果

6.3 应用说明

系统和软件

1. 软件是整个系统的组成部分
2. 区分系统需求和软件需求分析

系统包含非常重要的非软件因素时，采用 15288 标准

组织层和项目层：项目可能由组织执行

过程间的时序关系：没有明确过程、活动、任务间的时间依赖关系，支持活动之间的迭代和再现

过程分解：把过程划分为更小片段

生存周期模型和阶段：用生存周期模型对产品模型化、模型由阶段组成

剪裁：针对特定情况，修改生存周期过程

6.4 软件生存周期模型

含义：包含产品开发、运行、维护中有关活动、任务的框架，覆盖需求定义到使用终止

作用：为软件开发确定抽象层，并定义抽象层间的基本关系

6.4.1 瀑布模型

原理

1. 自上而下，固定顺序

2. 每一阶段工作成果的输出作为下一个阶段的输入

贡献

1. 存在需求阶段，鼓励系统做需求规约
2. 存在设计阶段，鼓励规划系统结构
3. 每个阶段都有评审
4. 前一步作为后一步被认可的、文档化、基线

存在问题

1. 客户能够完整、正确、清晰地表达需求，开发能正确理解需求
2. 需求具有不确定性，导致后续顺延
3. 难以评估进度状态，在项目没结束前无法演示功能
4. 过分强调基线、里程碑，花费更多时间建立用处不大的文档

6.4.2 增量模型

前提：需求可结构化

适用于 技术驱动 的软件开发

优点

1. 第一个可交付版本所需时间少
2. 很快发布第一个版本，减少用户需求变更
3. 允许增量投资

缺点

1. 没对用户变更要求进行规划，可能造成后来增量的不稳定性
2. 需求不能像早期稳定和完整，那么可能重新开发
3. 进度和配置复杂性，会增大管理成本

6.4.3 演化模型

全局软件生存周期开发模型，属于迭代开发方法，适用于事先不能完整定义需求的软件

第一次迭代（需求 -> 设计 -> 编码 -> 测试 -> 集成）-> 反馈 -> 第二次迭代 -> 反馈 -> …

优点

1. 任何功能一经开发便进入测试，验证是否符合产品需求
2. 帮助引导高质量产品要求
3. 减少软件开发盲目性

不足：弱化需求分析的工作

6.4.4 螺旋模型

瀑布模型和演化模型基础上，加入了 风险分析

强调风险分析，适用于庞大、复杂并具有高风险的系统

1. 制定计划：确定软件目标，选定实施方案，弄清限制条件
2. 风险分析：评估方案，识别和排除风险
3. 实施工程：实现软件开发和验证
4. 客户评估：评价开发工作，提出修改建议，制定下一步计划

特点：风险驱动，关注基本步骤

6.4.5 喷泉模型

以 用户需求 为动力，以 对象驱动，主要采用面向对象技术开发项目

喷泉模型认为：软件开发过程自下而上周期的各个阶段是相互迭代和无间隙的特性

6.5 过程规划管理

戴明环

Plan：计划

Do：执行

Check：检查

Aaction：处理

6.5.1 过程建立

1. 选择生存周期模型
2. 细化选择的生存周期模型
3. 为每个活动、任务标识合适的实例数目
4. 确定时序，并检查信息流
5. 建立过程计划文档

成果：项目的过程计划

6.5.2 过程监控

1. 软件生存周期过程的监控
2. 过程改变所产生的影响的评估
3. 改变的实施
4. 实现改变

7 集成产品能力成熟度模型 CMMI

关注软件 过程途径 的改善问题，过程改善的框架

过程改善：改进组织过程性能和成熟度，并改进程序的结果

7.1 基本介绍

目的：帮助企业对软件工程过程管理和改进，增强开发与改进能力，从而能按时、不超预算地开发高质量软件

基本假设：产品质量受制于过程质量

质量支撑点：人员、规程和方法、工具和设备

7.2 模型部件

过程域

1. 一个业务域中一束相关的实践

2. 22 个过程域，分为四类：项目管理类、工程类、支持类、过程管理类

专用目标

1. 有一个或多个

2. 描述该过程域独有特征

3. 用于确定过程域是否满足

专用实践：达到专用目标的重要活动

共用目标：用于多个过程域

典型工作产品：专用实践输出的样品

子实践：对专用实践、公用实践的详细描述

共用实践的精化：为共用实践唯一应用于一个过程域，提供相关指导

意图描述：描述过程域的意图

简介性解释：描述过程域所涉及的主要概念

相关过程域：过程域所引用的相关过程域，反映了过程域间的关系

7.3 CMMI 等级

能力等级：针对单一过程域不断改善该过程域

成熟度等级：针对一组过程域不断改善一组相关的过程域

7.3.1 能力等级

过程能力

1. 过程可达预期的程度
2. 对一个过程域的改善，不断改善过程域的一种手段

能力等级	描述
0	未完成级：过程不完整
1	已执行级：实现了特定目标
2	已管理级：跟踪费用、进度、功能特性等
3	已定义级：裁剪
4	量化管理级：统计控制的等级 3 的过程
5	持续优化级：改进等级 4

7.3.2 成熟度等级

一组过程域所有目标的一种过程改善等级

成熟度等级	描述
1	初始化级：过程是混乱的应付式的
2	已管理级：确保过程按照预定方针得到计划和执行
3	已定义级：过程得到很好的描述，并应用标准、规程、工具实现
4	量化管理级：建立量化目标，将其作管理过程的标准
5	持续优化级：持续改进过程

成熟度等级达到某个等级，则其所有过程域的能力等级都要达到

7.4 过程域举例

7.4.1 项目规划

意图：建立并维护活动计划的定义

专用目标	专用实践
SG1：建立估算	估算规模、建立工作产品和任务属性的估算、定义生存周期、确定工作量和成本估计
SG2：开发项目计划	建立预算和进度、标识风险、规划数据管理、规划项目资源、规划需要的知识和技术、规划利益攸关方的参与、建立项目计划
SG3：获得对该计划的承诺	评审项目计划、调和工作和资源等级、获得计划承诺

共用目标	共用实践
GG2：共用目标 2，对共用目标 1 的专用实践实施 PDCA	建立组织策略、规划过程、提供资源、指派责任、培训人员、管理配置、标识相关利益方参与、监视过程、客观评估、高层管理视角评审状态

7.4.2 需求开发

意图：分析客户需求、产品需求、产品部件需求

专用目标	专用实践
开发客户需求	引出要求、开发客户需求
开发产品需求	建立产品和产品构建需求、分配产品配件需求、标识接口需求
分析并验证需求	建立操作概念和场景、建立所需功能的定义、分析需求、达到平衡、确认需求