软件设计师（五）软件工程基础知识

一、软件工程概述

软件开发和维护过程中所遇到的各种问题称为“软件危机”。
软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。

1、计算机软件

计算机软件是指计算机系统中的程序及其文档。
程序是计算任务的处理对象和处理规则的描述。
文档是为了便于了解程序所需的阐述性资料。

分类	说明
系统软件	系统软件是一整套服务于其他程序的程序。特点：和计算机硬件大量交互；多用户大量使用；需要调度、资源共享和复杂进程管理的同步操作；复杂的数据结构以及多种外部接口
应用软件	应用软件是解决特定业务需要的独立应用程序。
工程/科学软件	这类软件通常带有“数值计算”算法的特征
嵌入式软件	嵌入式软件存在于某个产品或系统中，可实现和控制面向最终使用者和系统本身的特性和功能（刹车系统）
产品线软件	产品为多个不同用户的使用提供特定功能。
Web应用	Web 应用 (WebApp) 是一类以网络为中心的软件，其概念涵盖了宽泛的应用程序产品。
人工智能软件	人工智能软件利用非数值算法解决计算和直接分析无法解决的复杂问题（机器人）
开放计算
网络资源
开源软件	开源软件就是开放系统应用程序的代码，使得很多人能够为软件开发做贡献

2、软件工程基本原理

（1）用分阶段的生命周期计划严格管理

这条基本原理意味着应该把软件生命周期划分成若干个阶段，并相应地制订出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。
六类计划：

• 项目概要计划
• 里程碑计划
• 项目控制计划
• 产品控制计划
• 验证计划
• 运行维护计划

（2）坚持进行阶段评审

（3）实现严格的产品控制

（4）采用现代程序设计技术

（5）结果应能清楚地审查

（6）开发小组的人员应少而精

（7）承认不断改进软件工程实践的必要性

3、软件生存周期

（1）可行性分析与项目开发计划

• 这个阶段主要确定软件的开发目标及其可行性。
• 这个阶段的参加人员有用户、项目负责人和系统分析师。
• 该阶段产生的主要文档有可行性分析报告和项目开发计划。

（2）需求分析

• 需求分析阶段的任务不是具体地解决问题，而是准确地确定软件系统必须做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。
• 该阶段的参加人员有用户、项目负责人和系统分析师。
• 该阶段产生的主要文档有软件需求说明书。

（3）概要设计

• 在概要设计阶段，开发人员要把确定的各项功能需求转换成需要的体系结构。
• 这个阶段的参加人员有系统分析师和软件设计师。
• 该阶段产生的主要文档有概要设计说明书。

（4）详细设计

• 主要任务是对每个模块完成的功能进行具体描述，要把功能描述转变为精确的、结构化的过程描述。
• 这个阶段的参加人员有软件设计师和程序员。
• 该阶段产生的主要文档有详细设计文档。

（5）编码

（6）测试

• 这个阶段的参加人员通常是另一部门(或单位) 的软件设计师或系统分析师。
• 该阶段产生的主要文档有软件测试计划、测试用例和软件测试报告。

（7）维护

4、软件过程

软件开发中所遵循的路线图称为“软件过程”。

（1）能力成熟度模型（CMM）

研究目的是提供一种评价软件承接方能力的方法，同时它可以帮助软件组织改进其软件过程。
CMM是对软件组织进化阶段的描述。

级别	说明
初始级（Initial）	软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤
可重复级（Repeatable）	建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
已定义级（Defined）	管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程
已管理级（Managed）	制定了软件过程和产品质量的详细度量标准
优化级（Optimized）	加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

（2）能力成熟度模型集成（CMMI）

CMMI 是若干过程模型的综合和改进，能适应现代工程的特点和需要，能提高过程的质量和工作效率。
CMMI 提供了两种表示方法：阶段式模型和连续式模型

阶段式模型

阶段式模型的结构类似于 CMM，它关注组织的成熟度。

• 初始的：过程不可预测且缺乏控制。
• 已管理的：过程为项目服务。
• 已定义的：过程为组织服务。
• 定量管理的：过程已度量和控制。
• 优化的：集中于过程改进。

连续式模型

连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级 (Capability Level，CL)。CMMI 中包括 6个过程域能力等级，等级号为 0~5。

• $C{L}_0$(未完成的)：过程域未执行或未得到 $C{L}_1$中定义的所有目标。
• $C{L}_1$(已执行的)：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。
• $C{L}_2$(已管理的)： 其共性目标集中于已管理的过程的制度化。
• $C{L}_3$(已定义级的)：其共性目标集中于已定义的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进。
• $C{L}_4$(定量管理的)：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则。
• $C{L}_5$(优化的)：使用量化(统计学) 手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效。

二、软件过程模型

也叫软件开发模型。
典型的模型有瀑布模型、增量模型、演化模型(原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式化方法模型等。

1、瀑布模型（Waterfall Model）

瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水逐级下落。

瀑布模型是以文档作为驱动、适合于软件需求很明确的软件项目的模型。
优点：容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。
缺点：客户必须能够完整、正确和清晰地表达他们的需要: 在开始的两个或 3个阶段中，很难评估真正的进度状态;当接近项目结束时，出现了大量的集成和测试工作;直到项目结束之前，都不能演示系统的能力。

瀑布模型的一个变体是 V模型

2、增量模型（Incremental Model）

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征

3、演化模型（Evolutionary Model）

演化模型特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型等。

（1）原型模型（Prototype Model）

原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制订原型开发的计划，确定原型的目标和范围，采用快速射击的方式对其进行建模，并构建原型。被开发的原型应交付给客户使用，并收集客户的反馈意见，这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下轮原型的迭代开发。

分为探索型原型、实验型原型和演化型原型

（2）螺旋模型（Spiral Model）

螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。

1. 制订计划。确定软件的目标，选定实施方案，明确项目开发的限制条件。
2. 风险分析。分析所选的方案，识别风险，消除风险。
3. 实施工程。实施软件开发，验证阶段性产品。
4. 用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划。

4、喷泉模型（Water Fountain Model）

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。

5、基于构件的开发模型( Component-based Development Model )

基于构件的开发是指利用预先包装的构件来构造应用系统。

包括领域工程和应用系统工程两部分。

（1）领域工程

领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。

（2）应用系统工程

应用系统工程的目的是使用可复用构件组装应用系统。

6、 形式化方法模型 ( Formal Methods Model )

形式化方法是建立在严格数学基础上的一种软件开发方法，其主要活动是生成计算机软件形式化的数学规格说明。

7、 统一过程模型

统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML 方法和工具支持。
统一过程定义了 4 个技术阶段及其制品。

1. 起始阶段(Inception Phase )
2. 精化阶段( Elaboration Phase)
3. 构建阶段(Construction Phase)
4. 移交阶段 (Transition Phase)
   

8、 敏捷方法（Agile Development）

敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意
敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念(敏捷宣言)。

（1）极限编程XP

由价值观、原则、实践和行为4个部分组成，通过行为贯穿于整个生存周期。

1. 4 大价值观：沟通、简单性、反馈和勇气。
2. 5 个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
3. 12 个最佳实践：计划游戏(快速制定计划、随着细节的不断变化而完善)、小型发布(系统的设计要能够尽可能早地交付)、隐喻(找到合适的比喻传达信息)、简单设计(只处理当前的需求，使设计保持简单)、测试先行(先写测试代码，然后再编写程序).重构(重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求)、结队编程、集体代码所有制、持续集成(可以按日甚至按小时为客户提供可运行的版本)、每周工作 40 个小时、现场客户和编码标准。

（2）水晶法 Crystal

（3）并列征求法 Scrum

（4）自适应软件开发 ASD

（5）敏捷统一过程 AUP

敏捷统一过程 (Agile Unified Process，AUP)采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。

三、需求分析

1、软件需求

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

1. 功能需求
2. 性能需求
3. 用户或人的因素
4. 环境需求
5. 界面需求
6. 文档需求
7. 数据需求
8. 资源使用需求
9. 安全保密需求
10. 可靠性需求
11. 软件成本消耗与开发进度需求等
12. 其他非功能性的需求

2、需求分析原则

1. 必须能够表示和理解问题的信息域。
2. 必须能够定义软件将完成的任务。
3. 必须能够表示软件的行为 (作为外部事件的结束)。
4. 必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节。
5. 分析过程应该从要素信息移向细节信息。

3、需求工程

需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。
需求工程可以细分为：

1. 需求获取
2. 需求分析与协商
3. 系统建模
   面向数据流的结构化分析方法 (SA)、面向对象的分析方法 (OOA)
4. 需求规约
   需求规约作为用户和开发者之间的一个协议。包括引言、信息描述、功能描述、行为描述、检验标准、参考书目、附录
5. 需求验证
6. 需求管理

四、软件设计

“怎么做”
主要目的：就是为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方案。
主要内容：包括新系统总体结构设计、代码设计、输出设计、输入设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。
常用的设计方法有以下两种：面向数据流的结构化设计方法 (SD)、 面向对象的分析方法(OOD)
系统设计的基本任务大体上可以分为概要设计和详细设计两个步骤

（1）概要设计

1. 设计软件系统总计结构
2. 数据结构及数据库设计
3. 编写概要设计文档
   文档主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。
4. 评审

（2）详细设计

1. 对每个模块进行详细的算法设计，用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来
2. 对模块内的数据结构进行设计
3. 对数据库进行物理设计，即确定数据库的物理结构
4. 其他设计。根据软件系统的类型，还可能要进行以下设计。代码设计、输入/输出格式设计、用户界面设计
5. 编写详细设计说明书
6. 评审
   
   

五、软件测试

1、软件测试与调试

系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。
测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。
信息系统测试应包括软件测试、硬件测试和网络测试。

测试原则

1. 应尽早、不断地进行测试。
2. 测试工作应该避免由原开发软件的人或小组承担
3. 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果。
4. 在设计测试用例时，不仅要设计有效、合理的数据，也要包含不合理、失效的数据
5. 在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事
6. 严格按照测试计划来进行，避免测试的随意性。
7. 妥善保存测试计划、测试用例，作为软件文档的组成部分，为维护提供方便。
8. 测试例子都是精心设计出来的，可以为重新测试或追加测试提供方便
9. 修改后应进行回归测试
10. 尚未发现的错误数量与该程序已发现错误数成正比

测试过程

1. 制订测试计划
2. 编制测试大纲
3. 根据测试大纲设计和生成测试用例，产生测试设计说明文档
4. 实施测试
5. 生成测试报告

2、传统软件的测试策略

有效的软件测试实际上分为 4 步进行，即单元测试、集成测试、确认测试和系统测试。

（1）单元测试

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

单元测试的测试内容

• 模块接口
• 局部数据结构
• 重要的执行路径
• 出错处理
• 边界条件

单元测试过程

由于模块不是独立运行的程序，各模块之间存在调用与被调用的关系。在对每个模块进行测试时，需要开发两种模块。单元测试环境如图 5-9 所示。

（2）集成测试

集成测试就是把模块按系统设计说明书的要求组合起来进行测试。
集成测试有两种方法：一种是非增量集成，一种是增量集成。

自顶向下集成测试

自顶向下集成测试是一种构造软件体系结构的增量方法。
模块的集成顺序为从主控模块（主程序) 开始，沿着控制层次逐步向下，以深度优先或广度优先的方式将从属于 (或间接从属于) 主控模块的模块集成到结构中。

自底向上集成测试

自底向上集成测试就是从原子模块(程序结构的最底层构件) 开始进行构造和测试。由于构件是自底向上集成的，在处理时所需要的从属于给定层次的模块总是存在的，因此，没有必要使用桩模块。

回归测试

在集成测试策略的环境下，回归测试是重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。

回归测试要执行的测试子集包含以下3 种测试用例。

• 能够测试软件所有功能的具有代表性的测试样本
• 额外测试，侧重于可能会受变更影响的软件功能。
• 侧重于已发生变更的软件构件测试。

冒烟测试

冒烟测试是一种常用的集成测试方法。

1. 将已经转换为代码的软件构件集成到构建中。一个构建包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。
2. 设计一系列测试以暴露影响构建正确的完成其功能的错误，其目的是为了发现极有可能造成项目延迟的业务阻塞错误。
3. 每天将该构建与其他构建及整个软件产品(以其当前形势) 集成起来进行冒烟测试这种集成方法可以自顶向下，也可以自底向上。

（3）确认测试

确认测试始于集成测试的结束，那时已测试完单个构件，软件已组装成完整的软件包，且接口错误已被发现和改正。

确认测试准则

软件确认是通过一系列表明与软件需求相符合的测试而获得的。

配置评审

确认过程的一个重要成分是配置评审，主要是检查软件(源程序、目标程序)、文档 (包括面向开发和用户的文档) 和数据(程序内部的数据或程序外部的数据) 是否齐全以及分类是否有序。确保文档、资料的正确和完善，以便维护阶段使用。

$\alpha$测试与$\beta$测试

$\alpha$测试是由有代表性的最终用户在开发者的场所进行。软件在自然的环境下使用，开发者站在用户的后面观看，并记录错误和使用问题。$\alpha$测试在受控的环境下进行。
$\beta$测试在一个或多个最终用户场所执行。与 $\alpha$测试不同，开发者通常不在场，因此，$\beta$测试是在不被开发者控制的环境下软件的“现场”应用。最终用户记录测试过程中遇见的所有问题(现实存在的或想象的)，并定期地报告给开发者。接到 测试的问题报告之后，开发人员对软件进行修改，然后准备向最终用户发布软件产品。

$\beta$ 测试的一种变体称为客户验收测试，有时是按照合同交付给客户时进行的。客户执行一系列的特定测试，试图在从开发者那里接收软件之前发现错误。

（4）系统测试

系统测试是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种集成测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方。

• 恢复测试
• 安全性测试
• 压力测试
• 性能测试
• 部署测试

3、测试面向对象软件

对于面向对象软件，测试的基本目标仍然是在现实的时间范围内利用可控的工作量找出尽可能多的错误

（1）单元测试

面向对象软件的类测试是由封装在该类中的操作和类的状态行为驱动的。

（2）集成测试

由于面向对象软件没有明显的层次控制结构，因此面向对象环境中的集成测试有两种策略

• 基于线程的测试，对响应系统的一个输入或事件所需的一组类进行集成，每个线程单独地集成和测试，并应用回归测试以确保没有产生副作用。
• 基于使用的测试，通过测试很少使用服务类的那些类开始系统的构建。

4、测试Web应用

（1）质量维度

维度	说明
内容	在语法及语义层对内容进行评估
功能	对功能进行测试，以发现与客户需求不一致的错误
结构	对结构进行评估，以保证它正确地表示 WebApp 的内容及功能，是可拓展的，并支持新内容、新功能的增加
可用性	对可用性进行测试，以保证接口支持各种类型的用户，各种用户都能够学会及使用所有需要的导航语法及语义
导航性	对导航性进行测试，以保证检查所有的导航语法及语义，发现任何导航错误 (例如，死链接、不合适的链接、错误链接等)
性能	在各种不同的操作条件、配置及负载下对性能进行测试
兼容性	在客户端及服务器端，在各种不同的主机配置下通过运行 WebApp 对兼容性进行测试
安全性	对安全性进行测试，通过评定可能存在的弱点试图对每个弱点进行攻击

（2）WebApp测试策略

1. 对 WebApp 的内容模型进行评审，以发现错误。
2. 对接口模型进行评审，保证适合所有的用例。
3. 评审 WebApp 的设计模型，发现导航错误。
4. 测试用户界面，发现表现机制和或) 导航机制中的错误。
5. 对功能构件进行单元测试。
6. 对贯穿体系结构的导航进行测试。
7. 在各种不同的环境配置下实现 WebApp，并测试 WebApp 对于每一种配置的兼容性。
8. 进行安全性测试，试图攻击 WebApp 或其所处环境的弱点。
9. 进行性能测试。
10. 通过可监控的最终用户群对 WebApp 进行测试，对他们与系统的交互结果进行以下方面的评估，包括内容和导航错误、可用性、兼容性以及 WebApp 的安全性、可靠性及性能等方面的评估。

5、测试方法

软件测试方法分为静态测试和动态测试。
静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。
动态测试是指通过运行程序发现错误。在对软件产品进行动态测试时可以采用黑盒测试法和白盒测试法。

（1）黑盒测试

黑盒测试也称为功能测试，在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性。

常用的黑盒测试技术

1. 等价类划分
2. 边界值分析
3. 错误推测
4. 因果图

（2）白盒测试

白盒测试也称为结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。

白盒测试的原则

1. 程序模块中的所有独立路径至少执行一次。
2. 在所有的逻辑判断中，取“真”和取“假”的两种情况至少都能执行一次。
3. 每个循环都应在边界条件和一般条件下各执行一次。
4. 测试程序内部数据结构的有效性等。

白盒测试常用的技术

1. 逻辑覆盖
   逻辑覆盖考察用测试数据运行被测程序时对程序逻辑的覆盖程度，主要的逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖6种。
2. 循环覆盖
   执行足够的测试用例，使得循环中的每个条件都得到验证
3. 基本路径测试
   基本路径测试法是在程序控制流图的基础上通过分析控制流图的环路复杂性，导出基本可执行路径集合，从而设计测试用例。

6、调试

调试发生在测试之后，其任务是根据测试时所发现的错误找出原因和具体的位置，进行改正。调试工作主要由程序开发人员进行，谁开发的程序就由谁来进行调试。

（1）调试过程

调试过程通常得到以下两种结果： 发现问题的原因并将其改正、未能找到问题的原因

（2）调试方法

• 试探法
• 回溯法
• 对分查找法
• 归纳法
• 演绎法

---

六、软件运行和维护

1、系统转换

在进行新旧系统转换以前，首先要进行新系统的试运行。新系统试运行成功之后，就可以在新系统和旧系统之间互相转换。

系统试运行阶段的主要工作：

1. 对系统进行初始化、输入各种原始数据记录。
2. 记录系统运行的数据和状况。
3. 核对新系统输出和旧系统 (人工或计算机系统) 输出的结果
4. 对实际系统的输入方式进行考察(是否方便、效率如何、安全可靠性、误操作保护等)。
5. 对系统实际运行、响应速度进行实际测试。

新旧系统转换方式：

1. 直接转换
2. 并行转换
3. 分段转换（又称逐步转换、向导转换、试点过渡法）

2、系统维护概述

（1）系统可维护性概念

系统的可维护性：维护人员理解、改正、改动和改进这个软件的难易程度。
提高可维护性是开发软件系统所有步骤的关键目的。

系统可维护性的评价指标

• 可理解性
• 可测试性
• 可修改性

维护与软件文档

文档是软件可维护性的决定因素。
软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。

软件文档的修改

维护应该针对整个软件配置，不应该只修改源程序代码。

（2）系统维护的内容及类型

系统维护主要包括硬件维护、软件维护和数据维护

硬件维护

• 一种是定期的设备保养性维护
• 另一种是突发性的故障维护

软件维护
软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部修改。内容包括：

• 正确性维护
• 适应性维护
• 完善性维护
• 预防性维护

数据维护
数据维护工作主要是由数据库管理员来负责，主要负责数据库的安全性和完整性以及进行并发性控制。

（3）系统维护的管理和步骤

1. 提出维护或修改要求
2. 领导审查并做出答复，如同意修改则列入维护计划。
3. 领导分配任务，维护人员执行修改
4. 验收维护成果并登记修改信息。

3、系统评价

（1）系统评价概述

信息系统的评价分为广义和狭义两种。
广义的信息系统评价是指从系统开发的一开始到结束的每一阶段都需要进行评价。
狭义的信息系统评价则是指在系统建成并投入运行之后所进行的全面、综合的评价。

按评价的时间与信息系统所处的阶段的关系又可从总体上把广义的信息系统评价分成：立
项评价、中期评价（里程碑式评价）和结项评价。

（2）系统评价指标

• 从信息系统的组成部分出发，信息系统是一个由人机共同组成的系统，所以可以按照运行效果和用户需求 (人)、系统质量和技术条件 (机) 这两条线索构造指标。
• 从信息系统的评价对象出发，对于开发方来说，他们所关心的是系统质量和技术水平:对于用户方而言，关心的是用户需求和运行质量:系统外部环境则主要通过社会效益指标来反映。
• 从经济学角度出发，分别按系统成本、系统效益和财务指标 3 条线索建立指标。

---

七、软件项目管理

将项目管理思想引入软件工程领域，就形成了软件项目管理。
软件项目管理是指软件生存周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预设范围内有效地利用人力、资源、技术和工具，使软件系统或软件产品按原定计划和质量要求如期完成。

1、软件项目管理涉及的范围

人员(Person)、产品(Product)、过程(Procedure)和项目 (Project)。

（1）人员 Person

人员是软件工程项目的基本要素和关键因素，可以分为以下 5 类。

• 项目管理人员
• 高级管理人员
• 开发人员
• 客户
• 最终客户

（2）产品 Product

在进行项目计划之前，应该首先进行项目定义，也就是定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等。

软件开发者和客户必须一起定义产品的目的和范围。
软件范围是通过回答下列问题来定义的：

• 项目环境
  要开发的软件如何适应于大型的系统、产品或业务环境，该环境下要施加什么约束?
• 信息目标
  软件要产生哪些客户可见的数据对象作为输出?需要什么数据对象作为输入?
• 功能和性能
  软件要执行什么功能才能将输入数据变换成输出数据? 软件需要满足什么特殊的性能要求?

（3）过程 Procedure

软件过程提供了一个项目团队要选择一个适合于待开发软件的过程模型

（4）项目 Project

进行有计划和可控制的软件项目是管理复杂性的一种方式。

• 明确目标及过程
• 保持动力
• 跟踪进展
• 做出明智的决策
• 进行事后分析

2、软件项目估算

常用的估算方法有3种：

1. 基于已经完成的类似项目进行估算
2. 基于分解技术进行估算
3. 基于经验估算模型的估算 （IBM估算模型、CoCoMo模型、Putnam模型）

（1）成本估算方法

• 自顶向下估算方法
• 自底向上估算方法
• 差别估算方法
• 其他估算方法（专家估算法、类推估算法、算式估算法）

（2）CoCoMo估算模型

COCOMO 模型是一种精确的、易于使用的成本估算模型。COCOMO 模型按其详细程度分
为基本 COCOMO 模型、中级 COCOMO 模型和详细 COCOMO 模型。

基本 COCOMO 模型

$E=a(L{)}^b$
$D=c(E{)}^d$
E表示工作量，D表示开发时间，L是项目的源代码行数估值。a、b、c、d是常数。

中级 COCOMO 模型

$E=a(L{)}^{b}EAF$
E表示工作量，EAF是调节因子，L是项目的源代码行数估值，单位是千行。a、b是常数。

详细 COCOMO 模型

它将软件系统模型分为系统、子系统和模块 3 个层次，除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响。

（3）COCOMOⅡ模型

层次结构的估算模型，被分为 3 个阶段性模型

1. 应用组装模型
2. 早期设计阶段模型
3. 体系结构阶段模型

COCOMOⅡ模型也需要使用规模估算信息，体系结构阶段，在模型层次结构中有3种不同规模估算选择，即: 对象点、功能点和代码行。应用组装模型使用的是对象点；早期设计阶段模型使用的是功能点，功能点可以转换为代码行。体系结构模型把工作量表示为代码行数。

（4）Putnam估算模型

$L=C_k{E}^{1/3}{t}_d^{4/3}$
L 表示源程序代码行数 (LOC);
$t_d$表示开发持续时间(年);
E 是包括软件开发和维护在整个生存期所花费的工作量 (人年);
$C_k$:表示技术状态常数，其值依赖于开发环境

$C_k的典型值$	开发环境	开发环境举例
2000	差	没有软件开发方法学的支持，缺少文档和评审，采用批处理方式
8000	一般	有软件开发方法学的支持，有适宜的文档和评审，采用交互式处理方式采用
11000	较好	CASE 工具和集成化 CASE 环境

3、进度管理

目的是确保软件项目在规定的时间内按期完成。

（1）进度管理的基本原则

指导软件进度安排的基本原则：

• 划分：项目必须被划分成若干可以管理的活动和任务
• 相互依赖性：划分后的各个活动或任务之间的相互依赖关系必须是明确的
• 时间分配：必须为每个被调度的任务分配一定数量的工作单位
• 工作量确认：每个项目都有预定数量的人员参与
• 确认责任：安排了进度计划的每个任务都应该指定特定的团队成员来负责。
• 明确输出结果：安排了进度计划的每个任务都应该有一个明确的输出结果。
• 确定里程碑：每个任务或任务组都应该与一个项目里程碑相关联。

（2）进度安排

为监控软件项目的进度计划和工作的实际进展情况，表示各项任务之间进度的相互依赖关系，需要采用图示的方法。在图中明确标明如下内容。

• 各个任务的计划开始时间和完成时间
• 各个任务的完成标志
• 各个任务与参与工作的人数，各个任务与工作量之间的衔接情况。
• 完成各个任务所需的物理资源和数据资源

进度安排的常用图形描述方法有 Gantt 图(甘特图)和项目计划评审技术(Program Evaluation &Review Technique，PERT) 图。

Gantt 图

Gantt图是一种简单的水平条形图，它以日历为基准描述项目任务

PERT 图

PERT 图是一个有向图，图中的箭头表示任务，它可以标上完成该任务所需的时间

4、软件项目的组织

在软件项目组织中，其组织原则：

• 尽早落实责任
• 减少交流接口
• 责权均衡

（1）组织结构的模式

根据项目的分解和过程的分解，软件项目可以有以下多种组织形式。

• 1 、按项目划分的模式
  按项目将开发人员组织成项目组，项目组的成员共同完成该项目的所有开发任务，包括项目的定义、需求分析、设计、编码、测试、评审以及所有的文档编制，甚至包括该项目的维护。

• 2、按职能划分的模式
  按软件过程中所反映的各种职能将项目的参与者组织成相应的专业组，如开发组 (可进步分为需求分析组、设计组、编码组)、测试组、质量保证组、维护组等。

• 3、矩阵模式
  这种模式是上述两种模式的组合，它既按职能组织相应的专业组，又按项目组织项目组。每个软件人员既属于某个专业组，又属于某个项目组。每个软件项目指定一个项目经理，项目中的成员根据其所属的专业组的职能承担项目的相应任务。

（2）程序设计小组的组织方式

主要是指从事软件开发活动的小组，有以下 3 种不同的组织形式

• 主程序员制小组
  主程序员制小组由一名主程序员、若干名程序员、一名后援工程师和一名资料员组成。
• 民主制小组
• 层次式小组

5、软件配置管理

软件配置管理 (Software Configure Management，SCM)用于整个软件工程过程。其主要目标是标识变更；控制变更；确保变更正确地实现；报告有关变更。

（1）基线

基线是软件生存周期中各开发阶段的一个特定点，它的作用是使各开发阶段的工作划分更加明确，使本来连续的工作在这些点上断开，以便于检查与肯定阶段成果。

（2）软件配置项

软件配置项(Software Configure Item，SCI)是软件工程中产生的信息项，它是配置管理的基本单位，对于已经成为基线的 SCI，虽然可以修改，但必须按照一个特殊的、正式的过程进行评估，确认每一处修改。以下的 SCI是 SCM的对象，并可形成基线。

• 系统规格说明书
• 软件项目实施计划
• 软件需求规格说明书
• 设计规格说明书(数据设计、体系结构设计、模块设计、接口设计、对象描述(使用面向对象技术时))
• 源代码清单
• 测试计划和过程、测试用例和测试结果记录
• 操作和安装手册
• 可执行程序 (可执行程序模块、连接模块)
• 数据库描述(模式和文件结果、初始内容)
• 用户手册
• 维护文档(软件问题报告、维护请求、工程变更次序)
• 软件工程标准
• 项目开发小结

（3）版本控制

在图中各个结点是一个完全的软件版本。软件的每一个版本都是 SCI(源代码、文档、数据)的一个汇集，而且各个版本都可能由不同的变种组成。

（4）变更控制

软件工程过程中某一阶段的变更均要引起软件配置的变更，这种变更必须严格地加以控制和管理，保持修改信息，并把精确、清晰的信息传递到软件工程过程的下一步骤。

6、风险管理

风险是指损失或伤害的可能性。一般认为软件风险包含两个特性：不确定性和损失。

风险	说明
项目风险	项目风险威胁到项目计划。项目风险是指预算、进度、人员、资源、利益相关者、需求等方面的潜在问题以及它们对软件项目的影响。项目复杂度、规模及结构不确定性也属于项目风险因素。
技术风险	技术风险威胁到要开发软件的质量及交付时间。技术风险是指设计、实现、接口、验证和维护等方面的潜在问题。此外，规格说明的歧义性、技术的不确定性、技术陈旧以及“前沿”技术也是技术风险因素。
商业风险	商业风险威胁到要开发软件的生存能力，且常常会危害到项目或产品。市场风险、策略风险、销售风险、管理风险、预算风险

（1）风险识别

风险识别试图系统化地指出对项目计划(估算、进度、资源分配等) 的威胁。
识别风险的一种方法是建立风险条目检查表。该检查表可用于风险识别，并且主要用来识别下列几种类型中的一些已知风险和可预测风险。

• 产品规模
• 商业影响
• 客户特性
• 过程定义
• 开发环境
• 开发技术
• 人员才千及经验

（2）风险预测

风险预测又称风险估计，它试图从两个方面评估一个风险: 风险发生的可能性或概率；如果风险发生了所产生的后果。

风险显露度（Risk Exposure, RE）, $RE=P\ast C$

（3）风险评估

$(r_i{l}_i{x}_i)$
其中$r_i$表示风险，$l_i$表示风险发生的概率，$x_i$表示风险产生的影响。
一种对风险评估很有用的技术就是定义风险参照水准。成本、进度和性能。

（4）风险控制

风险控制的目的是辅助项目组建立处理风险的策略。一个有效的策略必须考虑以下 3 个问题：

• 风险避免
• 风险监控
• RMMM计划（风险管理计划）

---

八、软件质量

软件质量：指反映软件系统或软件产品，满足规定或隐含需求的能力的特征和特性全体。
软件质量管理：对软件开发过程进行独立的检查活动，由质量保证、质量规划和质量控制3 个主要活动构成。

1、软件质量的特性

利用软件质量模型来描述软件质量特性，例如 ISO/IEC 9126 软件质量模型和 Mc Call 软件质量模型。

ISO/IEC 9126 软件质量模型由 3 个层次组成：第一层是质量特性，第二层是质量子特性：第三层是度量指标。

Mc Call 软件质量模型从软件产品的运行、修正和转移 3 个方面确定了 11 个质量特性。第一层是质量特性，第二层是评价准则，第三层是度量指标

2、软件质量的保证

软件质量保证是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划有组织的活动，其目的是生产高质量的软件。在软件质量方面强调以下 3 个要点：

1. 软件必须满足用户规定的需求，与用户需求不一致的软件无质量可言。
2. 软件应遵循规定标准所定义的一系列开发准则，不遵循这些准则的软件，其质量难以得到保证。
3. 软件还应满足某些隐含的需求，例如希望有好的可理解性、可维护性等，如果软件只满足它的显式需求而不满足其隐含需求，那么该软件的质量是令人质疑的

软件质量保证包括了与以下 7 个主要活动相关的各种任务：

• 应用技术方法
• 进行正式的技术评审
• 测试软件
• 标准的实施
• 控制变更
• 度量
• 记录保存和报告

3、软件评审

通常，把“质量”理解为“用户满意程度”。为了使得用户满意，有以下两个必要条件。
(1) 设计的规格说明书符合用户的要求，这称为设计质量。
(2) 程序按照设计规格说明所规定的情况正确执行，这称为程序质量。

（1）设计质量的评审内容

设计质量评审的对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明，以及在软件概要设计阶段产生的软件概要设计说明书等。通常从以下几个方面进行评审。

• 评价软件的规格说明是否合乎用户的要求
• 评审可靠性
• 评审保密措施实现情况
• 评审操作特性实施情况
• 评审性能实现情况，即是否达到所规定性能的目标值。
• 评审软件是否具有可修改性、可扩充性、可互换性和可移植性。
• 评审软件是否具有可测试性。
• 评审软件是否具有复用性。

（2）程序质量的评审内容

程序质量评审通常是从开发者的角度进行评审，与开发技术直接相关。它是着眼于软件本身的结构、与运行环境的接口以及变更带来的影响而进行的评审活动。

软件的结构如下：

• 功能结构
• 功能的通用性
• 模块的层次
• 模块结构
• 处理过程的结构

（3）与运行环境的接口

运行环境包括硬件、其他软件和用户，主要检查项目：

• 与硬件的接口
• 与用户的接口

4、软件容错技术

提高软件质量和可靠性的技术大致可分为两类，一类是避开错误；另一类是容错技术。

（1）容错软件的定义

1. 规定功能的软件，在一定程度上对自身错误的作用(软件错误) 具有屏蔽能力，则称该软件为具有容错功能的软件，即容错软件。
2. 规定功能的软件，在一定程度上能从错误状态自动恢复到正常状态，则称该软件为容错软件。
3. 规定功能的软件，在因错误发生错误时仍然能在一定程度上完成预期的功能，则称该软件为容错软件。
4. 规定功能的软件，在一定程度上具有容错能力，则称该软件为容错软件。

（2）容错的方法

实现容错的主要手段是冗余。包括结构冗余、信息冗余、时间冗余、冗余附加技术。

分类	说明
结构冗余	结构冗余是通常采用的冗余技术，按其工作方法可以分为静态、动态和混合冗余3种
信息冗余	为检测或纠正信息在运算或传输中的错误需外加一部分信息，这种现象称为信息冗余
时间冗余	时间冗余是指以重复执行指令或程序来消除瞬时错误带来的影响
冗余附加技术	为实现上述冗余技术所需的资源和技术，包括程序、指令、数据、存放和调动它们的空间和通道等

---

九、软件度量

软件度量用于对产品及开发产品的过程进行度量。

分类	定义	举例
外部属性	指面向管理者和用户的属性，体现了软件产品/软件过程与相关资源和环境的关系	如成本、效益、开发人员的生产率
内部属性	指软件产品或软件过程本身的属性	可靠性、可维护性等

1、软件度量分类

软件度量有两种分类方法：
第一种分类是将软件度量分为面向规模的度量、面向功能的度量和面向人的度量；
第二种分类是将软件度量分为生产率度量、质量度量和技术度量。

（1）面向规模的度量

面向规模的度量是通过对质量和生产率的测量进行规范化得到的，而这些量都是根据开发过的软件的规模得到的。

度量	表示及含义
LOC 或 KLOC	代码行数或千行代码数
生产率 P	P= LOC / E，E 为开发的工作量(常用人月数表示)
每行代码平均成本 C	C=S / LOC，S为总成本
文档代码比 D	D= Pe / KLOC，Pe 为文档页数
代码错误率 EOR	EOR=N / KLOC，N为代码中的错误数

（2）面向功能的度量

应用最广泛的面向功能的度量是功能点(Function Point，FP)。功能点是根据软件信息域的特性及复杂性来计算的。
信息域的值用下列方式定义。

• 外部输入数（EI）
• 外部输出数（EO）
• 外部查询数 （EQ）
• 内部逻辑文件数（ILF）
• 外部接口文件数（EIF）

利用下面的关系式计算功能点:
$Fp=总计\ast [0.65+0.01\ast \sum (F_i)]$ 其中，“总计”是所有 Fp项的总数。$F_i(i=114)$是值调整因子

2、软件复杂性度量

软件复杂性是指理解和处理软件的难易程度。软件复杂性度量的参数主要有：

• 规模。规模即总共的指令数，或源程序行数。
• 难度。通常由程序中出现的操作数的数目所决定的量来表示。
• 结构。通常用与程序结构有关的度量来表示。
• 智能度。智能度即算法的难易程度。
  软件复杂性包括程序复杂性和文档复杂性，软件复杂性主要体现在程序的复杂性中。

（1）度量原则

程序复杂性度量是软件度量的重要组成部分。

• 程序复杂性与程序大小的关系不是线性的。
• 控制结构复杂的程序较复杂。
• 数据结构复杂的程序较复杂
• 转向语句使用不当的程序较复杂。
• 循环结构比选择结构复杂，选择结构又比顺序结构复杂
• 语句、数据、子程序和模块在程序中的次序对复杂性有影响
• 全局变量、非局部变量较多时程序较复杂。
• 函数的隐式副作用相对于显式参数传递而言更加难以理解。
• 具有不同作用的变量共用一个名字时较难理解。
• 模块间、过程间联系密切的程序比较复杂
• 嵌套程度越深，程序越复杂。

（2）McCabe度量法

又称环路度量

$V(G)=m-n+2$
其中V(G)是G中的环路书，m是G中的有向弧数，n是G中的节点数。

---

十、软件工具与软件开发环境

计算机辅助软件工程（Computer Aided Software Engineerin， CASE）是指使用计算机及相关的软件工具辅助软件开发、维护、管理等过程中各项活动的实施，以确保这些活动能高效率、高质量地进行。

1、软件工具

用来辅助软件开发、运行、维护、管理和支持等过程中的活动的软件称为软件工具。

（1）软件开发工具

对应于软件开发过程的各种活动，软件开发工具通常有需求分析工具、设计工具、编码与排错工具、测试工具等。

工具	定义	分类
需求分析工具	用于辅助软件需求分析活动的软件	1、基于自然语言或图形描述的工具；2、基于形式化需求定义语言的工具
设计工具	用于辅助软件设计活动的软件	1、概要设计工具；2、详细设计工具；3、基于形式化描述的设计工具； 4、面向对象的分析与设计工具
编码和排错工具	辅助程序员进行编码活动的工具有编码工具和排错工具	1、编码工具；2、排错工具
测试工具	用于支持软件测试的工具称为测试工具	1、数据获取工具；2、静态分析工具；3、动态分析工具；4、模拟工具；5、测试管理工具

（2）软件维护工具

辅助 软件维护过程中活动 的软件称为软件维护工具。
主要有：

• 版本控制工具
• 文档分析工具
• 开发信息库工具
• 逆向工程工具
• 再工程工具

（3）软件管理工具和软件支持工具

软件管理和软件支持工具用来辅助管理人员和软件支持人员的管理活动和支持活动，以确保软件高质量地完成。
主要有：

• 项目管理工具
• 配置管理工具
• 软件评价工具

2、软件开发环境

软件开发环境：指支持软件产品开发的软件系统，它由软件工具集和环境集成机制构成。
工具集用于支持软件开发的相关过程、活动和任务；环境集成机制为工具集成和软件开发、维护和管理提供统一的支持。

环境集成机制分类

分类	说明
数据集成	为各种相互协作的工具提供统一的数据模式和数据接口规范，以实现不同工具之间的数据交换
界面集成	指环境中的工具的界面使用统一的风格，采用相同的交互方法，提供一种相似的视感效果，这样可以减少用户学习不同工具的开销
控制集成	用于支持环境中各个工具或开发活动之间的通信、切换、调度和协同工作，并支持软件开发过程的描述、执行与转换
平台集成	指在不同的硬件和系统软件之上构造用户界面一致的开发平台，并集成到统一的环境中
方法与过程集成	指把多种开发方法、过程模型及其相关工具集成在一起

软件开发环境的特征

• 环境的服务是集成的
• 环境应支持小组工作方式，并为其提供配置管理
• 环境的服务可用于支持各种软件开发活动