计算机等级考试四级--软件工程_计算机4级软件工程

全国计算机等级考试四级教程

——软件工程（2013版）

（殷绍波）

2015年9月26日录入

目  录

第1章 软件工程概述 - 8 -

1.1 软件和软件工程的概念 - 8 -

1.1.1 软件的概念 - 8 -

1.1.2 软件危机 - 9 -

1.1.3 软件工程的概念 - 9 -

1.2 软件工程方法 - 9 -

1.2.1 面向过程方法 - 9 -

1.2.2 面向对象方法 - 10 -

1.2.3 形式化方法 - 10 -

1.3 软件过程与软件生存周期 - 10 -

1.3.1 软件生存周期 - 10 -

1.3.2 软件过程 - 11 -

1.4 软件过程模型 - 11 -

1.5 软件工具概述 - 13 -

第2章 面向对象的基本概念与UML - 14 -

2.1 面向对象系统的基本概念 - 14 -

2.1.1 面向对象系统的概念 - 14 -

2.1.2 面向对象系统的概念 - 14 -

2.1.3 类与封装 - 15 -

2.1.4 继承 - 15 -

2.1.5 多态与动态绑定 - 15 -

2.1.6 消息通信 - 15 -

2.2 统一建模语言UML概述 - 16 -

2.2.1 UML的产生和发展 - 16 -

2.2.2 UML的特点 - 16 -

2.3 UML的模型元素 - 16 -

2.3.1 UML的事物 - 16 -

2.3.2 UML中的关系 - 17 -

2.4 UML中的图 - 18 -

2.4.1 外部视图 - 18 -

2.4.2 内部视图 - 19 -

第3章 软件需求分析 - 19 -

3.1 系统工程的概念 - 20 -

3.1.1 基于计算机的系统 - 20 -

3.1.2 计算机系统工程 - 20 -

3.1.3 可行性研究 - 20 -

3.2 软件需求分析的任务和原则 - 21 -

3.2.1 软件需求的定义和层次 - 21 -

3.2.2 软件需求分析的任务 - 21 -

3.2.3 需求分析的原则 - 21 -

3.3 软件需求获取 - 22 -

3.3.1 需求获取的任务和原则 - 22 -

3.3.2 需求获取的过程 - 22 -

3.3.3 需求表达 - 23 -

3.4 结构化分析方法 - 23 -

3.4.1 数据建模 - 24 -

3.4.2 功能建模 - 24 -

3.4.3 行为建模 - 25 -

3.4.4 数据字典 - 26 -

3.4.5 基本加工逻辑说明 - 26 -

3.5 面向对象的分析方法 - 27 -

3.5.1 面向对象分析概述 - 27 -

3.5.2 识别类或对象 - 28 -

3.5.3 识别关系（结构） - 28 -

3.5.4 标识类的属性和服务 - 29 -

3.6 需求规格说明和需求评审 - 29 -

3.6.1 软件需求规格说明的目标 - 29 -

3.6.2 软件需求规格说明编制原则 - 29 -

3.6.3 软件规格说明模板 - 30 -

3.6.4 软件需求评审 - 30 -

第4章 软件设计 - 31 -

4.1 软件设计的任务和原则 - 32 -

4.1.1软件设计的概念 - 32 -

4.1.2 软件设计的任务 - 32 -

4.1.3 软件设计的过程 - 32 -

4.1.4 软件设计的原则 - 33 -

4.2 结构化设计方法 - 34 -

4.2.1 结构化设计与结构化分析的关系 - 34 -

4.2.2 软件结构及表示工具 - 35 -

4.2.3 结构化设计的过程 - 36 -

4.2.4 变换流映射 - 36 -

4.2.5 事物流映射 - 37 -

4.2.6 软件模块结构改进 - 37 -

4.2.7 接口设计 - 38 -

4.3 软件的过程设计 - 38 -

4.3.1 部署设计 - 38 -

4.3.2 算法设计 - 38 -

4.3.3 处理过程的描述 - 39 -

4.4 面向对象的系统设计 - 40 -

4.4.1 系统设计的目标和准则 - 40 -

4.4.2 子系统分解 - 40 -

4.4.3 问题域部分的设计 - 41 -

4.4.4 人机交互部分的设计 - 41 -

4.4.5 任务管理部分的设计 - 42 -

4.4.6 数据管理部分的设计 - 42 -

4.5 体系结构设计 - 43 -

4.5.1 体系结构的概念 - 43 -

4.5.2 体系结构的4+1视图 - 44 -

4.5.3 常用的体系结构风格 - 45 -

4.5.4 分布式系统的体系结构 - 46 -

4.6 对象设计 - 46 -

4.6.1 使用模式设计对象 - 47 -

4.6.2 接口规格说明设计 - 47 -

4.6.3 重构对象设计模式 - 47 -

4.6.4 优化对象设计模型 - 47 -

4.7 软件设计规格说明与评审 - 47 -

4.7.2 软件概要设计评审 - 48 -

4.7.3 软件详细设计评审 - 49 -

第5章 程序实现 - 49 -

5.1 程序实现的任务 - 49 -

5.2 结构化程序设计方法 - 50 -

5.2.1 自顶向下和逐步求精 - 50 -

5.2.2 使用基本控制结构构造程序 - 50 -

5.3 面向对象的程序设计方法 - 50 -

5.4 程序设计风格与编码规范 - 51 -

5.5 编程语言的选择 - 53 -

5.5.1 编程言特性的比较 - 53 -

5.5.2 编程语言的分类 - 54 -

5.5.3 编程语言的选择 - 55 -

5.6 程序复杂性 - 55 -

5.6.1 代码行度量法 - 55 -

5.6.2 McCabe度量法 - 55 -

5.7 程序调试 - 56 -

5.7.1 程序调试的步骤 - 56 -

5.7.2 几种主要调试方法 - 57 -

5.7.3 程序调试的原则 - 58 -

第6章 软件测试 - 58 -

6.1 软件测试的任务 - 58 -

6.2 软件测试方法 - 59 -

6.2.1 白盒测试方法 - 59 -

6.2.2 黑盒测试法 - 61 -

6.2.3 其他测试方法 - 63 -

6.3 软件测试的策略 - 63 -

6.3.1 软件测试活动 - 63 -

6.3.2 单元测试 - 64 -

6.3.3 集成测试 - 64 -

6.3.4 系统测试 - 65 -

6.3.5 验收测试 - 66 -

6.4 人工测试 - 66 -

6.4.1 桌上检查 - 67 -

6.4.2 代码检查 - 67 -

第7章 软件维护 - 68 -

7.1 软件维护的任务 - 68 -

7.1.1 软件维护的定义 - 68 -

7.1.2 软件维护的类型 - 68 -

7.2 软件维护的活动 - 68 -

7.2.1 维护机制 - 68 -

7.2.2 软件维护申请报告 - 68 -

7.2.3 软件维护过程模型 - 69 -

7.2.4 GB/T 20157-2006软件维护过程 - 69 -

7.2.5 维护记录文档 - 69 -

7.3 程序修改的步骤及修改的副作用 - 70 -

7.3.1 分析和理解程序 - 70 -

7.3.2 评估修改范围 - 70 -

7.3.3 修改程序 - 70 -

7.3.4 修改程序的副作用及其控制 - 71 -

7.3.5 重新验证程序 - 71 -

7.4 软件可维护性 - 71 -

7.4.1 可维护性的定义 - 71 -

7.4.2 软件可维护性度量 - 72 -

7.5 软件演进与再生工程 - 72 -

7.5.1 遗留系统的演化活动 - 72 -

7.5.2 软件再工程 - 73 -

7.5.3 遗留系统的现代化改造过程 - 73 -

7.5.4 重构和逆向工程 - 73 -

第8章 软件过程 - 74 -

8.1 软件过程的概念 - 74 -

8.2 软件过得的建模 - 74 -

8.2.1 软件生存周期过程模型 - 74 -

8.2.2 生存周期的基本过程 - 75 -

8.2.3 生存周期的支持过程 - 75 -

8.2.4 生存周期的组织过程 - 75 -

8.3 软件过程成熟度模型 - 76 -

8.3.1 软件过程成熟度 - 76 -

8.3.2 CMM与CMMI - 77 -

8.3.3 CMMI的分级表示 - 77 -

8.3.4 CMMI的连续表示 - 78 -

8.3.5 CMMI的模型构件 - 79 -

8.3.6 CMMI评估 - 79 -

8.4 软件过程改进 - 80 -

8.4.1 软件过程改进的IDEAL模型 - 80 -

8.4.2 软件过程改进框架 - 80 -

8.4.3 有效的软件过程 - 81 -

第9章 软件项目管理 - 81 -

9.1 软件项目与项目管理概述 - 81 -

9.1.2 项目管理的定义 - 82 -

9.1.3 过程与项目管理 - 82 -

9.2 软件项目计划与项目集成管理 - 82 -

9.2.1 项目集成成管理的概念 - 82 -

9.2.2 项目计划制订的过程 - 82 -

9.2.3 项目计划的执行和控制 - 83 -

9.3 软件项目度量与工作量估算 - 84 -

9.3.1 软件度量的概念 - 84 -

9.3.2 软件范围管理 - 84 -

9.3.3 软件项目中的资源 - 85 -

9.3.4 软件项目的工作量估算 - 85 -

9.4 项目的成本管理 - 85 -

9.4.1 项目成本的概念 - 85 -

9.4.2 项目成本管理过程 - 85 -

9.5 项目的进度管理 - 86 -

9.5.1 项目进度管理的概念 - 86 -

9.5.2 项目进度管理的过程 - 86 -

9.6 项目人员与沟通管理 - 87 -

9.6.1 项目人员管理的概念 - 87 -

9.6.2 项目的组织规划 - 87 -

9.6.3 项目的人员组织 - 88 -

9.6.4 项目团队的组织与建设 - 89 -

9.6.5 项目冲突及管理 - 90 -

9.6.6 项目沟通管理 - 90 -

9.7 项目风险管理 - 91 -

9.7.1 风险与风险管理的概念 - 91 -

9.7.2 项目风险管理的过程 - 92 -

9.8 软件配置管理 - 94 -

9.8.1 软件配置管理的概念 - 94 -

9.8.2 软件配置管理的过程 - 94 -

9.9 需求管理 - 95 -

9.9.1 需求管理的概念 - 95 -

9.9.2 需求管理的任务 - 95 -

9.9.3 需求变更请求的管理 - 96 -

第10章 软件质量管理 - 96 -

10.1 软件质量与质量模型 - 97 -

10.1.1 软件质量的概念 - 97 -

10.1.2 软件质量特性 - 97 -

10.1.3 软件质量模型 - 97 -

10.2 软件质量度量和度量模型 - 98 -

10.2.1 软件质量的度量 - 98 -

10.2.2 软件质量度量模型 - 99 -

10.2.3 软件质量度量方法 - 99 -

10.2.4 软件质量评价 - 99 -

10.3 软件质量计划 - 100 -

10.3.1 软件质量计划编制的目的 - 100 -

10.3.2 软件质量计划的内容 - 100 -

10.4 软件质量保证 - 101 -

10.4.1 软件质量保证的概念 - 101 -

10.4.2 软件质量保证的过程 - 101 -

10.4.3 软件质量保证的任务 - 102 -

10.4.4 质量保证体系与ISO9000标准 - 102 -

10.4.5 国际标准ISO90003 - 103 -

10.5 验证与确认 - 103 -

10.5.1 软件验证和确认的概念 - 103 -

10.5.2 生存周期中的验证和确认工作 - 103 -

10.6 软件评审 - 103 -

10.6.1 软件评审的概念 - 103 -

10.6.2 软件评审的作用 - 104 -

10.6.3 软件评审的实施 - 104 -

10.6.4 评审的方法的技术 - 104 -

10.7 审核 - 105 -

第11章 软件工程标准化与软件文档 - 106 -

11.1 标准和标准化 - 106 -

11.1.1 标准与标准化的概念 - 106 -

11.1.2 软件工程标准的制定与实施 - 107 -

11.2 软件工程标准的分类和分级 - 107 -

11.3 软件文档的作用和分类 - 108 -

11.4 软件工程文档的概要 - 109 -

11.5 对文档编制的质量要求 - 110 -

 

第1章 软件工程概述

1.1 软件和软件工程的概念

1.1.1 软件的概念

1. 软件的定义

（1）与硬件相互依存的部分。

（2）是程序——计算指令与数据定义的组合，使硬件执行或控制功能。

（3）是规程——执行任务面呈一系列动作的描述，规则+流程，为达到特定目标的一系列前后相继的组合

（3）程序开发、维护和使用的有关图文资料。

2. 软件的分类

（1）系统软件——服务于其他程序的程序。一类处理复杂但确定的信息结构，如编译器、文件管理器，一类处理不确定的数据，如驱动程序、网络软件。

（2）应用软件——满足特定业务需要软件。如处理商务或技术数据，交易处理，实时控制。

（3）工程/科学软件——如计算辅助设计、系统仿真等。

（4）嵌入式软件——嵌入某产品或系统中，执行有限功能。如微波炉控制键、燃油控制等。

（5）产品线软件——为多个用户提供特定功能、有限市场、大众消费的软件，如文字处理、财务应用等。

（6）Web应用软件——Web应用。

（7）人工智能——如机器人、专家系统、模式识别、人工神经网络等。

还有其他方面的：

遗留软件、网络平台、开源软件。

1.1.2 软件危机

软件危机原因：软件规模大、软件复杂、软件可靠性低，软件生产率低。

1. 软件危机的表现：

（1）软件生产成本高；

（2）软件生产进度拖延、生产率低；

（3）软件可靠性差；

（4）软件难以维护，缺乏维护文档，修改后又引入新的错误。

2. 软件危机解决的途径：工程化、标准化。

用工程化的原则来指导软件开发与维护，

1.1.3 软件工程的概念

1. 软件工程的定义

用计算机科学理论和技术以及工程管理原则和方法，按预算和进度，实现满足用户要求的软件产品的定义、开发、发布和维护的工程或进行研究的学科。

2.软件工程框架

软件工程的目标：生产正确性（功能）、可用性（用户接受）、开销适宜的产品（成本合算）。

软件工程的步骤：分析、设计、实现、验证与确认、支持（修改和完善）等活动。

软件工程活动4个原则：

（1）选取适宜的开发范型（开发方法学）

（2）采取合适的设计方法

（3）提供高质量的工程支持

（4）重视开发过程的管理

软件工程的其他理解：

（1）软件工程基本是质量，包括合格的产品、规定时间和成本内交付，客户满意。

（2）软件产品的质量需要在软件生产过程中层层把关，技术结合，合理的组织活动、人员、规程、方法，高效的开发软件。

（3）软件工程方法为构建软件提供了技术上解决方法。

（4）软件工具提供了自动化或半自动化的支持，计算机辅助设计CASE。

 

1.2 软件工程方法

即软件开发范型，解决问题的途径。

1.2.1 面向过程方法

初始化→输入→处理→输出→结束

从功能角度出发，将软件视为处理流，将步骤串起来。

（1）步骤：带有输入和输出的过程。

侧重于解决建立解决问题的处理流，其中的数据结构是根据程序算法步骤的要求开发的，提供过得所要求操作的信息。

用全局变量进行过程到过程的状态传递。

所建立的软件结构由一系列模块组成。

示例言语：C、Pascal语言。

1.2.2 面向对象方法

寻找问题中的实体，标识主要动作实体，考虑实休对象的行为，即针对对象的数据抽象和过程抽象。

数据抽象——对象的属性，抽取所关心的属性（共同特性）

过程抽象——对象操作属性值，即对象的运行状态。

对象——客观世界中存在的人、事、物体等实体在计算机逻辑中的映射。

优势：概念一表示方法上的一致性，尽量模拟人的思维方式。对于大型、复杂的交互性比较强的系统优势明显。

1.2.3 形式化方法

基于形式化数学变换的软件开发方法，可将规格说明书转换为可执行的程序。

过程的描述

需求定义→形式的规格说明书→形式化交换→集成和系统测试

形式化变换——规格说明书（数学记号）——转换成可执行程序。

需求规格说明语言——用数学记号表达详细的形式规格说明。

1.3 软件过程与软件生存周期

1.3.1 软件生存周期

软件生存周期——软件概念开始到废弃，代替的整个时期。

软件生存周期阶段划分：软件定义、软件开发、交付后运行维护。

1. 软件定义期间的基本任务：解决做什么的问题。

（1）工程目标和范围，功能、性能、质量要求，活动范围。

（2）可行性研究，

（3）需求获取，

（4）制订项目计划。

2. 软件开发时期的基本任务：解决如何做的问题，给出设计方案并构造出待开发软件。

（1）概念设计，一是建立分析模型，从功能、数据、行为等方面描述系统的静态、动态特性，引入需求细节。二是编写软件需求规格说明书。

（2）概要设计，从系统输入输出入手，搭建体系结构，全局数据结构，同时对人机交互界面和运行控制机制建模。

（3）详细设计，对构件和局部数据结构设计，人机界面细节，构件内部细节和构件在实际运行环境下部署。

（4）编码，程序进行编码，同时行行单元测试。

（5）测试，对集成系统组装测试。

3. 交付后维护：持久满足用户需求。

（1）更正性维护。更正出错

（2）适应性维护。适应环境

（3）完善性维护。用户要求进行扩充

（4）预防性维护。为将来维护预先准备。

1.3.2 软件过程

软件过程归结为如下：

（1）软件规格说明书，定义软件的功能和约束操作。

（2）软件设计与实现，生产规格说书里的软件。

（3）软件确认，确认有效性。

（4）软件演进，改进产品。

软件过程由软件交付物、里程碑、质量检查点，一组工作任务组成。

何护伞活动：软件质量保证、软件配置管理等。

1.4 软件过程模型

软件过程模型也称软件生存周期模型。以下为常用过程模型：

1. 编码：修补模型：简单代码拼凑，适用于100行至200行的小程序。

2. 瀑布模型：每阶段都要求交付物被认可，经过技术评审，才结束该阶段，进入下一阶段。

各个阶段：需求→分析→设计→实现→交付后维护→退役

问题：太理想化，各阶段划分固定，缺乏灵活性。

3. 快速原型开发模型：快速原型——客户确认——参照原型改进，再进行分析、设计、实现、交付后维护、退役。

4. 增量模型：先开发子系统，再把各个子系统组成完整软件系统。

特点：最重要的先交付使用，每个增量即一个子系统，每个增量可采用瀑布开发模型。

5. 快速应用开发模型（RAD）：也是增量式软件过程模型，强调极短时间（2～3个月）内开发完成。

主要包括以下阶段：

（1）沟通，客户与各领域专家协同，共同理解待开发软件。

（2）策划，任务分解，安排开发过程

（3）建模。由各开发小组同步分别进行。

①业务建模，业务功能中的信息流建模。

②数据建模，对一部分信息流求精得到一组数据对象。

③流程建模，数据对象操作的过程化描述。

（4）构建，构造待开发的系统。

①复用构建，新软件构件。

②代码自动生成技术。

③复用构建进行确认测试，新构件测试，用户界面程序测试。

6. 螺旋模型：将瀑布模型与快速原型模型结合起来，加入风险分析。软件过程被表示成螺旋线，每转一个圈，表明完成完成软件过程的一个阶段。最内圈是需求获取和可行性研究活动，第二圈是软件需求建模和编写规格说明书，第三圈是系统设计。

螺线上的每一个圈可划分为四个象限：

（1）目标设定。目标、目标的限制条件，管理计划，识别风险。

（2）风险评估与弱化。针对每个风险进行详细分析，设想弱化风险的步骤。

（3）开发与确认。

（4）计划。评价开发工作

7. 同步——稳定模型：需求阶段访问潜在客户，提高最高优的特性列表，制定规格说明文档，再将工作分为3到4个构件，第一包含最重要的特性，第二个次之…，每个构建都由多个小组半行完成，每天工作结束前，所有小组进行同步工作，也就是完成部分的构建放在一起，测试得到产品，构件开发结束前进行稳定化工作，修补遗错，并将构件冻结，不再修改规格说明。

每天构建同步进行——稳定化——构建冻结。

开发人员遵循的规则：

（1）软件人员每天代码输入数据库中，以便同步当天的工作。

（2）如果一个开发人员代码阻碍了当天的同步编译，必须立刻解决，以便当天完成测试和调试。

优点：重复同步，开发人员能及时掌握产品的工作状态。

8.开源过程模型：初始版本——免费使用——成熟阶段。

特点：参与成熟阶段的是自愿工作。

9.极限过程：用户故事，用户希望产品支持和各种特性，开发组通报实现特性需要的时间和花费，再由客户据成本—收益分析法选择构建应包含的特性。

开发阶段将构建再细分为任务，程序员首先应设计该任务的测试用例再做开发（测试驱动开发）

编码时，两个程序员结对编程，一个编程，一个检查代码，共同集成。

表现：

（1）成员组在一个房间，大房间分成相通的小隔间。

（2）一个客户代表与开发小组一起工作。

（3）没有一个人连续工作超过两周。

（4）没有规模说明书，小组成员共同守成规格说明、分析、设计、编码和测试。

（5）没有概要设计

极限编程与敏捷编程过程的共性：

（1）不强调分析和设计

（2）与客户协作，响应需求

（3）频繁交付可运行软件，每2或3周一次。

（4）上班前有站立会议，回答5个问题

敏捷过程的两个基本原则：交流与尽可能快地满足客户的需要。

10. Rational统一开发过程。用例驱动、体系结构为核心、迭代开发的、增量的过程。

迭代开发——连续应用瀑布模型的几个小部分，一部分进行需求分析和风险、设计、实现并确认之后，再对别一部分需求分析和风险、设计、实现并确认，直到完成整个项目。

RUP中的迭代过程分4阶段：

（1）初始阶段。建立系统用例，标识外部实体，定将与系统交互。

（2）细化阶段。系统需求模型、软件系统的结构描述和开发计划。

（3）构造阶段。构造完整产品，系统各部分并行开发，再逐步集成。

（4）移交阶段。开发部门移交给用户。制造、交付、培训、支持及维护。

RUP的特点：

（1）迭代式地开发软件。迭代和增量的开发过程。

（2）管理需求。一是需求获取并记入文档，二是估计生存周期的需求变并评估它们的影响。三是跟踪、记录和权衡所做出的各种决策。

（3）使用基于构件的软件体系结构。

（4）建立可视化的模型。

（5）不断验证软件质量。

（6）控制对软件的变更。持续监控变更。

1.5 软件工具概述

软件工具（CASE）分两类：一是软件开发的分析工具，如逐步求精法，成本—效益分析法。二是软件工具，即软件开发和维护的辅助工具

1. 逐步求精法：尽可能的将细节推延到最后，以便集中精力在重要的事项上。

2. 成本—效益分析法：软件工程项上是否合算。

3. 软件度量：

产品度量，检测产品的某些特性，如规模或可靠性。

过程度量，推断软件开发过程的某些信息，如错误检查有有效性=开发过程中错误数/软件整个生命周期错误数。

基本度量有：

（1）规模，代码行

（2）成本，元

（3）时间，月计

（4）工作量，人月计

（5）质量，错误数

观点：只有度量软件过程，才能控制软件过程。

4. 软件工具CASE工具：即计算机辅助软件工程工具。

CASE工具的作用如下：

（1）支持软件开发方法，辅助软件工程方法和过程的实施。

（2）提高软件开发、维护和管理效率。

（3）提供检测机制，提高软件质量。

5. CASE的分类

（1）工具：支持软件开发的单个活动或任务的软件工具。

（2）工作台：支持软件过程或活动的工具集。

（3）环境

按软件过程活动分：

（1）支持开发工具。

（2）支持软件维护过程工具。版本控制、文档分析、逆向工程

（3）支持软件管理过程和支持过程的工具。项目管理、配置管理、软件评价工具。

6. 版本工具

对交付物（文本、表格、代码），即软件制品进行修改管理的工具。

（1）修订版本：经过修改后的版本，新老版本都应保留。

（2）变种版本：为支持不同的设备和操作系统而进行修改的版本。

7. 配置控制

软件制品的代码分三种：原代码、目标代码（编译代码）、可执行载入映像（编译代码+运行时例程结合）。

版本控制工具的作用

（1）管理合格的软件制品，修订版本和变种版本。

（2）可执行载入映象包含了哪些制品及其版本号

（3）可自动管理变种版本。

8. 建造工具

与版本工具一同使用，可形成产品的一个特定版本。

 

第2章 面向对象的基本概念与UML

2.1 面向对象系统的基本概念

主流开发方法，以面向对象以实体为中心。

2.1.1 面向对象系统的概念

面向对象概念：对象+类+继承+消息通信。

面向对象系统的特点：

（1）易理解，实体出发，与人思维习惯。

（2）易修改，系统结构稳定性好，修改可以局部化。

（3）易组装，构件组装，可复用性好。

（4）易测试，适合开发大型软件产品。

（5）易维护，细节隐蔽，产品维护性好。

2.1.2 面向对象系统的概念

1. 对象的定义

客观事物的实体，是构成系统的基本单位。

每个对象由：名字、一组属性、一组操作构成。

对象表示：矩形框，名字加下画线。

概念的两个层次

（1）可以有形，如学生、人、梯，也可以是逻辑对象，如事件、调度器。

（2）由变量和操作的集合。变量为对象的状态，操作表明对象具有的行为。

对象的分类：物理对象、角色、事件、交互、规格说明书。

2. 对象的特点：

（1）是处理消息的主体。不存在即不发消息，也不收消息的对象。

（2）以数据为中心，操作与对象属性相关，返回结果属性值相关。

（3）实现了数据封装。对象是一个黑盒。

2.1.3 类与封装

1. 类的定义：类是相同属性、操作、语义相同的对象的集合

对象构成类，类中对象为实例。

2. 类与封装

按照便于用与现实分离的要求，封装类的属性和操作定义。

（1）清楚的边界，所有对象的内部信息被限制定在这个边界内。

（2）接口，对象向外界提供的方法，外界可以通过这些方法与对象进行交互。

（3）受保护的内部实现。即软件功能的实现细节，实现细节不能从类外访问。

目的：模块耦合度大大降低，模块独立性，程序易修改和维护。

2.1.4 继承

几个类共有的属性和和行为，抽取出来放在一个父类中，将各个类特有的特性放在子类中分别描述，则建立起子类对父类的继承。

继承内容上划分：

（1）取代继承：可以用子类代替父类。窗口与WINDOWS窗口。

（2）内容继承：如四形包括了矩形。

（3）受限继承：如驼鸟继承鸟的特性，但不会飞

（4）特化继承：子类可以直接使用父类的数据+操作，它自己还增加了数据+操作。如汽车与起重车。

2.1.5 多态与动态绑定

相同的操作名或函数对应不同的对象类型，可以利用重名来提高程序的抽象度和简洁度。如+，在对整数对象操作是加法操作，而在字符操作时为字符连接操作。具有多态的函数或操作在运行时才根据实际的对象类型执行相应实现程序的连接，即动态绑定。

多态性可以用两种方式实现

（1）利用继承关系。子类的不同被解释为不同的操作。

（2）利用模板机制，把所有可能的数据类型用一个参数化的数据类型来代替。

2.1.6 消息通信

消息是一个对象向别一个对象传递的信息，可分以下四类：

（1）请求接收对象提供服务

（2）激活接收对象

（3）询问接收对象

（4）仅传送信息给接收对象

消息使用方式类似于函数调用

2.2 统一建模语言UML概述

是面向对象的标准建模语言。

2.2.1 UML的产生和发展

1996年发布UML0.9

2001年发展到2.0版本

2.2.2 UML的特点

（1）统一标准。提供了面向对象模型元素的定义和表示法。

（2）面向对象。

（3）可视化，表达能力强大。

（4）独立于过程。不依赖于特定的开发过程。

（5）容易掌握使用。

（6）与编程语言的关系，可以自动生部分代码框架，支持程序测试及配置管理等工作。

2.3 UML的模型元素

UML的模型元素为标准图形符号，可组成系统模型，可描述结构和行为。

模型元素的分类

（1）模型中的事物。如类、对象、构件、节点、接口、包、注释等。

（2）模型中元素的连接关系。如关联、泛化、依赖、实现等。

2.3.1 UML的事物

是对模型中具代表性成分的抽象。

UML中，事物又可以分类为：结构事物、行为事务、分组事务、注释事物。

1. 结构事物类：描述概念或物理的元素。

（1）类，用带有类名的、属性、操作的矩形框表示。

（2）对象，是类的实例，其名字下加下划线，对象的属性值明确给出。

（3）接口，一个类或构件的一组外部可用的服务（操作）集。一般画成类或构件引出的气球接口，体现了使用与实现分离的原则。

（4）主动类，能够启动控制活动，为一个或多个进进程或线线程，类的基础上两侧加边框。

（5）用例：系统相要功能的实现，椭圆形表示。

（6）参与者：与系统交互关系的人、事、物，以小人表示。

（7）协作：功能的实现，用虚线椭圆形表示。

（8）状态：对象生存周期的某一动态行为。圆角矩形表示。

（9）构件：组件或模块，系统中物理的、可替代的部件。带有小方框的矩形表示。

（10）节点：系统部署时分布的物理资源，用立方体表示。

2. 行为事物

（1）交互：由一组对象之间传递的消息组成，包括消息和链（对象间的连接）。

（2）状态机：一个对象或一个交互生存周期内响应事件所经历的状态序列。

3. 分组事物，分组事物以包的出现形式，由一组模型元素组成的一个组由一组模型元素组成的一个组。目的是降低系统的复杂性。

4. 注释事物：带有约束或解释的图。

2.3.2 UML中的关系

模型元素之间的关系。

1. 依赖关系

用一个虚线加箭头表示，箭头从源事物指向目标事物，表示源事物依赖于目标事务。

依赖关系分以下三种：

（1）访问目标类内部数据值

（2）调用目标类内部的操作

（3）返回目标类的实例

UML中的特殊的依赖关系：

（1）访问<<access>>,可访问目标类的权限

（2）绑定<<bind>>,目标类是模板

（3）调用<<call>>,调用了目标类内部的操作

（4）派生<<derive>>,原事物可由目标事务通过计算导出

（5）创建<<create>>,源类可创建目标类的实例

（6）实例化<<instantiate>>,原类的实例创建了目标类的实例，并同完成了初始化和满足约束工作。

（7）实现<<realize>>,具体实现间的映射关系

（8）发送<<send>>,信号接收关系

（9）使用<<uses>>,

包之间的依赖关系还有导入依赖和导出依赖。

（1）导入依赖：包之间的依赖关系，源包可以用简单的名字访问目标包里的元素。

（2）导出依赖：调整元素的可见性而使得包中的元素可以被外部的操作访问。

用例之间的依赖关系还包括包含依赖、扩展依赖。

（1）包含依赖：源用例把目标用例的行为一部分包含进来

（2）扩展依赖：目标用例扩展了源用例的行为。

2. 关联关系：是结构关系，两个或多个类之间的连接关系。如：一架飞机有两个发动机，则飞机和发动机之间就存在关联关系。

关联关系又分普通关联、限定关联、关联类、聚合、复合关联。

（1）普通关联。普通关联又分二元关联和多元关联

①二元关联：两个类之间的关联。

②多元关联：3个或3个以止类间的关联。

（2）限定关联：一对多或多对多的关联中，可把多重性一对多变成一对一，或多对多简化成多对一。

（3）关联类：对关联关系的语义作详细定义、存储和访问，为此建立关联类。

（4）聚合（集）：描述整体与部分的结构关系。

①共享聚合：部分一侧的实例可同时参与多个处于整体一侧的实例的构成。

②复合聚合：部分实例完全隶属于整体类的实例，且部分类与整体类的实例共存。

3. 泛化关系：是类和特殊类之间的继承关系，特殊类完全拥用一般类的信息，并且可以附加一此信息

（1）普通泛化。如交通工具有汽车、轮船，汽车是车轮驱动，轮船是驱动螺旋桨转运。

（2）受限泛化。是指泛化关系具有约束条件。存在交叠、不相交、完全和不完全等。如人可分男人、女人，人也可分医生、教师。

4. 实现关系。实现是泛化关系和依赖关系的结合，也是类之间的语义关系，

2.4 UML中的图

UML的图分：内部视图，供开发者使用，外部视图，供参与者使用

2.4.1 外部视图

外部视图包括用例图、活动图和顺序图

1. 用例图

展现一组用例、参与者和扩展关系、包含关系。

作用是描述系统在它的上下文环境中应提供的外部可见服务。

用途：

（1）上下文环境建模，说明系统之外并与系统进行交互的参与者以及它们所扮演的角色信义。

（2）功能需建模。说明需系统的行为。

建立用例图的步骤：

（1）从问题中寻找参与者。

（2）寻找这些参与者的职责。

（3）确定参与者与用例之间的关系，得到整个用例图。

2. 活动图

用例图反映了系统应提供的功能，但不包括功能的细节。需用活动国资委和顺序图提供功能的实现细节。

活动图显示了用例中操作和操作之间的控制流和对象流，可以表达出计算过程或工作流顺序的和并发的执行步骤。

可以描述用例的业务工作流程。

3. 顺序图

按时间顺序显示对象间的交互，描述如何通过对象之间的交互实现用例。

对象表示为虚垂线顶端的矩形框。发起用例活动的参与者放在最左边。

对象下面的虚垂线为生命线，时间线，表明对象在一定时间内的创建和撤销。

顺序图展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。

2.4.2 内部视图

内部视图描述系统内部的过程、活动、关系和结构。

1. 类图

静态结构，包括建模元素包括类及其结构和行为，接口、协作、关联、依赖、泛化关系，多重性和导航指示符，角色等。

常见的可见性包括Public（+）、Private（-）、Protected（#）。约束性说明，如｛只读｝、又如｛const｝常值操作，操作不会改变类对象的值。

2. 对象图

是类图的一个实例，如一步电影的一个快照。

3. 通信图

称协作图或合作图，描述对象之间的相互交互，箭头表示发送或接收消息，消息上所附的序列号。

与顺序图不同点：顺序图强调消息收发的时间先后顺序，但没有明确的表达对象之间的关系；通信图强调各个对象的组织关系，但时间顺序必须从消息的序列号得到。

4. 状态机图

事件发生时，对象做出响应就会导致状态的转变。

5. 构件图

一组构件和它们之间的依赖关系。

6. 包图

建立包图是为了降低复杂性。

（1）包：包是一个组织单元，大多数只需列出重要的元素（工作人员、业务对象）就可以了。

（2）类：执行业务过程的人或相关人员的角色<<Worker>>

（3）业务对象，某些用例。

7. 部署图

展示了运行时处理节点在这些节点上制品的配置。

描述了处理器、设备和软件构件运行时的配置。

制品：代表了物理实体，如文件、脚本、数据库表单、网页等。

第3章 软件需求分析

回答系统必须做什么的问题？把软件的总体概念描述为软件需求规格说明书，是不断认识和逐步细化的过程。

3.1 系统工程的概念

3.1.1 基于计算机的系统

基于计算机系统工程，简称计算机系统，是软件开发的大环境，软件工程是计算机系统工程的一部分，体现软件在主算机系统中承担的职责，如何工作。

计算机系统元素：

（1）软件：程序，逻辑方法、过程或控制的相关文档。

（2）硬件：指提供计算机的计算能力的电子设备（CPU、存储器）和提供外部功能的机电设备（传感器、马达）

（3）人：硬件和软件的操作员。

（4）数据库：一个大型的有组织的信息集合。

（5）文档：手册、表格等描述系统使用过程的描述性信息。

（6）过程：即规程，每种系统元素便于用的特定步骤，或系统驻留的过程性环境。

3.1.2 计算机系统工程

1. 识别用户的要求，系统工程师与用户合作，确认用户的目标和约束。

2. 系统分析和结构设计，

（1）硬件系统模型结构。选择硬件，确定系统成分功能和性能范围，提出能与其他系统成分适当集成的接口要求。

（2）软件系统模型，分配给软件的功能和性能范围，分解子系统。

（3）人机交互模型，分配给人的各项活动，对话方式。

（4）数据库模型，定义数据库的信息、查询的类型，存取方式等等。

3.1.3 可行性研究

目的是做出细致而谨慎的评估，发现将来开发过程中遇到的问题，避免大量人工、金钱、时间上的浪费。

1. 可行性研究内容

（1）经济可行性，开发成本（人、时、物）和效益估算（指标度量、无形：性质、心理衡量），是否值得投资开发。

（2）技术可行性，现有资源和技术条件下，技术风险大小和系统能否实现。

①风险分析，考察技术解决方案的实用性。

②资源分析，人—熟悉程度，硬件软件是否具备实现条件。

③技术分析，技术、方法、算法或过程可能存在风险。

（3）法律可行性，关注系统开发过程中可能涉及的合同、侵权、责任以及各种与法律抵触的问题。如：雷同侵权，导致法律纠纷。

（4）用户操作可行性，系统构架是否符合使用单位的现状和制度，用户计算机利用情况和使用者分类现状，使用习惯。

3. 方案的选择和折中

4. 可行性研究报行，概述、目标、可行性的研究结果。得出行或不行的决断。

3.2 软件需求分析的任务和原则

获取需求和编写规格说明，以便做出满足客户期望的软件产品。

3.2.1 软件需求的定义和层次

1. 需求的定义，IEE《软件工程词汇表》给出。

（1）解决问题或达到目标所需的条件或能力。

（2）系统或系统部件满足合同、标准、规格说明或其他正式的强制文档所必须具有的条件或能能力。

（3）对（1）和（2）中所描述的文档化说明

GB/T 11457-2006《信息技术 软件工程述语》

（1）用户要求的系统所具有的外部行为

（2）开发者要要求的内部特征

（3）文档化。

2. 需求层次

（1）业务需求

（2）用户需求

（3）功能需求与非功能需求

功能需求——软件所要求的功能或服务

非功能需求——对系统的限制和用户对系统质量的要求。

①产品需求，性能、接口、可靠性、安全保密、运行限制、物理限制。

②过程需求，开发类型、开发工作量估计、开发方法选取、应遵守的规范和标准，可理解性、可修改性、可移植性、可测试性、效率、可维护性等质量的需求和优先级。

③系统需求，系统对软件成分的要求。

3.2.2 软件需求分析的任务

1. 需求分析的目标：全面理解用户的各种需求，准确表达被接受用户的需求。

2. 需求分析的任务：与客户沟通、向客户请教、聆听客户所言、观察他们行为。需求验证。

3.2.3 需求分析的原则

1. 必须理解和描述问题的信息域。

信息域即计算机处理的数据，包括信息流、信息内容、信息结构

①信息流：数据被传递和处理的形式。输入信息——转换成中间数据——加工成结果输出。

②信息内容：输入、处理、输出数据的实际内容。

③信息结构：数据项的逻辑组织。

2. 必须描述软件将要实现的功能

功能包括为最终用户提供服务，性能为外部可见特征的内部持。

3. 必须描述软件的行为

实体、系统与部部环境的前交互。

4. 要给出软件逻辑视图和物理视图。

逻辑视图：从用户角度对软件业务功能、业务信息和系统（实体）行为的描述。

物理视图：从系统实现角度，给出业务功能、业务信息和系统行为的实际实现形式。

3.3 软件需求获取

需求获取的目标是确定用户到底“需要解决什么问题”。是最难、最关键、最容易出错及最需要交流的方面。

3.3.1 需求获取的任务和原则

（1）需求的不稳定性。会随着时间推移发生变化。

（2）需求的不准确性。

（3）需要客户/开发者交流。

1. 需求获取活动的任务

（1）发现和分析问题，发现问题症结，并分析问题的原因/结果关系。

（2）使用调查研究方法收集信息。

（3）遵循需求获取框架。分3个问题观察不同侧面。数据、过程、接口。

（4）需求归档。

2. 需求获取技术的基本原则

（1）深入浅出原则。要求全面细致

（2）以流程为主线的原则。

3.3.2 需求获取的过程

1. 开发高层的业务模型。站在应用领域的高度，兼容该领域其他软件系统的用户业务模型。

业务模型包括业务流程模型和业务实体模型。

2. 定义项目的视图和范围。

在相关人员中获取共同理解和评判标准，不必涉及过多细节，通过它表示系统的概貌。

3. 识别用户类和用户代表

确定用户类别，并从选出客户代表，商定谁是项目需求的决策者

4. 获取具体需求

（1）交谈和讨论

（2）阅读现有产品或竞争产品的描述文档。

（3）分析系以需求规格说明。

（4）得到当前系统问题报行和改进要求。

（5）进行市场调查和用户问卷调查

（6）观察用户如何工作。

（7）分析用户工作的场景

（8）事件的响应。列出系统必须响应的外部事件和正确的响应。

5. 确定待开发系统的业务工作流

确定系统的业务工作流和主要的业务规则

6. 需求整理与描述

（1）业务规则的用例（或数据流图）并设置优先级。

（2）收集用户的质量信息和其他非功能需求。将性能、安全、可靠等需求和其他设计约束结合业务规则，形成功能需求。

（3）分类在用例（或数据流图）中涉及的数据，包括数据组成和数据之间的关系。

（4）详细撰写用例（或数据流图）的规格说明，建立功能模型，并进行审查。

（5）开发人机界面原型。

（6）对界面原型进行检查，验证用例（或数据流图）和功能需求。

3.3.3 需求表达

用例方法是一种表达需求的有效方法。

用例方法描述用讯需要通过系统执行什么服务，包括用例图和场景等。

使用用例方法描述用户需求的过程如下：

（1）标识参与。参与者可以不同类型的用户，可以是人、事件或其他系统。

（2）标识用例。分析每个参与者使用系统干什么。

（3）标识场景。分析参与者与用例之间的交互情节。

（4）求精用例，细化每个用例，

（5）标识用例之间的关系

（6）标识非功能需求。包括约束、文档、使用资源、安全性和质量等需求。

3.4 结构化分析方法

需求阶段概要地反映了用户需求，为了更详细描述系统需求，必须建立系统的分析模型，其目的是将来自客户的需求形工化。

传统的分析建模方法称为结构化分析方法。是一种面数据流的分析建模方法。

核心是数据，描述了所在系统中使用和生成的数据实体。围绕核心生成三种图：

（1）实体关系图。数据实体与数据实体之间的关系，用于数据建模。

（2）数据流图（DFD），描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能），用于功能建模。

（3）状态迁移图（STD），系统对外部事件如何响应，如何动作，用于行为建模。

3.4.1 数据建模

实体——关系图：描述数据实体及数据实体之间的关系，用于数据建模和面向对象分析建模。包含了3种相互关联的信息：数据实体、实体的属性、实体间相互连接的关系。

1. 实体-关系图中的主要成分

（1）数据实体：是系统涉及复合信息的表示，具有若干不同属性，用矩形框表示。如外部实体（鼠标）、事务（如报表）、角色（如学生）、行为（一个电话呼叫）、事件（单击鼠标左键）、组织单位（图书馆）、地点（教室）、结构（如文件）。一个实体集中的实体称为该实体的实例。

（2）属性。数据实体的特征，用圆角矩形框表示。

（3）主键与次键：为了唯一地标识数据实体集的某一实例，定义一个或几个属性为主键。

（4）实体的联系：表示数据实体的实例间的关系。（1：1）（1：n）（m：n）

2. 实体-关系图示例

3. 实体-关系图的建立步骤

（1）列出所有涉及的事务。

（2）一次考虑一个数据实体，并考虑实体是否与其他实体存在连接。

（3）当存在连接时，分析应创建一个或多个<实体-关系>对

（4）对每个实体-关系对，考察它的多重性

（5）迭代执行（2）～（4）步骤

（6）定义每个实体的属性

（7）规范化并复审实体-关系图。

（8）重复（1）～（7）步骤，直到数据建模完成。

3.4.2 功能建模

使用分层的数据流图描述系统的处理流程，从抽象到具体，自顶向下逐层分解，细化到能够实现的软件分量为止。

1. 数据流图的图形元素

描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能，用于功能建模。

数据流图的元素

（1）加工：负责对输入数据进行变换处理以产生输出数据，用椭圆形表示。

（2）数据流：加工之间的数据传送，用带箭头的线→表示。

（3）数据存储：保存数据的数据组织，用双下划线表示。

（4）数据源或数据潭：外部实体，表示图中要处理的输入或输出到哪里用矩形框表示，它不属于系统，是与系统打交道的实体，构成系统的边界。

2. 分层的数据流图：按照系统的功能层次逐层分解，分层分解数据流图。

3. 数据流图示例

4. 功能建模的步骤

（1）确定系统有交互关系的外部实体（数据源或数据潭）。构成系统的输入输出。

（2）确定外部实体与系统交互的数据流。外部实体使用系统干什么？

（3）画出顶层的数据流图。

（4）分析系统的主要功能，建立第1层数据流图。

（5）对每一个加工继续进行细化。

照此画下去，直到不细分为止。

5. 绘制分层数据流图的原则

（1）数据流图上的图形篻号只限于前述四种图形元素，命名反映其实际含义。

（2）顶层图的数据流必须封闭在外部实体间。

（3）每个加工至少有一个输入数据流和一个数据输出流。

（4）允许一个有多条数据流流向另一个加工，也允许一加工有两个相同的输出数据流流向两个不同的加工。

（5）需按层给加工框编号。编号表明该加工的层次与上下层的亲子关系。

（6）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据和输出数据流必须一致，即父图与子图的平衡。

（7）如果一个数据存储在展开的数据流子图中使用，可以在父图中不画出。

（8）可以在数据流图中加入物质流，帮助用户理解。

（9）数据流图中不可夹带控制流，但针对实时系统可以加入控制流，成为数据流图的扩展式（数据流是实箭头，控制流是虚箭头）

3.4.3 行为建模

为了直观地描述系统的行为，需要建立动态模型。最常用的动态（行为）模型方法有状态迁移图和顺序图（面向对象分析）等。

状态迁移图：描述系统的状态如何响应外部信息进行推移的一种图形表示。

状态迁移图可以使用状态迁移矩阵来表达。

状态迁移图的优点：

（1）状态之间的关系能够直观地捕捉到；

（2）能免机械地分析许多情况，可很容易进行分析。

如果系统复杂，可以把状态迁移图分层表示，开成嵌套的状态图，还可以加入判断条件和处理内容。

3.4.4 数据字典

描述数据的数据，详细定义所有数据流图中出现的所有被命名的图形元素。

3.4.5 基本加工逻辑说明

基本加工逻辑，底层数据流图中的加工，它是自顶向下、逐步细化的终点，应可以写出其处理规则。其主要目的是表达“做什么”，而不是“怎样做”。

（1）每一个基本加工，必须一个加工逻辑说明。

（2）加工逻辑说明必须描述基本加工如何把输入数据变换为输出数据的加工规则。

（3）加工逻辑说明必须描述实现加工的策略而不是实现加工的细节。

（4）加工逻辑说明中包含的信息应是充足的、完备的、有用的、没有重复的多余信息。

用于写加工逻辑说明书的工具有结构化语言、判定表和判定树。

1. 结构化语言（PDL伪码）

介于自然语言和形式化语言之间的半形式化语言，又称伪码。

结构化语言词汇表由原形动词、数据字典中定义的名字、有限的自定义词。以及用于划分基本控制结构的逻辑关系词IF_THEN_ELSE（两分支判断）、While_Do（先判断的循环）、Repeat_Until（后判断）、Case_Of（多分支判断）等组成。

2. 判定表

某个加工需依赖多个逻辑条件的取值时，用判定表，判定表示例：

左上部分是条件桩、右下部分是动作桩，右上部分是条件项取值，右下部分是动作项取值。

3. 判定树

表达逻辑加工的和种工具，用◇表示。

在表达一个加工逻辑时，结构化语言、判定表和判定树常常交叉使用，相互补充。

判定树的使用，不太复杂的判定条件，当使用判定表有困难。

结构化语言的使用，同时存在顺序、判断和循环条件时。

判定表的使用，复杂的判定，组合条件较多。

3.5 面向对象的分析方法

进行面向对象分析（OOA）的目的是得到对问题领域的清晰、精确的定义。

3.5.1 面向对象分析概述

典型有以下几种方法：

（1）Booch方法。

（2）RumHbugh方法

（3）Goad和Yourdon方法

（4）Jacobson方法

（5）Wirfs-Brock方法

（6）UML的OOA方法

3.5.2 识别类或对象

面向对象分析模型由3个独立的模型构成：由用例和场景表示的功能模型，由类和对象表示的分析对象模型；由状态图和顺序图表示的动态模型。

类分为实体类、边界类、控制类。

实体类——表示系统将跟踪的持久信息。

边界类——表示系统中与参与者打交道的类。

控制类——负责用例的实现。

例如：按钮和液晶显示屏是边界类；年、月、日是实体类；变更日期是控制类。

1. 识别实体类

（1）自然言语分析法。

①短语频率分析。

②矩阵分析

（2）从用例模型中识别选选对象

（3）从状态模型中识别候选对象

①事件响应模型

②状态迁移图

2. 识别边界对象

（1）识别与参与者有交互的用例的用户界面控制

（2）识别参与者需要录入的系统数据表格

（3）识别系统需要识别的事件和系统用于响应用户的消息

（4）当用例有多个参与者时，根据构想的用户界面来标识参与者的行为。

3. 识别控制对象

控制对象负责协调实体与边界对象，现实中没有具体事务，它通常从边界对象处收集信息并将这些信息分析给实体对象。

3.5.3 识别关系（结构）

使用类图，能够表示类之间的关系，通常类图中使用关联表示类之间的具体链接。使用多重性表示类的实例间的对应关系。

（1）检查指示状态的动词或动词短语，识别动作的主体和客体，从角色寻找关联。

（2）准确地命名关联和角色

（3）尽量使用常用的修饰词标识出名字空间和关键属性

（4）应消除导出其他关联的关联

（5）在一组关联被稳定之前先不考虑实例之间的多重性

（6）过多的关联将使得一模型不可读

3.5.4 标识类的属性和服务

对象是一组属性值和作用在其上的一组操作的封装体。

1. 标识类的属性

（1）每个对象至少包含一个属性，例如_id

（2）属性的取值必须适合对象类的所有实例

（3）出现在泛化关系中的对象所继承的属性必须与泛化关系一致。

（4）系统的所有储数据必须定义为属性

（5）对象导出属性应当略去

（6）如果某属性描述了对象的外部不可见状态，应将属性从分析模型中删去。

2. 标识类的服务

对象收到消息后所能执行的操作称为它可提供的服务。

（1）简单服务，每一个对象都应具备的服务，如初始化一个新对象，存取对象的属性值，释放一个对象，这些服务在分析时不标出，但实现类时有定义。

（2）复杂的服务，可分以下两种。

①计算服务。利用对象属性值计算，以实现某种功能。

②监控服务，处理对外部系统的输入/输出，外部设备的控制和数据的存取。

3. 对每个对象的与状态有关的行为建模

通过对象的行为模型描述对象的行为和对象之间的消息通信，说明所标识的各种对象是如何共同协作，使系统运行起来。

消息通信路径表示对象在什么状态下对哪个消息做出怎样的反应，可使用交互图（例如UML的顺序图）来标识和描述对象之间的相互通信。

对于一个事件，顺序图表明由哪个对象来识别事件的发生，产生什么消息，哪些对象接收消息，并产生什么响应，事件追踪图的表示方法类似于顺序图。

3.6 需求规格说明和需求评审

3.6.1 软件需求规格说明的目标

是描述需求的重要文档，是软件需求分析工作的主要成果。应着重反映软件的功能需求、性能需求、外部接口、数据流程等多个方面，在开发、动行、维护过程都起着重要的作用。

软件需求规格说明书的目标

（1）开发人员与客户达成共同协议建立了基础。

（2）让客户在软件设计之前能周密的思考全部需求，减少返工。

（3）为成本估算和编制进度计划提供基础。

（4）为确认和验证提供一个基准。

（5）成为软件不断改进的基础。

3.6.2 软件需求规格说明编制原则

原则是为促使软件成功实现的方法来描述和表达需求

原则1：从现实分离功能，即描述“做什么”，而不是“怎样实现”。

原则2：要求使用面向处理的规格说明语言（或称为系统定义语言）

原则3：如果新软件是大系统的一部分，那么大系统也应在规格说明中描述。

原则4：规格说明必须包括系统动行的环境。

原则5：系统规格说明必须是一个认识的模型。

原则6：规格说明必须是可操作的。

原则7：规格说明必须不完备性并允许扩充。

原则8：规格说明必须是局部化和松散耦合的。

3.6.3 软件规格说明模板

GB/T 8567-2006《计算机软件文档编制规范》

1. 软件需求规格说明书

计算机配置项的需求以及为确保需求得到满足所使用的方法。

软件需求规格说明主要内容

 

数据需求说明

3.6.4 软件需求评审

对需求规格说明书的评审，对它们的质量进行评估。目的是确保软件需求规格说明及相关文档的无歧义性、一致性、完备性和正确性。

主要审查如下：

（1）用例：描述正确？用例规格说明书是否包含了所有备选事件的事件流和异常事件流？清楚、歧义、完整地记录了每个场景的交互？

（2）功能： 清楚、明确地描述所有功能？满足用户需要？是否覆盖了所有非正常情况的处理？

（3）性能：是否精确的描述了所有的性能需求和可容忍的性能降低程度？

（4）接口：是否定义了所有外部、内部接口？各接口间关系是否一致性。

（5）数据：是否定义了系统的所有输入和输出？是否说明了输入和输出的类型、值域、单位、格式和精度？是否说了如何进行输入的合法性检查？对异常数据半生的结果是否进行了精确描述？

（6）硬件：是否指定了最小、最大存储空间要求？

（7）软件：是否指定了软件环境、操作系统环境？是否指定了需要的所有软件设施？

（8）通信：是否指定了网络协议？网络连接数量和网络性能需求？

（9）正确性：需求规格是否满足标准的要求？处理规则是否做过测试？是否定义了针对各种故障模式和错误类型所必须的反应。

（10）完整性：是否包含功能、性能、限制、目标、质量等方面的所有需求？是否定义了将来可能会变化的需求？是否定义了人机界面的需求？是否按完成时间、重要性对系统功能、外部接口、性能进行了优化排序？

（11）一致性：各个需求间是否一致？是否使用了标准术语和定义形式？需求是否与其硬件操作环境相容？

（12）清晰性/无歧义性：所有定义、实现方法是否清楚和准确地表达了用户有需求

（13）安全性

（14）健壮性：是否有容错需求？

（15）可修改性

（16）可测试性和可验证性

（17）可维护性。松耦合

（18）可跟踪性

（19）可靠性

（20）其他

 

 

第4章 软件设计

项目工程在设工前要完成设计工作，软件设计处于需求分析阶段与软件构造（编码）阶段的中间工作，需求分析是“做什么？”，软件设计是基于需求提出一系列解决方案，解决“怎么做”。

 

4.1 软件设计的任务和原则

4.1.1软件设计的概念

软件设计既是过程又是模型，是一系列的迭代步骤，使软件设计师能够描述待开发软件的各个侧面。

设计模型首先描述目标系统的整体构架，然后逐步细化得到构造细节的指导原则。

4.1.2 软件设计的任务

从工程角度分，软件设计可分概要设计和详细设计。

从技术角度分，体系结构设计，数据（类、对象）设计、接口设计及过程（构件）设计4个部分。

（1）结构化设计中

概要设计将软件需求转化为数据结构和软件的系统结构，即完成体系结构设计、数据设计、接口设计。

详细设计的任务完成过程设计。

（2）面向对象的方法中

概要设计是完成体系结构设计，初步的类设计/数据设计、接口设计。

详细设计是在概要设计基础上完成构件级设计。

4.1.3 软件设计的过程

首先建立软件系统总框架（直接反映功能、数据、行为需求），然后进一步细化（加工成细节上接近于源程序的软件表示）。

主要活动如下：

（1）设计输入评审。审查需求分析所提供的文档，补充和完善分析模型。

（2）制定技术规范。

①确定设计目标，优先顺序，选择合适的设计方法。

②确定文档的编制标准，文档体系、记述详细程度、图形的画法。

③规定系统的接口规约、命名规则、以及编程语言等。

（3）确定运行环境，确定硬/软件环境，开发支撑工具，其他相关的系统等

（4）体系结构设计，包括体系桔构设计、模块设计和接口设计等

（5）数据设计，数据（库）结构设计、数据保护性设计等

（6）质量设计，如何把软件质量特性要求映射到软件系统结构中，如何验证。

（7）运行设计，确定算法和评估算法性能、模块间的控制方式，外部信息的拉收及发送形式，以及用户界面的设计方案。

（8）概要设计说明的编写与评审。

详细设计的活动包括：

（1）确定各模块的具体算法。

（2）确定内部数据结构。

（3）确定外部接口方式。

（4）描述各种算法和相关数据结构。

（5）描绘用户界面和操作流程。

4.1.4 软件设计的原则

1. 分而治之和模块化原则。将大而复杂的问题分成许多相对容易解决的不问题，模块到子模块。

2. 模块独立性。软件模块的编写和修改都可能尽可能少地考虑与其他模块的牵连。模块间的低耦合，模块内的高内聚。

3. 尽可能降低耦合。

紧密←耦合性←松散

弱→模块独立性→强

（1）内容耦合，如果一个模块直接问另一个模块的内部数据，或不通过正常入口转到另一个模块内部，就发生了内容耦合。

（2）公共耦合，两个模块共同访问同一个全局数据。

（3）控制耦合，一个模块通过控制参数显示另一个模块的动作。

（4）标记耦合，两模块通过参数表传递数据结构，如记录、数组或对象。

（5）数据耦合，两个模块通过参数表传递简单变量（不是控制参数、数据结构）。

模块化设计的目的是建立模块间耦合度尽可能低的系统。以便独立地可以对某一个模块进行独立的设计、编码、测试和维护。

4. 尽量提高内聚性

紧→内聚性→松散

强←模块独立性←弱

（1）信息内聚，把访问或操作同一数据结构的操作，连同这个数据结构，都放在一个模块中，就形成了信息内聚。

（2）功能内聚，一个模块只执行单一计算并返回结果且没有副作用，即执行单一功能。

（3）通信内聚，模块内的一系列操作，按预定的顺序执行，且他们都访问相同的数据。

（4）过程内聚，模块内的一系列操作，按预定的顺序执行，不要求访问相同的数据。

（5）时间内聚，又称经典内聚，模块内有多个操作，这些操作间联系很弱，便这些操作必须同一时间执行，例如初始化模块和终止模块。

（6）逻辑内聚，几种不相关但不是顺序执行的，而是可各自独立执行的操作放在一个模块内。每次调用时，由传递给模块的控制参数来确定该模块应执行哪一种操作，如错误处理模块。

（7）巧合内聚，把那些没有独立功能但在许多模块中重复多次的语句的抽取出来，组成一个新模块，目的是为了节省空间。一但修改会引起其他模块的措误。

5. 提高抽象层次

（1）信息隐蔽：实现细节对于使用者来说是隐蔽的，使用者只能模块接口来使用模块中包含的信息（包括数据和操作）。

（2）数据类型参数化：对于一个过程或对象类为了做到“一次编写，处处使用”，把其中所涉及的数据类型参数化。

参数化的方式就是抽象，一是设计时使用自定义类型代替实际使用的数据类型，二是使用模板把数据类型参数化。三是采用面向对象的多态机制，建立不同（数据类型）具体类对抽象类的继承结构，把抽象类当作接口。

（3）自顶向下，逐步细化。从高层到低层的软件体系结构设计。

6. 复用性设计

一是尽量使用已有的构件，二是在设计时就考虑将来的重复利用问题有意识的按可复用构件的要求建立自己的设计。

设计中引用复用性的方法：使设计尽可能的通用（数据类型参数化，所有数据自包含）；提高构件的独立性和抽象性（高内聚、低耦合）；设计系统时要包含钩子（建立一些表格或链接，以纳入新的功能）；尽量简化设计。

7. 灵活性设计

灵活性是软件对于环境或需求变化有较强的适应性。灵活性的关键在于抽象，灵活性会因抽象程度的提高而提高。

8. 预防过期

预测将来环境上可能发生的变化，并采取相应的预防措施。

9. 可移植性设计

软件不经修改或稍加修改就可以运行于不同的不同软件硬件环境。

10. 可测试性设计

能够被测试的容易程度，提倡优先编写测试代码。

11. 防御性设计

考虑自动检错、报错和纠错功能。

（1）前置条件：必须满足条件才执行。

（2）后置条件：正常执行结果必须满足的条件。

（3）不变式：在执行时一直保持成立的条件。

4.2 结构化设计方法

结构化设计方法是在模块化、自顶向下、逐步细化及结构化程序设计基础上发展起来的，根据系统的处理过程进行设计，故称过程驱动的设计。

4.2.1 结构化设计与结构化分析的关系

结构化设计方法的实施要点如下：

（1）首先研究、分析和审查数据流图，弄清楚数据流加工的过程。

（2）根据数据流图决定问题的类型，确定数据处理是变换流型还是事物流型。针对两种不同的类型分别进行分析处理。

（3）便于用变换流角磨机塔克事物流遇射，由数据流图图推导出系统的初始结构图。

（4）利用一些启发式原则来改进系统的初始结构图。

（5）根据分析模型中的实体-关系图和数据字典进行数据设计。

（6）在上面设计的基础上，并依据分析模型中的加工规格说明、状态迁移图以及控制规格说明书进行过程设计。

4.2.2 软件结构及表示工具

结构化设计，一般通过功能划分，依据分析建立的分层数据流图，采用自顶向下、逐层细化的方式建议程序的模块层次结构。

1. 模块的层次结构

顶层的模块是程序的主模块，再引出下一层下属模块。

层次结构的特点：整个结构只有一个主模块，上层模块调用下层模块，同层模块不相互调用。

最低层存在一些公共模块，由上层模块调用。

2. 结构图

结构图定义和模块名，功能和接口，以及模块间的层次调用关系。主要图如下：

（1）模块。用矩形框表示，用模块名字标记功能。

（2）模块的调用关系和接口。

（3）模块间的信息传递。用空心圆的短箭头表示数据，用实心圆的短箭头表示控制信息。

（4）复得调用和选择调用的符号。

（5）模块的扇出和扇入。扇出数为调用下属模块数目。扇入数为调用一个给定模块的调用模块的数目。

3. 数据结构

数据结构是数据各个元素之间的逻辑关系的一种表示。由于数据结构不同则底层处理算法也不同，所以数据结构与模块结构同样重要。

4. 结构图中的模块

结构图中有4种类型的模块

（1）传入模块，调用下属模块取得的输和数据，进行某些处理，再将其作为上级模块的输入传给它的上级模块，它传关的数据流称为逻辑输入数据流。

（2）转出模块，调用从它的上级模块获得数据，进行某些处理，再调用某个下属模块并将数据传给下属模块，它传送的数据流称为逻辑输出数据流。

（3）变换模块，又称加工模块，它从调用它的上级模块获得输入数据，进行特定处理，转换成结果数据，随着调用返回，再传送回上级模块。

（4）协调模块：对所有下属模块进行协调和管理的模块。

实际中，还有上述各类型的组合。

4.2.3 结构化设计的过程

（1）复查并改造数据流图。确保数据流图给出了系统正确的功能模型，图中每个处理都代表一个相对独立的子功能。

（2）区分数据流图具有变换流特性还是事务流特性。如果“输入-变换-输出”则变换流型数据处理。如果是事件驱动，则惜属于事物流型。也有可能是混合体，此时应区分以哪一种为主。

（3）导出初始的软件结构图。根据数据流类型。

（4）逐级分解。

（5）改进软件结构。使用设计度量和启发式规则对得到的软件结构进一步进行改进。

（6）导出接口描述和全局数据结构。每个模块给出进出该模块的信息，即该模块的接口描述。

4.2.4 变换流映射

将具有变换流图特点的数据流图映射成软件结构，分4步：

（1）重画数据流图。物理输入端-处理-物理输出端

（2）在数据流图上区分系统的逻辑输入、逻辑输出和变换中心部分。

变换中心——系统中最核心的加工所在位置。

物理输入——变换中心——逻辑输入。

物理输出——变换中心——逻辑输出。

（3）进行一级分解，设计系统模块结构的顶层和第一层。即顶层模块，功能是调用第一层模块，完成系统所要做的各项工作。

下属的第一屋按照输入、变换中心和输出等分支来设计。为每一个逻辑输入设计一个输入模块，功能是为主模块提供数据。为每个逻辑输出设计一个输出模块，功能是将主模块的数据输出。为变换中心设计一个变换模块，功能是将逻辑输入转换成逻辑输出。

第一层模块与主模块之间传送的数据与数据流图相对应。

（3）进行二级分解，设计中、下层模块。自顶向下、逐层细化，为每一个输入模块、输出模块、变换模块设计它们的从属模块。

除物理输入模块外，其他输入模块的功能是向调用它的上级模块提供数据，所以必须有一个数据来源，因而它有两个从属模块：一个负责接收数据，一个负责把这些数据变换成上级模块所需的数据。

除物理输出模块外，其他输出模块是调用它的上级模块接收数据，用于输出，因此也有两个从属模块：一个是负责将上级模块提供的数据变换成适合输出的形式；一个是负责将它们输出。

每个逻辑输入，还要有加工框，在相应输入模块下面建立一个子输入模块和一个子变换模块。对于每个逻辑输出，还要有加工框，在相应输出模块下面建立一个子变换模块和一个子输出模块。

设计变换中心模块的下层模块没有通用的方法，参照数据流图的变换中心部分和功能分解的原则来考虑如何对中心模块进行分解。

4.2.5 事物流映射

如果数据流图中存在多个事务处理，它们不是按照预定的步骤，而是根据接收到的一项事物请求，选择并分派执行某一个处理，最后给出结果，即事物流型数据流图。

完成选择和分派任务的部分称为事务中心（或分派部件）。

使用事物流映射，首先建立一个主模块用代表整个加工，然后考虑第一层模块，第一层模块只有3个：取得事物请求、事物中心、给出结果。

步骤如下：

（1）识别事物源。利用数据流图和数据字典，确定事物中心和每一种要处理的事务，以及数据接收通路。

（2）将事物流型数据流图映射成最高层的系统结构。包括顶层和第一层。顶层模块就是主模块，它的功能就是系统的功能。第一层模块包括接收模块（事物请求）、分派模块（调度各个事物处理）、输出模块（输出处理结果）。

（3）进一步分解。识别各种事物处理，根据它们内部的处理特性，使用变换流映射或事物流映射，建立它们的结构图。

4.2.6 软件模块结构改进

改进系统的初始结构图的启发式规则如下

（1）模块功能的完善化。除规定执行的功能部分外；还应有错误处理，不能完成规定功能时送回出错标志，向调用者报告出错原因；

（2）消除得复功能，发送软件结构。

①完全相似。结构上完全相似，数据类型不一致，可采用合并的办法，把数据类型当参数就可以了。

②局部相似。不可以把它们合并为一，否则会造成判断过多，模块内部控制过于复杂。正确的方法是把相同部分从各模块中分离出去，重新定义成下层一个独立的模块。

（3）模块的作用范围应在控制范围之内。

控制范围包括本身及从属模块。作用范围是指模块内一个判定的作用范围，凡是受这个判定影响的所有模块都属于这个判定的作用范围。

（4）应尽可能减少高扇出结构，随着深度增大扇入。扇出数大，意味着模块复杂，应适当增加中间层，比较适当的为2～5个，不要超过9。扇出数过小也不好，将增大结构图的深度。

模块的扇入数越大，则共享该模块的上级模块数目越多，若扇入数太大，例如超过8，而它又不是公共模块，则应当对它进一步分析并将其功能分解。

（5）避免或减少使用病态连接，应限制以下3种病态连接。

①直接病态连接。模块A直接从模块B内部取出某些数据，或者把某些数据直接送到模块B内部，上为内容耦合，绝对不可出现。

②公共数据域病态连接。模块A和模块B通过全局数据直接发送或接收数据，而不是通过它们的上级模块，此为公共耦合，应尽量避免。

③通信模块病态连接。模块A直接从模块B通过通信模块传送数据。由于它们之间的数据传送没有通过它们的上级模块，上级模块的修改、排错和维护都可能会干扰模块A和模块B之间的数据传送。

（6）模块大小要适中。通常50～100行，保持在一页纸内，最多不超过500行，有利于提高程序的可理解性。

（7）设计功能可预测的模块，避免过分受限制的模块。即对于相同输入数据，总能产生同样的结果。

（8）设计大小可控的局部数据结构。调用者可通过模块接口上的参数或一些预定义外部参数来规定或改变局部数据结构的大小。

4.2.7 接口设计

接口设计依据数据流图的系统的边界。

系统边界将数据流图中的处理划分为手工处理部分和系统处理部分，系统边界之外是手工处理部分，系统边界之内是系统处理部分。

系统的接口设计由穿越边界的数据流定义。最终形成用户界面中的表单、报表或其他系统进行交互的文件或通信。

接口设计包括3个方面：模块或软件构件之间的接口设计、软件与其他软/硬件系统间的接口设计、软件与人（用户）之间的交互设计。

4.3 软件的过程设计

软件的过程设计即详细设计，延续了概要设计，其结果将成为编程实现的直接依据。主要考虑如何构造具体的实施方案，主要任务包括部署设计和算法设计。

4.3.1 部署设计

包括处理方式、软/硬件选择、网络设计、系统环境设计的配置等

（1）处理方式。系统处理模式，批处理、实时处理、联机处理和分布式处理等，也可以是混合使用。

（2）软/硬件先择。为系统购置必须的软件和硬件配置。硬件，技术成熟可靠、良好性价比，售后服务与技术服务好、操作方便、一定时间内保持先进的计算机及外部配件。软件方面有，操作系统、开发语言、开发工具、应用软件包等。

（3）网络设计。C/S，B/S。

（4）系统环境的配置。

①网络环境

②硬件环境配置

③软件配置。

4.3.2 算法设计

问题求解、控制的流程、程序的实现都要借助算法，判断算法优劣的主要有以下几个标准。

（1）正确性。正确执行预定的功能和性能要求。

（2）健壮性。要求在算法中加入调用状态进行自动检错、报错并通过与用户对话来纠错的功能。

（3）可读性。逻辑必须是清晰的、简单的结构化的，所有变量名、函数名的命名必须有实际意义，加入注释。

（4）高效性。算法的效率，执行时间和空间的开销，即时间代价和空间代价。

（5）简单性。算法越简单，出错率越底。

4.3.3 处理过程的描述

使用表达工具来描述模块内的处理流程。表达工具有3种。图形工具、表格工具、语言工具。

1. 图形工具

（1）程序流程图。

①顺序图。

②选择型。

③选判定循环型。

④后判定循环型。

⑤多情况选择型。

（1）N-S图，也称盒图。也有5种基本控制结构图。

（3）UML活动图。它不但支持经典的顺序图、if选择型、while循环型，还可描述并行操作，比程序流程图的功能更强大。

2. 表格工具

当算法包含多重嵌套选择条件时，用程序流程图、N-S图都不易清楚描述，判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系。

判定表是一个表格，分为四个部分，其左部是条件或数组元素的名称，右上部是所有条件的组合，左下部是处理中活动的名称，右下部标明条件组合和相应的活动的对应关系。

判定表优点是能够简洁，无二义性地描述所有的处理规则，但不能表达加工的顺序，也不能表达循环结构。

3. 语言工具

PDL是描述功能模块的算法设计和加工细节的语言，称为设计程序用语言。是一种伪码伪码，分为外语法和内语法。

外语法使用程序设计语言常用语法规则和关键字，用于控制结构和数据结构。

内语法用日常语言。

4.4 面向对象的系统设计

结构化设计过程中，数据定义及在数据上的处理是分开描述的。而面向对象设计中，数据及其处理是封装在一起的，具有更好的独立性，也能更好地支持复用。

分析不考虑任何特定计算机有关的事情，而设计必须考虑与软件实现有关的周边环境和实际运行环境。

面向对象设计分两个阶段，即系统设计和对象设计，系统设计建立软件的体系结构，对象设计集中于类的详细设计。

4.4.1 系统设计的目标和准则

面向对象的系统设计的主要活动如下：

（1）标识系统目标：标识并区分各种质量属性的优先实现次序。

（2）子系统分解：根据用例和分析模型，将系统分解为一系列子系统，

（3）子系统细化：对各个子系统不断分解求精，直到所有的设计目标都能满足为止。

明确系统设计的目标是系统设计的第一步，设计目标可以从以下5组设计中选择：

（1）性能准则：包括响应时间、吞吐量、占用存储量等

（2）可靠性准则：包括可靠性、可用性、容错性、保密性、安全性。

（3）最终用户准则：包括效用、易用性。

（4）成本准则：包括开发、部署、升级、维护和管理成本。

（5）维护准则：包括可扩展性、可修改性、可适应性、可移植性、可读性、需求的可追踪性。

4.4.2 子系统分解

软件体系结构设计的第一步是做子系统分解，从而搭建软件体系结构的架构。初始子系统应该从需求的功能模型（用例模型）中导出。

MVC是模型-视图-控制器的缩写，该模型把所有人机交互的系统分解成模型、视图、控制器3种部件。

模型部件用于封装问题的核心数据，处理逻辑和功能，独立于具体的界面表达和I/O操作。

视图部件用于把模型数据信息、系统状态的信息以支付宝的形式展示给用户。它从模型获得显示信息，对于相同的信息可以有多个不同显示形式或视图。

控制部件的作用是接收输入，把输入传送给模型，进而实现对模型的计算控制，使模型和视图协调工作，通常一个视图具有一个控制器。

MVC模型将系统分为问题域、人机交互、任务管理、数据管理4个子系统。

4.4.3 问题域部分的设计

问题域部分包括与应用问题直接有关的所有类和对象。在面向对象设计过程中，可以对面向对象分析得出的问题域模型进行以下方面补充或调整。

（1）调整需求。一是用户需求或环境发生变化，二是分析人员对问题理解不透彻，导到分析模型不能准确地反映用户的真实需求。

（2）复用已有的类。

①从类库中选择已有的类，购买、网络、小组搜集遗留软构件，把它们增加到问题域部分的的设计中去。

②在被利用的已有类和问题域类之间添加泛化（一般化\特殊化）关系。

③标出在问题域类中因继承被复用的已有类或构件而变得多余的属性和服务。

④修改与问题域类相关的关联。

（3）把问题域类组合在一起。引入根类，将下层类组合到一起。

（4）增添泛化类以建立类间的协议。将来自不同包的一组类似服务，把该包当物特化类，定义一个泛化类。

（5）调整继承的支持级别。分析模型中的多继承关系，针对单继承或无继承的编程言进行修改。

①针对单继承语言的调整：将多继承结构转换成单继承结构。

②针对无继承语言的调整：将每个泛化关系的层次展开，成为一组类及对象。

（6）改进性能。为了提高性能，改变问题域的结构。

①需经常在类之间传送大量消息，可以合并类，减少消息传递引起的速度损失。

②将某些属性添加到原来的类中，或增加低层类，以保存暂时的结果，避免每次都要重复计算造成速度损失。

③为克服性能瓶颈，从高层绕过某些层直接访问低层的接口。

（7）存储对象。每个对象将自己传送给数据管理部分，由数据管理部分来存储对象本身。

4.4.4 人机交互部分的设计

即用户界面，影响软件产品的竞争力和寿命。包括必须的实际显示和输入。

（1）明确用户界面应具备的特性，衡量人机用户界面好坏的标准。

①可用性，简单、界面一致、拥用帮助功能、快速地系统响应和低的系统成本、具有容错能力等。

②灵活性。为不同用户提供不同的界面形式。

③可靠性。

（2）用户分类。可分4类，外行型、初学型、熟练型、专家型。

（3）描述用户。仔细了解使用系统的每类用户的情况。

（4）选择界面设计类型。

（5）设计详细的交互，准则如下：

①一致性。术语、步骤、风格一致。

②操作步骤少。使用按键、点击鼠标减少及减小下拉菜单的深度。

③不要哑播放。进展信息反馈。

④提供Undo功能，对于基本的操作提供恢复功能。

⑤共享剪贴板。

⑥提高学习效率。提供联机帮助信息。

（6）建造人机交互界面原型。

（7）设计人机交互的细节。

4.4.5 任务管理部分的设计

任务是进程的别称，是执行一系活动的一段程序。通常任务管理子系统有4种。

1. 将子系统映射到构件和处理器

（1）选择硬件配置和平台。

（2）将对象和子系统分配到节点上。

2. 标识并存储持久性数据

（1）标识持久性对象。

（2）选择存储管理策略。如何存储这些持久对象，需考虑检查速度、查询的复杂程度、内存、磁盘空间的需要量等。

3. 提供访问控制

不同的参与者对不同的功能和数据可以有不同的访问权限。

4. 全局控制流设计

（1）识别事件驱动任务。通过事件-响应模型建立每一个事件的响应处理。

（2）识别时钟驱动任务。以固定的时间间隔来执行某些处理。

（3）识别优先任务。根据处理的优先级别来安排任务，以满足高优先级的处理需求。

（4）识别关键任务。关键任务是与系统成败有关的关键处理，分离出来，满足高可靠性处理的要求。

（5）识别协调任务。当有多个任务时，可考虑增加一个协调任务，将不同任务间的协调控制封装在协调任务中。

（6）审查每个任务。

（7）定义每个任务。任务命名，如何协调任务，如何通信。

4.4.6 数据管理部分的设计

对要存储的数据及其结构进行设计。

1. 文件设计

根据使用要求、处理方式、存储信息量、数据的活动性，以及所能提供的设备条件，来确定文件类别，选择文件媒体，决定文件的组织方法，设计文件记录格式，估算文件的容量。

文件的组织方式：

（1）顺序文件。一种是连续文件，顺序地放在外存的一片连续区域中，另一种是串联文件，通过块链指针将文件顺序地链接起来。适合批处理，所有文件存储媒体。磁带、打印机、只读光盘采用。

（2）直接存取文件。文件的记录键值直接指定了记录地址，可根据记录键值通过散列函数计算，直接映射到记录的存放地址。

（3）索引顺序文件。记录按顺序组织，记录按排序键值升序安排。

（4）分区文件。主要用于存放程序。

（5）虚拟存储文件

2. 数据库设计

如何将对象设计映射到关系数据库中。

（1）类可以映射为一个表或多个表。竖切用于实例软少而属性很多的对象。横切常常用于记录与时间相关的对象。

（2）关联关系的映射。

一对一，一对多，多对多。

（3）继承关系的映射。

4.5 体系结构设计

随着软件规模和软件复杂程度的不断增大，系统结构设计和规格说明的作用就显得越来越明显。

4.5.1 体系结构的概念

1. 软件体系结构的概念

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

2. 构件的概念

是构成系统的基本组成单位。一个构件由一个或多个对象经过包装构成，通过接口独立地对外提供服务。

构件由：构件名、属性、服务、接口组成。

属性描述构件静态特征

服务构件动态特征的操作序列

接口是构件为外界提供服务的界面。

3. 构件的描述

3C模型，从概念、内容、语境3个方面来描述构件。

概念——构件做什么？

内容——是概念的具体实现。

语境——刻画构件的应用环境。

4. 构件的分类

按承担职责不同分

（1）纯计算构件。简单输入输出，没有运行状态变化，主要承担计算或数据处理的构件。

（2）存储构件。用来存储共享的、永久的、结构化数据的构件。

（3）实何构件。操作和数据的封装体，它执行的操作与运行状态紧密相关。

（4）控制构件。用于管理或调试其他构件运行的时间、时机及次序的构件。

（5）连接构件。用于实体间传递信息的构件。

5. 构件的连接件

用于构件间的通信、合作和协调。

（1）过程调用

（2）数据流

（3）间接激活

（4）消息传递

（5）共享数据

6. 构件的特性

外部可见特征如下

（1）计算功能。描述构件所实现的整体功能。

（2）结构特性。描述特定构件定义、打包的方式、相互交互方式，构件如何组织以构成整个系统。

（3）附属功能。构件的执行效率、处理能力、环境假设、全局特性等。

（4）家族特性。描述相同和相关构件之间的关系。

4.5.2 体系结构的4+1视图

软件体系建立是一个循序渐进的增量式过程。

（1）逻辑视图：系统的逻辑分解，其目标是建立系统面向问题的逻辑架构，从而描述功能需求。可用类图描述静态类结构，还可以用状态图描述类实例的内部行为。

（2）进程视图：在系统架构基础上添加控制机制，给出系统行为描述的实现。进程是系统执行的单元，系统性能特性、并发性、分布性，以及各种控制和调度策略的实现，都需进程视图，因此时程视图是系统运行动态行为的实现。

（3）开发视图：该视图把系统的逻辑体系结构映射到程序结构，即模块。模块是程序的独立构件，它可以包括一个类或几个关系密切的类，也可以仅包括一个类的一部分。模块结构实现所面临的问题包括模块接口、模块管理、模块控制和一致性等问题。

（4）物理视图：是软件体系结构的实施视图。目标是把模块结构映射到分布式系统的网络节点上。满足系统的可用性、可靠性、性能和可伸缩性等非功能需求或的质量需求。

（5）场景视图：最重要的要素是用例图，是用户角度可以看到的系统服务的情节。场景及用例是系统开发的驱动器，它将4个视图有机的结合起来。

（6）模型的剪裁：并不是所有软件体系结构都需要4+1图。如一个处理器则可以省略物理视图，如果仅一个进程或程序，则可省略进程视图。

4.5.3 常用的体系结构风格

1. 软件体系风格的概念

根据经验，倾向于采用某一个特定解决模式，软件风格描述了一种系统模型，包括了一个词汇表和一组约束。反映了模型的结构的语义。

常用可分为构建型、控制型、求精型。

2. 构建型体系结构风格

根据各构件如何共享数据、如何分布、如何相互交互，构建型风格可分为以下3类：

（1）数据仓库风格。数据库系统、超文本系统和黑板系统都属于数据仓库风格。

数据仓库（如文件或数据库）位于这种体系结构的中心，其他的客户会经常访问该数据库，并对数据进行增加、修改或删除操作。

这种风格的体系结构可以共享大量数据，在构件间无须进行数据转换。

（2）客户机/服务器（C/S）风格。这种体系结构是一个分布式系统架构，表明如何将种种数据和处理分布到各个处理器上，由3部分组成。

①服务器：负责给其他子系统提供服务，如数据库服务器提供数据存储和管理，文件服务器提供文件管理服务，打印服务器提供打印服务。

②客户机：向服务器请求服务，是独立的子系统，可以多个客户机并发运行。

③网络：连接客户机和服务器，使客户机能够访问服务器。

该风格对硬件和软件的变化显示出极大适应性和灵活性，且易于扩充。

（3）层次风格。把系统组织成一系列的层次，每一层次为上层提供一组服务，并可以使用下层提供的服务。

3. 控制型体系风格

构建型体系结构风格将一个系统分解为构件或子系统，但人为一个整体必须对各构件加以控制，使得它们有报务能够在正确的时刻被导向到正确的方向

控制型体系风格实际是指体系结构层次上的控制模型，应考虑构件之间的控制流。

（1）集中控制风格的体系结构。将一构件设计成为系统控制器，职责是管理其他构件的执行，即控制构件顺序执行，也控制构件并发执行。作为集中控制器的构件将控制权交给另一个构件后，由其完成它的功能，之后还要将控制权归还给集中控制器。

①调用-返回风格。用结构化方法建立的程序模块就属这种系统结构。控制始于程序层次的顶部，通过子程序调用，从较高层的程序向较低层的程序传递控制信息，程序执行结控制权返回较高层的父程序。

公应用于顺序执行的系统。

②管理器风格。既应用于顺序、又应用于并发系统。系统结构中有一个系统构件（进程）被设计成系统管理器，用于控制程序的开始、终止，并协调其他系统的进程。

系统控制器不停地循环传感器和其他进程的事件和状态变化，决定什么时候该启动或停止进程。因此此结构也称事件-循环结构。

（2）事件驱动风格的体系结构。集中控制系统通过一些系统状态变量值决定控制的流向，通过外部生成的事件来驱动系统。

①中断驱动风格。专用于实时系统。

②广播风格。一个事件向所有的子系统广播，由能够处理此事件的子系统来响应它。

4. 求精型风格的体系结构

将系统分解后构建的进一步细化所得到的结构。

（1）数据流风格。将系统进一步分解成一系列功能构件，管道及过滤器。进行数据变换的构件称过滤器。把数据从一个过滤器的输出导入到别一个过滤器的输入，就是管道。

（2）对象风格。在对象风格的体系结构中，将系统分解为一组对象。分解的焦点在于对象类、对象属性及对象操作。

4.5.4 分布式系统的体系结构

所有大型计算机系统现在都是分布式系统，分布式系统在信息分布在多个计算机上，系统运行在网络相连的一组松散地集成在一起的处理器上。如ATM机、机票预订系统。

1. 分布式系统的主要特点

（1）资源共享。硬件、软件资源共享使用。

（2）开放性。可通过非私有资源来扩展自己的能力，可包括来自不同厂家的硬件和软件产品兼容。

（3）并发性。网络上的不同计算机可同时运行多个进程，运行期间可以相互通信。

（4）可伸缩性。可通过增加新的资源满足对系统的新需求。

（5）容错性。可容忍某些硬件或软件失效，只有网络失效时才完全丧失服务能力。

（6）透明性。对用户隐藏了系统的分布情况，可以完全透明地访问系统的资源而不必了解资源分布情况。

2. 多处理器系统

系统由许多进程组成，这些进程可以在不同的处理器上并行行运，可以极大提高系统性能。

3. 客户机/服务器体系结构

客户机必须知道可用的服务器及它们所提供的服务。

分3层：数据层、应用逻辑层、表示层。

（1）廋客户机结构。数据层和应用逻辑层都在服务器上执行。增加了客户机和服务器的网络流量。

（2）胖客户机结构。服务器只负责数据层，客户机负责实现逻辑层和表示层。但客户机软件移植困难。

为了出现上述情况，出现了3层C/S体系结构。

4. 浏览器/服务器风格的体系结构

结构为浏览器、Web服务器、数据库服务器。

5. 分布式对象体系结构

应用服务被分割成具有完整逻辑含义的独立子模块（即对象构件），各个对象构件可和在同一台服务器上或分布在多台服务器上，对象之间的通信由中间件负责。通常将这个中间件称软件总线或对象请求代表，它的作用是对象之间提供一个无缝接口。

6. Web Services体系结构

（1）服务提供者：发面自己的服务，并且对服务请求进行响应。

（2）服务注册中心：注册已经发布的Web Services，对其进行分类，并提供搜索服务。

（3）服务请求者：利用服务中心查找所需的服务，然后使用该服务。

4.6 对象设计

主要任务是追加与问题求解有关的对象和已有对象进行细化，包括使用模式设计对象、接口规格说明、对象模型重构、对象模型优化。

4.6.1 使用模式设计对象

一些问题及其解决方案可能是以不同形式呈现的，但本质相同，这些共同的本质就是模式。软件设计模式可以视为对面向对象软件体系结构中常见的设计方案的总结，用抽象父类给出声明，用具体子类给出实现。一个设计模式包括以下4个要素：

（1）名字：根据名字来使用设计模式。

（2）问题描述：说明在何种场合下使用模式、使用模式的先决条件和特定设计问题。

（3）解决方案：描述设计模式的结构、各成分间的关系，各自的职责和合作方式。

（4）结果：描述了模式使用的效果及使用模式应当权衡的问题。

利用模式设计对象，利用的4个步骤：选择、分解、配置、演变。

4.6.2 接口规格说明设计

包括以下活动。

（1）确定遗漏的属性和操作：检查每个子系统提供的服务及每一个对象，标识出遗漏的操作和属性。

（2）描述可见性和识别标志：确定哪耻操作对其他对象和子系统是可用的，哪一个操作仅对本子系统可用，并说明操作的识别标志（包括操作名及参数表）。

（3）描述契约：描述每一个对象操作应该遵守的约束条件。包括不变式、前置条件和后置条件。

4.6.3 重构对象设计模式

重构是对源代码的转换，在不影响系统的行为的前提下提高源代码的可读性和可修改性，重构通过考虑类的属性和方法，达到改进系统的目的，重构可在小范围内进行，每一步均包含测试，且应避免更改类的接口。

4.6.4 优化对象设计模型

优化对象设计对象的目的是达到在进行系统设计时提出的性能要求，如最小响应时间、执行时间或内存资源，需确定各质量指标的相对重要性，以便在优化时制定折中方案。

应在效率与清晰度之间寻找平衡，优化可以提高系统效率，但同时也会增加系统的复杂度。

4.7 软件设计规格说明与评审

软件设计明描述了软件系统的设计方案，包括系统级的设计决策、体系结构设计（概要设计）和实现该软件系统所需的详细设计。

数据库设计说明描述了数据库设计和存取与操纵数据库的软件系统。

接口说明描述了系统、硬件、软件、人工操作以及其他系统部件的接口特性。

 

 

 

 

 

 

4.7.2 软件概要设计评审

评审的内容

（1）系统概述：是否准确，充分阐述了系统在软件中的地位和作用，其与同等、上级系统的关系是否描述。

（2）系统描述和可跟踪性：

（3）是否对需求分析中不完整、易变动、潜在的需求进行了相应的设计分析：

（4）总体设计：

（5）接口设计：

（6）质量设计：

（7）数据结构：

（7）运行设计：

（8）出错处理：

（9）运行环境：

（10）运行环境

（11）清晰性：

（12）一致性：

（13）可行性：

（14）可行性

（15）详细程度

（16）可维护性。

4.7.3 软件详细设计评审

评审查检的内容如下：

（1）清晰性：

（2）完整性：

（3）规范性：

（4）一致性：

（5）正确性

（6）数据：

（7）功能性：

（8）接口：

（9）详细程度：

（10）可维护性：

（11）性能：

（12）可靠性：

（13）可测试性：

（14）可跟踪性：

 

第5章 程序实现

5.1 程序实现的任务

程序实现阶段也称为软件实现阶段，是软件产品由概念到实体的过程，即将详细设计的结果翻译成某种编程语言编写的并且最终可以运行的程序代码。

程序实现的过程如下：

设计审查→程序编码→程序检查→单元测试→程序调试

程序编码活动的工作制品是源程序、目标程序和用户指南。

5.2 结构化程序设计方法

5.2.1 自顶向下和逐步求精

主要包括以下两个方面

（1）在程序设计中，尽量采用自顶向下和逐步求精的原则，一步步展开。

（2）在编写程序时，强调使用几种基本控制结构，通过组合嵌套，形成程序的控制结构，尽可能避免使用会使程序受到影响的GOTO语句。

自顶向下和逐步求精的方法，把一个模块的功能逐步分解、细化成一系列具体的步骤。先全局后局部，先整体后细节，先抽象后具体的逐步求精的开发过程。细化工作如同倒树结构，细化工作相互独立，同一层的其他节点不受影响。

5.2.2 使用基本控制结构构造程序

结构化程序设计的主要原则如下：

（1）使用语言中的顺序、选择、重复等有限的基本控制结构表示程序逻辑。

（2）选用的控制结构只准许一个入口和一个出口。

（3）由程序语句组成容易识别的块（Block），每块只有一个入品口和一个出口。

（4）复杂程序结构应该用基本控制结构进行组合嵌套来实现。

（5）严格控制用GOTO语句，仅有下列情形才可使用：

①用一个非结构化的编程语言去实现一个结构化的构造。

②在某种可以改善而不是损害程序可读性的情况下。

5.3 面向对象的程序设计方法

OOP的特点是封装、泛化、多态、协同和复用。

1. 封装

对象是数据和操作的封装体，只能通过定义在接口上的操作才能访问对象所存储的数据。

Private是私有，Protected是保护性的，Public是开放的。

2. 泛化

泛化关系即类之间的继承关系，实现方式有两种：一是通用方式，以线性表为例。另一种是实现方式，以树为例。

3. 多态

多态的方式分为类：

（1）参数多态。指把数据类型作为对象或函数的参数。实现“一次编写，处处使用”。

（2）包含多态。指通过继承，让某个或某些类型成为一个类型的子类型。如：一个多边型的类型可以是三角形、四边形、六边形等，包含多态方式可以自动寻找多边形的一个对应的子类型，并以该子类型的操作代替多边形的同名操作来工作。

（3）过载多态。也称重载多态，例如操作++可以使整数加1，也可以让指针加1.

（4）强制多态。通过强制类型来实现多态，如int*，为长度为n的整数组分配空间。

4. 协同

协同指一组对象通过它们之间的协作来完成一个任务。协作包含了消息序列，在使用消息传递时需要仔细考虑每个消息中操作执行前置条件和后置条件。

5. 复用

利用现成类来实现类，有4种方式：选择、分解、配置、演变。重要优点。

（1）选择：从现成构件中选择合乎需要的构件。

（2）分解：把一个类分成几个类。

（3）配置：可以在定义属性时使用其他类的实例。

（4）演变：利用泛化关系建立一般——特殊的关系，可实现特殊化处理。有3种处理方法：

①由已有类建立子类。

②由已有类建立新类。

③建立已有类的父类。

5.4 程序设计风格与编码规范

程序设计风格是编程应遵循的原则。效率与清晰。微软发布的部分编码规范：

1. 版面

（1）采用缩进编写，缩进的空格数为4个。

（2）在相对独立的程序块之间、变量说明之后必须加空行。

（3）软长（>80字符）要分多行书写，长表达式在低优先级操作符处划分新行，操作符放在新行之首，划分出新行要进行适当缩进，使排版整齐，语句可读。

（4）循环、判断等语句中的条件判定语句若有较长的表达式，要进行适当分行划分，长表达式要在低优先级操作符处划分新行，操作符放在新行首。

（5）不允许把多个短语句写在一行中，即一行只写一条语句。

（6）if、while、for、default等语句自占一行。

（7）在函数体开始、类定义、结构定义、枚举定义以及if\for\do\while\switch\case语句中程序都要采用如上缩进方式。

（7）程序模块的分块符，如C++的{}应各占一行并且位于同一列。

2. 注释

（1）源程序和有效注释占20%以上。

（2）说明性文件在首部加注释，应简要说明函数功能

（3）源程序文件的首部应加入注释

（4）边写代码边写注释，修改时要修改注释，保证注释与代码一致。

（5）内容要清楚、明了、含义准确，防止二义。

（6）避免在注释中使用缩写，必须使用应做出说明。

（7）对于有物理含义的变量、常量，命名不能说明含义，必须在声明时加以注释。

（8）全局声明数据结构时，加注释

（9）全局变量有较详细的注释

（10）对变量的定义和分支语句必须编写注释

3. 标识符命名

标识符的命名是使源程序文档化的一个重要手段。

（1）命名清晰并有明确的含义。

（2）若在命名中使用了特殊的约定或缩写，则应注释说明

（3）命名风格一致

（4）变量命名，除有实际含义外，应表明数据类型，i\j\k等作为局部循环变量命名。

（5）命名规则必须与便于用的系统风格保持一致，并在同一项目中保持统一。

4. 变量与表达式

（1）去掉没必要的全局变量，以降低模块间的耦合度。

（2）仔细定义前明确全局变量的含义、作用、取值范围及全局变量间的关系。

（3）明确全局变量与操作此全局变量的函数或过程间的关系。

（4）当向全局变量传递数据，若有需要应进行合法性检查。

（5）避免局部变量与全局变量同名

（6）严禁便于用未经初始化的变量。

（7）避免在程序中直接使用数字，可以用有实际物理含义的常量标识来替代。

（8）注意运算优先级，并用括号明确表达式的操作顺序。

5. 函数

（1）对所调用函数的错误返回码要进行仔细、全面的处理

（2）明确函数功能，精确（而不是近似）地实现函数设计。

（3）编写可复用函数时要注意局部变量的便于用，不要使用静态局部变量

（4）编写可复用函数时，若便于用全局变量，则应通过中断、信号量（即P\V操作）等手段对其加以保护。

6. 可测试性

（1）集成测试系统、与系统联调用的调试开关、打印函数。

（2）打印的信息有模块名、行号，以便集成测试

（3）构造测试代码、测试用例

（4）构造好测试环境、测试项目、测试用例。

（5）使用断言来发软件问题，提高代码的可测试性。

（6）复杂断言加入明确注释

（7）用断言确认函数参数和合理性

（8）正式发布的软件产品中应把断言及其他调试代码去掉。

7. 程序效率

（1）全局效率是整个系统的效率，局部效率是模块或函数的效率，时间效率是程序处理输入任务所需的时间，空间效率是程序所需内存空间的数量。

（2）保证正确、稳定、可读、可测试的前提下，提高代码的效率。

（3）局部效率全局效率服务

（4）通过对系统数据结构的划分与改进，对程序算法的优化来提高空间效率

（5）将循环体内的计算工作量最小化，可考虑将循环内语句放在循环体外，从而提高程序的时间效率。

8. 质量保证

（1）在软件设计和实现过程中构筑软件质量

（2）代码质量的保证优先原则：正确性、稳定性、安全性、可测试性、符合编码规范、可读性、系统整体效率、模块局部效率、个人表达方式、个人编程习惯。

（3）只引用属于自己的空间

（4）防止引用已释放的内存空间

（5）在函数中动态分配的内存空间，在过程函数退出前要释放

（6）在函数中打开的文件，在函数退出前要关闭

（7）防止对数组、指针、内存地址等操作越界。

（8）系统运行之初要初始化有关变量及运行环境，防止未经初始化的变量。

（9）系统运行之初要对加载到系统中的数据进行一致性检查。

（10）严禁随便更改其他模块或系统的有关设置和配置。

（11）不能随便改变与其他模块的接口。

（12）充分了解系统的接口后再使用系统提供的功能。

（13）编程时要防止差1错误，此类错误一般由于把<=误写成<或>=等造成的，当编写完程序后，应对这些操作进行彻底检查。

（14）要时刻注意容易混淆的操作符。如C++中的=与==

（15）在外层if语句中嵌套的内层if语句应加在外层if语句的else分支上。

9. 代码编辑、编译、审查

（1）打开编译器所有告警开关对程序进行编译。

（2）通过代码审查及走查方式对代码进行检查。

（3）测试程序代码之前应对代码进行抽查及评审。

5.5 编程语言的选择

程序实现是把软件的详细设计转换成用汇编语言实现的程序代码，即用PDL这样的伪码写成的程序翻译成计算机能接受的语言。

5.5.1 编程言特性的比较

编程是人机对话媒介，是一项人类的智力活动。

1. 编程言的心理学特性

编程言语的性能对程序员心理影响。

（1）一致性。表示一种言便于用符号的兼容程度。例如同一符号，给予多种用途，会引起许多难以察觉的错误。

（2）二义性。如果读者可能用不同的方式理解语句，则这种编写程序就很容易出错。

（3）简洁性。用该语言编写程序简到什么程度。具有简洁性的编程容易学习，编写简单位，容易理解和维护，出错率也低。

（4）局部性。与模块化有关，该语言支持模块结构，允许用模块组装成系统，并在组装过程可实现模块结构的高内聚、低耦合，那么这种言就有局部性。

（5）线性。程序中不存在大量分支和循环，用GOTO转来转去，每个程序都有单入口和单出口就具备线性的特性。

（6）传统。学习一种新编程语言的能力受到传统语言特性的影响，有的需要花的时间更长。

2. 编程语言的工程特性

编程言语的特性应符合软件开发项目的需要。对于程序编码有如下工程上的性能要求：

（1）详细设计应能直接并且容易地翻译成源代码程序，这要求用编程语言写出的程序与详细设计在结构上比较接近。

（2）用编程语言编写源代码应具备可移植性。

（3）编译程序应具有较高的效率。

（4）尽可能使用软件开发工具，从设计到自动转换成代码，缩短编码时间，发送源代码质量。

（5）源代码应具有可维护性，要求编程语言支持结构化构造、模块化，且具有丰富的数据类型，特别是抽象数据类型，使程序具有可读性、可修改性和可测试性，将来的维护就能以较少的工作量成功地更新程序。

3. 编程语言的技术特性

软件的设计质量与编程言语的技术性无关，但在设计转换为程序代码时，转化的质量往往会受语言性能的影响，因而也会影响到设计方法。

（1）支持模块结构。

（2）能够提高模块独立性，包括支持信息隐蔽能力。

（3）能够定制数据结构。

（4）具有某种专门性能可满足特定设计要求。

（5）能够提供结构化构造。目的是降低程序复杂性，增强测试和维护能力。

5.5.2 编程语言的分类

低级到高级分类，级是指操作者与计算机对话的复杂程度。

1. 从属于机器的语言——第一代语言。

由机器二进制代码组成的指令集合，不需翻译，可以直接被计算机识别和执行，占用内存少，执行效率高。

缺点：编程工作量大，不直观，出错率高，查错和修改困难。

2. 汇编语言——第二代语言

比机器语言直观。

但都针对某个特定计算机，又称面向机器语言。

3. 高级编程语言

由编码、词汇、语法等组成。

按照解决问题的方式可分：面向过程型，函数型、逻辑型、面向对象型和面向互联网型。

需要编译、解释后才能执行。

（1）面向过程的编程语言。

（2）面向对象的编程语言。

4. 面向互联网语言

（1）HTML和XML。

（2）JAVA语言。具有简单、面向对象、分布式、安全、构中立、可移植、多线程等特点。

（3）C#语言

5. 第四代语言

也用不同文法表示程序结构和数据结构，它不需要规定算法的细节。

兼有过程性和非过程性的两重特性。程序员规定和相应的动作是过程的部分，并且指出想要的结果，这是非过程性部分。

分类：

（1）查询语言。为数据库有关的应用而开发的。

（2）程序生成器。只需很少的语句就能生成完整的第三代语言程序。

（3）其他4GL，如判定支持言语，原型语言，形式化规格说明语言。

5.5.3 编程语言的选择

总的原则是语言能使编码容易实现、减少测试的工作量、编写的程序容易阅读和维护。

1. 理想的选择

（1）所选用的高级语言应有模块化机制，可读性好的控制结构和数据结构，使程序容易测试和维护，同时减少软件生存周期和总成本。

（2）应支持抽象数据类型，尽可能支持面向对象的机制，可以使系统更灵活、容易查错、更容易修改。

（3）应有良好的编译机制，以降低软件开发和维护的成本。

2. 实践标准

（1）编程语言自身的功能。

（2）系统用户的要求。

（3）编码和维护成本。

（4）软件的兼容性

（5）可以使用的软件工具。

（6）软件可移植性

（7）所开发系统的规模

（8）程序设计人员的水平。

5.6 程序复杂性

程序的复杂性主要指的是模块内程序的复杂性，关系开发费多少，开发周期长短和软件内部潜伏错误的多少。

解决办法，减少程序复杂性，提高软件简单性和可理解性。

5.6.1 代码行度量法

就是统计源代码行数。

（1）程序复杂性随着程序规模的增加不均衡的增长。

（2）控制程序的规模采用分而治之的办法。

简单的，估计得很粗糙。

5.6.2 McCabe度量法

是一种基于控制流的复杂性性度量方法。

又称圈复杂度，用一个程序模块的控制流图中圈的个数作为其圈复杂度的度量值，因此前提是画出控制流图。

控制流图是退化的程序流程图。

计算圈复杂性的方法：

在一个强连通的有向图G中，环的个数由以下公式给出：

V(G)=m-n+1

V(G)是有向图G中环路数，m是G中弧数，n是图G中的结点数，1是图G中的强连通分量个数（强连通图中的强连通分量就是它自己）

如上图

V(G)=13-11+1=3

即McCabe圈复杂度量值为3

McCabe圈复杂度还可以便于用以下两个方法度量，它们与上述度量法得到的结果相同：

（1）McCabe圈复杂度=控制流图中被封闭的区域数

（2）McCabe圈复杂度=控制流图中判断条件数+1

复合判定：A and B or D,应算作3个判定

对于圈复杂度超过10的程序，应分成几个小程序，因为此阶段出错率间断跃变。

错误与程序的判定加上例行子程序的调用数目成正比。

5.7 程序调试

程序调试（Debug）是在源代码编写完成，进行单元测试并发现错误之后才开始的工作，与软件测试不同，软件测试的目的是找错，程序调式的任务是纠错。

程序调试活动由两部分组成：一是确定程序中可疑缺陷的确切性质和位置。二是对程序（设计、编码）进行修改，提成除这个缺陷。

一般认为定位点95%工作量，改正工作量点5%。

5.7.1 程序调试的步骤

（1）根据测试问题报告给出错误现场记录，进入调试步骤。

（2）研究有关部分的程序，找出缺陷的内在原因。

①缺陷原因不肯定，先假设，再设计测试用例证实这个假设。

②找到缺陷原因，分析相关程序和数据结构，界定修改范围。

（3）修改设计和代码，排除缺陷。

（4）重复进行这个缺陷的原始测试或某些相关测试（回归测试），确认错误排除，是否引进新错误。

（5）如果修改无效，撤销此次修改，重复上述步骤，直到找到解决办法止。

从技术角度看，查找缺陷的难度表现在：

（1）现象与问题所处的位置可能相距很远。

（2）改正后表象消除，实际并未排除。

（3）现象实际上是一些非缺陷原因（浮点计算、四舍五入）引起。

（4）现象可能由于一些不容易发现的人为原因引起。

（5）缺陷是由时序问题引起，与处理过程无关

（6）现象难以精确现现输入状态引起的。

（7）现象可能周期性的出现。在软、硬件结合的嵌入式系统中常常遇到。

（8）缺陷是由于把任务分布在若干不同处理机上运行而造成的。

5.7.2 几种主要调试方法

调试的关键在于的个数由以程序内部的缺陷位置及原因。

1. 强行法调试

使用较多，效率较低，省脑筋，思想是“通过计算机打错”。

（1）通过内存全部打印来排错。

（2）在程序特定位置设置打印语句。

（3）使用自动调试工具。任何调试工具也代替不了开发人员在对完整的设计文档和清晰的源代码进行认真审阅和推敲之后所起的作用。

2. 回溯法调试

小程序中常用方法，一旦发现缺陷，先分析缺陷征兆，确定最先出现“症兆”位置，然后人工沿程序的控制流程，向回追踪程序代码，找到缺陷根源确定缺陷产生的范围。

大程序回头的路径数目较多，回溯变得很困难。

3. 归纳法调试

是从特殊推断一般的系统化思考方法，从一些线索（缺陷）征兆入手，通过分析它们之间的关系来找找出缺陷。

（1）收集有关的数据。输入哪些是正确的，输入哪些运行结果有缺陷。

（2）组织数据。以便发现规律，2W1H形式：What、Where、When、How。

（3）提出假设。分析线索之间的关系，利用在线索结构中观察到的矛盾现象，设计一个或多个原因出错原因的假设。

（4）证明假设。设计或执行测试用例。

4. 演绎法调试

从原理或前提出发，经过排除和细化过程来推导出结论的思考操作。

（1）例举所有出错原因可能有关的假设。把所有缺陷原因列举出来。

（2）利用已有的测试数据，排除不正确的假设。

（3）改进余下的假设。

（4）证明余下的假设。

5.7.3 程序调试的原则

1. 确定缺陷的性质和位置的原则

（1）用头脑去分析思考与缺陷征兆有关的信息。一个能干的调试员能做到不用计算机就能确定大部分缺陷。

（2）避开死胡同。暂时抛开问题，第二天再去思考，做一个好听众。

（3）只把调试工具当作辅助手段来便于用。

（4）避免用试探法。如用修改尝试问题解决。

2. 修改缺陷的原则

（1）在修改缺陷的地方，很可能还有别的缺陷。

（2）修改缺陷常见的失误在于，修改的征兆或表现，没有修改缺陷本身。

（3）当心修正一个缺陷引入新的缺陷。

（4）修改缺陷的过程将迫使人们暂时回到程序设计阶段。

（5）修改源代码程序，不要改变目标代码。

 

第6章 软件测试

提高软件质量从两方面入手，一是在软件生存周期需求分析与设计、程序编码等个个阶段防止问题的发生，二是一旦发现问题要及时改正，后者就是软件测试任务。

软件开发点工作量的40%，软件测试上开销要占30%-50%。

6.1 软件测试的任务

1. 软件测试的目的和定义

1990年IEEE。

（1）在规定条件下运行系统或构件，观察和记录结果，并对系统或构件的某些方面给出评价。

（2）检测现有状况和需求状况之间的不同（bug），并评估软件项目的特性。

GB/T11457-2006：测试是一个过程，目的是评价系统或构件的某些方面，看它是否满足规定的需求；评估项目的特性，看期望的结果和实际结果之间有无差别。

2. 软件测试的原则

软件测试的原则

（1）应当尽早地、不断地进行软件测试。把测试贯彻于整个软件开发环节中。

（2）测试用例应由测试输入数据、执行条件和对应的预期输出结果组成。

（3）程序员应避免检查自己的程序。不是说不能，只是别人检查更客观有效。

（4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

（5）充分注意测试中的集群现象。发现错误集中模块时，重点检查。

（6）严格执行测试计划，排队测试的随意性。

（7）应当对每个测试结果侨全面检查。

（8）妥善保存测试计划、测试用例、出错统计和最终分析报告。

3. 软件测试的实践

（1）所有测试都应追溯到用户需求。

（2）测试应从小规格开始，逐步向大规模。

（3）穷举测试是不可能的。

（4）尽早产生一个综合的测试计划。

（5）测试应当分级别进行。

（6）测试应当有重点

（7）测试不公包括功能确认，还应包括性能、可靠性、可维护性、安全性和的确认。

（8）提供集成化的测试工具和测试基础支持。

（9）加强测试度量工作和缺陷分析工作，不断地改进测试。

（10）加强测试培训

4. 软件测试的对象

软件测试不等于程序测试，软件测试应贯彻于整个软件定义与开发的整个期间（需求分析、概要设计、详细设计及程序编码等）。

需求分析和软件设计的错误占64%，程序编写错误公点36%。

5. 测试信息流

软件测试需要3类输入：

（1）软件配置：软件需求规格说明、软件设计说明、源代码等。

（2）测试配置：包括测试计划、测试用例、测试规程等，测试配置是软件配置的一个子集。

（3）测试工具：目的是为了提高软件测试效率，减轻手工测试劳动。

测试确定软件缺陷——调试（修正文档）——再次测试——

测试发现不了错误并不代表软件错误，而是错误仍隐藏在软件中，需要用户去发现，改正这些错误比开发阶段发现错误费用高40-60倍。

6.2 软件测试方法

为编码后的动态软件测试方法，一般分为

（1）白盒测试方法，结构测试方法，依据是程序的逻辑结构。

（2）黑盒测试方法，又称功能测试方法，依据是软件行为描述。

6.2.1 白盒测试方法

依据逻辑结构，有如下基本要点：

（1）采用控制流图来表达被测程序模型，提示程序中的控制结构。

（2）通过合理地选择一组穿过程序的路径，以达到某种测试度量。

白盒用例测试方法有：语句覆盖、分支覆盖、条件覆盖、分支条件覆盖、条件组合覆盖、条件确定测试，路径覆盖。

1. 语句覆盖

要求设计的调试用例，最小数目的语句到少执行一次，甚至被测语句到少执行一遍。

第一步：建立源代码的控制流图。转换如下图所示：

执行测试用例以后，必须确定执行了哪些语句，达到事先定义的覆盖率后，测试终止。

如果有条件表达式，x>3 or y<5，通过逻辑运算符or、and、not来和括号连接多个条件称为复合条件表达式。

2. 分支覆盖

要求每个判定取值取真和取假的分支至少执行一次，因此又称判定覆盖。

例：x>3 or y<5，可设计成以下测试用例。

分支覆盖率=（被执行的分支数/总的分支数）*100%

3. 条件覆盖

条件覆盖深入到条件表达式中，要求设计测试用例每个条件取值（True或False），都至少求值一次。

这里的条件仅包括>、=这样的关系运算符，不包括AND、OR 、NOT这样的逻辑运算符。

示例：以下用例条件覆盖虽然正确，但不能保证分支覆盖。

4. 分支条件覆盖

设计测试用例时，使得每个判定取True分支和取False的分支至少执行一次，且每个原子条件取True值和取False值计算也至少一次。

因为至少执行一次，因此可以用短路原则：

A OR B，A取True即可认定整个复合条件的取值为True，不再计算B，若A取False，则还要计算B确定整个复合条件取值。

A AND B，若A取False即可认定整个复合条件的取值为False，不再计算B，若A取True，则还要计算B的取值来确定整个复合条件取值。

示例：基于短路原则的分支条件覆盖x>3 or y<5测试用例

5. 条件组合覆盖

要求每个判定条件中的所有取取True分支和取False的组合至少执行一次。

示例：如x>3 or y<5测试用例，有两个条件，因此至少有4种条件组合取值。

既满足语句覆盖，又满足分支覆盖，还考虑了条件取值，是一种很不错的测试方式，但随着千件数目的增加，组合的数目可能会呈指数增加（2n），n为条件个数。

6. 条件确定覆盖

在条件组合中又引入短路原则。仅考虑那些取值变化会导致整个复合条件取值改变的条件取值。

示例：如x>3 or y<5测试用例，有4个组合，但test1中x>3如果计算错误由True变False，但不会影响整个表达式的取值，因此可以删除；test2中如果x>3如果计算错误由True变False，整个表达式的结果会变为False，因此保留；test3中如果y<5，计算错误由True变False，会影响整个表达式的取值，因此保留；test4中如果y<5，计算由False变True会影响整个表达式的取值，因此保留。

具体的测试用例数应界于n+1和2n之间，其中n为原子条件个数。

7. 路径覆盖

如果被测中包含循环语句，仅靠前面的覆盖是不够的，必须考虑路径覆盖。就是要注被测程序中所有的不同路径都至少被执行一次。

对于x>3 or y<5，如果不考虑短路情形需2个用例，如果考虑短路形，则需3个测试用例实现路径全覆盖。如果考虑循环条件，一般限制循环重复的资数最多为1，从而达到语句覆盖。

白盒测试，只能验证代码，不能验证功能需求。

6.2.2 黑盒测试法

不必知道程序内部结构，测试用例从规格说明书中导出。考虑到测试数据组合是天文数据，因此完全测试是不现实的。

因此测试设计必须从可能的测试用例中合理的选择。路径覆盖

1. 等价类划分

依据规格说明来测试用例，把数目极多的输入数据（有效的和无效的）划分为若干等价类。假定输入某等价类的代表值就是这一类其他值的测试，用分类的方法进行部分推断整体的方法。

等价类——某个输入数据的子集合。

划分：

（1）有效等价类：对于程序规格说明来说是合理的，有意义的输入数据构成集合，用于检测程序是否实现了规格说明预先规定的功能和性能。

（2）无效等价类：对于程序规格说明来说是不合理的、无意义的输入数据构成的集合，用于检测程序中功能和性能的是否有不符合规格说明要求的地方。

检测时需要同时考虑有效等价类和无效等价类，才能获得软件较高的可靠性。

等价划分的原则：

（1）按区间划分：用于取值范围和个数限制类输入数据。

（2）按数值划分：允许输入值和不允许输入值。

（3）按数值集合划分：可能的输入数据属于一个值的集合。

（4）按限制条件或规则划分：输入数据必须遵守或限制条件。

建立等价类之后，建立等价类表，列出所有划分的等价类，从划分出的等价类中按以下原则选择测试用例。

（1）设计尽可能少的测试用例，覆盖所有的有效等价类。

（2）针对每一个无效等价类，设计一个测试用例来覆盖它。

2. 边界值分析

大量错误是发生在输出范围的边界值上，而不是输入范围内部，因此可针对边界值情况设计测试用例。

边界值法是最有效的黑盒测试方法。

3. 错误推测法

靠直觉和经验推测程序中可能存在各种错误。列举出程序可能发生的错误和容易发生错误的特殊性况，根据它们选择测试用例。

4. 因果图

前述着重考虑了输入条件，但未考虑条件之间的联系。如果测试考虑了输入条件的组合，相应产生多个动作形式来设计测试用例，这就需要利用因果图。最终产生判定表，以检查程序输入的条件的各种组合情况。

步骤如下：

（1）分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给出每个原因和结果赋予一个标识符。

（2）分析规格说明书中的语义，找出原因与结果之间对应的关系，根据这些关系，画出因果图。

（3）有些原因与结果之间的组合情况不可能出现，在因果图上标识这些特殊情况，有一些记号标明约束或限制条件。

（4）把因果图转换成判定表。

（5）以判定表的每一列动作为依据设计测试用例。

5. 选择测试方法的综合策略

（1）任何情况下都必须便于用边界值分析方法，表明这种测试用例发现程序错误的能力最强。

（2）必须时用等价类划分方法补充一些测试用例。

（3）用错误推测法再追加一些测试用列。

（4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程序，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

（5）如果程序的功能说明中含有输入条件的组合情况，则一开始即可选用因果图法。

6.2.3 其他测试方法

1. 灰盒测试

界于白盒测试和黑盒测试之间，依据数据抽象和代码抽象来设计测试用例。

数据抽象——不考虑与测试目标无关的数据细节，只关心与测试目标有关的数据对象和应用于对象的操作。

代码抽象——忽视与测试目标无送的代码细节，只关心与测试目标有关的代码所实现的操作和算法。例如针对数据库表，只测试它的插入、修改、删除、查询、连接操作，测试相关完整性。

可见灰盒测试适用于集成测试

2. 冒烟测试

如果测试找到并修复了缺陷，想知道修改是否真解决了程序缺陷，或者对其他模块造成影响，专门针地此问题进行专门测试。

优点：节省测试时间，缺点是覆盖率比较低。

3. 随机测试

针对被测软件的一些重要功能进行复测。对于软件更新和新增加的功能要重点测试，可以和回归测试一并进行。

由对被测软件熟悉的人进行测试。

4. 回归测试

是在软件变更后，对软件重新进行测试。目的是检验对软件的修改是否正确，修改会不会带来不可预料的行为或另外的错误，3种类型：

（1）能够测试软件的所有功能的代表性测试用例，即预测试用例。

（2）专门针对可能会被修改影响的软件功能的附加测试。

（3）针对修改过的软件成分的测试。

6.3 软件测试的策略

指在测试过程中对各种活动的组织和管理，为编码后的软件测试活动。

6.3.1 软件测试活动

软件测试活动分四步：即单元测试、集成测试、系统测试和验收测试。

单元测试——对用源代码实现每个程序单元进行测试，检查各个程序模块是否实现了支规定的功能。

集成测试——把已测试过的模块组装起来，在组装过程中，检查程序结构组装的正确性。

系统测试——检查已实现的软件是否满足了规格说明中确定了的各种需求，检查是否配置完全、正确。

最后是验收测试。

6.3.2 单元测试

1. 单元测试的目标和活动

单元测试是针对软件设计的最小单位——程序单元，进行正确性检验的测试工作，目的是验证代码是否与设计相符合，跟踪需求和设计的实现，发现设计和需求中存在缺陷，发现编码过程中引入的错误。

活动：与其他程序部分隔离，分:人工检查和动态执行跟踪。

应做为编码工作的一部分，一般在代码交付前由程序员完成。

2. 单元测试的环境

并非系统投入使用的真实环境，建立一个满足单元测试要求的环境。

需要设计一些辅助模块来模拟与被测模块的其他模块：

驱动模块——相当于被测模块的控制程序。负责接收测试数据，把数据传递给被测模块。

桩模块——用于代替被测模块调用的子模块。

驱动模块和桩模块是测试的辅助部分，不交付使用，但需要较少开发费用。

3. 单元测试的任务

依详细设计说明和源程序清单位，了解模块的I/O条件和模块的逻辑结构。从2个方面进行测试：

（1）单元接口。数据的正确输入、输出接口。

（2）局部数据结构。保证临时存储在模块内的数据程序执行过程中完整、正确。

（3）独立路径。每条独立执行路径进行测试，保证每语句至少执行一次。

（4）出错处理。出错处理功能正确检错、报错和处理错误。

（5）边界条件。指程序中判定语句中的条件或循环语句中继续循环的条件。

6.3.3 集成测试

与软件概要设计相对应，单元测试已完成之后。

1. 集成测试的目的和活动

目的：将已经过测试的程序单元逐步组装起来，对系统的接口以及集成后的功能进行正确性检验。需考虑的问题：

（1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。

（2）一个模块的功能是否会对另一个模块的功能产生不利的影响。

（3）将各个子功能组合起来，能否达到预期要求的父功能。

（4）全局数据结构是否有问题。

（5）单个模块的误差累积起来，是否会放大，从而达到不接受的程度。

集成测试分三层：模块内集成测试、子系统内集成测试、子系统间集成测试。

面向对象集成测试可分：类内集成测试、类间集成测试。

2. 集成测试环境

集成测试环境比单元测试环境复杂（单机系统除外）。

（1）硬件环境。尽可能使用环境，如果不能才使用模拟环境。

（2）操作系统。要考虑不同机型，不同操作系统。

（3）数据库环境。性能、版本、容量等方面考虑，针对常见几种数据库产品进行测试。

（4）网络环境。以太网，合理利用开发组织内部网络，考虑无线网络。

（5）测试工具运行环境。借助测试工具，搭建测试工具能运行的环境。

（6）其他环境。Web服务器环境、浏览器环境等。

3. 集成策略

软件集成方法多种多样

（1）一次性集成方法。也称（Big Bang），先对每个单元分别进行单元测试，然后再把所有单元组，然后将单元组装在一起进行测试，最终得到要求的软件系统。

优点：一次性完成集成测试，测试用例最少。方法简单，多个测试人员并行工作，人力、物力资源利用率高。

缺点：试图连接所有被测单元困难，成功性小，发现错误时定位和修改困难。

（2）自顶向下的增量式集成。与设计一样，沿系统构构的控制层次自顶向下逐步组装各个单元测试。先测试处于顶层的模块，然后逐层向下，测试处于低层的模块。

优点：可以较早地验证主要控制和判断点，发现主控问题，减少以后返工。与设计一致，发现问题容易。

缺点：需要建立多个桩模块，建桩模块成本高，真正有输入\输出和复杂算法的模块都位于底层，验证他们太晚，底层发现问题可能会导致上层模块返工，增加集成成本。

（3）自底向上的增量式集成。从最底层的模块开始集成和测试。

优点：较早验证底层模块的行为，可并行测试，比自顶向下策略效率高，驱动模块比桩模块简单，驱动模块编写工作量低于桩模块，定位错误容易。

缺点：高层的验证被推迟到最后，设计上的错误不能及时的纠正和发现。

（4）混合的增量式（三明治）集成。中间层为目标层，把目标上层的一层使用自顶向下的集成策略，把目标下层使用自底向上的集成策略。

优点：集合了自顶向下和自底向上集成测试的优点，对中间层充分测试。

缺点：中间层选取不当，会有较大的驱动模块和桩模块的工作量。

6.3.4 系统测试

1. 系统测试的目的

对系统进行综合检验，目的不再是找出缺陷，而是确认其功能和性能。除了功能外，还要进行非功能测试，如性能测试、压力测试、可靠性测试。目的是最终确保软件产品能被用户接受。

系统测试属黑盒测试

通过系统需求与需求规格说明书比较，验证系统的功能和性能是否满足规格说明所指定的要求。

2. 系统的测试环境

不同版本操作系统、不同版本的数据库、不同版本的网络服务器、应用服务器等，构建系统测试环境工作复杂而频繁。

3. 系统测试的类型

（1）功能测试。为了发现不正确或遗漏了的功能，能否正确接收输入以及能否正确的输出。

（2）协议一致性测试。检查实现的系统与标准协议符合程度，检查同一协议在不同实现版本间的互能力和互操作能力。

（3）性能测试

（4）压力测试

（5）容量测试

（6）安全性测试

（7）恢复性测试

（8）备份测试

（9）GUI测试。即图形用户接口，产品外观，现实现界面情况符合，确认办面能够正确处理事件。

（10）健壮性测试

（11）兼容性测试

（12）易用性测试

（13）安装测试

（14）文档测试

（15）在线帮助测试

（16）数据转换测试

6.3.5 验收测试

是一种正式测试，以用户为主。或有测试人员、用户、其他权威机构来决定是否可以接受一个产品的验证性测试。

决定用户验收签字和付款。

依据软件需求规格说明文档和验收标准，测试用例可以直接采用内部测试组所设计的测试用例，也可以由验收人员自行设计。

（1）Alpha测试，又称开发方测试。

（2）Beta测试是将软件完全交给用户，在实际环境下测试。

6.4 人工测试

人工测试不是在计算机上动态执行的测试，就是人工方法阅读程序，能够有效发现30%-70%的逻辑设计和编码缺陷。

包括：桌面检查、代码检查、走查等。

6.4.1 桌上检查

（Desk Checking）是由程序由自己检查自己编写的程序。编译之前，对源代码进行分析。目的是发现程序中的缺陷。

1. 桌面检查项目

（1）检查变量的交叉引用表。

（2）检查子程序、宏、函数。

（3）等价性检查

（4）常量检查

（5）标准检查

（6）风格检查

（7）比较控制流

（8）选择、激活路径

2. 补充文档

桌面检查不公开，通过编写文档，帮助程序员发现和抓住更多的缺陷，管理部门通过检查文档，了解模块质量，完全性、测试方法和程序员的能力。

文档内容：

（1）建立小型数据库，描述程序中出现的每一种数据结构、变量和寄存器的用法，相应地建立各种交叉引用表。

（2）描述主要的路径和异常的路径，为覆盖准备条件。

（3）当检查程序逻辑时，可通过判定表或布尔代数方法来确定逻辑覆盖情况。当检查程序状态时，可考虑程序中的一组状态和状态迁移，以检查状态控制变量。

（4）以纯粹的功能术语来描述输入和输出。

（5）描述全部已知的限制和假定。

（6）描述全部的接口和对接口的假定。

6.4.2 代码检查

走查（Walkthrough）与代码检查相似，都是以小组为单位进行的。规程稍微不同，采用缺陷检查技术也不一样。

目的：是评价一个产品，发现缺陷、遗漏和矛盾的地方，改进产品，还有技术交流、参与人员的培训、设计思想介绍等。

小组：3～5人组成。协调人、记录员、测试员、程序编写者等。

过程步骤：

（1）计划走查会议。安排相关人员工作，审查资料、审查标准、产品介绍等。

（2）评审产品。提供测试用例等。

（3）执行走查。起查小组会，测试用例推演，讨论争议。

（4）解决缺陷。无法解决的提交领导寻求解决。

（5）走查记录。评审者、被评产品、日期、缺陷、遗漏、矛盾和改进。

（6）产品返工。

与代码检查相同，参与者的态度非常关键，应针对程序本身提问题，不针对程序员。

走查优点：如果发现错误，可对代码进行精确定位，降低修正成本，可发现成批错误。

 

第7章 软件维护

软件交付用户后，进入维护阶段，保证软件正常运行。

7.1 软件维护的任务

软件需要不断更新。

7.1.1 软件维护的定义

修改软件系统与部件以排除故障，改进性能或其他属性或适应变更了的环境的过程。

与硬件维护不同，不是提供一个新产品，而是对原始软件进行修改了新产品。

目的是：纠正、修改、适应或改进现有软件。

7.1.2 软件维护的类型

与软件维护与开发的一个主要差别：维护是指在一个现有的软件结构中引入修改，并且必须考虑对代码结构所施加的约束。

（1）改正性维护（18%）。程序错误和的设计缺陷的维护。

（2）适应性维护（18%）。数据环境和处理环境的变化。

（3）完善性维护（60%）。改进、增加功能，完善性能要求。

（4）预防性维护。采用先进和工程方法，对软件或软件中的某一部分重新进行设计、编制和测试。

7.2 软件维护的活动

建立维护机制，提出维护申请报告，规定标准处理步骤，建立活动登记和评价评审的标准。

7.2.1 维护机制

可以不保持一个正式的组织机构，在开发部门有一个维护机制，有维护操作规程，有专人负责管理方面的工作。

维护流程：递交维护申请——评估评价——修改——审计。

7.2.2 软件维护申请报告

说明：什么错误、什么地方、输入什么数据导致运行出错，错误位置、错误影响，提出修改说明，列出希望修改的错误。

评估员：做出修改报告，优先级，工作量，预计修改后状况，经批准才能安排维护实施。

7.2.3 软件维护过程模型

根据由简到繁的原则，介绍以下模型。

（1）快速变更模型。一量发现问题，立即迅速解决，救火式。不分析，不记入文档。

优点：一个人开发和维护、客户不愿等待的，就属此型，快速、经济。

（2）Boehm模型。把维护过程表现为闭合环路。

（3）Osborn模型。当作开发生存周期持续迭代。

（4）面向复用的Basili模型。把维护看成一组复用现有程序构件的活动。

①标识可供复用的老部件

②理解这些系统部件

③修改这些部件，以适应新的需求

④将修改后的系统部件集成到新系统中。

7.2.4 GB/T 20157-2006软件维护过程

包括六个过程

（1）过程实施。策划对维护过程的管理。

①维护计划和规程。

②问题报告规程。

③配置管理。

（2）问题和修改分析。先确认需求，与用户反复协商，下星期清楚错误概况及对业务影响大小，用户希望做出何种修改，确认维护类型。

（3）变更实施。修改软件需求说明、修改软件设计、设计评审、对源程序做出修改、单元测试、集成测试、系统测试、软件配置评审。

（4）维护评审/验收。哪一方面可以改进？维护资源应该有但没有？王八中主要或次要障碍？是否应当有预防性维护？

（5）迁移。迁移到新环境。

（6）退役。制订退休计划并通知用户。

7.2.5 维护记录文档

维护记录文档可以为估价维护技术有有效性，确定维护费用等作用。记录包括：

（1）程序名称，源程序语句条数、机器指令代码要数，所用到的程序设计语言。

（2）程序安装的日期、程序安装后的运行时间、在运行时间内的故障次数.

（3）修改程序增加或减少的涛程序语句数、每次修改的人时数、修改的日期。

（4）维护人员姓名、维护申请报告名称，维护类型，维护开始时间和维护结束时间，花费累计人时数，维护工作的净收益等。

7.3 程序修改的步骤及修改的副作用

软件维护，特别是完善性维护，相当于次开发。

7.3.1 分析和理解程序

（1）理解和修改程序的管理活动。

①接受、记录、跟踪用户问题报告\修改要求，和用户提供反馈的规程。

②参与配置管理过程的活动，以管理对现有软件系统的修改。

③分析问题报告或修改要求，以确定是哪一种维护类型。

④模拟用户使用过程，重现或验证问题。

（2）理解程序要点

①理解程序的功能和目标。

②掌握程序的结构信息。程序结构、控制结构、数据结构和输入/输出结构等。

③数据流跟踪。

④控制流跟踪。

⑤理解程序的操作（使用）要求。

（3）充分阅读和使用源程序清单和文档。

（4）如有可能，维护人员应介入软件开发的过程，以便将来实施修改。

7.3.2 评估修改范围

评估修改的规模多大，需要的工作量，估计修改的成本和费用。

7.3.3 修改程序

（1）设计程序修改计划。包括：

①规格说明信息：数据修改、处理修改、作业控制语言修改、系统间接口修改。

②维护资源：新程序版本、测试数据、所需的软件系统、计算机时间等。

③人员：程序员、用户相关人员、技术支持人员、厂家联系人、数据录入员。

（2）向用户提供回避措施。以便在可能范围内继续开展业务。

（3）修改代码，以适应变化。修改时，要求：

①正确、有效地编写修改代码。

②谨慎地修改程序，尽可能保持风格，改动注明。

③不要删除语句，除非确定无用。

④不要试图共享程序中已有的临时变量或工作区，应自行设计变量。

⑤插入错误检测语句。

⑥修改过程中要做好详细记录，消除变更中任何有害的副作用（波动效应）。

7.3.4 修改程序的副作用及其控制

副作用——因修改软件而造成或其他意外情况

（1）修改代码的副作用。可能会引入错误。

（2）修改数据的副作用。可能会造成软件设计与数据结构不匹配，因而导致软件出错。

（3）文档的副作用。对数据流、软件结构、模块逻辑或任何其他相关特性进行修改时，必须对相关技术文档进修改。进行以上修改必须进行评审。

为了控制因修改而引起的副作用，要做到以下几点：

（1）按模块把修改分组。

（2）自顶向下地安排被修改模块的顺序。

（3）每次修改一个模块。

（4）对于每个修改了的模块，在修改下一个模块前，要确定修改副作用。可以使用交叉引用表、存储映象表、执行流程跟踪。

7.3.5 重新验证程序

提交用户前，要进行充分的确认与测试，以保证修改后程序的正确性。

（1）静态确认。修改软件，伴随着引起新的错误的危险。

①规格说明书修改否？

②是否修正问题？

③对其他部分有无不良影响（副作用）

（2）回归测试。对计算机修改程序进行确认测试。

①确认测试顺序。对修改部分隔离测试。

②准备标准的测试用例。

③充分利用软件工具帮助重新验证过程。

④在重新确认过程中，需邀请用户参与。

（3）维护后评审与验收。由维护主管部门进行

7.4 软件可维护性

7.4.1 可维护性的定义

软件可维护性，指软件可被修改的能力，包括纠正软件中出现的错误和缺陷，根据需求或功能规格说明的变化改进软件，为适应环境变化修改软件等。

（1）易分析性。

（2）易变更性。

（3）稳定性。避免发布是而造成意外结果的能力。

（4）可测试性。

（5）维护性符合性。遵循与可维护性相关的标准或约定的能力。

7.4.2 软件可维护性度量

1. 外部可维护性度量

实施者用户、测试人员、开发人员、产品评价人员、维护人员，目的是评价修改软件产品的难易程度。

（1）易分析性度量。故障诊断、定位能力，原因失效分析能力和系统运行实时监视能力。

（2）易变更性度量。可否容易修改参数以更改软件并解决问题，标识修订过的版本，维护人员是否容易地更改软件解决问题，用户可接受时间内得到满意解决。

（3）稳定性度量。维护后是否不再出现失效，维护人员能否容易地缓解因维护的副作用引起的失效。

（4）可测试性度量。维护人员可容易进行系统测试并确定软件是否准备好运行。

（5）维护性的依从性度量。可维护的法规、标准及约定的程度。

2. 内部可维护性度量

一般是用户和开发者，目的是评估软件在开发各个阶段，可维护性制作到产品中的程度。

（1）易分析性度量。设计风格、是否结构化、注释充分、准确，文档完整、清晰，系统结构是否模块化，变化记录完备，需求可追踪，评估软件产品是否可理解，是否易分析。

（2）易变更性度量。是否遵循信息隐蔽和抽象化，考虑了将来修改灵活性，是否可修改局部化，分离了软件中的易变部分，是否考虑了前置条件、后置条件和不变式，记录了规格说明和程序中所做的变更，是否易修改，且修改后能有效执行。

（3）稳定性度量。高内聚、低耦合原则，是否考虑了抽象数据类型，是否修改范围影响量小化，是否避免了修改的副作用，修改后的软件的稳定性。

（4）可测试性度量。是否结构化，程序中关键部位是否设置了检查点，能否跟踪及显示逻辑控制流程，在检查点显示任意中间结果，按要求显示所有的输入/输出等，测试资料是否保全，测试是否易进行。

（5）维护性的依从性度量。可维护的法规、标准及约定的程度。

7.5 软件演进与再生工程

软件使用年限太长，难以修改和演化，就称遗留系统，遗留系统中的知识可能是相当重要的企业资源，如果这些系统仍能提供很高的业务价值，就必须对它们进行改造或替换。

7.5.1 遗留系统的演化活动

（1）维护，当系统不能再演进，需要彻底替换它。

（2）现代化改造。保留系统很大部分功能，包括重构系统、增强功能或者修改软件属性。工作量比维护更多。

①白盒现代化改造。理解遗留系统内部结构，进行逆向工程，进行系统重构或代码重构。

②黑盒现代化改造。检查系统在操作系统中输入和输出，理解系统接口着手，使用一个接口软件层把遗留系统包裹起来，输入和输出都通过这个接口层，就可以解决遗留系统原来的接口与集成在它周边的其他系统的接口之间不匹配的问题。

（3）替换。要求重头开始重新构建系统。

7.5.2 软件再工程

软件再工程是现代化改造一种形式，引入现代技术和实践，把遗留系统改造成一种新的形式，提高系统在操作、系统能力、功能、性能、可演化性等方面的质量。

再生工程的形式以下6种，都是为了提高遗留系统的某个质量或一组质量。

（1）重新定位目标机。把遗留系统引入一个更现代化的平台上。

（2）修补。替换系统的用户界面（UI）就是修补。

（3）市售构件。用市售构件来替换现有遗留程序。

（4）源代码翻译。老编程语言转换为更现代的编程语言。

（5）代码简化。移植代码时，消除不必要的代码和功能。

（6）功能转换。程序结构改进、程序模块化和数据再工程。

7.5.3 遗留系统的现代化改造过程

一个遗留系统的现代化改造由3个基本过程组成。

（1）逆向工程。根据现有制品，重构系统的一个或多个更高层的逻辑描述。

（2）转化。把这些逻辑描述转化成新的，改进了的逻辑描述。

（3）正向工程。把这些新的和改进的逻辑描述细化为源代码。

转化包括：

（1）代码转化。最低级的软件演化方式，是对软件进行修改，使其易于理解或易于维护。

（2）功能转化。中级演化方式。保持基本功能条件下的技术变更。

（3）体系结构转化。是最高级演化，通过重构，使得系统的体系结构得到演化。

7.5.4 重构和逆向工程

重构与程序理解密切相关，允许软件人员逐步形成对系统的抽象描述。典型情况下，程序理解技术以逐步抽象的形式到具体概念。

第8章 软件过程

做任何工作都需按步骤，有次序地进行，这是由于工作本身的特点和性质决定的，不可任意打乱，否则工作的目标难于达到，甚至会导致失败，这就是过程。

8.1 软件过程的概念

1. 软件过程的定义

软件过程为建造一个调质量软件所需要完成的任务的框架。

软件过程与软件工程都定义了软件开发中采用的方法，软件过程与软件工程是相通的。但是软件工程还包括过程中应用的技术（如面向过程、面向对象化方法）、还有自动化工具。

软件过程的目的：软件组织问题，如开发费超支，不能按时交付，产品质量不佳的有效方法之一。

2. 软件过程的任务

几个重要论点：

（1）软件系统的质量取决于用以开发和改进它的过程质量。

（2）解决软件问题的重要一步是把整个软件工作当成一个过程来对待，使其能够控制、度量和改进。

（3）软件过程是人们用以开发软件产品 的一套工具、方法和实践。

（4）软件过程管理的目标是按计划生产产品，同时提高软件组织的能力，以便生产出好的产品。

（5）成本估算和开发期的安排的承诺应该是比较合理的，开发出的产品应该在功能和质量方面都能满足用户的期望。

（6）有效的软件管理必须考虑所要完成的任务、所采用的方法和工具，以及参与工作人员的技能、培训和积极性。

（7）有效的软件过程必须是可预测的。

8.2 软件过程的建模

8.2.1 软件生存周期过程模型

软件生存周期过程模型指的软件生存周期可能出现的过程，这些过程用以计划、管理、执行、监控和改进与软件产品相关的活动。

基本过程可分为5个基本过程、9个支持过程和7个组织过程。

8.2.2 生存周期的基本过程

软件生存周期的基本过程有5个，供各个参与方在软件生存周期使用。参与方指发起或完成软件产品开发、运行或维护的组织，包括需方、供方、开发方、操作方、维护方。

（1）获取过程。需方为得到一个软件系统或软件产品所进行的一系列活动。

（2）供应过程。供方为向需方提供软件系统或软件产品所进行的一系列活动。

（3）开发过程。开发方（定义并开发软件产品的组织）为开发软件所进行的一系列活动。

（4）运行过程。操作方（在规定环境中为其用户提供运行计算机系统服务的组织）为使用软件产品需进行的一系列活动。

（5）维护过程。维护方（提供维护软件产品服务的组织）所从事的一系列活动。

在维护过程中还贯穿了其他软件工种过程的实施。

8.2.3 生存周期的支持过程

生存周期支持过程是有关各方为支持基本过程的成功实施从不同途径实施的一系列活动。

（1）文档编制过程。记录任何其他过程所产生的信息，并生成相应的文档。

（2）配置管理过程。一组活动或任务，目的是建立和维护软件生存周期各个过程或项目的工作产品的完整性，使它们对相关团队都是可用的。

（3）质量保证过程。包括一组活动或任务，目的是保证软件产品和相关过程在项目生存周期符合规定的需求并遵循已制订的计划。

（4）验证过程。用于确定某项活动所产生的软件产品是否满足在以前的活动中对它的要求或条件。

（5）确认过程。用于确认需求和最终、已建立的系统或软件是否满足特定的预期用途。

（6）联合评审过程。用于在适当时机评价一项活动的状态和产品。

（7）审核过程。用于判断软件产品或活动是否符合需求、计划和合同，由审核方审核被审核方。

（8）问题解决过程。用于分析和解决在实施开发、运行、维护，以及其他过程上发现的问题（包括不符合项）。

（9）易用性过程。包含的活动要考虑在整个软件或系统开发和运行过程中处理或使用系统输出的哪些个人或小组所关心的问题和需要，确保软件使用质量。

8.2.4 生存周期的组织过程

组织过程指与软件生产组织有关的活动集合，包括7个过程。

（1）管理过程。由项目经理或管理团队从事的对项目进行管理的活动，组织、监督和控制一个项目的启动和执行以达到其目标。

（2）基础设施过程。为其他过程建立和维护所需基础设施的过程，基础设施是可以包括用于开发、运行和维护的硬件、软件、工具、技术、标准和设施。

（3）改进过程。管理人员所从事的一组活动，目的是建立、评估、测量、控制和改进软件生存周期过程。

（4）人力资源过程。为组织和项目提供具有技能和知识的人员的过程，提供适当的人力资源，使他们能有效地改造其角色并在一起协同工作。

（5）资产管理过程。由资产管理者所从事的一组活动。

（6）复用大纲管理过程。为组织复用大纳主管而定义的活动。系统性复用。

（7）领域工程过程。为领域工程师所定义的一组活动，目的是开发和维护领域模型、领域体系结构和该领域其他可复用资产。

8.3 软件过程成熟度模型

8.3.1 软件过程成熟度

任何一个组织，在完成自身的开发、维护业务时，总有自己的软件过程，软件过程可能是初级的、低效的、也可能是高效的，在其成熟性方面存在差异。

软件过程成熟度——一个特定软件过程得到清晰的定义、管理、测量、控制以及有效的程度。成熟度意味着能力的增长具有法力，组织的软件过程是有效的，在组织内所有项目中的应用是一致的。

8.3.2 CMM与CMMI

1. CMM

Capability Maturity Model，能力成熟度模型，划分了5个等级，1级被认为成熟度最低，5级则被认为成熟度最高。

2. CMM族和CMMI

（1）P-CMM，人员的能力成熟度模型

（2）SA-CMM，软件获取成熟度模型。

（3）IPD-CMM，集成系统产品开发能力成熟度模型。

（4）SE-CMM，系统工程能力成熟度模型。

（5）SSE-CMM，系统安全工程能力成熟度模型。

多个模型集合起来，形成一个集成模型，即CMMI（Capability Maturity Model Integration）

8.3.3 CMMI的分级表示

1. CMMI模型的分级表示

CMMI对软件过程成熟度改进提供了两种不同的途径，即分级表示和连续表示。

分级表示的成熟度等级侧重于软件组织过程改进方面的成熟度。

2. 各个成熟度等级的特征

（1）初始级：

①项目工作处于混乱状态，组织缺乏明文的管理办法，软件工作充满任意性，制订了计划又不执行，紧急情况下把已定的规程丢在一边，急于编码和测试。

②个别项目成功依赖于某个有经验的管理人员的努力，他们顶住削减过程的压力，然后他们离职后情况则全然不同。

③项目进度、预算、功能及产品质量无法保证，项目的实施不可预测。

（2）已管理级。

①已经建立了用于跟踪成本、进度和功能的基本项目管理过程。

②基于以往的项目经验，制订了过程实施规范，能组织的方针对项目进行策划，并能按已制定的计划执行，使类似的项目可再次成功。

③管理人员对项目工作产品的状态和工作的进展有清楚的了解和控制，能追踪成本、进度、功能、及时发现问题。

④如有分包，其质量也能得到控制。

（3）已定义级：

①已制定组织的标准过程文件，对标准、规程、工具和方法进行了描述。

②已建立了组织的软件工种过程组SEPG，负责软件过程活动。

③已制订和实施了人员培训大纲，保证人员能够胜任岗位知识和技能要求。

④针对特定项目，可对标准软件过程进行剪裁，得到项目执行过程。

⑤项目成本、工期和功能已受控，质量可跟踪。

⑥管理人员了解所有项目对技术进步的要求。

（4）已定量管理级

①已为产品和过程建立了量化的目标，对产品质量和过程活动均可做定量的度量。

②利用过程数据库收集和分析过程测量数据，可量化评估项目过程和产品。

③可有效地评估过程和产品的绩效，及时进行控制，限制偏差在规定的范围内。

④新应用领域的风险可控。

⑤可预知产品的质量。

（5）优化级

①基于对过程偏差原因的量化理解，组织可自知过程的薄弱环节，持续改进自身的软件过程。

②通过对当前过程的分析，可评估新技术的出现对项目过程的变更影响。

③重视探索创新活动，并将成功的创新推广。

④可及时分析出现的产品缺陷，找出原因，防止现次发生。

3. 软件过程域

除第1级（初始级）外，每个成熟度等级若干过程域。

8.3.4 CMMI的连续表示

1. CMMI的连续表示

表明软件组织选择的过程在软件过程改进方面的能力有多强，能力等级越高，软件过程改进的能力越强。

2. 各个能力等级的征

（1）不完备级。没有实施或只有部分实施的过程，过程域的特定目标未得到满足，也就谈不上制度化的要求。

（2）已实施级。过程能满足该过程域的特定目标，虽然展开了一些重要改进，但如不能做到制度化，其改进的成交也无法保持。

（3）已管理级。过程应有基础设施给予支持，包括制订计划，并执行此计划，聘胜任工作的工作人员，保证获得受控结果，过程得到监督、控制和评审，对过程描述的遵循情况得到评价。

（4）已定义级。过程是按照组织的剪裁指南对组织的标准过程剪裁而得到的，并把过程中得到的工作产品、测量数据以及过程改进信息反馈给组织，成为组织的过程资产，对已定义过程的描述更细致。对过程活动和过程精细测量数据之间的相互关系，以及对过程工作产品和过程服务的理解更深刻，过程将得到更为有效的管理。

（5）已定量管理级。采用了统计技术和其他定量技术对过程实施控制。制定了质量和过程绩效的定量目标，并将其用于管理过程的准则，质量和过程绩效均在统计的意义上理解，并在过程的整个生存周期中得到管理。

（6）优化级。过程根据对过程中出现偏差的共同原因的理解进行改进，并通过递增式和创新式的改进持续不断地提高过程的绩效。

8.3.5 CMMI的模型构件

1. 模型构件

也称过程域构件，目的是告诉CMMI用户，对这些构件的关注程度应有所不同。

（1）必须的构件。必须做到的内容。

（2）期望的构件。可能实施的内容。

（3）资料性构件。帮助组织思考如何达到上述两种构件时需参考的一些具体信息。

2. 共用目标和共用实践

为了达到共用目标就需要有相应的共用实践。

3. 制度化要求

是在共用目标中一再出现，体现了过程改进不容忽视的要求。表明在改进的各个环节上都要形成人们工作的习惯和自觉行为。

4. 专用目标和专用实践

给出满足某个过程域应该达到的一组特定目标，为了达到专用目标需开展的一些活动或者说是一组最佳实践，它是过程域的期望构件。

8.3.6 CMMI评估

1. 标准评估方法

对实施情况及过程改进的成交都需要通过评估加以检验。

2. CMMI评估应遵循的原则

（1）高层主持。

（2）关注组织制订的业务目标

（3）重视客观证据的收集，包括被评估组织的访谈情况和过程文档的相关信息。

（4）对评估信息应予保密

（5）使用CMMI模型作为评估的依据

（6）评估组成员协调配合工作，妥善地处理意分歧，最终应给出一致的结论。

（7）始终着眼于过程的改进。

3. 评估实施要注意的问题

（1）确定评估的范围，那些部门、项目参与评估。

（2）选定评估实施的等级。A（最严格，最广泛，不仅要考察过程的定义、试点工作、推广工作、还要考察制度化的情况）、B、C级。

（3）确定评估组成员。

（4）确定被组织参加访谈的人员。

（5）制订评估实施计划。

8.4 软件过程改进

8.4.1 软件过程改进的IDEAL模型

启动——诊断——建立——行动——提高。

1. 启动阶段

明确改进什么，

（1）激励变更：找出过程改进的原因。

（2）确定变更范围。确定参与过程改进的部门或项目以及过程域

（3）着手发动：动员员工参与和投入改进中来。

（4）建立基础设施：提供过程改进必要的条件和环境。

由高层发起和承诺。

2. 诊断阶段

理解软件过程的实际情况包括它的成熟度或能力。弄清具体和真实的情况，弄清现状与预期目标之间的差距。

（1）表征行为的过程状态和期望的状态。

（2）提出过程改进的建议。

如果你不知道你现在站在哪里，那么即使你手里拿着地图也无法找到通往目的地的路径。

3. 建立阶段

（1）安排优先顺序：使改进的工作安排有先有后。

（2）确定改进途径。

（3）策划行动：制订改进的行动计划。

4. 行动阶段

（1）提出解决方案：即实施过程改进的具体方案。

（2）试行解决方案：检查方案试行情况。

（3）改进解决方案：依检查的结果修订方案。

（4）正式实施解决方案。

5. 提高阶段

（1）分析确认已实施方案

（2）提出后续行动建议。

8.4.2 软件过程改进框架

1. 过程改进框架

（1）改进基础设施：

①组织管理基础设施，建立、监控和推进过程改进活动必须设置的岗位及其职责。

②技术基础设施。支持改进工作的技术平台、设备、设施或工具。

（2）过程改进路线图：

（3）软件过程评估方法：

（4）软件过程改进计划：

2. 软件过程改进循环

软件改进通常不可能是一次性的，相要通过一次改进解决过程存在的所有问题，达到尽善尽美的境地只能是幻想。

（1）评估：发现弱项或存在的问题。

（2）计划：针对弱项或问题制订改进计划。

（3）改进：实施改进计划。

（4）监控：检验实施的情况，纠正不符合要求的现象。

8.4.3 有效的软件过程

1. 有效的软件过程应具备的条件

（1）过程得到遵循。文件编写得再好，若不能认真实施也只能是一纸空文。

（2）过程受督促检查。不断督促检查，发现问题并及时得到纠正的情况下才能坚持下来。

（3）过程要有测量。测量出数据作为监督检查的依据。

（4）以过程要求为内容进行培训。不仅知怎么做，而且要知道怎么做得更好？

（5）明确过程所有者。明克维护者和他们的职责。

（6）管理者对过程的有效支持。认清这一支持与实现企业的业务目标是一致。

（7）把对员工的激励与过程目标的现实结合起来。

（8）新员工接受过程培训。

（9）员工对过程的意见受到鼓励、分析和指导。

（10）过程在技术上的适当支持。

2. 建立软件过程更为有效的机制

为了使企业的软件过程具务上述条件，应当在企业内建立一种机制。

（1）明确过程的所有者。全面负责软件过程的建立、运行、维护和改进的有关工作。

（2）组织培训。

（3）对过程实施情况进行测量，收集过程实施的反馈意见。

（4）吸收过程使用者的意见。

（5）吸收来自企业外部意见。

（6）实施过程的督促和检查。

 

第9章 软件项目管理

项目完成不好的原因70%的项目问题是由于管理不善引起的。管理是影响软件研发项目全局的因素，而技术因素只影响局瓿。

9.1 软件项目与项目管理概述

1. 项目的定义

项目是需要协同工作的一组任务，其目的在于开发和维护一个具体的产品。项目一般涉及一些人员，他们履行一些相互管理的活动。

2. 项目的特点

（1）唯一目的。

（2）一次性，有开始，也有结束。

（3）需要多方面的资源，包括人力、物力、财力和时间。

（4）应当有一个主发起人和客户

（5）具有不确定性。

（6）优秀的项目经理是项目成功的关键。还需发起人、组成人员的合作。

9.1.2 项目管理的定义

1. 项目管理

在项目管理活动中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目相关方的需要和期望。

项目的核心功能是范围、时间、成本和质量管理。

2. 项目管理三约束

范围、时间、成本称为项目管理三要素。

9.1.3 过程与项目管理

如何正确地计划和控制软件工程行为，以满足项目在成本、进度和质量等方面的目标。

1. 软件项目管理与软件过程的关系

软件过程规定了如何执行产品工程的任务，而软件项目管理规定了如何根据软件产品的需求和设计要求设置里程碑，如何组织项目团队，如何管理风险，监督进展等。

2. 项目管理与CMMI

CMMI体现了软件组织和其也组织在软件开发管理方面的最佳实践。一个软件组织想持续地提高软件开发能力，首要就是要提高软件项目管理能力。

9.2 软件项目计划与项目集成管理

9.2.1 项目集成成管理的概念

又称项目整体管理，任务是协调所有项目管理活动。确保所有要素在正确的时间结合到一起。

包括：项目计划制定、项目计划执行、整体变更控制。

专业软件开发和业余编程之间的区别就在于项目管理。项目集成成管理需要以整体的、系统的方式考虑问题，而不能只顾技术细节。

9.2.2 项目计划制订的过程

对项目进展情况作全面规划，预见可能出现哪些问题，并准备一些试探性解决方案来应对。

项目计划随项目的不同而不同，大项目与小项目计划详细程度不同。

1. 确定项目范围

（1）清晰定义项目的各项工作。

（2）清楚定义工作责任划分，明确每个人在项目中的地们和角色。

（3）确定项目范围变更的控制机制。

可用工作分解结构图、任务责任矩阵图分解。

2. 定义项目活动

活动即一系列工作。

3. 项目活动排序和历时估计。

项目活动之间的逻辑关系：顺序关系、并行关系、反复关系和嵌套关系。确定活动的持续时间和资源使用情况。

项目进度可以使用甘特图来安排各项活动。

4. 制订项目开发计划和其他辅助计划

最基本和必须的计划有：范围计划、进度计划、成本计划、资源计划。

辅助开发计划有：质量保证计划、沟通计划、风险计划、采购计划、人力资源计划。

辅助计划可能是基本计划的一部分，如：采购计划。

5. 项目计划确认

（1）项目组织团队对计划的认可。共同约定的依据

（2）组织上级管理层和相关职能部门对计划的认可。行政保障。

（3）项目客户的最终用户对计划的认可。界定双方责任，提高项目透明度，提高客户满意度。

9.2.3 项目计划的执行和控制

1. 项目里程碑

一个里程碑，表明一项软件过程活动的终结，包含一修正式可提交给管理层的输出结果（工作制品）。

需求获取过程中的里程碑。

2. 项目的实施

（1）项目团队的建设与发展。

①通过会议、培训、沟通与交流等提高团队和团队成员的技能，加强项目执行效果。

②获取必要的各方面专业人才。

（2）项目信息系统的建设。

信息的形式有：个别沟通谈话，书面材料，团体口头信息、电子技术信息。

（3）项目按计划执行。

（4）项目的采购管理。向供应商和分包商采购。

3. 项目的控制

目的是在预算成本内、有限资源内、进度内、按相关技术和质量指标下实现项目的目标，达到客户要求。

（1）控制信息的来源。

（2）偏差识别与分析。

（3）偏差分析结果与决策。

（4）制订相应的措施。

①组织措施

②经济措施

③合同措施

④技术措施

（5）措施执行决策。

（6）更新计划并执行。

9.3 软件项目度量与工作量估算

9.3.1 软件度量的概念

项目管理中，主要关注生产率与质量的度量。

计划和进行估算时，借助历史经验，推断当前期上报生产率和质量。

软件项目度量有两种方式：直接度量和间接度量。

直接度量：代码行数（LOC）、执行速度、存储量大小、在某个时间周期中所报告的差错数。

间接度量：功能性、效率、可靠性、可维护性和其他的质量特性。

1. 面向规模的度量

直接度量，记录工作量和成本。

生产率=KLOC/PM（人月）

质量=错误数/KLOC

成本=元/LOC

文档=文档页数/KLOC

2. 面向功能的度量

间接度量，关注程序的功能性。

通过量化输入/输出/查询数量和文件数计算功能点。

（1）外部输入数：系统外流入的数据或控制信息所做的计数。

（2）外部输出数：系统内流出的各种数据，包括报告、屏幕信息等计数。

（3）外部查询数：交互次数做统计

（4）内部逻辑文件数：

（5）外部接口文件数。

3. 在软件生存周期过程中使用度量

（1）建立基线。基线由以往的软件开发项目中收集到的数据构成。

（2）度量数据的收集、计算和评价。

9.3.2 软件范围管理

确定软件的范围。一是软件产品应包含那些特征和功能。二是项目要做什么工作，如何做才能交付具有特定功能的软件产品。

项目范围管理的结果是产生详细的工作分解结构WBS。

9.3.3 软件项目中的资源

项目最基本的是人，还有支持软件开发的工具（软件硬件），还有可复用构件库。

资源：什么资源，用来干什么，什么时候投入，要用到什么时候。

1. 人力资源

技术水平、专业、人数，和阶段需要。

2. 硬件资源

工具投入

（1）宿主机：开发时使用的计算机及外围设备。

（2）目标机：运行已开发成功软件的计算机及外围设备。

（3）其他硬件设备。专用软件开发时需要的。

3. 软件资源

软件工具来帮助开发。

4. 软件可复用部件库

9.3.4 软件项目的工作量估算

先估算一些可分别独立估算的子功能，然后对每个子功能估算其LOC和FP。用用基线生产率度量计算出子功能的工作量，最后，综合各子功能的估算值就能得到整个项目总工作量估算值。

9.4 项目的成本管理

为了保证项目所花费的实际成本不超过其预算成本而展开的成本估算、项目预算编制和项目成本控制等方面的管理活动。

9.4.1 项目成本的概念

项目成本由直接成本、管理费用、其他直接费用等组成。

直接成本：直接人工、直接材料、其他直接费用等。

管理费用：管理人员工资、差旅费、固定资产投资使用、办公费、医保。

期间费用：不受项目业务量增减影响的费用，如行政管理费，销售费等。

软件项目成本有4种：硬件/支持软件成本、差旅及培训费、软件开发成本、项目管理费，其中硬件/支持软件成本、差旅及培训费所占比重较大。

9.4.2 项目成本管理过程

项目成本管理由资源计划编制、成本估算、成本预算和成本控制4个过程组成。

1. 资源计划编制

为了完成计划的资源种类、数量和时间、包括人力、财力、物力资源，完成资源的配置。

编制项目资源计划的方法有以下几种：

（1）专家判断法：

（2）定额法：

（3）资料统计法：根据以往类的项目的历史统计数据资料。

（4）利用工作分解结构：

（5）资源均衡法：在保证项目完工时间不变的情况下可以调整资源的需求情况。

2. 成本估算

项目成本是项目形成全过程所耗用的各种费用的总和。

包括：决策成本、项目设计成本、项目获得成本、项目实施成本。

成本估算需要项目资源需求和对这些资源的预计价格为基础进行成本做算。

（1）自顶向下估算法。

（2）自底向上估算法。

（3）参数模型法。利用项目的一些度量建立数学模型来估算成本。

（4）利用项目成本管理软件。大型项目都是利用项目估算软件计算工得到的。

3. 成本预算

项目成本预算是项目成本控制的基础，包括：直接人工费用的预算、咨询服务费用的预算、资源采购费用的预算、预外成本的预算。

4. 成本控制

实际成本与计划成本对比，尽量使项目的实际成本控制在计划和预算范围内的管理过程。

（1）识别引起变动的因素，关注这些因素，变不利为有利。

（2）以工作包为单位，监督实际成本开销，找出与预算成本偏差的原因。

（3）采取纠正措施，必要时对成本基准计划进行调整。

（4）将核准的成本变更我调整后的成本计划通知给项目方。

（5）防止不正确、不合适或未授权的项目变更发生的费用被列入项目成本预算。

（6）防止因单纯控制成本而引起项目范围、进度和质量方面的问题。因此成本控制应与项目范围变更、进度变更、质量控制紧密结合。

9.5 项目的进度管理

9.5.1 项目进度管理的概念

项目进度的安排的准确程度比成本估算的准确程度更重要。成本可以重新弥补，便进度会导致市场机会的丧失和用户不满意。

多人并行，保证安排中的保证重点。

9.5.2 项目进度管理的过程

项目进度管理由项目活动定义、活动排序、活动时间估计、制订进度计划和进度控制5个过程组成。

1. 项目活动定义

项目活动定义是对工作分解结构中规定的具体活动进行定义、并形成文档。有两种方法：

一是分解。

二是模板。据以往类似项目列成模板，模板包括工作量、风险识别及其他描述。

2. 项目活动顺序安排

项目活动必须有一个清晰的起点和一个清晰的结束点，一般产生可交付物。

3. 活动时间估计

活动工期=工作量/人数

活动工期=SQRT(工作量)

还要考虑开发人员的能力差异、对项目了解的差异等。

4. 制订进度计划

决定各项活动的开始和完成时间、安排好进度。

5. 进度控制

（1）分析进度，找出在何处需采取纠正措施

（2）确定采取什么具体纠正措施

（3）修改计划，将纠正措施列入计划

（4）重新计算计进度，估计计划采取的纠正措施的效果。

当项目的实际进度滞后于计划进度时，通常可采用以下方法缩短工期。

（1）投入更多的资源以加速活动进程。

（2）指派经验更丰富的人去完成或帮助完成项目工作。

（3）减小活动的范围或降低活动的要求

（4）通过改进方法和技术来提高生产率。

9.6 项目人员与沟通管理

项目失败人原因：成员不适合当前项目的需要；团队的成员很少或根本没有彼此合作的经验；团队成员的士汽低落；项目团队的任务和职责分配不清等。

9.6.1 项目人员管理的概念

项目管理就是发挥每一个参与项目人员的作用的过程。包括：投资方、客户、上级领导、项目组成员、支持人员、供应商。应考虑如下：

（1）领导、沟通、协商、问题的解决以及其他影响组织能力的传统管理技巧。

（2）授权、激励士气、指导、忠告以及其他与处理团队内部个人关系的问题。

（3）项目团队的建设、冲突的解决以及其他与处理团队关系有关的问题。

（4）绩效评订、招聘、留用、劳工关系，健康以安全规则，以及其他与管理人员有关的问题。

9.6.2 项目的组织规划

1. 项目的组织模式

开发组织采用什么形式，针对项目的特点来决定，同时也与参与人员的素质有关。

（1）组织原则

①尽早落实原则。尽时指定专人负责，对任务完成负责。

②减少接口。合理分工，有效沟通，沟通路径数越多，生产率越低。

③责权均衡：软件经理人员所负的责任不应比委任给他的权力还大。

（2）组织结构的模式。

①项目型模式。把软件人员按项目组成小组，小组成员自始至终参加所承担项目的各项任务。

②职能型模式。软件人员按任务工作阶段分配到若干专业的职能部门。

③矩阵型模式。介于职能型和项目型之间的一种组织形式。

项目人员必须听从项目经理和职能经理的指挥，职能经理控制着人员的考绩、任务和解聘的权利。

项目经理通过职能经理控制所有资源，包括成本和人员，但仍然需要由职能经理提供项目所需的工作人员。

存在项目经理的职能经理的冲突，包括项目优先权、人力成本、给项目经理分配人员，以及盈亏责任等。

2. 项目组织规划要考虑的问题

项目组织规划的目的是确定、书面规划并分配项目的任务、职责以及项目的报告关系。需考虑以下几个方面的问题：

（1）项目的接口。

①组织接口。组组单位之间存在正式的接口。

②技术接口。同一项目同不同技术人员之间工作协调一致。

③人际接口。不同个人之间正式和非正式的沟通。

（2）人员配置的要求。项目要什么样个人和团队、技能，什么时候可用。

3. 确定人员配备要求

建立专人才库，建立矩阵，根据实际能力给专业人才特长打分。

每个项目需要用的能力矩阵。

将任务和职责分配给每个人。

4. 制订人员配备计划

描述所需人员什么时候，以什么方式加入或离开项目团队，可以正式的，也可以是非正式的。

9.6.3 项目的人员组织

合理配备人员包括：按不同阶段适时任用人员，恰当掌握用人标准。

人员素质优劣的评判标准：

（1）牢固掌握计算机软件的基本知识和技能。

（2）善于分析综合问题，具有严密的逻辑思维能力。

（3）工作踏实、细致，不靠碰运气，遵循标准的规范，具有严格的科学作风。

（4）工作中表现出有耐心、有毅力、有责任心。

（5）善于听取别人的意见，关于与周围人团结协作，建立良好的人际关系

（6）具有良好的书面和口头表达能力。

此外，还应考虑：

（1）工作经验

（2）个人兴趣

（3）个性，是否愿意与其他个人作为一个团队一起工作。

（4）可用性。是否能在最适当的时候加入项目工作。

（5）能力或技能。

如果一个历时很长的项目，重点考虑启用对项目感兴趣的人；如果项目比较紧，重点考虑启用能力或技能比较好的人。

9.6.4 项目团队的组织与建设

项目团队的特点：一是有共同工作目标；二是成员需要协作工作。

1. 项目团队成员的个人因素

员工分类：

（1）面向任务型。喜欢富有挑战性的工作，被工作本身所激励。

（2）面向自我型。接受任务前要考虑对我有什么好处，接受工作任务是为了实现自我，主要被自我价值所激励。

（3）面向合作型。主要被同事的存和活动所激励。

团队中的个人都面向合作型，领导是面向任务型，如果不可能选择性格互补的人员，就需要严格的管理来控制那些个人利益高于集体利益的行为。

2. 团队忠诚度

不受外办干扰的实体，做出决策或接受决策时保持一致的能力，相互支持和帮助，能适应环境变化。

3. 项目团队的交流

交流的原因：建立信任和友情，促进协同的工作，没有效益的交流应最小化。

交流与效率的关系：交流越多，管理越困难，沟通花费时间和代价，降低软件生产率。

一个软件小组的规模不能太多，人数不能太多，一般以2～8人为宜。

4. 项目团队的建设

建设创造一种开放和自信的后气氛，使成员有认同感，愿意为实现项目目标做工作。

5. 项目团队的构成

常见项目角色包括：项目经理、系统分析师、系统架构师、数据库管理员、程序员、质量保证人员、测试员等。

项目团队的组织结构与软件项目开发模型和软件产品结构相对应。

（1）结构化开发团队。按树状结构组织软件开发团队和所有人员。树的根是项目经理和项目总的技术负责人，结点是程序员小组，一般5～8人。

（2）主程序员小组：主程序员应该是项目负责人，其他成员包括程序员、后备工作师等是程序员的助手。

（3）民主制小组：组织内强调人人平等，组内问题均由集体讨论决定。有利于集思广益、互相取长补短、但工作效率较低。

9.6.5 项目冲突及管理

冲突不可避免。

1. 冲突产生的原因

（1）工作内容：如何完成、要做多少工作、以怎样的标准完成，导致技术方面的冲突。

（2）资源分配：分配某个成员从事某项具体工作任务，或为某项具体任务分配一定数量的资源时产生。

（3）时度时划：完成工作的次序及完成工作所需时间的不同意见。

（4）项目成本：所需成本多少冲突。

（5）先后次序：分配或资源分配时，可能产生在项目优先级方面的冲突。

（6）组织问题：制订某种规程或决策有不同意见，缺乏沟通而产生冲突。

（7）个体差异：成员在个人价值及态度上的差异在他们中产生冲突。

2. 团队冲突处理

处理得当，会产生有利的影响。冲突能将问题暴露出来，及早得到重视解决，引发讨论，澄清成员的观念，迫使成员寻求新的解决方案和方法，可以培养人们的创造性，更好地解决问题。

处理不当，会产生不利影响。

从以下方面着手：

（1）营造后气氛、控制情绪，建立友善信任的环境。

（2）正视问题，换位思考，愿意倾听别人的意见

（3）要积极沟通，交换意见，寻找分歧。

（4）要肯放弃原来观点，尽力得到最好方案。

项目团队常用的5种处理冲突的模式

（1）回避或撤退。会使冲突积聚起来，并在后来逐步升级。

（2）竞争或逼迫。把冲突当做一种争胜败的局势，会使用权力来处理冲突，会导致怨恨心理，恶化工作气氛。

（3）调停或消除。找出一致，可能伤害感情或协作的话题，能缓和冲突，但没有将问题彻底解决。

（4）妥协。寻求一个调和折中的方案，使每一位成员都得到某种程度的满足，但也许并非是最好的计划。

（5）合作、正视和解决问题。正视问题，要求得到一种双赢的结局，也重视人与人之间的关系，并愿意就冲突广泛交换意见，把异议都暴露出来。前提：有一个良好的项目环境，人们以诚相待。

解决冲突时，不能情绪激动，应当花一些时间理解别人的观点和相法。

9.6.6 项目沟通管理

1. 沟通的概念

沟通：是分享经验、思想和情感的过程。

沟通目的：相互了解、相互回应，期待能经由沟爱的行为与历程建立接纳及共识。

没有沟通就没有项目，威胁最大的就是沟通失败。

保障软件项目成功3因素：用户的积极参与、明确的需求表达、管理层的大力支持。

70%的项目问题由于管理不善引起，沟通还灵是原因之一。

2. 沟通的形式

（1）正式沟通。依组织原则信息传递与交流。有正式会议、文件、回复等。

（2）非正式沟通。正式渠道以外的信息交流。

（3）向上沟通渠道。项目经理与管理层进行的信息交流。

①层层传递。

②越级传递。

（4）向下沟通渠道。项目经理将指令及要求传达给下属或项目组成员。

（5）模向汇通渠道。中层级、个人、团队之间进行的信息传递与交流。

①项目组、项目经理与组织内其他职能部门之间的信息沟通。

②项目组各岗位、成员间信息沟通。

③项目组与用户在工作上的沟通。

④与项目有关的第三方合作伙伴的沟通。

可以采取正式形式，也可以或非正式形式。

3. 沟通的方法

（1）积极倾听。听——理解——反馈。

（2）同情心。有时沟通的目的并不是听取建议，而是为了发泄或希望对方接受自己的观点。

（3）谨慎探询真相。

沟通黄金定律：用别人喜欢被对待的方式来对待它们，求大同，存小异，努力双赢。

9.7 项目风险管理

自然、经济、社会、政治环境中，完全避开风险，或只享受权益而不担风险是不可能的。

9.7.1 风险与风险管理的概念

1. 风险的概念

风险是损失的不确定性，风险是给定情况下一定时期内可能发生的各种结果间的差异。

基本特征：不确定和损失。

2. 项目风险的3个主要观点

（1）风险是人们有目的的活动有关。

（2）风险与将来的活动和事件有关。

（3）风险与变化（行为方式或路线、思想方针）有关。

3. 风险的属性

（1）风险事件的随机性。

（2）风险的相对性（指承受能力因人而异）。

承受能力受以下因素影响：

（1）收益多少。收益越大，人们愿意承担风险越大。

（2）成本的多少。投入少时，可接受较大风险，反之。

（3）项目活动主体的地位和拥有的资源。

（4）风险的可变性。

（5）风险后果的变化。

4. 风险的分类

（1）管理风险。项目复杂、规模、结构不确定导致预算不稳。

（2）技术风险。技术太新，采用非常规，技术目标制订过高或技术标准发生变化。

（3）商业风险。

①市场风险。软件优秀但市场不要。

②策略风险。软件产品不符合公司整个产品策略。

③管理风险。重点转移或人员变动而的人去上级管理部门的支持。

④预算风险。没有得到预算或人员保证。

（5）组织风险。组织内部目标不一致，高层不重视，资金不足。

（6）外部风险。法律法规变化等外部不可抗力。

此外还可将风险分类为：

（1）已知风险。

（2）可预测风险。

（3）不可预测风险。

5. 风险成本

风险事故造成的损失或减少的收益，以及为减少风险事故发生采取措施而支付的费用就是构成了风险成本，包括有形成本、无形成本、预算和控制风险的费用。

其中有形成本包括风险发生造成的直接损失和间接损失。

风险的代价：

（1）减少了机会。

（2）阻碍了生产率的提高。

（3）造成资源分配不当。

（4）风险预算和控制需要费用。

只有当风险的不利后果超过风险管理而付出的代价时，才执行风险管理。

9.7.2 项目风险管理的过程

是对项目风险进行识别、分析和应对的系统的过程。

项目风险管理过程包括：风险管理计划编制、风险识别、风险分析、风险应对计划编制、风险监控等。

1. 风险管理计划编制

风险管理计划描述了项目生存周期内风险识别、风险分析、应对计划编制、跟踪和控制等活动如何组织和执行。包括：

（1）方法：可能用于项目风险管理的方法、工具和数据信息来源，评估方法。

（2）岗位和职责。

（3）预算

（4）时间

（5）评分和解释。

（6）承受度。

（7）报告形式

（8）追踪

2. 风险识别

有哪些风险？风险的基本特征？可能会影响项目的哪些方面？

识别内部因素、外部因素。

主要识别以下内容：

（1）识别并确定项目有哪些潜在的风险

（2）识别引起这些风险的主要因素

（3）识别项目风险可能引起的后果。

3. 风险分析

风险分析的目的是评估风险的概率和后果。

（1）确定风险概率及其影响。极高、高、中、低、极低等5级，风险事件用（风险概率、风险后果）两个维度描描述。

（2）建立风险概率/后果评分矩阵。

（3）十大风险事件跟踪表。

4. 风险应对计划编制

目标是提升实现项目目标的机会，减少项目目标的风险，包括确定和分析人员，负责每一个已经认可的风险应对行动。

经过分析，风险会出现两种情况。

（1）项目整体风险超出项目组织或项目客户能够承受的水平。

（2）项目整体风险在项目组织和项目客户可承受的水平之内。

情况（1）停止项目或全面取消。情况（2）可制订应对措施，规避或控制风险：

①风险避免。改变项目计划或条件。

②风险缓解。降低风险发生的概率。如：开发原型。

③风险转移。将风险转移给另一方去承担，如：分包商。

④风险接受。

⑤风险研究。调查更多的信息以获得应对措施。

⑥风险储备。预留应急费用和进度计划。

⑦风险退避。如：应急处理补贴、可选择的开发、改变项目范围。

⑧风险分担。把风险扩散到工作环节中去。

5. 风险监督与控制

跟踪与识别的风险，保证项目计划的执行，并评估这些计划对降低风险的有效性。

9.8 软件配置管理

9.8.1 软件配置管理的概念

第一：软件项目开发，会产生制品，代码、文档、数据、脚本、执行文件、安装文件、配置文件、参数等。制品信息极容易被修改，导致管理复杂性。

第二：软件开发期间的变更，最终都反映到软件项目的制品中。要监控变更，使变更可追踪性。

第三：软件产品是由许多构件组装在一起，每个构件都会产品一系列版本，需要综合进行管理。

1. 软件配置管理（Software Configuration Management，SCM）的定义。

应用技术和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证对规定的需求的遵循性。

可以概括为四个方面：

（1）配置标识：配置项的类型和版本信息加以标识。

（2）配置控制：控制这些配置项的投放和变更。

（3）配置状态报告:记录和报告配置项变更的状态和变更的请求。

（4）审核和评审：验证配置项的完整性和正确性。

软件配置协调软件开发，减少混乱发生，是一种标识、组织和控制修改的技术，目的是有效地提高生产率。

2. 软件配置项（Software Configuration Items）的定义

（1）与合同、过程、计划和产品有关的文档的数据

（2）源代码、目标代码和可执行代码

（3）相关产品，包括软件工具、库内的可复用软件、外购软件及用户提供的软件。

3. 基线

基线（Baseline）又称里程碑（Milestone）。是经评审同决的正式制品。

基线冻结后，如果需要修改它，必须经过一个严格的审查程序，以决定是否可以修改。

9.8.2 软件配置管理的过程

在项目的整个生存周期中所开发的软件制品实施管理，严格执行配置识别、变更控制、状态报告和配置审核。

1. 角色职责

（1）项目经理（PM）。根据配置控制委员会的建议，批准配置管理的各项活动并控制它们的进程。

（2）配置控制委员（CMO）。负责指导控制配置各项具体活动的进行，为项目经理的决策提供建议。

（3）系统集成员（SIO）。负责生成和管理项目的内部和外部发布版本。

（4）开发人员（DEV）。使用软件配置管理工具完成开发任务。

（5）质量保证人员（SQA）。向参与配置管理的人员提供配置管理的技术支持。

2. 配置管理过程的描述

软件配置管理来说，软件开发与维护阶段所督脉的活动是一致的，所以把它们合二为一。

（1）项目计划阶段。

（2）项目开发的维护阶段。

3. 软件配置管理的关键活动

（1）制订项目的配置管理计划

（2）对配置项进行标识

（3）对配置项进行版本控制

（4）对配置项进行变更控制

（5）定期进行配置审计

（6）向相关人员报告配置的状态

9.9 需求管理

9.9.1 需求管理的概念

需求管理可定义为：一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队不断变更的系统需求达成并保持一致的过程。

需求管理的目的是客户与开发方之间建立对需求的共同理解。

（1）控制对需求基线的变动

（2）保持项目计划与需求一致

（3）控制单个需求和需求文档的版本

（4）管理需求和跟踪链之间的联系或管理单个需求和其他项目可交付物之间的依赖关系。

（5）跟踪基线中需求的状态。

9.9.2 需求管理的任务

需求管理任务有3个：需求是版本控制、变更控制、需求跟踪及需求的状态跟踪。

1. 需求规格说明的版本控制

版本控制是为了管理软件需求规格说明文档。

最初版可标记为“1.0版（草案1）”

正式采用后标记为“1.0正式版”

较小修订用“1.1版，1.2版”

较大修订，较长时间，完成评审后为“2.0版”。

2. 需求跟踪

需求跟踪确保所有需求都被实现。

（1）需求跟踪链。通过需求跟踪链，可以在整个软个

第一链：从用户需求跟踪到软件需求。

第二链：从软件需求回溯到用户需求。

第三链：通过定义每个需求和特定的工作制品之间的联系实现从需求向前跟踪。即下游制品跟踪。

第三链：从下游制品回溯到需求，告诉人们每个下游制品之所以存在的原因。

（2）需求跟踪矩阵：描述需求和其他工作任务与工作制品联系的跟踪链。

3. 需求状态跟踪的过程

（1）准定定义哪几种需求跟踪链。

（2）选择使用的需求跟踪矩阵。

（3）确定产品的哪部分维护跟踪能力信息。

……

9.9.3 需求变更请求的管理

1. 变更控制的策略

（1）所有需求的变更必须遵循一个变更控制过程。

（2）未经批准的变更，队可行性论证外，不应再做其他设计和实现工作。

（3）提交一个变更请求不能保证该变更一定能实现。由变更控制委员会决定实现哪些变更。

（4）项目风险承担者应该了解变更数据库的内容。

（5）绝不能从数据库中删除或修改变更请求的原始文档。

（6）每个集成的需求变更必须能跟踪到一个经核准的原始文档。

2. 变更控制步骤

（1）引言：说明变更控制的目的，步骤应用的范围。

（2）角色和责任。

（3）变更请求状态。

（4）开始条件。合适渠道合法的变更请求。

（5）任务：评估变更的技术可行性、代价和资源限制。

（6）评审：通过评审确保更新后的软件需求规格说明、用例、分析模型都正确地反映变更的各个方面。

（7）退出条件：完成变更控制执行过程应退出的条件。

①被拒绝、结束或已取消。

②修改扣的工作产品安装到合适的位置。

③参与者都注意到变更的细节和当前的状态。

④已经完成修改并成功安装，并给予了新版本号。

⑤已经更新需求跟踪能力矩阵。

（8）变更控制状态报告。

 

第10章 软件质量管理

软件质量管理它与绩效、成本、时间一起构成项目成功的关键要素。

质量管理由：质量方针、组织结构、项目过程中的活动以及相应的资源组成。

确定质量的政策、目标、责任，并在质量体系中凭借质量计划编制、质量控制、质量保证和质量提高等措施达到质量的目标。

10.1 软件质量与质量模型

10.1.1 软件质量的概念

软件质量强调三点：一是用户需求是软件质量评价的基础。二是规定的标准和规范是软件开发的共同准则。三是某些未明确提出，但却大家公认的，也应得到满足。

软件产品满足规定和隐含的与需求能力有关的全部特征和特性。

（1）软件产品质量满足用户要求和程度。

（2）软件各种属性的组合程度。

（3）用户对软件产品的综合

（4）软件在使用过程中满足用户要求的程度

10.1.2 软件质量特性

软件质量是由各种质量特性（开发环境等）的复杂组合来描述。

软件质量分为：内部质量、外部质量、使用质量。

10.1.3 软件质量模型

1. 3种软件质量

使用者方便使用、维护人员希望方便维护，开发人员便于开发。因此与观察者的立场有关。

（1）使用质量：用户的使用环境下，用户的质量要求。是第一位的。

（2）外部质量：根据使用质量要求进行分析，定义出产品质量需求，作为开发依据，确认目标。

（3）内部质量：开发阶段的质量要求。

2. 外部和内部质量的质量模型

6个外部质量特性和27个内部质量特性。

（1）功能性。在使用条件下满足已说明和隐含功能的能力。

①适合性。规定作业和合适功能的能力。

②准确性。所需精确度的结果或影响能力。

③互操作性。与多个规定系统交互的能力。

④安全性：保护信息和数据，非授权不能阅读或修改的能力。

⑤依从性。符合功能性相关标准、约定或法律规定以及类似规定的能力。

（2）可靠性。在规定使用条件下满足规定性能水平的能力。

①成熟性。避免故障导致失效的能力。

②容错性。在软件故障或违反规定接口的情况下保持性能水平的能力。

③恢复性。恢复直接受影响数据的能力。

④可靠性的依从性。符合可靠性有关的标准、约定和法规的能力。

（3）易用性。规定条件下使用时被用户理解、学会、使用和吸引用户的能力。

①易理解性。理解是什么，如何用的能力。

②易学性。能学会如何应用的能力。

③易操作性。用户操作和控制它的能力。

④吸引性。吸引用户的能力。

⑤易用性的依从性。符合易用性有关的标准、约定、风格指南或法规的能力

（4）效率。规定条件眄提供与所用资源量相关的合适性能的能力。

①时间特性。执行功能时响应和处理时间、吞吐率的能力

②资源利用。资源类型和数量的能力。（包括人）

③效率的依从性。符合与效率相关的标准或约定的能力。

（5）可维护性：软件产品被修改的能力。

①易分析性。诊断出缺陷或失效的原因，识别出要被修改的部件。

②易变更性。修改能实现的能力。

③稳定性。避免软件修改带来不希望的影响的能力。

④易测试性。修改的软件能被确认的能力。

⑤可维护性的依从性。可维护性相关的标准或约定的能力。

（6）可移植性。从一个环境转移到另一个环境的能力。

①适应性。无需开展额外活动或采用额外手段的能力。

②易安装性。安装在规定环境的能力。

③共存性。在公共环境中共享公共资源的能力。

④易替换性。可包手易安装性和适应性。

⑤可移植性的依从性。符合可移植性相关的标准和约定的能力。

3. 使用质量的质量模型

（1）可用性：有效性，正确、规定目标的能力。

（2）生产率：消耗适当资源的能力。

（3）安全性：使用环境中在人员、经营、软件、财产或环境损伤方面实现可接受风险的能力。

（4）满意度：满足用户的能力。

10.2 软件质量度量和度量模型

10.2.1 软件质量的度量

用于确定软件产品所具有的质量特性组合与期望质量特性组俣的符合程度。用户、项目管理人员、系统设计和开发人员、维护人员各自关注点不同：

（1）用户、项目管理人员通过质量度量，辨识、确定和优化一个系统的质量需求，据此在项目后期进行评估，确定需求是否得到满足。

（2）系统设计和开发人员辨识软件质量的具体特性，以便在构建软件产品时能满足质量需求。

（3）系统维护人员在产品演化、升级期间，参与变更管理，估计变更的难易程度。

从技术上说，软件度量的具体项目如下：

（1）通过质量度量建立明确的系统质量需求。

（2）开发中度量控制开发实现质量需求。

（3）对照已建立的质量需求，预测、评估产品的质量等级。

（4）检测系统中存在潜在异常。

（5）在修改软件产品时监视质量方面的变化。

（6）在产品需升级、演化时判断改变产品的难易程度。

10.2.2 软件质量度量模型

1. FCM软件产品质量度量模型

（1）质量因素：表示外部质量特性或行为特征。如功能、性能、效率等。

（2）质量标准：将质量因素细化到必须在产品中满足哪些质量特性。如易用性可细化到易学、易操作、吸引性等。

（3）质量度量。对质量属性给出可评估的方法或计算式。

自顶向下，使用FCM质量模型的度量工作步骤如下：

（1）以若干质量因素来识别质量需求

（2）建立质量因素和产品属性（质量标准）、度量之间的关系。

（3）识别和质量因素、产品属性相关的度量方法。

自底向上，FCM质量模型使管管理和技才人员通过以下途径交流和反馈

（1）在最底的试题方法层上评估产品。

（2）通过分析度量值来评估质量因素。

2. GQM软件产品质量度量模型

度量应当有目的性，根据目标去跟踪相关数据，提供一个框架解释这些数据与所确定目标之间的关系。

（1）第一层：概念层，包含多个目标、目标涉及的度量对象及属性等信息。

（2）第二层：运作层。问题由上层目标细化而来，用于描述该目标的实现方式。

（3）第三层：量化层。一组以量化的方式回答上层问题的度量。

度量（M）

 

M51（错误延误）=（错误呈现时间-错误产生时间）/过程周期

 

M52=（改错人工）=∑（所参加改错的人）用于改错的时间

10.2.3 软件质量度量方法

软件质量度量有两类：预测型、验收型。

预测型：用定量或定性的方法对软件质量的评价值进行估计，以得到软件质量比较准确的估算值。

验收型：对预测度量的一种确认，对开发过程中的预测进行评价。

预测型有两种，一种为尺度度量，这是一种定量度量,尺度度量适用于能够直接度量的特性。如出错率。

另一种为二元度量，这是一种定性度量，是定性度量，适用于间接度量的特性，如可使用性、灵活性。

10.2.4 软件质量评价

一般由（6～10位）专家打分来评价，专家是富有实际经验的带头人。

1. 评分

对某阶段要达到的质量指标详细开列，建立度量工作表。

2. 分析结果

对照评价指标，检查某个质量特性是否达到了质量标准，不符合的，找出达不到的原因。应自顶向下，按系经级、子系统级、模块级逐步分析。

质量特性低于规定的质量标准有以下两个原因：

（1）该质量特性与其他质量特性冲突，而那些质量特性正好很重要。

（2）这个软件部分有质量问题。

10.3 软件质量计划

10.3.1 软件质量计划编制的目的

目的是识别与项目相关的质量目标，以及如何满足这些相关的质量目标。

1. 质量方针

由组织的最高管理者正式发布的该组织总的质量意图和质量方向。几个要求：

（1）与组织宗旨相适应。

（2）包含对满足要求的持续改进质量管理体系有效性的承诺。

（3）提供制订和评审质量目标的框架。

（4）在组织内得到沟通和理解。

（5）在持续适宜性方面得到评审。

2. 项目的范围说明和产品说明

项目的范围说明记录了该项目最终应交付的所有可交付物，产品说明则详细记录了这些可交付物的功能、特点、需要达到的性能指标以及相关的技术细节。

3. 质量目标

要求如下：

（1）制订质量目标的主要考虑。主要目标是持续改进、提高质量、使客户满意，考虑：高层当前和未来需要，当前产品及客户满状况。

（2）质量目标应给予分解和展开。

（3）质量目标应是可测量的。

（4）质量目标与质量方针保持一致。

4. 质量目标的内容

（1）产品要求：体现产品的固有特性（功能、性能、行为、心理、时间）和产品的赋予特性（如价格）。

（2）满足产品要求所需的内容。资源、过程、文件和活动。

（3）包括对持续改进的承诺。

10.3.2 软件质量计划的内容

（1）引言

（2）项目概述

（3）项目计划实施策略

（4）项目组织

（5）质量对象分析与选择

（6）质量管理的任务

（7）实施计划

（8）资源计划

（9）计录收集、维护和保存。

10.4 软件质量保证

10.4.1 软件质量保证的概念

ISO/IEC 12207-1995指出：向相关人员提供证据，证明质量功能在按质量要求运行。

质量保证过程：是保证项目生存周期中的软件产品和过程符合规定的需求和已制定的计划提供足够保证的过程。

质量保证过程分4个方面的活动：过程实施、产品质量保证、过程质量保证和质量保证体系的质量保证。

10.4.2 软件质量保证的过程

4个目标

（1）SQA的活动应是有计划的。

（2）软件产品的活动遵循适用的标准、规程和需求的情况得到客观的验证。

（3）所有参与SQA活动或受影响的组和个人都得到活动结果和通知。

（4）高级管理者处理在软件项目内部不通解决的不符合问题。

这些目标依赖8项活动

（1）制定质量保证计划

（2）按计划执行SQA组的活动。

（3）SQA组应参与制定软件开发计划、标准和规程。

（4）SQA组应参与评审项目中各项软件工程活动。

（5）SQA组应参与审核指定的软件工作产品。

（6）SQA组应定期向软件工种组报告其活动结果

（7）SQA按组织预先制订的文档化规程处理评审和审核中发现的偏差并建立文档。

（8）必要时SQA组和顾客的SQA组一起评审自己的活动与发现，记录所有不符合部分，向管理部门报告。

指导保证措施：

（1）组织应制定实施SQA的方针并要求项目遵守。

（2）对于全部项目，SQA功能到位

（3）SQA组有向高级管理者报告的渠道。

（4）高级管理者定期评审SQA活动和结果

基础保证措施

（1）项目组中建立并保持一个负责协调和实施项目质量保证活动的SQA组

（2）提供足够的资源和资金。

（3）进行必需的培训

（4）对项目组成员进行有关SQA组的任务、职责、权利和价值等的定向培训。

测量和分析SQA组活动的实践：

（1）测量SQA过程实施的状况，以便分析和确定SQA活动的成本和进度状态。

（2）定期比较通过SQA活动守成里程碑的情况

（3）定期比较SQA完成的工作、花费的工作量和消耗的资金。

（4）比较产品审核和活动评审的次数。

最后，验证实施阶段3项关键活动：

（1）高级管理者定期参与评审SQA活动

（2）项目经理定期地，且事件驱动地参与评审SQA的活动。

（3）独立于SQA组的专家定期评审项目SQA组的活动和软件工作产品 。

10.4.3 软件质量保证的任务

（1）清晰的规格说明。

（2）使用完善的标准。

（3）历史经验。

（4）合格的资源。

（5）设计评审

（6）变更控制。

10.4.4 质量保证体系与ISO9000标准

ISO9000系列标准就是推出的目的：为做好质量管理工作，针对相方面（顾客、员工、分包方及组织的所有者）的需求建立质量管理体系。

（1）GB/T19000-2000质量管理体系：基础和术语。

（2）GB/T19001-2000质量管理体系：证实组织具有提供满足顾客要求和适用的法规要求的产品能力。

（3）GB/T19004-2000质量管理体系：业绩改进指南，考虑质量管理体系有效性和效率的指南。

ISO9000系列标准的核心思想：

（1）以顾客为焦点。

（2）领导作用。

（3）全员参与。

（4）过程方法。

（5）管理的系统方法。

（6）持续改进。

（7）基于事实的决策方法。

（8）与供方互利的关系。

10.4.5 国际标准ISO90003

ISO9003标准作为计算机软件相关组织实施ISO9000标准的指南，对软件行业的特点给予了必要的说明。

10.5 验证与确认

10.5.1 软件验证和确认的概念

（1）验证：用数据证明人们是否在正确地制造产品。强调过程的正确性。

（2）确认：用数据证明人们是否制造了正确的产品。强调结果的正确性。

验证和确认的目标是发现缺陷，并确定软件是否实现了需要功能和质量特性。

（1）验证是软件生存周期每个阶段的产品，前一阶段是否满足要求，以此基础建立下阶段启动。

（2）确认是最终产品遵循了已建立的软件与系统的需求。

10.5.2 生存周期中的验证和确认工作

1. 概念阶段的验证和确认。关注系统需求分析和系统体系结构设计。

2. 需求阶段的验证和确认。输出软件需求规格说明书。

3. 设计阶段的验证和确认。

4. 实现阶段的验证和确认。目标是确定是代码的质量。

5. 测试阶段的验证和确认。对集成后的软件进行确认是否满足需求。

6. 安装和校验阶段的验证和确认。

7. 运行和维护阶段的验证和确认。

10.6 软件评审

用测试的方法只能发现软件开发中大约1/5的缺陷，认真进行评审则可发现4/5的缺陷。

10.6.1 软件评审的概念

1. 软件评审的定义

评审是把工作产品或一组工作产品交给项目个人、管理者、用户、客户或其他感兴趣的部门为了市政府或批准的过程或会议。

目的是验证软件元素满足其规格说明，并且符合标准的要求。

注意：审核与评审是不同的概念。

2. 软件评审的特点

（1）目的是发现隐藏的缺陷。

（2）参加人员应是项目开发组以外的同行为主。

（3）对象通常是软件开发中的各种技术产品。

（4）评审的多种形式。评审人员签字以示责任。

10.6.2 软件评审的作用

（1）及时排除软件开发过程中引入的缺陷。

（2）提高软件生产率，降低消除缺陷的成本

（3）可为项目监控提供信息

（4）可找出测试无法发现的缺陷

（5）通过评审可学到知识，从中吸取有益的教训。

10.6.3 软件评审的实施

主要分：管理评审、技术评审、过程评审。

1. 管理评审

是对管理体系的适应性、管理活动的有效性及充分性进行评价。

（1）适应性：适应外部环境（市场、法规、设备、人事、产业结构）变化。

（2）有效性：是否满足市场、客户、书店一样利益，

（3）充分性：管理体系运行后，目标达到程度，包括方针和目标的实现等。

2. 技术评审

是对产品以及各阶段输出内容进行评估。

目的：确保需求说明、设计说明书与用户需求保持一致，并按照计划对软件进行了正确的开发。提示软件在逻辑、执行以及功能和编码上的错误；验证软件是否符合需求；确保软件一致性。

不仅需关注评审目标，还要注意技术的共享和延续性。如果某些人对某个模块特别熟悉，可能会形成固化思维，可能使问题被隐藏，不利于知识的共享和发展。

3. 文档评审。

（1）需求评审

（2）设计评审

（3）代码评审

（4）质量验证评审

4. 过程评审

对象是质量保证流程。

目的是：评估主要质量保证流程，处理和解决评审过程中发现的不符合问题；总结和共享好的经验；指出需要进一步完善和改进的部分。

10.6.4 评审的方法的技术

从最不正式到最正式的分以下：

（1）临时评审：临时请另一位程序员帮助他查找一个缺陷属临时评审。

（2）桌面检查或轮查。由多人组成的并行的同行桌面检查。

（3）结对评审。伙伴评审。

（4）走查：使用一些样品数据作为测试用例，一步步地执行模块，几个参与评审的同一事一起检查以确保正确的逻辑和行为。

（5）小组评审：允许由一组有资格的人来判断产品是否可用，并找出该产品没有达到规格说明和规范要求的方面。

（6）正式审查：

①通过审查可以验证产品是否满足功能规格说明、质量特性和用户需求，并识别偏差。

②通过审查可以维产品是否符合相关标准、规范、规则、计划和过程，并识别偏差。

③提供缺陷和审查工作量，以改进审查过程和组织的软件工程过程。

不同场合可选择不同的评审方法。

10.7 审核

GB/T19001-2000标准规定了供方组织建立和实施质量管理体系的要求，质量审核就是依据该标准。

有4个方面的具体要求：管理职责、资源管理、产品实现及测量、分析和改进。

1. 管理职责

（1）管理承诺。向组织传达满足顾客要求的重要性，制定质量方针，确保质量目标的制订，进行管理评审，确保资源的获得。

（2）以顾客为关注焦点。

（3）质量方针。

（4）策划。

（5）职责、权限与沟通。

（6）管理评审。

2. 资源管理

（1）资源的提供。

（2）人力资源

（3）基础设施

（4）工作环境

3. 产品实现

（1）产品实现的策划

（2）与顾客有关的过程

（3）设计和开发

①设计和开发策划

②设计和开发输入

③设计和开发输出

④设计和开发评审

⑤设计和开发验证

⑥设计和开发确认

⑦设计和开发更改的控制

（4）采购。

（5）生产和服务提供

（6）监视和测量装置的控制。

4. 测量、分析和改进

（1）目的：验证产品的符合性，提高质量管理有有效性。

（2）监视和测量。

①顾客满意度

②内部审核

③过程的监视和测量

④产品的监视和测量

（5）不合格品控制

（6）数据分析

（7）改进

 

第11章 软件工程标准化与软件文档

用文件的形式给出规范化要求，这就是标准

11.1 标准和标准化

11.1.1 标准与标准化的概念

1. 标准的概念

标准是对重复性事物和概念所作的统一规定。以科学、技术和实践的综合成果为基础，以获得最佳秩序和促进最佳社会效益为目的的，经有关方面协商一致，由主管或公认机构批准，共同遵守的准则或依据。规格说明、规程是标准的一种形式。

2. 标准的特点

（1）以科学、技术和实践的综合成果，具有一定科学性和先进性。

（2）内容是经过有关方面的研究和协调，实质内容得到普遍认可。

（3）有一套制定、发布程序和固定的书定格式

（4）本质是对重复性事务的统一。

（5）可分不同等级。我国4级，国家标准、行业标准、地方标准和企业标准。

（6）按不同的标志分成不同各类，如管理标准、技术标准。

3. 标准化的概念

是对标准的理解与贯彻实施的相关活动。

4. 标准化的特点

（1）标准化的目的是建立最佳秩序，提高生产效率，从而获得最佳效益。

（2）标准化的对象具有多样性、相关性的重复事物。

（3）标准化是一个过程，它经历制定标准、贯彻标准，进而修订标准的过程。

软件工种标准化问题：

（1）软件设计的标准化：包括设计方法、设计表示方法、程序结构、编程语言、编程风格、用户界面设计、数据结构设计、算法设计等。

（2）文档编制的标准化：可研报告、项目开发计划、需求规格说明、数据需求规格说明、软件测试计划、软件概要设计说明、数据库设计说明、模块开发卷宗、用户手册、安装和操作手册、测试分析报告、开发进度月报、项目开发总结报告等。

（3）项目管理的标准化：开发流程、计划和进度管理、人员组织、质量管理、成本管理、维护管理和配置管理等。

11.1.2 软件工程标准的制定与实施

1. 软件工程标准的制定

标准的制定是为了贯彻实施。标准是环状生命周期：

（1）建议：拟订初步建议标准方案草稿。

（2）开发：制定标准具体内容草稿。

（3）咨询：征求并吸取有关人员意见。

（4）审批：由管理部门决定能否推出。

（5）公布：公布发布，使标准生效。

（6）培训：为推行标准准备人员条件。

（7）实施：投入使用。

（8）审核：检验实施效果，决定修改还是撤销。

（9）修订：修改其中不适当的部分，形成新的标准版本，进入新的周期。

影响实施的因素：

（1）标准制定得有缺陷，或是存在不够合理、不恰当的部分。

（2）标准文本编写得有缺点。文字叙述可读性差、难于理解，缺少实例供读者参阅。

（3）主管部门未能坚持大力推行，在实施在过程中遇到问题又未能及时加以解决。

（4）未能及时做好宣传、培训和实施指导。

（5）未能及时修订和更新。

2. 软件组织的标准化工作

软件组织是实施软件工程标准的基层单位。

（1）安排专人负责推行标准的工作。

（2）参考国际标准、国家标准或行业标准，制定适用于本组织的规范或企业标准，编制本组织的软件工程标准化手册。

（3）制定本组织的软件工程标准时，最好吸收有经验的软件工程师参与。

（4）适时组织培训。了解理解为什么这样要求。

（5）为了适应软件工程发展的形势，需要及时地对软件组织所制定的标准或规范进行审查和更新。

（6）提倡的做法是以辅助工具进行支持。

11.2 软件工程标准的分类和分级

1. 根据标准的适用范围分类

可分为：基础标准、产品标准、方法标准、安全标准、卫生标准、环境保护标准、服务标准。

（1）基础标准：在一定范围内作为其他标准的基础并普遍通用，具有广泛指导意义的标准。

（2）产品标准：为了保证产品的适用性，对产品必须达到的某些或全部特性要求所制定的标准。

（3）方法标准：一类涉及试验、检查、分析、抽样、统计、计算、测定、作业等方法。另一类是合理生产优质产品，并在生产、作业、试验、业务处理等方面为提高效率而制定的标准。

2. 根据标准性质分类

根据标准性质分类可分为：技术标准、管理标准、工作标准。

（1）技术标准：针对重复性的技术项而制定的标准，是从事生产、建设及商品流通时需要共同遵守的一种技术依据。

（2）管理标准：是管理机构为了行使其管理职能而制定的具有特定管理功能的标准。

（3）工作标准：为了协调整个工作过程，提高工作质量和效率，针对具体岗位的工作制定的标准。

3. 根据法律的约束性分类

根据标准的法律约束性，可分为强制标准、推荐标准、和指导性技术文件。

（1）强制性标准：必须严格执行的标准，是国家技术法规的重要组成。

（2）推荐性标准：其内容是鼓励或是建议选择采用的要求。GB/T

（3）指导性技术文件：其内容是供使用者参考使用的。GB/Z

4. 标准的分级

根据制定的机构和标准适用范围，分级：国际标准、国家标准、行业标准、地区标准、企业（组织）标准以及项目规范。

（1）国际标准：由国际标准机构组织制定和发布，提供给各国参考的标准

①ISO，国际标准化组织。

②IEC，国际电工委员会。

（2）国家标准，由政府或国家机构组织制定和发布，适用全国范围。

①GB标准。中国

②ANSI（American National Standards Institute）美国国家标准协会。

③FIPS（NBS）闰车商务部国家标准局联邦信息处理标准。

④BS,英国国家标准。

⑤DIN，德国标准协会

⑥JIS，电影票工业标准。

（3）行业标准：由行业机构或国防机构制定，适用于某个业务领域的标准。

①SJ，我国信息行业标准。

②IEEE，美国电所与慢性子工程师学会。

③GJB，中国军用标准

④DOD-STD，美国国防部标准。

⑤MIL-S，美国军用标准。

（4）地区标准。地区的技术管理机构制定和发而，简称DB

（5）企业标准。大型软件组织制定租用于本组织的标准。

（6）项目规范。多单位或部门联合开发而制定大家共同遵守的项目标准或规范。

①等同采用（记为IDT）,全文采用国际标准。

②等效采用（记为EQV），取其主要内容。

③参照使用（记为NEQ），参考国际标准的内容制定我国的标准。

11.3 软件文档的作用和分类

1. 文档的概念

文档——是某种数据媒体和其中所记录的数据。永久性，人或机器阅读，能用仅指人工可读的信息。

文档是软件的一部分，没有文档就不能称为软件。

2. 软件文档的作用

（1）管理的依据。

（2）任务之间衔接的凭证。

（3）质量保证。

（4）培训和参考。

（5）软件维护支持。

（6）历史档案。

3. 文档的分类

从形式上大致可分：一是开发过程中填写的各种图表，可称之为工作表格。二是编制的技术资料或技术管理资料，可称之为文档或文件。

书写方式：自然言语、形式语言、半形式语言（结构化语言）、图形、表格。

（1）开发文档。

（2）管理文档。

（3）用户文档。

（4）维护文档。

4. 文档的内容

18种基本文档，可行性分析（研究）报告、软件（或项目）开发计划、软件需求规格说明、接口需求规格说明、系统/子系统设计（结构设计）说明、软件（结构）设计说明、接口设计说明、数据库（顶层）设计说明、用户手册、操作手册、测试计划、测试报告、软件配置管理计划、软件质量保证计划、开发进度月报、项目开发总结报告、软件产品规格说明、软件版本说明等。

11.4 软件工程文档的概要

（1）可行性分析（研究）报告：项目初期策划的结论。

（2）软件（或项目）开发计划：描述的是软件开发人员实施的开发工作计划。

（3）软件需求规格说明：描述的是对软件配置项的需求，目的是在于每项需求均在项目实施中得到满足。

（4）接口需求规格说明：接口。

（5）系统/子系统设计（结构设计）说。体系结构。

（6）软件（结构）设计说明：

（7）接口设计说明

（8）数据库（顶层）设计说明

（9）用户手册

（10）操作手册

（11）测试计划

（12）测试报告

（13）软件配置管理计划

（14）软件质量保证计划

（15）开发进度月报

（16）项目开发总结报告

（17）软件产品规格说明

（18）软件版本说明

11.5 对文档编制的质量要求

高质量文档体现在：

（1）针对性：分清读者对象。

（2）精确性：行文恰当，不能出现多义性。

（3）清晰性：力求简明，如有可能，配以图表，增强其清晰性。

（4）完整性：任何一个文档都应是完整的、独立的，自成体系的。

（5）灵活性：不同软件项目，其规模和复杂程度有许多实际差别，不能等同对待。

（6）可追溯性。