5.1 软件工程概述

【软件工程】是指应用计算机科学、数学及管理科学等原理,以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。P239

5.1.1 计算机软件

计算机软件是指计算机系统中的【程序】及其【文档】。P240

【程序】是计算任务的处理对象和处理规则的【描述】。P240

【文档】是为了便于了解程序所需的阐述性【资料】。P240

1.系统软件

【系统】软件是一整套服务于其他程序的【程序】。P240

2.应用软件

【应用】软件是解决【特定业务】需要的独立应用程序。P240

3.工程/科学软件

4.嵌入式软件

5.产品线软件

【产品线】软件关注有限的特定专业市场(例如库存控制产品)或大众消费品市场(例如，文字处理、多媒体、娱乐、数据库管理等)。P240

6.Web应用

7.人工智能软件

8.开放计算

9.网络资源

10.开源软件

5.1.2 软件工程基本原理

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

Boehm认为，在软件的整个生存周期中应该制定并严格执行六类计划：【项目概要计划】、【里程碑计划】、【项目控制计划】、【产品控制计划】、【验证计划】和【运行维护计划】。P242

2.坚持进行阶段评审

根据Boehm等人的统计，【设计】错误占软件错误的63%，【编码】错误仅占37%。P242

3.实现严格的产品控制

【基准】配置又称为【基线】配置，它是经过阶段评审后的软件配置成分(各个阶段产生的文档或程序代码)。P242

【基准配置管理】也称为【变动控制】，一切有关修改软件的建议，特别是涉及基准配置的修改建议，都必须按照严格的规程进行评审，在获得批准以后才能实施修改。P242

4.采用现代程序设计技术

5.结果应能清楚地审查

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

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

5.1.3 软件生存周期

【软件生存周期】包括可行性分析与项目开发计划、需求分析、设计(概要设计和详细设计)、编码、测试、维护等活动。P243

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

可行性分析与项目计划阶段的参加人员有【用户】、【项目负责人】和【系统分析师】。该阶段产生的主要文档有【可行性分析报告】和【项目开发计划】。P243

2.需求分析

需求分析阶段的参加人员有【用户】、【项目负责人】和【系统分析师】。该阶段产生的主要文档有【软件需求说明书】。P243

3.概要设计

概要设计阶段的参加人员有【系统分析师】和【软件设计师】。该阶段产生的主要文档有【概要设计说明书】。P244

4.详细设计

详细设计阶段的参加人员有【软件设计师】和【程序员】。该阶段产生的主要文档有【详细设计文档】。P244

5.编码

6.测试

【测试】是保证【软件质量】的重要手段，其主要方式是在设计【测试用例】的基础上检查软件的各个组成部分。P244

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

7.维护

软件【维护】是软件生存周期中时间最长的阶段。P244

5.1.4 软件过程

【过程】是【活动】的集合。P245

【活动】是【任务】的集合。P245

软件过程有3层含义：一个是【个体】含义，即指软件产品或系统在生存周期中的某一类活动的集合，如软件开发过程、软件管理过程等；二是【整体】含义，即指软件产品或系统在所有上述含义下的软件过程的总体；三是【工程】含义，即指解决软件过程的工程，应用软件的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行实例化，以及在用户环境下的运作，以此进一步提高软件的生产率，降低成本。P245

1.能力成熟度模型(CMM)

2.能力成熟度模型集成(CMMI)

CMMI提供了两种表示方法：【阶段式】模型和【连续式】模型。P246

1）阶段式模型

2）连续式模型

5.2 软件过程模型

【软件过程模型】习惯上也称为【软件开发模型】，它是软件开发全部过程、活动和任务的【结构框架】。P247

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

5.2.1 瀑布模型(Waterfall Model)

【瀑布】模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括【需求分析】、【设计】、【编码】、【测试】、【运行与维护】。P248

瀑布模型的一个变体是【V模型】，描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。P248

5.2.2 增量模型(Incremental Model)

【增量模型】融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。P249

5.2.3 演化模型(Evolutionary Model)

1.原型模型(Prototype Model)

2.螺旋模型(Spiral Model)

5.2.4 喷泉模型(Water Fountain Model)

【喷泉】模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。P252

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

一种基于构建的开发模型，包括【领域工程】和【应用系统工程】两部分。P252

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

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

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

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

5.2.7 统一过程(UP)模型

统一过程模型是一种“【用例】和【风险】驱动，以【架构】为中心，【迭代】并且【增量】”的开发过程，由UML方法和工具支持。P253

【统一过程】定义了4个技术阶段及其制品：【起始】阶段(Inception Phase)、【精化】阶段(Elaboration Phase)、【构建】阶段(Construction Phase)、【移交】阶段(Transition Phase)。P254

统一过程的典型代表是【RUP】。P254

【RUP】是UP的商业扩展，完全兼容UP,但比UP更完整、更详细。P254

5.2.8 敏捷方法(Agile Development)

1.极限编程(XP)

【XP】由【价值观】、【原则】、【实践】和【行为】4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。P255

XP的4大价值观：【沟通】、【简单性】、【反馈】和【勇气】。P255

XP的5个原则：【快速反馈】、【简单性假设】、【逐步修改】、【提倡更改】和【优质工作】。P255

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

2.水晶法(Crystal)

3.并列争求法(Scrum)

4.自适应软件开发(ASD)

5.敏捷统一过程(AUP)

5.3 需求分析

5.3.1 软件需求

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

需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。P256

5.3.2 需求分析原则

5.3.3 需求工程

【需求工程】是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。P257

【需求工程】可以细分为【需求获取】、【需求分析与协商】、【系统建模】、【需求规约】、【需求验证】以及【需求管理】6个阶段。P257

1.需求获取

2.需求分析与协商

3.系统建模

分析方法有两种：面向数据流的结构化分析方法(【SA】)、面向对象的分析方法(【OOA】)。P258

4.需求规约

【需求规约】是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。P259

需求规约中通常包含以下内容：【引言】、【信息描述】、【功能描述】、【行为描述】、【检验标准】、【参考书目】、【附录】。P259

5.需求验证

【需求验证】作为需求开发阶段工作的复查手段，其目的是要检验需求功能的正确性、完整性和清晰性。P259

6.需求管理

【需求管理】是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动，对需求工程所有相关活动的规划和控制。P260

【需求管理】就是一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。P260

5.4 系统设计

【系统设计】的主要目的就是为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方案。P261

【系统设计】的主要内容包括新系统总体结构设计、代码设计、输出设计、输入设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。P261

系统设计方法有以下两种：面向数据流的结构化设计方法(【SD】)、面向对象的分析方法(【OOD】)。P261

系统设计的基本任务大体上可以分为【概要设计】和【详细设计】两个步骤。P261

5.4.1 概要设计

1）设计软件系统总体结构

2）数据结构及数据库设计

3）编写概要设计文档

概要设计的文档主要有【概要设计说明书】、【数据库设计说明书】、【用户手册】以及【修订测试计划】。P261

4）评审

5.4.2 详细设计

详细设计的文档有【详细设计说明书】。P262

5.5 系统测试

5.5.1 系统测试与调试

1.系统测试的意义、目的及原则

2.测试过程

5.5.2 传统软件的测试策略

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

1.单元测试

1）单元测试的测试内容

2）单元测试过程

2.集成测试

【集成】测试就是把模块按系统设计说明书的要求【组合】起来进行测试。P266

集成测试有两种方法：一种是【非增量】集成，另一种是【增量】集成。P266

1）自顶向下集成测试

2）自底向上集成测试

3）回归测试

【回归】测试有助于保证变更不引入无意识行为或额外的错误。P268

4）冒烟测试

3.确认测试

1）确认测试准则

2）配置评审

【确认】过程的一个重要成分是配置评审，主要是检查软件(源程序、目标程序)、文档(包括面向开发和用户的文档)和数据(程序内部的数据或程序外部的数据)是否齐全以及分类是否有序。P269

3）α测试与β测试

4.系统测试

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

1）恢复测试

2）安全性测试

3）压力测试

4）性能测试

5）部署测试

5.5.3 测试面向对象软件

1.单元测试

2.集成测试

5.5.4 测试Web应用

1.质量维度

评估和测试都要检查下面质量维度中的一项或多项：【内容】、【功能】、【结构】、【可用性】、【导航性】、【性能】、【兼容性】、【安全性】。P272

2. WebApp测试策略

【WebApp】测试策略采用所有软件测试使用的基本原理，并建议使用面向对象系统使用的策略和战术。P273

5.5.5 测试方法

软件测试方法分为【静态】测试和【动态】测试。P273

【静态】测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。P273

【动态】测试是指通过运行程序发现错误。在对软件产品进行动态测试时可以采用【黑盒】测试法和【白盒】测试法。P273

【测试用例】由测试输入数据和与之对应的预期输出结果组成。P273

1.黑盒测试

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

常用的黑盒测试技术有【等价类划分】、【边界值分析】、【错误推测】和【因果图】等。P274

等价类划分有两种不同的情况：【有效】等价类和【无效】等价类。P274

2.白盒测试

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

【白盒】测试常用的技术是【逻辑覆盖】、【循环覆盖】和【基本路径测试】。P275

5.5.6 调试

【调试】发生在测试之后，其任务是根据测试时所发现的错误找出原因和具体的位置，进行改正。P276

1.调试过程

2.调试方法

常用的【调试】方法有以下几种：【试探】法、【回溯】法、【对分查找】法、【归纳】法、【演绎】法。P277

5.6 运行和维护知识

5.6.1 系统转换

新旧系统之间的转换方式有【直接】转换、【并行】转换和【分段】转换。P278

【直接】转换就是在确定新系统运行无误时立刻启用新系统，终止旧系统运行。P278

【并行】转换方式是新旧系统并行工作一段时间，经过一段时间的考验以后，新系统正式替代旧系统。P278

【分段】转换又称【逐步】转换、【向导】转换、【试点过渡法】等。P279

【分段】转换方式实际上是直接转换和并行转换的结合。P279

5.6.2 系统维护概述

1.系统可维护性概念

系统的【可维护性】可以定义为维护人员理解、改正、改动和改进这个软件的难易程度。P279

1）系统可维护性的评价指标

系统可维护性的评价指标：可【理解】性、可【测试】性、可【修改】性。P280

2）维护与软件文档

【文档】是软件可维护性的决定因素。P280

软件系统的文档可以分为【用户】文档和【系统】文档两类。P280

【用户】文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的。P280

【系统】文档描述系统设计、实现和测试等各方面的内容。P280

3）软件文档的修改

2.系统维护的内容及类型

系统维护主要包括【硬件】维护、【软件】维护和【数据】维护。P280

1）硬件维护

【硬件】维护应由专职的硬件维护人员来负责。P280

2）软件维护

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

软件维护的内容一般有以下几个方面：【正确】性维护、【适应】性维护、【完善】性维护、【预防】性维护。P281

3）数据维护

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

3.系统维护的管理和步骤

5.6.3 系统评价

1.系统平均的概述

信息系统的评价分为【广义】和【狭义】两种。P283

【广义】的信息系统评价是指从系统开发的一开始到结束的每一阶段都需要进行评价。P283

【狭义】的信息系统评价则是指在系统建成并投入运行之后所进行的全面、综合的评价。P283

按评价的时间与信息系统所处的阶段的关系又可从总体上把广义的信息系统评价分成【立项】评价、【中期】评价和【结项】评价。P283

2.系统评价的指标

5.7 软件项目管理

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

5.7.1 软件项目管理涉及的范围

有效的软件项目管理集中在4个P上，即【人员】(【Person】)、【产品】(【Product】)、【过程】(【Procedure】)和【项目】(【Project】)。P284

1.人员

【人员】是软件工程项目的基本要素和关键因素。P285

人员可以分为5类：【项目管理】人员、【高级管理】人员、【开发】人员、【客户】、【最终用户】。P285

2.产品

软件范围是通过回答下列问题来定义的：【项目环境】、【信息目标】、【功能和性能】。P285

3.过程

4.项目

1) 明确目标及过程

2) 保持动力

3) 跟踪进展

4) 做出明智的决策

5) 进行事后分析

5.7.2 软件项目估算

1.成本估算方法

1) 自顶向下估算方法

2) 自底向上估算方法

3) 差别估算方法

4) 其他估算方法

专家估算法、类推估算法和算式估算法等。

2.COCOMO估算模型

【COCOMO】模型是一种精确的、易于使用的成本估算模型。P288

COCOMO模型按其详细程度分为【基本】COCOMO模型、【中级】COCOMO模型和【详细】COCOMO模型。P288

1) 基本COCOMO模型

2) 中级COCOMO模型

3) 详细COCOMO模型

3.COCOMOⅡ模型

4.Putnam估算模型

5.7.3 进度管理

软件项目【进度管理】的目的是确保软件项目在规定的时间内按期完成。P289

1.进度管理的基本原则

2.进度安排

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

1）Gantt图

2）PERT图

5.7.4 软件项目的组织

1.组织结构的模式

1) 按项目划分的模式

2) 按职能划分的模式

3) 矩阵模式

2.程序设计小组的组织方式

1）主程序员制小组

2）民主制小组

3）层次式小组

5.7.5 软件配置管理

【软件配置管理】(Software Configure Management,【SCM】)用于整个软件工程过程。P294

1.基线

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

2.软件配置项

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

3.版本控制

4.变更控制

配置数据库可以分为三类：【开发】库、【受控】库、【产品】库。P296

5.7.6 风险管理

5个主要的商业风险如下：【市场】风险、【策略】风险、【销售】风险、【管理】风险、【预算】风险。P296

1.风险识别

【风险识别】试图系统化地指出对项目计划(估算、进度、资源分配等)的威胁。P297

风险因素以如下方式定义：【性能】风险、【成本】风险、【支持】风险、【进度】风险。P297

2.风险预测

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

1) 风险预测活动

2) 评估风险影响

3.风险评估

4.风险控制

【风险控制】的目的是辅助项目组建立处理风险的策略。P299

1) 风险避免

2) 风险监控

3) RMMM计划

5.8 软件质量

5.8.1 软件质量特性

1）ISO/IEC 9126软件质量模型

2) Mc Call软件质量模型

5.8.2 软件质量保证

5.8.3 软件评审

1) 设计质量的评审内容

2) 程序质量的评审内容

3) 与运行环境的接口

5.8.4 软件容错技术

1) 容错软件的定义

2) 容错的一般方法

冗余技术分为4类：【结构】冗余、【信息】冗余、【时间】冗余、【冗余附加】技术。P306

【结构】冗余是通常采用的冗余技术，按其工作方法可以分为【静态】、【动态】和【混合】冗余3种。P306

5.9 软件度量

5.9.1 软件度量分类

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

1.面向规模的度量

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

2.面向功能的度量

面向【功能】的度量以功能(由应用程序提供)测量数据作为规范化值。P308

信息域的值用下列方式定义：外部输入数(【EI】)、外部输出数(【EO】)、外部查询数(【EQ】)、内部逻辑文件数(【ILF】)、外部接口文件数(【EIF】)。P308

5.9.2 软件复杂性度量

软件【复杂性】是指理解和处理软件的难易程度。P309

软件复杂性度量的参数很多，主要有以下几个：【规模】、【难度】、【结构】、【智能度】。P309

软件复杂性包括【程序】复杂性和【文档】复杂性，软件复杂性主要体现在【程序】的复杂性中。P309

1.程序复杂性度量原则

2.McCabe度量法

【McCabe】度量法是由Thomas McCabe提出的一种基于程序控制流的复杂性度量方法。P310

5.10 软件工具与软件开发环境

5.10.1 软件工具

1.软件开发工具

软件开发工具通常有【需求分析】工具、【设计】工具、【编码与排错】工具、【测试】工具等。P311

测试工具分为【数据获取】工具、【静态分析】工具、【动态分析】工具、【模拟】工具以及【测试管理】工具。P312

2.软件维护工具

【软件维护】工具主要有【版本控制】工具、【文档分析】工具、【开发信息库】工具、【逆向工程】工具和【再工程】工具。P312

3.软件管理和软件支持工具

软件管理和软件支持工具，其中常用的工具有【项目管理】工具、【配置管理】工具和【软件评价】工具。P312

5.10.2 软件开发环境

【软件开发环境】(Soffware Development Environment)指支持软件产品开发的软件系统，它由软件工具集和环境集成机制构成。P313