软件工程基础知识【软考】

计算机技术与软件专业技术资格（水平）考试目录

一、 软件工程概述

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

1. 计算机软件

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

（1）系统软件

  是一整套服务于其他程序的程序，系统软件多具有以下特点：和计算机硬件大量交互；多用户大量使用；需要调度、资源共享和复杂进程管理的同步操作；复杂的数据结构以及多种外部接口。

（2）应用软件

  是解决特定业务需要的独立应用程序。

（3）工程/科学软件

  涵盖了广泛的应用领域，当今科学工程领域的应用软件已经呈现出实时性甚至具有系统软件的特性，这类软件通常带有"数值计算"算法的特征。

（4）嵌入式软件

  存在于某个产品或系统中，可实现和控制面向最终使用者和系统本身的特性和功能。

（5）产品线软件

  关注有限的特定专业市场或大众消费品市场，产品为多个不同用户的使用提供特定功能。

（6）Web 应用

  一类以网络为中心的软件，其概念涵盖了宽泛的应用程序产品。绝大多数 WebApp 具备网络密集性、并发性、无法预知的负载量、性能、可用性和数据驱动属性。

（7）人工智能软件

  利用非数值算法解决计算和直接分析无法解决的复杂问题。

（8）开放计算机

  无线网络的快速发展将促成真正的普适计算、分布式计算的实现。

（9）网络资源

  万维网已经快速发展为一个计算引擎和内容提供平台，软件工程师面临的新任务是构建一个简单而智能的应用程序，为全世界的最终用户市场提供服务。

（10）开源软件

  开放系统应用程序的代码，使得很多人能够为软件开发做贡献，这种方式正在逐步成为一种趋势。

2. 软件工程基本原理

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

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

（2）坚持进行阶段评审

  在每个阶段都应进行严格的评审，以便尽早发现在软件开发过程中所犯的错误。

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

  在软件开发过程中不应随意改变需求，因为改变一项需求需要付出较高的代价。要采用科学的产品控制技术来顺应这种要求。在改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置【又称为基线配置，它是经过阶段评审后的软件配置成分；也称为变动控制，一切有关修改软件的建议，特别是涉及基准配置的修改建议，都必须按照严格的规程进行评审，在获得批准以后才能实施修改】

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

  方法大于力气，采用先进的技术既可以提高软件开发的效率，又可以降低软件维护的成本。

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

  应根据软件开发的总目标及完成期限尽量明确地规定开发小组的责任和产品标准，从而使所得到的结果能够清楚地审查。

（6）开发小组成员应小而精

  开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。
  这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少得多；当开发小组为 $N$ 人时，可能的通信信道为 $N(N-1)/2$ 。可见，随着人数 $N$ 的增大，通信开销将急剧增大。

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

  用户不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术.

3. 软件生存周期

  一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡的许多阶段，一般称为软件生存周期。把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大、结构复杂和管理复杂的软件的开发变得容易控制和管理。

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

  主要确定软件的开发目标及其可行性。
  参加人员：用户、项目负责人和系统分析师。主要文档：可行性分析报告和项目开发计划。

（2）需求分析

  任务：准确地确定软件系统必须做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。
  参加人员：用户、项目负责人和系统分析师。主要文档：软件需求说明书。

（3）概要设计

  概要设计就是设计软件的结构，开发人员要把确定的各项功能需求转换成需要的体系结构，即每个模块都和某些功能需求相对应。同时，还要设计该项目的应用系统的总体数据结构和数据库结构。
  参加人员：系统分析师和软件设计师。主要文档：概要设计说明书。

（4）详细设计

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

（5）编码

  把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的源程序清单。

（6）测试

  保证软件质量的重要手段，主要方式：在设计测试用例的基础上检查软件的各个组成部分。
  `参加人员：通常是另一部门(或单位)的软件设计师或系统分析师。主要文档：软件测试计划、测试用例和软件测试报告。

（7）维护

  是软件生存周期中时间最长的阶段，已交付的软件投入正式使用后，便进入软件维护阶段。

4. 软件过程

  在开发产品或构建系统时，遵循一系列可预测的步骤是非常重要的，它有助于及时交付高质量的产品。软件开发中所遵循的路线图称为“软件过程”，过程是活动的集合，活动是任务的集合。软件过程的 $3$ 层含义：

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

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

  是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高，CMM将软件过程改进分为以下5个成熟度级别：

• 初始级（Initial）
    软件过程的特点：杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤。项目的成功完全依赖个人的努力和英雄式核心人物的作用。
• 可重复级（Repeatable）
    建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
• 已定义级（Defined）
    管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。
• 已管理级（Managed）
    制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。
• 优化级（Optimized）
    加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

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

  是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率，CMMI提供了两种表示方法：

• 阶段式模型
    结构类似于CMM，它关注组织的成熟度：初始的【过程不可预测且缺乏控制】、已管理的【过程为项目服务】、已定义的【过程为组织服务】、定量管理的【过程已度量和控制】、优化的【集中于过程改进】
• 连续式模型
    关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级，包括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）

  将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。为软件的开发和维护提供了一种有效的管理模式，根据这一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导。
  以文档作为驱动、适合于软件需求很明确或者二次开发（需求稳定）的项目。

2. V模型

  是瀑布模型的一个变体。该模型极为强调测试的作用，测试始终贯穿流程的始终。优点【容易理解、管理成本低、强调开发的阶段性早期计划及需求调查和产品测试】，缺点【客户必须能够完整、正确和清晰地表达他们的需要】

3. 增量模型（Incremental Model）

  融合了瀑布模型的基本成分和原型实现的迭代特征，是一种递增式设计，将产品一步一步进行设计，每完成一步就交由客户审视，这样也可以使得下一步的设计更为明确，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级高的服务最先交付。
  增量模型的每一次增量版本都可作为独立操作的作品。

4. 演化模型（Evolutionary Model）

  是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本,演化模型特别适用于对软件需求缺乏准确认识的情况。

（1）原型模型（Prototype Model）

  比较适合于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法比较好，目的是定义软件的总体目标，标识需求，然后快速制订原型开发的计划。
  原型和瀑布模型是互补关系，原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。

  根据使用原型的目的不同，原型可以分为：探索型原型【目的是要弄清目标的要求】、实验型原型【目的是验证方案或算法的合理性】和演化型原型【目的是将原型作为目标系统的一部分】。

（2）螺旋模型（Spiral Model）

  综合了瀑布模型和演化模型的优点，是多种模型的混合，针对需求不明确的项目，与原型相似，还增加了风险分析，螺旋模型包含四个方面的活动：制定计划、风险分析(是螺旋模型最为显著的特征)、实施工程、客户评估。
  强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，从而做出应有的反应，特别适用于庞大、复杂并且具有高风险的系统。

5. 喷泉模型（Water Fountain Model）

• 喷泉模型
    是一种以用户需求为动力，以对象作为驱动的模型。适用于面向对象的开发方法是开发过程，具有迭代性和无间隙性，它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。
  
• RAD模型
    该模型最大的特点是能够快速构建业务系统，包括：业务建模、数据建模、过程建模、应用生成、测试与交付。
  

7. 构件组装模型（CBSD）

  将软件开发过程中的各个模块都做成构件，最后再将构件进行组装，基于构件的软件开发，主要强调在构建软件系统时复用已有的软件“构件”，在检索到可以使用的构件后，需要针对新系统的需求对构件进行合格性检验适应性修改，然后集成到新系统中。
  优点：极大的提高了软件开发当中的复用性，缩短时间、节省成本、增强可靠性。

7. 基于构件的开发模型（Component-based Development Model）

  指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品（Commercial Off-The-Shelf，COTS）软件构件。
  具有许多螺旋模型的特点，它本质上是演化模型，需要以迭代方式构建软件。其不同之处在于，基于构件的开发模型采用预先打包的软件构件开发应用系统。
  一种基于构建的开发模型包括领域工程【目的是构建领域模型、领域基准体系结构和可复用构件库】和应用系统工程【目的是使用可复用构件组装应用系统】两部分。

8. 形式化方法模型（Formal Methods Model）

  建立在严格数学基础上的一种软件开发方法，其主要活动是生成计算机软件形式化的数学规格说明。
  形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的歧义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能。

9. 统一过程（UP）模型

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

• 起始阶段（Inception Phase）
    专注于项目的初创活动。
• 精化阶段（Elaboration Phase）
    在理解了最初的领域范围之后进行需求分析和架构演进。
• 构建阶段（Construction Phase）
    关注系统的构建，产生实现模型。
• 移交阶段（Transition Phase）
    关注软件提交方面的工作，产生软件增量。

  每次迭代产生包括最终系统的部分完成的版本和任何相关的项目文档的基线，通过逐步迭代基线之间相互构建，直到完成最终系统。随着UP的阶段进展，每个核心工作流的工作量发生了变化，$4$ 个技术阶段由主要里程碑所终止：

• 初始阶段：生命周期目标。
• 精化阶段：生命周期架构。
  构建阶段：初始运作功能。
• 移交阶段：产品发布。

10. 敏捷方法（Agile Development）

  总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意，通过在软件开发过程中加入灵活性，使用户能够在开发周期的后期增加或改变需求。
  基本原则：短平快的会议、小型版本发布、较少的文档、合作为重、客户直接参与、自动化测试、适应性计划调整、结对编程、测试驱动开发、持续集成、重构。
  不是一个模型，而是一组有着共同价值观的。局限性 ：一般只做小型项目，大型就力不从心。

（1）极限编程（XP）

  一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。
  $4$ 大价值观：沟通、简单性、反馈和勇气。
  $5$个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
  $12$个最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结队编程、集体代码所有制、持续集成、每周工作40个小时、现场客户和编码标准。

（2）水晶法（Crystal）

  每一个不同的项目都需要一套不同的策略、约定和方法论。

（3）并列争求法（Scrum）

  使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品，多个自组织和自治的小组并行地递增实现产品。

（4）自适应软件开发（ASD）

  强调开发方法的适应性，有 $6$ 个基本的原则：有一个使命作为指导；特征被视为客户价值的关键点；过程中的等待是很重要的，因此“重做”与“做”同样关键；变化不被视为改正，而是被视为对软件开发实际情况的调整；确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；风险。

（5）敏捷统一过程（Agile Unified Process，AUP）

  采用“在大型上连续，在小型上迭代”的原理来构建软件系统。采用经典的 UP 阶段性活动（初始、精化、构建和转换），提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。

（6）特性驱动开发

  一套针对中小型软件开发项目的开发模式，是一个模型驱动的快速迭代开发过程，它强调的是简化，使用，易被开发团队接受，适用于需求经常变动的项目。

11. 信息系统开发方法

  该类方法包括四种：结构化法【典型代表是瀑布模型】、原型法【典型代表是原型和演化模型】、面向对象方法【目前应用最广的方法】、面向服务方法【尚处于摸索阶段】。

三、 需求分析

1. 软件需求

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

• 功能需求：考虑系统要做什么，在何时做，在何时以及如何修改或升级。
• 性能需求：考虑软件开发的技术性指标。
• 用户或人的因素：考虑用户的类型。
• 环境需求：考虑未来软件应用的环境，包括硬件和软件。
• 界面需求：考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定，对数据存储介质的规定。
• 文档需求：考虑需要哪些文档，文档针对哪些读者。
• 数据需求：考虑输入、输出数据的格式，接收、发送数据的频率，数据的准确性和精度，数据流量，数据需保持的时间。
• 资源使用需求：考虑软件运行时所需要的数据、其他软件、内存空间等资源；软件开发、维护所需的人力、支撑软件、开发设备等。
• 安全保密要求：考虑是否需要对访问系统或系统信息加以控制，隔离用户数据的方法，用户程序如何与其他程序和操作系统隔离以及系统备份要求等。
• 可靠性要求：考虑系统的可靠性要求，系统是否必须检测和隔离错误；出错后，重启系统允许的时间等。
• 软件成本消耗与开发进度需求：考虑开发是否有规定的时间表，软/硬件投资有无限制等。
• 其他非功能性要求：如采用某种开发模式，确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以及可维护性方面的要求。
  

2. 需求分析原则

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

3. 需求工程

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

（1）需求获取

  系统分析人员通过与用户的交流、对现有系统的观察以及对任务进行分析确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为更好地定义需求而开发的原型。
  需求获取的工作产品为进行需求分析提供了基础。

（2）需求分析与协商

  对需求进行分类组织，分析每个需求与其他需求的关系，以检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。

（3）系统建模

  可以通过合适的工具和符号系统地描述需求，常用的分析方法有：面向数据流的结构化分析方法（SA）、面向对象的分析方法（OOA）。

（4）需求规约

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

（5）需求验证

  作为需求开发阶段工作的复查手段，其目的是要检验需求功能的正确性、完整性和清晰性，是否能够反映用户的意愿，由于需求的变化往往使系统的设计和实现也跟着改变，所以由需求问题引起系统变更的成本比修改设计或代码错误的成本高得多。
  需求验证也不可能发现所有的需求问题。在需求验证之后，对遗漏的补充以及对错误理解的更正是不可避免的，因此需要进行需求管理。

（6）需求管理

  是一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。在需求管理中，每个需求被赋予唯一的标识符，一旦标识出需求，就可以为需求建立跟踪表，每个跟踪表标识需求与其他需求或设计文档、代码、测试用例的不同版本间的关系。

四、 系统设计

  主要目的就是为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方案。
  主要内容包括：新系统总体结构设计、代码设计、输出设计、输入设计、处理过程设计、数据存储设计、用户界面设计和安全控制设计等。
  常用的设计方法有：面向数据流的结构化设计方法（SD）、面向对象的分析方法（OOD）。
  结果是一系列的系统设计文件，这些文件是物理实现一个信息系统（包括硬件设备和编制软件程序）的重要基础。

1. 概要设计

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

  基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。
  是概要设计关键的一步，直接影响到下一个阶段详细设计与编码的工作，软件系统的质量及一些整体特性都在软件系统总体结构的设计中决定。

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

• 数据结构的设计
    逐步细化的方法也适用于数据结构的设计，在概要设计阶段要加以细化需求分析阶段的内容，详细设计阶段则规定具体的实现细节。在概要设计阶段，宜使用抽象的数据类型。
• 数据库的设计
    指数据存储文件的设计，主要进行以下几方面设计：
    ① 概念设计：在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用 E-R 模型【既是设计数据库的基础，也是设计数据结构的基础】来表述数据模型。
    ②逻辑设计：要结合具体的数据库管理系统（DBMS）特征来建立数据库的逻辑结构。
    ③物理设计：设计数据模式的一些物理细节。
• 编写概要设计文档
    主要有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。
• 评审
    对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等进行评审。

2. 详细设计

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

五、 系统测试

1. 系统测试与调试

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

  为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。
  目的：希望能以最少的人力和时间发现潜在的各种错误和缺陷。
系统测试是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析、系统设计和实施的最后复查。根据测试的概念和目的，在进行信息系统测试时应遵循以下基本原则：

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

（2）测试过程

  测试是开发过程中的一个独立且非常重要的阶段，测试过程基本上与开发过程平行进行。

• 制订测试计划
• 编制测试大纲
• 根据测试大纲设计和生成测试用例，产生测试设计说明文档
• 实施测试
• 生成测试报告

2. 传统软件的测试策略

  将软件测试用例的设计方法集成到一系列经过周密计划的步骤中，从而使软件构造成功地完成。
  软件测试策略应该具有足够的灵活性，以便促进测试方法的制定。同时，它必须足够严格，以便在项目进行过程中对项目进行合理地策划和追踪管理。

（1）单元测试

  也称模块测试，在模块编写完成且无编译错误后就可以进行，侧重于模块中的内部处理逻辑和数据结构。如果选用机器测试，一般用白盒测试法。这类测试可以对多个模块同时进行。

（2）集成测试

  把模块按系统设计说明书的要求组合起来进行测试。
  通常，集成测试有两种方法：非增量集成【分别测试各个模块，再把这些模块组合起来进行整体测试】，增量集成【以小增量的方式逐步进行构造和测试非增量式集成可以对模块进行并行测试，能充分利用人力，并加快工程进度】

• 自顶向下集成测试
    是一种构造软件体系结构的增量方法。模块的集成顺序为从主控模块（主程序）开始，沿着控制层次逐步向下，以深度优先或广度优先的方式将从属于（或间接从属于）主控模块的模块集成到结构中。
• 自底向上集成测试
    从原子模块（程序结构的最底层构件）开始进行构造和测试。由于构件是自底向上集成的，在处理时所需要的从属于给定层次的模块总是存在的，因此，没有必要使用桩模块。
• 回归测试
    每当加入一个新模块作为集成测试的一部分时，软件发生变更，建立了新的数据流路径，可能出现新的I/O，以及调用新的控制逻辑。
    回归测试有助于保证变更不引入无意识行为或额外的错误。
• 冒烟测试
    当开发软件产品时，冒烟测试是一种常用的集成测试方法，是时间关键项目的决定性机制，它让软件团队频繁地对项目进行评估。
  

（3）确认测试

  始于集成测试的结束，在进行确认测试或系统级测试时，传统软件、面向对象软件及WebApp之间的差别已经消失，测试集中于用户可见的动作和用户可识别的系统输出。

• 确认测试准则
    通过一系列表明与软件需求相符合的测试而获得的。
• 配置评审
    确认过程的一个重要成分，主要是检查软件、文档是否齐全以及分类是否有序。确保文档、资料的正确和完善，以便维护阶段使用。
• $\alpha$ 测试与 $\beta$ 测试
    $\alpha$ 测试：由有代表性的最终用户在开发者的场所进行。软件在自然的环境下使用，开发者
  站在用户的后面观看，并记录错误和使用问题，在受控的环境下进行。
    $\beta$测试：在一个或多个最终用户场所执行，在不被开发者控制的环境下软件的"现场"应用。
    客户验收测试： $\beta$ 测试的一种变体，有时是按照合同交付给客户时进行的。某些情况下，验收测试可能是非常正式的，可能会测试很多天，甚至几个星期。

（4）系统测试

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

• 恢复测试
    是一种系统测试，通过各种方式强制地让系统发生故障，并验证能否按照要求从故障中恢复过来，并在约定的时间内开始事务处理，而且不对系统造成任何伤害。
• 安全性测试
    安全性测试验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。
• 压力测试
    要求以非正常的数量、频率或容量等方式执行系统。
• 敏感性测试
    压力测试的一个变体，试图在有效输入类中发现会引发系统不稳定或错误处理的数据组合。
• 性能测试
    经常与压力测试一起进行，且常需要硬件和软件工具，通过检测系统，测试人员可以发现导致效率降低或系统故障的情形。
• 部署测试
    也称为配置测试，是在软件将要运行的每一种环境中测试软件。

3. 测试面向对象软件

  基本目标：在现实的时间范围内利用可控的工作量找出尽可能多的错误，但是其本质特征的不同使得测试策略和技术也发生了变化。

• 单元测试
    封装的类常是单元测试的重点，面向对象软件的类测试是由封装在该类中的操作和类的状态行为驱动的。
• 集成测试
    由于面向对象软件没有明显的层次控制结构，因此面向对象环境中的集成测试有两种策略：基于线程的测试【对响应系统的一个输入或事件所需的一组类进行集成，每个线程单独地集成和测试，并应用回归测试以确保没有产生副作用】、基于使用的测试【通过测试很少使用服务类的那些类开始系统的构建】

4. 测试Web应用

  与很多不同的操作系统、浏览器（位于很多不同的设备上）、硬件平台、通信协议及“暗中的”应用系统进行交互作用，错误的查找是一个重大的挑战。

（1）质量维度

  良好的设计应该将质量集成到Web应用中，通过对设计模型中的不同元素进行一系列技术评审，对质量进行评估。评估和测试都要检查质量维度中的一项或多项：

• 内容：在语法及语义层对内容进行评估
• 功能：发现与客户需求不一致的错误
• 结构：保证它正确地表示 WebApp 的内容及功能，是可扩展的，并支持新内容、新功能的增加
• 可用性：对保证接口支持各种类型的用户，各种用户都能够学会及使用所有需要的导航语法及语义
• 导航性：保证检查所有的导航语法及语义，发现任何导航错误
• 性能：保证系统响应用户的交互并处理极端的负载情况，而且没有出现操作上不可接受的性能降低
• 兼容性：目的是发现对特定主机配置的错误
• 安全性：通过评定可能存在的弱点试图对每个弱点进行攻击

（2）WebApp测试策略

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

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

5. 测试方法

（1）静态测试

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

• 人工检测
    不依靠计算机而是依靠人工审查程序或评审软件，包括代码检查、静态结构分析和代码质量度量等。
• 计算机辅助静态分析
    利用静态分析工具对被测试程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。

（2）动态测试

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

① 黑盒测试

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

• 等价类划分
    将程序的输入域划分为若干等价类，然后从每个等价类中选取一个代表性数据作为测试用例。
• 边界值分析
    需要对等价类之间的边界值进行测试（一般是端点、略小于端点的值、略大于端点的值），用边界值分析来补充等价类划分，其测试用例，既注重于输入条件边界，又适用于输出域测试用例。
• 错误推测
    是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法，即自己推测错误的原因，该方法强调经验。
    基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
• 因果图
    从自然语言描述的程序规格说明中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。

②白盒测试

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

• 逻辑覆盖：考察用测试数据运行被测程序时对程序逻辑的覆盖程度。

  A. 语句覆盖：选择足够的测试数据，使被测试程序中的每条语句至少执行一次，覆盖很低。

  B. 判定覆盖：也称分支覆盖，设计足够的测试用例，使得被测程序中的每个判定表达式至少获得一次“真"值和“假”值，比语句覆盖更强一些。

  C. 条件覆盖：构造一组测试用例，使得每一判定语句中每个逻辑条件的各种可能的值至少满足一次。

  D. 判定/条件覆盖：设计足够的测试用例，使得判定中每个条件的所有可能取值（真/假）至少出现一次，并使每个判定本身的判定结果（真/假）也至少出现一次。

  E. 条件组合覆盖：指设计足够的测试用例，使得每个判定中条件的各种可能值的组合都至少出现一次。满足条件组合覆盖的测试用例是一定满足判定覆盖、条件覆盖和判定/条件覆盖的。

  F. 路径覆盖：指覆盖被测试程序中所有可能的路径。

• 循环覆盖：执行足够的测试用例，使得循环中的每个条件都得到验证。
• 基本路径测试：在程序控制流图的基础上通过分析控制流图的环路复杂性，导出基本可执行路径集合，从而设计测试用例。

6. 调试

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

（1）调试过程

  执行测试用例，对测试结果进行评估，当期望的表现与实际表现不一致时，调试过程就开始了。调试试图找到隐藏在症状背后的原因，从而使错误得到修正。
  调试过程通常得到以下两种结果之一：发现问题的原因并将其改、未能找到问题的原因。

（2）调试方法

• 试探法
    利用在程序中设置输出语句，分析寄存器、存储器的内容等手段获得错误的线索，一步步地试探和分析出错误所在。
    效率很低，适合于结构比较简单的程序。
• 回溯法
    从发现错误症状的位置开始，人工沿着程序的控制流程往回跟踪代码，直到找出错误根源为止。
    适合于小型程序，对于大规模程序，由于其需要回溯的路径太多而变得不可操作。
• 对分查找法
    主要用来缩小错误的范围。
• 归纳法
    从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在。
• 演绎法
    根据测试结果，列出所有可能的错误原因；分析已有的数据，排除不可能和彼此矛盾的原因；对其余的原因，选择可能性最大的，利用已有的数据完善该假设，使假设更具体；

六、 运行和维护知识

1. 系统转换

  一个系统开发后，让它实际运行一段时间，是对系统最好的检验和测试方法，系统试运行阶段的主要工作：

• 记录系统运行的数据和状况
• 对系统进行初始化、输入各种原始数据记录
• 核对新系统输出和旧系统（人工或计算机系统）输出的结果。
• 对实际系统的输入方式进行考察（是否方便、效率如何、安全可靠性、误操作保护等）。
• 对系统实际运行、响应速度（包括运算速度、传递速度、查询速度和输出速度等）进行实际测试。

  新系统试运行成功之后，就可以在新系统和旧系统之间互相转换,新旧系统之间的转换方式有：

• 直接转换：在确定新系统运行无误时立刻启用新系统，终止旧系统运行。优点【节省人员、设备费用】，特点【一般适用于一些处理过程不太复杂、数据不太重要的场合】
• 并行转换：新旧系统并行工作一段时间，经过一段时间的考验以后，新系统正式替代旧系统。优点【安全、可靠】，缺点【费用和工作量都很大】。
• 分段转换：又称逐步转换、向导转换、试点过渡法等。在新系统全部正式运行前，一部分一部分地代替旧系统，要求子系统之间有一定的独立性，对系统的设计和实现都有一定的要求，否则无法实现这种分段转换的设想。优点【既保证了可靠性，又不至于费用太大】

2. 系统维护概述

  是软件生命周期中的最后一个阶段，处于系统投入生产性运行以后的时期中，因此不属于系统开发过程。软件维护是在软件已经交付使用之后为了改正错误或满足新的需求而修改软件的过程，即软件在交付使用后对软件所做的一切改动。

（1）系统可维护性概念

  维护人员理解、改正、改动和改进这个软件的难易程度。提高可维护性是开发软件系统所有步骤的关键目的，系统是否能被很好地维护，可以用系统的可维护性这一指标来衡量。

• 系统可维护性的评价指标
    可理解性：别人能理解系统的结构、界面、功能和内部过程的难易程度。
    可测试性：诊断和测试的容易程度取决于易理解的程度。
    可修改性：诊断和测试的容易程度与系统设计所制定的设计原则有直接关系。
• 维护与软件文档
    文档是软件可维护性的决定因素。软件系统的文档分为：用户文档【主要描述系统功能和使用方法，并不关心这些功能是怎样实现的】和系统文档【描述系统设计、实现和测试等各方面的内容】。
    可维护性是所有软件都应具有的基本特点，必须在开发阶段保证软件具有可维护的特点。在软件工程的每一个阶段都应考虑并提高软件的可维护性，在每个阶段结束前的技术审查和管理复查中应该着重对可维护性进行复审。
• 软件文档的修改
    维护应该针对整个软件配置，不应该只修改源程序代码。

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

• 硬件维护
    应由专职的硬件维护人员来负责，主要有：定期的设备保养性维护【保养周期可以是一周或一个月不等，维护的主要内容是进行例行的设备检查与保养，易耗品的更换与安装等】，突发性的故障维护【当设备出现突发性故障时，由专职的维修人员或请厂方的技术人员来排除故障，这种维修活动所花的时间不能过长，以免影响系统的正常运行】。
• 软件维护
    主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部修改。修改时应充分利用源程序，修改后要填写程序修改登记表，并在程序变更通知书上写明新旧程序的不同之处。
    正确性维护（25%）：指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
    适应性维护（20%）：指使应用软件适应信息技术变化和管理需求变化而进行的修改。
    完善性维护（50%）：为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
    预防性维护（5%）：为了改进应用软件的可靠性和可维护性，适应未来的软/硬件环境的l变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。
• 数据维护
    主要是由数据库管理员来负责，主要负责数据库的安全性和完整性以及进行并发性控制。还有一项很重要的内容：代码维护，不过代码维护发生的频率相对较小。

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

  系统的维护工作应有计划、有步骤地统筹安排，按照维护任务的工作范围、严重程度等诸多因素确定优先顺序，制定出合理的维护计划，然后通过一定的批准手续实施对系统的修改和维护。
通常，对系统的维护应执行以下步骤。

• 提出维护或修改要求：操作人员或业务领导用书面形式向系统维护工作的主管人员提出对某项工作的修改要求。这种修改要求一般不能直接向程序员提出。
• 领导审查并做出答复，如同意修改则列入维护计划：系统主管人员进行一定的调查后，根据系统的情况和工作人员的情况，考虑这种修改是否必要、是否可行，做出是否修改、何时修改的答复。如果需要修改，则根据优先程度的不同列入系统维护计划。
• 领导分配任务，维护人员执行修改：系统主管人员按照计划向有关的维护人员下达任务，说明修改的内容、要求和期限。
• 验收维护成果并登记修改信息：系统主管人员组织技术人员对修改部分进行测试和验收。

3. 系统评价

（1）系统评价概述

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

• 立项评价：指信息系统方案在系统开发前的预评价，即系统规划阶段中的可行性研究。评价的目的【决定是否立项进行开发】，评价的内容【分析当前开发新系统的条件是否具备，明确新系统目标实现的重要性和可能性】。
• 中期评价：又称为里程碑式评价，包含两种含义，一是【指项目方案在实施过程中因外部环境出现重大变化，需要对项目的方案进行重新评估，以决定是继续执行还是终止该方案】另一种【也称为阶段评估，指在信息系统开发正常的情况下，对系统设计、系统分析、系统实施阶段的阶段性成果进行评估】。
• 结项评价：指项目准备结束时对系统的评价，一般是指在信息系统投入正式运行以后，为了了解系统是否达到预期的目的和要求而对系统运行的实际效果进行的综合评价，是狭义的信息系统评价。信息系统项目的鉴定是结项评价的一种正规的形式。

（2）系统评价的指标

• 按照运行效果和用户需求（人）、系统质量和技术条件（机）这 $2$ 条线索构造指标。
• 从信息系统的评价对象出发，开发方【系统质量和技术水平】；用户方【用户需求和运行质量】；系统外部环境【主要通过社会效益】
• 从经济学角度出发，分别按系统成本、系统效益和财务指标 $3$ 条线索建立指标。

七、 软件项目管理

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

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

  有效的软件项目管理集中在 $4$ 个 $P$ 上，即人员 $（Person）$、产品$（Product）$、过程$（Procedure）$ 和项目$（Project）$。

（1）人员

  是软件工程项目的基本要素和关键因素，在对人员进行组织时，有必要考虑参与软件过程（及每一个软件项目）的人员类型：

• 项目管理人员
    负责软件项目的管理工作，其负责人通常称为项目经理，任务就是要对项目进行全面的管理，对项目目标要有一个全局的观点。
• 高级管理人员
    可以是领域专家，负责提出项目的目标并对业务问题进行定义，这类业务问题经常会对项目产生较大的影响。
• 开发人员
    这类人员常常掌握了开发一个产品或应用所需的专门技术，可胜任需求分析、设计、编码、测试、发布等各种相关的开发岗位。
• 客户
    是一组可说明待开发软件的需求的人，也包括与项目目标有关的其他风险承担者。
• 最终用户
    产品或应用提交后，那些与产品/应用进行交互的人称为最终用户。

（2）产品

  在进行项目计划之前，应该首先进行项目定义，也就是定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等。
  软件开发者和客户必须一起定义产品的目的和范围，其目的是从客户的角度定义该产品的总体目标，但不必考虑这些目标如何实现，软件范围定义了与软件产品相关的数据、功能和行为及相关的约束。

（3）过程

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

（4）项目

  进行有计划和可控制的软件项目是管理复杂性的一种方式：明确目标及过程、保持动力、跟踪进展、做出明智的决策、进行事后分析

2. 软件项目估算

  软件项目估算涉及人、技术、环境等多种因素，因此很难在项目完成前准确地估算出开发软件所需的成本、持续时间和工作量，常用的估算方法有：

• 基于分解技术进行估算
• 基于经验估算模型的估算
• 基于已经完成的类似项目进行估算（常用、有效）

（1）成本估算方法

• 自顶向下估算方法
    估算人员参照以前完成的项目所耗费的总成本（或总工作量）来推算将要开发的软件的总成本（或总工作量），然后把它们按阶段、步骤和工作单元进行分配。
    优点【估算中不会遗漏系统级事务的成本估算、估算工作量小、速度快】，缺点【不清楚低级别上的技术性困难问题，使成本上升】。
• 自底向上估算方法
    将待开发的软件细分，分别估算每一个子任务所需要的开发工作量，然后将它们加起来，得到软件的总开发量。
    优点【估算较为准确】，缺点【系统级工作量估算往往偏低】
• 差别估算方法
    将待开发项目与一个或多个已完成的类似项目进行比较，找出与某个相似项目的若干不同之处，并估算每个不同之处对成本的影响，导出待开发项目的总成本。
    优点【提高估算的准确度】，缺点【不容易明确“差别”的界限】
• 专家估算法
    依靠一个或多个专家对要求的项目做出估算，其精确性取决于专家对估算项目的定性参数的了解和他们的经验。
• 类推估算法
    自底向上【类推在两个具有相似条件的工作单元之间进行】
    自顶向下【将估算项目的总体参数与类似项目进行直接比较得到结果】
• 算式估算法
    企图避免主观因素的影响，用于估算的方法有两种基本类型：由理论导出和由经验导出。

（2）COCOMO 估算模型

  一种精确的、易于使用的成本估算模型。

• 基本 COCOMO 模型
    一个静态单变量模型，用于对整个软件系统进行估算，公式：
  $$E=a（L{）}^b，D=c{E}^d$$
    其中，$E$ ：工作量（人/月），D：开发时间（月），L：项目的源代码行估计值（千行代码），$a、b、c、d$：常数。
• 中级COCOMO模型
    一个静态多变量模型，将软件系统模型分为系统和部件两个层次，系统由部件构成，它把软件开发所需的人力（成本）看作是程序大小和一系列"成本驱动属性"的函数，公式：
  $$E=a（L{）}^{b}EAF$$
    其中，$L$ ：软件产品的目标代码行数（千行代码数），$a、b$ ：常数。
• 详细 COCOMO 模型
    将软件系统模型分为系统、子系统和模块 $3$个层次，除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响。

（3）COCOMOⅡ 模型

  一种层次结构的估算模型，分为 $3$ 个阶段性模型：

• 应用组装模型：在软件工程的前期阶段使用，这时用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的。
• 早期设计阶段模型：在需求已经稳定并且基本的软件体系结构已经建立时使用。
• 体系结构阶段模型；在软件的构造过程中使用。

（4）Putnam 估算模型

  一种动态多变量模型，它是假设在软件开发的整个生存周期中工作量有特定的分布。代码行数、工作量和开发时间之间的关系：
$$L=C_k{E}^{\frac{1}{3}}{t}_d^{\frac{3}{4}}$$
  其中，$L$ ：源程序代码行数，$t_d$ ：开发持续时间（年），$E$：包括软件开发和维护在整个生存期所花费的工作量（人/年），$C_k$：技术状态常数，其值依赖于开发环境。

3. 进度管理

  目的：确保软件项目在规定的时间内按期完成。
  软件开发项目的进度安排两种方式：系统最终交付日期已经确定，软件开发部门必须在规定期限内完成；系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定。

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

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

（2）进度安排

  为监控软件项目的进度计划和工作的实际进展情况，表示各项任务之间进度的相互依赖关系，需要采用图示的方法。在图中明确标明：各个任务的计划开始时间和完成时间；各个任务的完成标志；各个任务与参与工作的人数；各个任务与工作量之间的衔接情况；完成各个任务所需的物理资源和数据资源。

• Gantt 图
    一种简单的水平条形图，它以日历为基准描述项目任务。水平轴表示日历时间线，每个条形表示一个任务，任务名称垂直地列在左边的列中，水平条的起点和终点对应水平轴上的时间，分别表示该任务的开始时间和结束时间，水平条的长度表示完成该任务所持续的时间。当日历中同一时段存在多个水平条时，表示任务之间的并发。
  
    优点：清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性
    缺点：不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分
• 目计划评审技术（Program Evaluation & Review Technique，PERT）图
    一个有向图，图中的箭头表示任务，它可以标上完成该任务所需的时间。
    结点：流入结点的任务的结束，并开始流出结点的任务，这里把结点称为事件。只有当流入该结点的所有任务都结束时，结点所表示的事件才出现，流出结点的任务才可以开始。事件本身不消耗时间和资源，它仅表示某个时间点。一个事件有一个事件号和出现该事件的最早时刻【在此时刻之前从该事件出发的任务不可能开始】和最迟时刻【从该事件出发的任务必须在此时刻之前开始，否则整个工程就不能如期完成】。
    每个任务还可以有一个松弛时间（Slack Time），表示在不影响整个工期的前提下完成该任务有多少机动余地，反映了完成某些任务时可以推迟其开始时间或延长其所需完成的时间。为了表示任务间的关系，还可以加入一些空任务（用虚线箭头表示），完成空任务的时间为 $0$。
  

图中松弛时间为 0 的这些任务是完成整个工程的关键路径，其事件流为：1→2→3→4→6→8→10→11。

  优点：不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系，以及如期完成整个工程的关键路径。
缺点：不能反映任务之间的并行关系。

某软件项目的活动图，图中顶点表示项目里程碑，连接顶点的边表示包含的活动。
求：① 里程碑的关键路径    ② 活动 FG 的松弛时间
① A. B     B. C      C. D     D. I
② A. 19    B. 20    C. 21    D.24

---

① 关键路径为图中最长的路径：D-F-H 权值 = 48，选C
② FG的松弛时间为：关键路径 - 包含FG的最长路径 =$（DFH）-（DFG）=48-28=20$，选B

4. 软件项目的组织

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

• 尽早落实责任：在软件项目开始组织时，要尽早指定专人负责，使他有权进行管理，并对任务的完成负全责。
• 减少交流接口：一个组织的生产率随着完成任务时存在的通信路径数目的增加而降低。要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。
• 责权均衡：软件管理人员承担的责任不应比赋予他的权利还大。

（1）组织结构的模式

• 按项目划分的模式
    按项目将开发人员组织成项目组，项目组的成员共同完成该项目的所有开发任务。
• 按职能划分的模式
    按软件过程中所反映的各种职能将项目的参与者组织成相应的专业组。
• 矩阵模式
    上述两种模式的组合，它既按职能组织相应的专业组，又按项目组织项目组。每个软件人员既属于某个专业组，又属于某个项目组。每个软件项目指定一个项目经理，项目中的成员根据其所属的专业组的职能承担项目的相应任务。

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

• 主程序员制小组
    由一名主程序员、若干名程序员、一名后援工程师和一名资料员组成。突出了主程序员的领导作用，小组内的通信主要体现在主程序员与程序员之间。
• 民主制小组
    成员之间地位平等，虽然形式上有一位组长，但小组的工作目标和决策都是由全体成员决定的，互相合作，形成一个良好的工作氛围。
• 层次式小组
    一名组长领导若干名高级程序员，每名高级程序员领导若干名程序员。组内的通信路径数介于主程序员制小组和民主制小组之间。

5. 软件配置管理（Software Configure Management，SCM）

  为了协调软件开发使得混乱减到最小，使用配置管理技术，使变更所产生的错误达到最小并最有效地提高生产率。
  用于整个软件工程过程，主要目标：标识变更；控制变更；确保变更正确地实现；报告有关变更。

• 基线
    是软件生存周期中各开发阶段的一个特定点，作用：使各开发阶段的工作划分更加明确，使本来连续的工作在这些点上断开，以便于检查与肯定阶段成果。
• 软件配置项（Software Configure Item，SCI）
    是软件工程中产生的信息项，是配置管理的基本单位。
• 版本控制
    是一个动态的概念，它一方面随着软件生存周期向前推进，SCI的数量在不断增多，一些文档经过转换生成另一些文档，并产生一些信息；另一方面又随时会有新的变更出现，形成新的本。
• 变更控制
    软件工程过程中某一阶段的变更均要引起软件配置的变更，这种变更必须严格地加以控制
  和管理，保持修改信息，并把精确、清晰的信息传递到软件工程过程的下一步骤。

6. 风险管理

  指预算、进度、人员、资源、利益相关者、需求等方面的潜在问题以及它们对软件项目的影响。项目复杂度、规模及结构不确定性也属于项目风险因素。
  一般认为软件风险包含两个特性：不确定性【指风险可能发生也可能不发生】和损失【指如果风险发生，就会产生恶性后果】。在进行风险分析时，重要的是量化每个风险的不确定程度和损失程度。
  项目风险威胁到项目计划；技术风险威胁到要开发软件的质量及交付时间；商商业风险威胁到要开发软件的生存能力，包括：

• 市场风险：开发了一个没有人真正需要的优良产品或系统。
• 策略风险：开发的产品不在符合公司的整体商业策略。
• 销售风险：开发了一个销售部门不知道该如何销售的产品。
• 管理风险：由于重点的转移或人员变动而失去了高级管理层的支持。
• 预算风险：没有得到预算或人员的保证。

（1）风险识别

  试图系统化地指出对项目计划（估算、进度、资源分配等）的威胁。识别出已知风险和可预测风险后，项目管理者首先要做的是在可能时回避这些风险，在必要时控制这些风险。
  识别风险的方法：建立风险条目检查表【可用于风险识别，并且主要用来识别下列几种类型中的一些已知风险和可预测风险】。

（2）风险预测

  又称风险估计，从两个方面评估一个风险：风险发生的可能性或概率；如果风险发生了所产生的后果。整体的风险显露度$（RiskExposure，RE）=P\times C$，$P$：风险发生的概率，$C$：风险发生时带来的项目成本。

（3）风险评估

  对风险评估很有用的技术：定义风险参照水准，将识别出来的风险评估分类，对于大多数软件项目来说，成本、进度和性能就是 $3$ 种典型的风险参照水准。

（4）风险控制

  目的：辅助项目组建立处理风险的策略。

• 风险避免
    应对风险的最好办法是主动地避免风险，即在风险发生前分析引起风险的原因，然后采取措施，以避免风险的发生。
• 风险监控
    项目管理者应监控某些因素，这些因素可以提供风险是否正在变高或变低的指示。
• RMMM 计划
    将所有风险分析工作文档化，并由项目管理者作为整个项目计划中的一部分来使用。

八、 软件质量

  软件质量：指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。
  软件质量管理：指对软件开发过程进行独立的检查活动，由质量保证、质量规划和质量控制 $3$ 个主要活动构成。
  软件质量保证：指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的软件。

1. 软件质量特性

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

  由 $3$ 个层次组成：第一层【质量特性】，第二层【质量子特性】，第三层【度量指标】，该模型的质量特性和质量子特性如下：

序号	质量特性	质量子特性
1	效率	时间特性 资源特性
2	功能性	适合性 准确性 互用性 依从性 安全性
3	可靠性	成熟性 容错性 易恢复性
4	易使用性	易理解性 易学性 易操作性
5	可移植性	适应性 易安装性 一致性 易替换性
6	可维护性	易分析性 易改变性 稳定性 易测试性

（2）Mc Call软件质量模型

  从软件产品的运行、修正和转移 $3$ 个方面确定了 $11$ 个质量特性（见下图），也给出了一个三层模型框架，第一层【质量特性】，第二层【评价准则】，第三层【度量指标】。

2. 软件质量保证

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

• 软件必须满足用户规定的需求，与用户需求不一致的软件无质量可言。
• 软件应遵循规定标准所定义的一系列开发准则，不遵循这些准则的软件，其质量难以得到保证。
• 软件还应满足某些隐含的需求，这些隐含的需求可能未被明确地写在用户规定的需求中，如果软件只满足它的显式需求而不满足其隐含需求，那么该软件的质量是令人质疑的。

3. 软件评审

  通常，把“质量”理解为“用户满意程度”，为了使得用户满意，有两个必要条件：设计质量【设计的规格说明书符合用户的要求】、程序质量【程序按照设计规格说明所规定的情况正确执行】
  软件的规格说明分为：外部规格说明【从用户角度来看】和内部规格说明【从开发者角度来看】，设计质量是由外部规格说明决定的，程序是由内部规格说明决定的。

4. 软件容错技术

  提高软件质量和可靠性的技术可分为两类：避开错误【在开发的过程中不让差错潜入软件的技术】；容错技术【对某些无法避开的差错，使其影响减至最小的技术】。

（1）容错软件的定义

• 在一定程度上能从错误状态自动恢复到正常状态
• 在一定程度上具有容错能力，则称该软件为容错软件
• 在因错误发生错误时仍然能在一定程度上完成预期的功能
• 在一定程度上对自身错误的作用（软件错误）具有屏蔽能力

（2）容错的一般方法

  容错：软件遇到错误的处理能力，实现容错的主要手段是冗余。
  冗余：指对于实现系统规定功能是多余的那部分资源，包括硬件、软件、信息和时间。由于加入了这些资源，有可能使系统的可靠性得到较大的提高。

• 结构冗余：结构冗余是通常采用的冗余技术，按其工作方法可以分为静态【通过表决和比较，少数服从多数，常用的有三模冗余和多模冗余】、动态【多重模块待机储备，故障是切换备份机】和混合【兼有静态冗余和动态冗余的长处】冗余。
• 信息冗余：为检测或纠正信息在运算或传输中的错误需外加一部分信息。
• 时间冗余：指以重复执行指令或程序来消除瞬时错误带来的影响。
• 冗余附加技术：指为实现数据结构，信息和时间冗余技术所需的资源和技术，包括程序、指令、数据、存放和调动它们的空间和通道等。

九、 软件度量

  用于对产品及开发产品的过程进行度量。软件产品、软件过程、资源都具有外部属性【指面向管理者和用户的属性】和内部属性【指软件产品或软件过程本身的属性】。

1. 软件度量分类

  两种分类方法：第一种分类将软件度量分为【面向规模的度量（用于收集与软件规模相关的软件工程输出信息和质量信息） 、面向功能的度量（集中在程序的“功能性”和“实用性”）和面向人的度量（收集有关人们开发软件所用方式的信息和人员理解有关工具的方法和效率的信息）】；第二种分类将软件度量分为【生产率度量（主要关注于软件工程活动的制品）、质量度量（可指明软件满足明确的和隐含的用户需求的程度）和技术度量（主要集中在软件产品的某些特征上，而不是软件开发的全过程）】。

（1）面向规模的度量

  通过对质量和（或）生产率的测量进行规范化得到的，而这些量都是根据开发过的软件的规模得到的。软件规模通常用程序的代码行 $（LineofCode，LOC）$ 或千行代码 $KLOC$ 来衡量。由于代码行自然、直观地反映了软件项目的规模，也容易直接测量，因此面向规模的度量是一种常用的度量方法。

  虽然面向规模的度量方便、直观，但代码行数依赖于程序设计语言，对于同一个软件，采用不同程序设计语言编写的程序，代码行数是不同的。对于一些因良好的设计而导致代码量小的软件来说，这种度量显得不够客观。

（2）面向功能的度量

  以功能（由应用程序提供）测量数据作为规范化值，应用最广泛的面向功能的度量是功能点 $（FunctionPoint，FP）$ ，是根据软件信息域的特性及复杂性来计算的。

2. 软件复杂性度量

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

（1）程序复杂性度量原则

  程序复杂性度量是软件度量的重要组成部分。开发规模相同、复杂性不同的程序花费的时间和成本会有很大的差异。

（2）McCabe 度量法

  又称为环路复杂度，一种基于程序控制流的复杂性度量方法，程序的复杂性在很大程度上取决于控制的复杂性。
  根据图论，在一个强连通的有向图 $G$ 中，环的个数 $V（G）$由以下公式给出：
$$V（G）=m-n+2p$$
  其中，$V（G）$是有向图 $G$ 中的环路数，$m$ 是图 $G$中弧的个数，$n$ 是图 $G$ 中的结点数，$p$ 是 $G$ 中的强连通分量个数。

求下图 McCabe 环路复杂的度量

---

由图中得：结点数 $n=6$，弧数 $m=9$，强连通分量数 $p=1$
则：$V（G）=m-n+2p=9-6+2=5$

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

1. 软件工具

（1）软件开发工具

  对于软件开发过程的各种活动。

• 需求分析工具：用于辅助软件需求分析活动的软件。
• 设计工具：用于辅助软件设计活动的软件。
• 编码与排错工具：辅助程序员进行编码活动的工具有编码工具和排错工具。编
• 测试工具：用于支持软件测试的工具。

（2）软件维护工具

  辅助软件维护过程中活动的软件称为软件维护工具，它辅助维护人员对软件代码及其文档进行各种维护活动。

• 版本控制工具
• 文档分析工具：用来对软件开发过程中形成的文档进行分析，给出软件维护活动所需的维护信息。
• 开发信息库工具：用来维护软件项目的开发信息，包括对象、模块等。
• 逆向工程工具：辅助软件人员将某种形式表示的软件（源程序）转换成更高抽象形式表示的软件。
• 再工程工具：用来支持重构一个功能和性能更为完善的软件系统。

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

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

• 项目管理工具：用来辅助软件的项目管理活动。
• 配置管理工具。：用来辅助完成软件配置项的标识、版本控制、变化控制、审计和状态统计等基本任务，使得各配置项的存取、修改和系统生成易于实现，从而简化审计过程，改进状态统计，减少错误，提高系统的质量。
• 软件评价工具：用来辅助管理人员进行软件质量保证的有关活动。

2. 软件开发环境（Software Development Environment）

  指支持软件产品开发的软件系统，它由软件工具集【用于支持软件开发的相关过程、活动和任务】和环境集成机制构成【工具集成和软件开发、维护和管理提供统一的支持】。
环境集成机制主要有：数据集成、界面集成和控制集成，其他方面的集成。
  数据集成：为各种相互协作的工具提供统一的数据模式和数据接口规范，以实现不同工具之间的数据交换。
  界面集成：指环境中的工具的界面使用统一的风格，采用相同的交互方法，提供一种相似的视感效果，这样可以减少用户学习不同工具的开销。
  控制集成：用于支持环境中各个工具或开发活动之间的通信、切换、调度和协同工作，并支持软件开发过程的描述、执行与转换。
  方法与过程集成：指把多种开发方法、过程模型及其相关工具集成在一起。
  平台集成：指在不同的硬件和系统软件之上构造用户界面一致的开发平台，并集成到统一的环境中。
  软件开发环境的特征：环境的服务是集成的、环境应支持小组工作方式，并为其提供配置管理、环境的服务可用于支持各种软件开发活动【包括分析、设计、编程、测试、调试和文档等】、
  集成型开发环境：一种把支持多种软件开发方法和开发模型的软件工具集成在一起的软件开发环境。这种环境应该具有开放性和可剪裁性。开放性为环境外的工具集成到环境中来提供了方便，可剪裁性可根据不同的应用和不同的用户需求进行剪裁，以形成特定的开发环境。