软件工程手札

软件工程

软件开发活动中的各种组织及规范方法。

各阶段及其文档

1、需求分析——SRS（软件需求规格说明书），在这一阶段主要进行问题定义，可行性研究和需求分析。复审（所有的参与者：开发者、客户、用户）

2、系统设计——SAD（系统结构图），主要针对于用户界面。复审（开发者和客户）

 3、程序设计——文档，主要针对模块分析和算法设计。复审（开发者） 

4、程序实现——源代码和注释。复审（开发者和程序员） 

5、单元测试——单元测试报告，主要进行模块功能和性能测试。复审（测试团队）

 6、集成测试——集成测试报告，主要针对于系统结构图进行测试。复审（测试团队） 

7、系统测试——系统测试报告，根据SRS对系统的整体功能进行测试。复审（开发者和客户）

 8、系统提交，复审（根据用户和操作手册）——验收测试报告

 9、维护——维护报告。复审（维护团队）  

抽象

基于某种层次归纳水平的问题描述。它使我们将注意力集中在问题的关键方面而非细节。

重用

重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去。.  

软件过程

软件开发活动中产生某种期望结果的一系列有序任务，涉及活动、约束和资源。

包括三个阶段：单用户、桌面生产工具； 部门应用。

瀑布模型

开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈。

a) 优点 

i. 描述了软件开发活动，每一个过程活动都有与其相关联的里程碑和可交付产品，以便

与项目经理能够用模型来判断在某一时刻项目里最后完成还有多远。 

ii. 简单。开发人员很容易向不熟悉软件开发的客户作出解释。 

iii. 是其他复杂模型的基础。很多其他更复杂的模型实际上是在瀑布模型基础上的润色，

如加入反馈循环以及额外的活动。 

b)缺点 

i.面临软件变动时，该模型无法处理实际过程中的复杂开发问题。没有把软件看做一个问题求解的过程，软件是一个创造的过程，不是一个制造的过程。 

ii.文档转换有困难

原型

一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。 

分阶段开发模型

系统被设计成部分提交，每次用户只能得到部分功能，而其他部分正处于开发过程中。

增量式开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能呢的子系统集。 

迭代式开发：系统开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统的功能达到最强。 

螺旋模型

每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。

第一象限：制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

 第二象限：风险分析：分析评估所选方案，考虑如何识别和消除风险；

第三象限：实施工程：实施软件开发和验证；

第四象限：客户评估：评价开发工作，提出修正建议，制定下一步计划。

四重循环的含义： 

1、操作概念是第一次迭代的产品。

 2、而需求则是第二次迭代的主要产品。 

3、在第三次迭代中，系统开发产生设计。 

4、第四次迭代能够进行测试。 

5、螺旋模型的每一次迭代都根据需求和约束进行风险分析，以权衡不同的选择，并且在确定某一选择之前，通过原型化验证可行性或期望度。当风险确认之后，项目经理必须决定如何消除风险或使风险降到最低。 

V模型 

又称软件测试的V模型。它通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。

划分为：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

原型化模型 

迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。 

统一过程模型 UP

一种“用例驱动，以体系结构为核心，迭代及增量”的软件过程框架，由UML方法和工具支持。

统一开发过程RUP

开发被组织成一系列固定的短期小项目；每次迭代都产生经过测试、集成并可执行的局部系统；每次迭代都具有各自的需求分析、设计、实现和测试；随着时间和一次次迭代，系统增量式完善。从一个迭代过程到另一个迭代过程到成为最终的系统。

项目进度

对特定项目的软件开发周期的刻画。包括对项目阶段、步骤、活动的分解，对各个离散活动的交互关系的描述，以及对各个活动完成时间及整个项目完成时间的初步估算。 

活动

项目的一部分，一般占用项目进度计划中的一段时间。 

里程碑

指特定的时间点，标志着活动的结束，通常伴随着提交物。

主要风险管理活动：

风险估算（风险识别、风险分析、风险优先级分配）

风险控制（风险降低、风险管理计划、风险化解） 

需求 

是对来自用户的对软件系统的期望行为的综合描述，设计系统的对象、状态、约束、功能等。

确定需求的过程 

a) 原始需求获取 b) 问题分析 c) 规格说明草稿 d) 需求审核 e) 最后形成正式的需求文档SRS 

需求的优先级

a) 绝对要满足的需求（必须的） 

b) 非常值得要的但并非必须的需求（值的要的） 

c) 可要可不要的需求（可选的） 

需求文档

a) 需求定义：需求定义是客户想要的每一件事情的完整列表。 

b) 需求规格说明，用技术术语和符号重述需求定义使得设计者可以开始设计。

功能需求：描述系统内部功能或系统与外部环境的交互作用，设计系统输入应对，实体状态变化，输出结果，涉及约束与过程约束等。  

非功能需求/质量需求：描述软件方案必须具备的某些质量特征。

设计约束

是已经做出的设计决策或限制问题解决方案集的设计决策。 

a) 物理环境：对环境或设备的限制等 

b) 接口：涉及输入输出的限制或约束条件（输入格式预定等） c) 用户：使用者的基本情况 

过程约束

对于构建系统技术和资源的限制。 

a) 资料：材料、人员技能或其他。 b) 文档：类型、数量或其他 c) 标准

抛弃型原型

仅用于了解问题、探索可行性，并不打算用来作为将来实际提交系统的一部分。 

进化式原型

用于了解问题，并作为将来准备提交的系统的一部分。 

体系结构

一种软件解决方案，用于解释如何将系统分解为单元，以及单元如何相互关联，还包括这些单元的所有外部特性。 

设计模式

一种针对单个软件模块或少量模块而给出的一般性解决方案，它提供较低层次的设计决策。 

设计公约

一系列设计决策和建议的集合，用于提高系统某方面的设计质量。（敏捷方法中的很多原则就属于设计公约） 

设计

将需求中的问题描述转述编程软件解决方案的创造性过程 

概念设计

侧重于系统的功能，用顾客理解的语言描述系统功能，通过解释看得见的系统外部特征使顾客理解系统的功能。（确切的告诉客户系统要做什么） 

技术设计

描述了系统采用的工艺，用计算机行话和技术术语描述，对技术规格说明的技术性描述。 

 

软件设计过程模型的阶段

a) 初始建模：尝试可能的分解，根据需求描述的系统的关键特性等确定软件体系结构风格，

进行系统级别的决策。 

b) 分析：主要关注软件系统的质量属性（性能、安全性、可靠性等）、各种约束等。（关注

系统级别决策） 

c) 文档化：确定了各个不同的模型视图 d) 复审：检查文档是否满足了所有需求 

e) 最后输出：正式的<SAD>（软件体系结构文档）

模块化

模块有清晰的输入和输出，设计目的明确，功能独立，可以做独立检测。 

抽象

对细节的隐藏成为抽象。

耦合

两个软件部件之间的相互关联程度。 

i. 非直接耦合：模块之间没有信息传递 

ii. 数据耦合：模块之间传递的是数据 

iii. 特征耦合：模块间传递的是数据结构 

iv. 控制耦合：模块间传递的是控制量 

v. 公共耦合：不同模块访问公共数据 

内容耦合：一个模块直接修改另一个模块（模块A直接调用模块B的私有数据或直接转移到B模块中去） 

内聚

软件部件内部各组成成分的关联程度。 

i. 偶然性内聚：不相关的功能，过程，数据等出现在同一个部件中 

ii. 逻辑性内聚：逻辑上相关或相似的功能或数据放置在同一个部件中 

iii. 时间性内聚：部件各个部分要求在同一时间完成 

iv. 过程性内聚：各部分有特定的次序 v. 通讯性内聚：各部分访问共享数据 

vi. 顺序性内聚：各部分有输入输出的关系 

vii. 功能性内聚：各部分组成单一功能 

测试的各个阶段

a) 单元测试：对每个程序组件独立进行测试，与系统中其他组件分离。通读代码对其进行检查，试着找出算法，数据和语法上的错误。

b) 集成测试：验证系统的组件是否按照系统和程序设计说明中描述的那样一起工作。 

c) 功能测试：对系统进行评价以判定继承的系统是否真的执行了需求说明中描述的功能。 

d) 性能测试：将系统与软件和硬件需求的其它部分作比较。 

e) 验收测试：根据客户的需求描述对系统进行检查。 

f)安装测试：在用户的环境下测试，解决由于开发环境和用户环境的不同而引起的错误。

性能测试

a) 强度测试：在短时间内加载极限负荷，以验证系统的能力 b) 容量测试：验证系统处理巨量数据的能力 

c) 配置测试：分析需求中制定的不同软件和硬件配置 

d) 兼容性测试：当系统与其他系统进行交互时，检查结构功能是否按造需求的要求进行 

e) 回归测试：新的系统代替了旧的系统之后进行回归测试 

f) 安全性测试：确保安全性需求 

g) 计时测试：对需求中涉及用户响应的时间和执行一个功能的时间进行测试 

h) 环境测试：了解系统在安装地点的执行能力 

确认测试

在确信软件开发的初始阶段系统满足了所有置顶的需求后让用户对系统进行的测试。 主要分为：基准测试和引导测试 

a) 基准测试：顾客准备测试用例，这些测试用例代表了系统实际安装投入运行的典型条件，

顾客针对每个测试用例评价系统的性能。 

b)  引导测试：在试验的基础上安装该系统，用户测试该系统的安装是否耐用。它依赖的日常工作来测试所有的功能 

 Alpha测试

在顾客实际的引导测试之前先让自己的机构或公司的用户来测试这个系统。 

Beta测试

顾客的引导测试。 

黑盒测试

把测试对象看做一个不了解其内容的闭盒（黑盒），测试时向闭盒提供输入，记录输出测试。（人员完全不考虑程序内部的逻辑结构和内部特征，只依据程序的需求规格说明书检查程序的功能是否符合它的功能要求。） 

i. 等价分类法 ii. 边界值分析法 iii. 错误猜测法 iv. 因果图法 

白盒测试

把测试对象看做一个透明的盒子，可以根据测试对象的结构不同的方式进行测

试。（它允许测试人员利用程序内部的逻辑结构及有关信息或选择测试用例，对程序所有逻辑结构进行测试。） 

i. 逻辑覆盖法 

1. 语句覆盖：每条语句至少执行一次 2. 判定覆盖：每一分支至少执行一次 

3. 条件覆盖：判定中的每个条件均按“真”、“假”两种结果至少执行一次 

4. 条件组合覆盖 

ii. 路径覆盖法 

1. 边覆盖 2. 节点覆盖 

代码走查

由程序员领导组成的评审小组审查，主要检查代码和文档中的错误，属于非正

式的检查。 

c) 代码检查

正式的审查，评审小组对照一个事先准备好的关注点列表来检查代码和文档。  

黑盒白盒方法各自的分类？测试用例的设计和给出方法（结合补充材料）