软件工程复习

U2 软件工程

2.1 定义软件工程学科

软件工程层次图

支持软件工程的根基在于质量关注点。
软件工程的基础是过程层。
软件工程方法为构建软件提供技术上的解决方法。
软件工程工具为过程和方法提供自动化或半自动化的支持

2.2 软件过程

软件过程定义
  软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。活动主要实现宽泛的目标。动作包含了主要工作产品生产过程中的一系列任务。任务关注小而明确的目标，能够产生实际产品。

2.2.1 过程框架

• 一个通用的软件工程过程框架通常包括以下5个活动：沟通、策划、建模、构建、部署。
  • 沟通。在技术工作开始之前，和客户（及其他利益相关者）的沟通与协作是极其重要的；其目的是理解利益相关者的项目目标，并收集需求以定义软件特性和功能。
  • 策划。也可以称为软件项目计划，它定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。
  • 建模。利用模型来更好地理解软件需求，并完成符合这些需求的软件设计。
  • 构建。它包括编码（手写的或者自动生成的）和测试以发现编码中的错误。
  • 部署。软件（全部或者部分增量）交付到用户，用户对其进行评测并给出反馈意见。

题目

• 软件工程的基本要素包括方法、工具和（ A ）。
  A、过程
  B、软件系统
  C、硬件环境
  D、人员

软件工程的基本要素包括方法、工具和过程，并且人员也是一个重要的要素。

• 软件过程包括五个框架活动——沟通、策划、建模、构建和部署。其中，哪个活动主要涉及确定软件系统的需求、功能和性能等方面的规范和描述？（ C ）
  A、沟通
  B、策划
  C、建模
  D、构建
  E、部署

建模活动主要涉及确定软件系统的需求、功能和性能等方面的规范和描述。在软件过程中，建模活动通过使用不同的建模技术和工具，如需求建模、系统建模、数据建模等，来对软件系统进行抽象和描述，以便于后续的开发、测试和部署工作。

• 软件工程是一门迅速发展的新兴学科，现已经成为计算机科学的一个重要分支。软件工程是一种层次化的技术，软件工程包括（ C ）三个要素。
  A、技术、方法和工具
  B、封装、继承、多态
  C、方法、工具和过程
  D、过程、模型、方法

• 软件需求确定以后，进入由软件设计、编码(Coding)和（ B ）三个关联阶段构成的软件开发(develupmeni)阶段。
  A、需求分析
  B、软件测试
  C、系统定义
  D、软件维护

• 可行性研究又称为可行性分析，目的是避免盲目投资，减少不必要的损失。下列（ C ）不是可行性分析阶段的任务。
  A、确定项目规模和目标
  B、确定资源(人力、硬件、软件等)需求
  C、建立新系统的高层逻辑模型
  D、提出实现高层逻辑模型的各种方案，并推荐可行的方案

可行性研究是在项目初期进行的一项工作，旨在评估项目的可行性和可行性方案的可行性。在可行性分析阶段，主要任务包括确定项目规模和目标、确定资源需求（人力、硬件、软件等）、提出实现方案并推荐可行的方案。
 "建立新系统的高层逻辑模型"不是可行性分析阶段的任务，而是在系统设计阶段进行的工作，用于描述系统的逻辑结构和组成部分。

• 可行性研究主要从以下几个方面进行研究：（ A ）
  A、技术可行性，经济可行性，操作可行性
  B、技术可行性，经济可行性，系统可行性
  C、经济可行性，系统可行性，操作可行性
  D、经济可行性，系统可行性，时间可行性

U4 软件生命周期（惯用过程模型）

瀑布模型

关键：需求准确定义且稳定

• 前提：需求必须是准确定义和相对稳定的
  各项活动规定为固定顺序链接的工作，即从用户需求规格说明开始，
  顺序地通过沟通、策划、建模、构建和部署过程，最终提供完整软件和持续技术支持。
  
• 特点：
  • 阶段间具有顺序性和依赖性；
  • 推迟实现的观点：前面步骤完成后才考虑实现；
  • 质量保证的观点：每一阶段都需要有文档以及经过评审；

优点：适用于小型项目，强调文档化和可追溯性，提供了明确的开发流程

• 问题：
  • 瀑布模型需要客户明确需求，但客户难以准确表达所有需求。
  • 得到可执行程序的时间太迟(项目接近尾声)，对于系统中存在的重大缺陷，如果在可执行程序评审之前没有被发现，将可能造成惨重损失。
  • 可能导致一些阻塞(开发团队的一些成员要等待另一些成员工作完成，尤其在开始和结束阶段，花在等待的时间可能超过生产性工作时间)
  • 过于理想化，难以应对开发过程中的各种不确定因素。

缺点：难以适应需求变化、开发周期较长、不适用于大型项目

V模型

关键：瀑布模型pro（将验证确认动作应用于软件早期）

• 瀑布模型与V模型没有本质区别，V模型提供了一种将验证确认动作应用于早期软件工程工作中的方法
  

增量模型

关键：需求不明确；迫切需要；后续细化改进，每个增量都是可运行程序；

• 前提：需求不明确或迫切需要为用户迅速提供一套功能有限的软件产品，然后再后续版本中再进行细化和扩展功能。

演化模型

关键：业务和需求经常变化；是迭代的过程模型

• 前提：开发过程中，业务和产品需求经常变化；严格的交付时间；核心产品需求确定，但是系统扩展的细节问题却没有定义

• 演化模型是迭代的过程模型，每次迭代产生软件的一个更完整的版本

• 缺点

1. 大多数的项目管理和估算技术是基于活动的线性布局，所以并不完全适用于演化软件过程。
2. 没有确定演化的最快速度，不定带来的不确定
3. 演化模型侧重灵活性和可延展性，而不是高质量。这种说法听起来很惊人。演化模型优先追求开发速度，而不是零缺陷。

原型开发

• 前提：
  客户提出基本功能，但是未详细定义详细需求（输入输出）
  开发人员对于开发的运行环境、算法效率、兼容性、人机交互不确定

• 流程：
  在原型系统不断调整以满足各种利益相关者需求的过程中，采用迭代技术，同时也使开发者逐步清楚用户的需求。

• 问题：

因为是原型，所以需要重新搭建，但是利益相关者不愿意并要求对软件稍加修改变成一个可运行的产品，最终软件开发管理往往陷入失效。
由于一开始的快速搭建，对于效力会有一个向下的适应，最终造成并不完美的选择变成了系统的组成部分

螺旋模型

关键：循环方式；结合瀑布模型与原型模型，但独有风险分析；与增量模型不同，不需要每个增量都是可运行程序；开发大型系统和软件的理想方法

• 风险驱动的软件开发模型：

  1. 采用循环的方式，逐步加深系统定义和实现的深度（原型开发的迭代性质）；
  2. 确定一系列里程碑，确保利益相关者都支持系统解决方案（瀑布模型的系统性和可控性）；

• 将瀑布模型与原型的迭代特征结合,并加入两种模型均忽略了的风险分析,和增量模型不同，它并不要求每一个增量都是可运行的程序

• 开发大型系统和软件的理想方法，更好地应对风险

题目

以下情况应该选用什么过程模型？

• （1）客户不太清楚待开发的系统需要提供什么服务。

  • 需求不明确
  • 原型模型

• （2）开发团队了解待开发软件的相关领域知识，尽管此系统庞大，但其较已经开发的系统差异并不大。

  • 需求明确
  • 瀑布模型

• （3）软件的功能是把读入的浮点数开平方，所得到的结果应该精确到小数点后4位。

  • 需求很明确
  • 瀑布模型

• （4）开发一个已发布软件的新版本，公司规定了严格的完成期限，并对外公布。

  • 新版本 + 严格期限
  • 增量模型

• （5）汽车防锁死刹车控制系统

  • 考虑技术风险 + 循环的方式逐步加深系统定义和实现深度
  • 螺旋模型

• （6）大学记账系统，准备替换一个已存在的系统

  • 需求很明确
  • 瀑布模型

• （7）一个位于火车站的交互式火车车次查询系统

  • “交互式”体现的是沟通上的迭代，需求不明确
  • 原型模型

• 在一个为机器视觉领域服务的公司中，你被指派为项目管理者。你的工作是管理一个软件产品的开发，该产品能够加速图像识别的速度。这项工作是面向研究及开发（R&D）的，但其目标是在下一年内生成产品。你会选择那种软件过程模型？BD
  A、XP
  B、增量模型
  C、Scrum
  D、原型模型

• 你被指派为一个小型软件产品公司的项目管理者。你的工作是建造一个结合了虚拟现实的硬件和高超的体验的游戏软件。因为家庭娱乐市场的竞争非常激烈，且团队人员有限，完成这项工作的压力很大。你不会选择那种软件过程模型？BC
  A、增量模型
  B、螺旋模型
  C、瀑布模型
  D、原型模型

• （21）如果客户要求交付产品的时间非常迫切、团队中有几个项目同时在开发，我们最好采用（ A ）来开发这个项目。
  A、增量模型
  B、螺旋模型
  C、瀑布模型
  D、原型模型

  增量模型是一种软件开发方法，它将项目划分为多个小的增量部分，每个增量都是一个可交付的、完整的功能子集。在每个增量中，团队可以按照优先级完成必要的功能和特性。这种方法可以让团队快速交付部分功能，并在后续增量中逐步完善和改进。对于紧迫的项目交付需求和并行开发的情况，增量模型可以帮助团队以迅速且可控的方式进行开发，并及时满足客户的要求。

• 具有风险分析的软件生命周期模型是（ C ）。
  A、瀑布模型
  B、喷泉模型
  C、螺旋模型
  D、增量模型

螺旋模型是一种迭代的软件开发模型，结合瀑布模型与原型模型，但独有风险分析，强调风险管理和迭代开发。在螺旋模型中，项目经理和开发团队通过多个迭代周期来逐步开发和完善软件系统。每个迭代周期包括四个主要阶段：计划、风险分析、工程开发和评审。

• 以下哪个不属于瀑布模型的优点？（ D ）
  A、适用于小型项目
  B、强调文档化和可追溯性
  C、提供了明确的开发流程
  D、强调迭代和快速原型开发

瀑布模型是一种线性的开发模型，按照固定的阶段顺序进行开发，不支持迭代和快速原型开发。瀑布模型的优点包括适用于小型项目、强调文档化和可追溯性、提供了明确的开发流程。

• 以下哪个不瀑布模型的缺点？（ D ）
  A、难以适应需求变化
  B、开发周期较长
  C、不适用于大型项目
  D、不适用于团队协作

瀑布模型的缺点包括难以适应需求变化、开发周期较长、不适用于大型项目。然而，瀑布模型并没有明确指出不适用于团队协作。在实际项目中，瀑布模型可以适用于团队协作，但要求各个团队成员在各个阶段按顺序进行工作，以确保项目的顺利进行。

• 瀑布模型本质上是一种（ A ）。
  A、线性顺序模型
  B、顺序迭代模型
  C、线性迭代模型
  D、增量开发模型

瀑布模型是软件开发过程中最早被提出的一种经典模型，它采用线性顺序的方式进行软件开发。在瀑布模型中，各个阶段按照顺序依次进行，每个阶段的输出作为下一个阶段的输入，形成了一个明确的开发流程。

• 在软件开发过程中，原型模型和瀑布模型是两种常见的开发方法。以下哪个描述是正确的？（ A ）
  A、原型模型采用迭代和增量的方式进行开发，允许快速原型验证和反馈，适用于需求不明确或经常变化的项目。瀑布模型是一种线性顺序的开发方法，按照预先定义的阶段顺序进行开发。
  B、原型模型和瀑布模型都是一种迭代的开发方法，根据项目需求的复杂性和规模选择使用。原型模型更适合小型项目，而瀑布模型适用于大型项目。
  C、原型模型和瀑布模型是完全相同的开发方法，只是名称不同而已。
  D、原型模型和瀑布模型都是一种敏捷开发方法，强调团队合作和持续交付。它们在开发过程中没有本质上的区别。

B错误，原型模型和瀑布模型适用的项目规模和复杂性没有直接关联。
C错误，原型模型和瀑布模型是两种不同的开发方法，不仅仅是名称的差异。
D错误，原型模型和瀑布模型虽然都有敏捷的特点，但它们在开发过程和方法上有本质的区别。

• 如果需求不明确，我们最好采用（ A ）来明确需求。
  A、原型模型
  B、瀑布模型
  C、增量模型
  D、螺旋模型

原型模型是一种迭代开发方法，它通过构建初步的原型来帮助用户和开发团队更好地理解需求，并在需求澄清的过程中进行迭代和改进。通过原型模型，用户可以提供反馈和建议，开发团队可以根据反馈进行调整和完善，从而逐渐明确和理解需求。

• 软件开发的结构化生命周期方法将软件生命周期划分成（ A ）。
  A、计划阶段、开发阶段、运行阶段
  B、计划阶段、编程阶段、测试阶段
  C、总体设计、详细设计、编程调试
  D、需求分析、功能定义、系统设计

软件开发的结构化生命周期方法将软件生命周期划分成计划阶段、开发阶段、运行阶段。
计划阶段包括问题定义、可行性研究和需求分析；
开发阶段包括概要设计、详细设计、编码和测试；
运行阶段包括部署和维护。

• 在一个为遗传工程领域服务的公司中，你被指派为项目管理者。你的工作是管理一个软件产品的开发，该产品能够加速基因分类的速度。这项工作是面向研究及开发（R&D）的，但其目标是在下一年内生成产品。你会选择那种软件过程模型？
  
  你会选择那种团队结构？
  

• 你被指派为一个小型软件产品公司的项目管理者。你的工作是建造一个具有突破性的产品，该产品结合了虚拟现实的硬件和高超的软件。因为家庭娱乐市场的竞争非常激烈，完成这项工作的压力很大。你会选择那种软件过程模型？
  
  你会选择那种团队结构？
  

• 请简要描述三个适于采用瀑布模型的软件项目。

• 传统的桌面应用程序：对于传统的桌面应用程序，通常具有明确的功能需求和固定的技术环境。这种项目通常遵循传统的软件开发生命周期，并且在项目开始之前能够明确定义所有的功能和规范。瀑布模型可以帮助团队在每个阶段有序地进行设计、开发和测试。
• 嵌入式系统开发：嵌入式系统往往需要与硬件进行密切集成，其开发过程需要严格的计划和预测。在这种情况下，瀑布模型可以帮助团队在每个阶段有序地完成需求分析、设计、编码和测试，并最终交付一个完整且稳定的嵌入式系统。
• 传统的企业级软件开发：某些企业级软件项目对于稳定性和可靠性的要求较高，而且对于变更的容忍度相对较低。这些项目通常有明确的业务需求和规范，并需要按计划进行开发和交付。在这种情况下，瀑布模型可以帮助团队按照预定的计划进行逐个阶段的开发和测试，确保项目按时交付。

U5 敏捷开发

5.1 什么是敏捷

5.2 敏捷及变更成本

• 敏捷的变更：
  • 敏捷的拥护者认为，一个设计良好的敏捷过程“拉平”了变更成本曲线，使软件开发团队在没有超常规的时间和费用影响的情况下，在软件项目后期能够适应各种变化。
  • 敏捷过程包括增量交付。当增量交付与其他敏捷实践耦合时，例如连续单元测试及结对编程，引起变更的费用会衰减。
  • 虽然关于拉平曲线的程度的讨论仍然在进行，但是证据表明，敏捷变更费用显著降低。

5.3 什么是敏捷过程

• 敏捷过程的定义：
    基于敏捷原则进行的软件开发过程，视为敏捷过程。所谓“基于”，是指充分考虑，而不是全部包含。

• 敏捷过程的三大假设

  • 提前预测需求或变化很难，预测优先级也存在困难；
  • 理论上讲，是先有设计，后有构建。但实际上这两步是交替反复的，因为设计者是人，不是神；
  • 从客观角度和软件开发的经验来讲，软件开发的几大要素（分析、设计、构建和测试）都要不断的调整、变化，而这正是敏捷的内涵。

• 敏捷原则

1. 我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。
2. 即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
3. 经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最富有效果和效率的信息传递方法是面对面交谈。
7. 可运行软件是进度的首要度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人（sponsor）、开发者和用户应该能够保持一个长期的、恒定的开发速度 。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单是必要的。
11. 最好的架构、需求和设计出自于自组织团队。
12. 每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。

★并不是每一个敏捷模型都同等使用这12项原则，一些模型可以选择忽略（或至少淡化）一个或多个原则的重要性。

5.4 极限编程

• 使用得最为广泛的敏捷过程。
• 三个特点：
  • 是一些相互关联的准则和惯例的集合；
  • 追求变更曲线平坦化；
  • 适合于小团队、高风险的项目。

极限编程过程

• XP使用面向对象方法作为推荐的开发范型，
  它包含了策划、设计、编码和测试4个框架活动的规则和实践。
  (区别于：软件工程过程框架通常包括以下5个活动：沟通、策划、建模、构建、部署)

策划：
  建立一系列描述待开发软件必要特征与功能的“故事” (故事：由客户谈论系统应该完成什么功能，然后用通俗的自然语言，使用自己的语汇，将其写在卡片上)；
  评估每一个故事，并给出以开发周数为度量单位的成本；
  客户和XP团队共同决定如何对故事分组，并置于将要开发的下一个发行版本中（下一个软件增量）；
  形成关于一个发布版本的基本承诺；
  对有待开发的故事进行排序：（1）所有选定故事 (下一个增量)将在几周之内尽快实现；（2）具有最高权值的故事将移到进度表的前面并首先实现；（3）高风险故事将首先实现。
  在第一个版本发布之后，XP团队计算项目的速度。项目速度由第一个发行版本中实现的客户故事个数来决定。
  项目速度将用于： (1) 帮助估计后续发行版本的发布日期和进度安排；(2) 确定是否对整个开发项目中的所有故事有过分承诺。一旦发生过分承诺，则调整软件发行版本的内容或者改变最终交付日期。
  在开发过程中，客户可以增加故事，改变故事的权值，分解或者去掉故事。然后由XP团队重新考虑并修改计划。

设计：
  严格遵循KIS (Keep It Simple)原则，即使用简单而不是复杂的表述。不鼓励额外功能性（因开发者假定以后会用到）设计。
  鼓励使用CRC卡（类-责任-协作者）确定与当前软件增量相关的面向对象的类。
  在某个故事设计中遇到困难时，立即建立这部分设计的可执行原型，实现并评估设计原型 (Spike解决方案：让不明确的评估成为明确的评估)，其目的是在真正的实现开始时降低风险，对可能存在设计问题的故事确认其最初的估计。
  鼓励“重构”。【重构：是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。实质上，重构就是在编码完成之后改进代码设计 (设计优化，代码优化)。重构所需工作量随着应用软件规模的增长而急剧增长。】

编码：
  XP推荐在故事开发和初步设计完成之后，团队不是直接开始编码，而是开发一系列用于检测本次（软件增量）发布的包括所有故事的单元测试。一旦编码完成，就可以立即完成单元测试，从而向开发者提供即时的反馈。(先开发测试用例，然后再编码)
  结对编程。XP建议两个人面对同一台计算机共同为一个故事开发代码。这一方案提供了实时解决问题 (两个人总比一个人强)和实时质量保证的机制 (在代码写出后及时得到复审)，同时也使得开发者能集中精力于手头的问题。
  实施中不同成员担任的角色略有不同，例如，一名成员考虑设计特定部分的编码细节；而另一名成员确保编码遵循的标准。
  当结对的两人完成其工作，他们所开发的代码将与其他人的工作集成起来。有些情况下，团队(专人)进行集成。还有一些情况下，结对者自己负责集成，这种“连续集成”策略有助于避免兼容性和接口问题。

测试：
  建立的单元测试应当使用一个可以自动实施的框架（因此易于执行并可重复），这种方式支持代码修改之后即时的回归测试策略。
  将个人单元测试组织到一个“通用测试集”，与传统方式不同，每天都可以进行系统的集成和确认测试，可以为XP团队提供连续的进展指示，也可在一旦发生问题的时候及早提出预警。 “每几个小时修改一些小问题，比仅在最后截止期之前修正大问题要节省时间。”
  XP验收测试，也称为客户测试 (由客户主导)，由客户规定技术条件，并且着眼于客户可见的、可评审的系统级的特征和功能。验收测试根据本次软件发布中所实现的用户故事而确定。

5.5 其他敏捷过程模型
5.6 敏捷过程工具集

题目

• 关于极限编程（XP）的优点，以下哪个说法是正确的？（ A ）
  A. 提供高度灵活性和响应变化能力
  B. 强调个人技能而忽视团队合作
  C. 仅适用于小型项目
  D. 降低软件质量和可维护性

极限编程（XP）注重高度灵活性和快速响应变化的能力。它通过迭代开发、持续交付和频繁反馈的方式，使团队能够适应需求变化，并在项目进展中及时调整。

• 软件工程的敏捷理念强调以下哪个重要方面？（ C ）
  A. 高度规范化的流程和文档
  B. 个人技能的发展和提升
  C. 自组织团队的控制力
  D. 长期的计划和预测

软件工程的敏捷理念强调4个关键问题：
自组织团队对所开展工作具有控制力的重要性；
团队成员之间以及开发参与者和客户之间的交流与合作；
对“变更代表机遇”的认识；
强调快速交付让客户满意的软件。

• Scrum是一种敏捷软件开发框架，强调（自组织、迭代开发和持续反馈）。它通过迭代开发周期，称为（sprint），来持续交付可工作的软件增量。每个（sprint）的工作内容由（团队）自行决定，并通过（产品Backlog）来确定和调整优先级。团队在每天的（每日站会）会议中分享工作进展、遇到的问题和计划。Sprint结束后，进行（回顾会议）会议以评审已完成的工作并进行反馈，以及回顾会议以识别改进机会。

• 敏捷过程模型声称能够有效控制成本，即便是经常发生需求变更也支持。请结合Scrum、XP、看板法，谈谈其内在机制是哪些？
  

敏捷过程模型是一种以人为核心、迭代、增量的软件开发方法论，它强调适应性、灵活性和快速响应变化。Scrum、XP（极限编程）、看板法（Kanban）是敏捷开发中的几种常见方法。这些方法通过以下内在机制来有效控制成本，即使在需求频繁变更的情况下：

1. 迭代开发（Iterative Development）：

• Scrum和XP都采用短周期的迭代开发模式，通常称为Sprint或迭代。每个迭代周期内，团队会完成一部分需求的开发和测试，这样有助于快速获得反馈并进行调整。

2. 持续集成（Continuous Integration）：

• 在XP中，团队成员频繁地集成代码，确保代码的集成质量。这有助于及早发现集成问题，减少后期集成的成本。

3. 最小可行产品（Minimum Viable Product, MVP）：

• 敏捷方法鼓励开发最小可行产品，即只包含核心功能的版本，以验证产品概念。这有助于减少不必要的开发工作和成本。

4. 需求优先级（Requirement Prioritization）：

• Scrum和看板法都强调根据业务价值对需求进行优先级排序，优先开发最重要的功能。这有助于确保资源被集中用于最有价值的部分。

5. 透明性（Transparency）：

• 敏捷方法要求项目的进展和状态对所有团队成员和利益相关者透明。这有助于及时发现问题和偏差，减少误解和返工。

6. 自我组织团队（Self-Organizing Teams）：

• 在Scrum和XP中，团队成员自行组织工作，选择最适合完成工作的方式。这种自主性有助于提高团队的效率和适应性。

7. 持续改进（Continuous Improvement）：

• 敏捷方法鼓励团队定期回顾和改进工作流程。例如，Scrum中的Sprint回顾会议，看板法中的持续流程改进。

8. 适应性规划（Adaptive Planning）：

• 敏捷方法允许在项目过程中根据反馈和变化调整计划。这种灵活性有助于应对需求变更，而不是坚持一个固定的计划。

9. 限制在制品（Limit Work In Progress, WIP）：

• 看板法特别强调限制在制品数量，以减少多任务处理和提高流程效率。这有助于更快地响应需求变更。

10. 测试驱动开发（Test-Driven Development, TDD）：

• 在XP中，测试驱动开发是一种核心实践，它要求先编写测试用例，再编写功能代码。这有助于确保代码质量，减少后期的修复成本。

11. 客户协作（Customer Collaboration）：

• 敏捷方法强调与客户紧密合作，以便更好地理解需求并及时调整。Scrum中的Product Owner角色就是客户代表。

12. 快速反馈循环（Fast Feedback Loops）：

• 敏捷方法通过快速的反馈循环，使得团队能够迅速响应需求变更和市场变化。
  通过这些内在机制，敏捷过程模型能够有效地控制成本，提高开发效率，同时保持对需求变更的适应性。这些方法论的共同目标是交付高质量的软件，同时最大化客户满意度。

U6 软件工程的人员方面

6.1 软件工程师的特质

• 七种特质

1. 责任感。这会让软件工程师去努力实现对同伴、其他利益相关者和管理者的承诺。为获得成功的结果，他会在需要的时候不遗余力地做他需要做的事情。
2. 对一些人的需求有敏锐的意识，这些人包括同团队的成员、利益相关者、掌控整个项目并能找到解决方法的管理者。他会观察人们工作的环境，并根据环境和人本身来调整自己的行为。
3. 坦诚。如果发现了有缺陷的设计，他会用诚实且有建设性的方式指出错误。
4. 展现抗压能力。前面我们提到，软件工程工作经常处在混乱的边缘。压力（以及由此产生的混乱）来自很多方面——需求和优先级的变更、要求苛刻的利益相关者或同伴、不切实际或者令人难以忍受的管理者。但一个卓有成效的软件工程师可以在不影响业绩的情况下很好地处理这些压力。
5. 有高度的公平感。他会乐于与同事分享荣誉，努力避免利益冲突并且绝不破坏他人劳动成果。
6. 注重细节。这并不意味着追求完美，而是说他会利用产品和项目已有的概括性标准（如性能、成本、质量），在日常工作基础上仔细思考，进而做出技术性决策。
7. 务实。他知道软件工程不是要恪守教条的宗教信仰，而是可根据当下情景需要进行调整的科学规则。

6.2 软件工程心理学
6.3 软件团队

6.4 团队结构

软件工程团队的四种组织模式：

1. 封闭式模式。按照传统的权利层次来组织团队。当开发与过去已经做过的产品相似的软件时，这种团队十分有效。但在这种封闭式范型下难以进行创新性的工作。
2. 随机式模式。松散地组织团队，团队工作依赖于团队成员个人的主动性。当需要创新或技术上的突破时，按照这种随机式范型组织的团队很有优势。但当需要“有次序地执行”才能完成工作时，这种团队就会陷入困境。
3. 开放式模式。试图以一种既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队。良好的沟通和根据团队整体意见做出决策是开放式范型的特征。开放式范型的团队结构特别适合于解决复杂的问题，但可能不像其他类型团队那么有效率。
4. 同步式模式。 依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么主动的交流。

组织结构

主程序员式组织结构
随机式组织结构
民主式组织结构

6.5 敏捷团队
6.6 社交媒体的影响
6.7 软件工程中云的应用
6.8 协作工具
6.9 全球化团队

题目

• 在一个信息系统组织中，你被指派为项目管理者。你的工作是建造一个应用，类似于你的小组以前已经做过的项目，虽然这一个规模更大且更复杂一些。需求已经由用户写成文裆。你会选择那种团队结构？
  

U7 理解需求

7.4 开发用例

1.出卷系统案例

1. 问题描述

   • 系统支持人工辅助出卷和自动出卷：
     • 自动出卷：根据教师出卷要求，抽取题目，自动得到一份试卷；
     • 人工辅助出卷：根据教师出卷要求，抽取符合要求的题目，供教师选择。
     • 出卷要求包括总分，总难度及其比例，总题型及其比例，总知识点及其比例。
   • 系统能进行题库管理：
     • 包括试题录入、修改、删除等；
     • 至少有1000道不同类型的试题；
     • 能容纳足够多的试题；
     • 试题含有内容、答案、题型、难度、知识点和加入时间等信息。
   • 系统能支持不同科目；
   • 系统有一个好的图形界面；
   • 试题不允许重复出现；
   • 试卷符合要求的96%以上即可结束，允许教师调整。
   • 能进行试卷分析。

2. 功能分析

   • 用户：教师、学生、题库维护人员。

   • 用户的各自问题：

     • 教师：出一份合理的试卷，并能根据样式打印与输出；
     • 学生：通过生成一些模拟试题，进行在线学习和检查学习结果；
     • 题库维护人员：添加、更新、删除试题。

   • 精化后的问题：

     • 教师：自动出卷、手动出卷、试卷编辑、试卷输出；
     • 学生：随机抽卷、在线练习、在线评价；
     • 题库维护人员：试题管理。

   • 系统的功能需求：

     • 自动出卷：根据教师要求自动生成一份合理的试卷；
     • 手动出卷：教师手动从候选试题中挑选题目；
     • 试卷编辑：更新试题；
     • 试卷输出：根据某个样式输出试卷。
     • 随机抽卷：随机抽取试题，生成一份试卷；
     • 在线练习：学生可以在线做练习和查看答案；
     • 在线评价：根据测试结果，评价学生的表现；
     • 试题管理：管理人员维护题库中的试题；

     

2.短信系统案例

1. 问题描述

   • 基本目的：利用快捷的短信业务，发送即时消息以支持企事业单位进行信息通知、通告等各种服务，以及用短信进行客户服务。
   • 短信发送：客户选择若干个目标人员，编辑内容，立即或定时发送通知信息。
   • 短信人工应答：用户查看收到的短信内容，并可回复。
   • 短信自动应答：根据短信询问内容，并依据规则自动回复询问者。
   • 短信接收：接收外部短信。
   • 短信确认：确认接收方是否接收。
   • 客户资料维护：添加、删除和更新用户。
   • 接口要求：支持移动终端通过串口通信，支持与移动网关通信。

2. 功能分析

   • 用户：收发人员、管理人员
   • 用户的各自问题：
     • 收发人员：负责发送短信给用户或接受用户短信；
     • 管理人员：添加、更新、删除用户。
   • 功能需求：
     • 用户：
       • 短信发送：填写发送内容、选择发送用户、指明是否要回执、然后（通过无线终端或短信网关）发送短信；
       • 短信接收：从无线终端或短信网关读取短信内容，并查看；
     • 管理员：
       • 用户管理：添加用户、更新用户、删除用户。
       • 系统设置
         

3.SafeHome系统案例

1. 问题描述
   • 房主通过使用报警控制面板或计算机等多种方式与住宅安全功能交互：
     • 输入密码以便能进行其他交互操作。
     • 查询安全区的状态。
     • 查询传感器的状态。
     • 在紧急情况时按下应急按钮。
     • 激活或关闭安全系统。
   • 考虑到房主使用控制面板的情况，系统激活的基本用例(场景)：
     • 房主观察控制面板，以确定系统是否已准备好接收输入。如果系统尚未就绪，“not ready”消息将显示在LCD显示器上，房主必须亲自动手关闭窗户或门以使得该消息消失。
     • 房主使用键盘输入4位密码，该密码和系统中存储的有效密码相比较。如果密码不正确，控制面板将鸣叫一声并自动复位以等待再次输入。如果密码正确，控制面板等待进一步的操作。
     • 房主选择“stay”或“away”启动系统。“stay”只激活外部传感器，“away”激活所有的传感器。
     • 当激活时，房主可以看到一个红色的警报灯。
2. 功能分析
   

题目

• 需求分析中开发人员要从用户那里了解（ A ）。
  A、软件做什么
  B、用户使用界面
  C、输入的信息
  D、软件的规模

• 需求分析是（ A ）。
  A、软件开发工作的基础
  B、软件生存周期的开始
  C、由系统分析员单独完成的
  D、由用户自己单独完成的

• （21.综合.1）某经营文具用品企业需要构建一个在线购物系统，下图是某个用户通过系统下订单的效果图。
  我的全部订单
  订单编号：2016010008625
  订单生成时间：2022-05-22 18:20:15
  送货地址：福州市大学城区学院路2号
  付款方式：货到付款

商品编号	商品名称	购买数量	单价（元）
A0023	涂改带	20	5.00
B0421	0.7mm签字笔	10	3.00
B0422	0.5mm签字笔	10	2.50

总价：155.00
（1）要达到这样的效果，该如何设计相关类？给出主要类图
（2）为了促销，该企业决定推出618活动：满100元减5元、满200元减15元、满300元减30元。考虑到将来还会有双十一、双十二等不同促销手段的活动，你将如何修改设计方案，以适应上述要求？给出设计方案并说明运用了哪些设计原则。

（1）主要类图设计如下：

（2）为了促销，可以使用策略模式来修改设计方案，以适应不同的促销手段。策略模式是一种行为型设计模式，它定义了一系列算法，并将每一个算法封装起来，使它们可以相互替换。策略模式让算法独立于使用它的客户端。
 具体来说，可以定义一个抽象类或接口促销策略，它有一个抽象方法计算优惠金额。然后定义不同的促销策略类，如618活动、双十一活动等，它们都实现或继承促销策略类，并重写计算优惠金额方法。最后，在订单类中增加一个属性促销策略，并在计算总价方法中调用促销策略的计算优惠金额方法。
 这样做的好处是，可以根据不同的活动动态地选择不同的促销策略，而不需要修改订单类的代码。这符合开闭原则（对扩展开放，对修改关闭）和单一职责原则（每个类只负责一件事）。
 修改后的设计方案如下：
 

• （21.综合.4）互联网技术和智能手机的普及，使得人们出行方式发生了改变，人们可以通过叫车系统呼叫或预约汽车，送顾客到目的地，系统根据行程的距离、用车时段、车型以及是否拼车等方式计算出行费用，用户到达目的地后再结算费用并评价司机服务。其中叫车系统提供三种出行方案：快车、出租车和顺风车。其中快车方式，用户可以选择车型，不同车型价格不同；出租车方式，用户可以添加调度费来召唤出租车；顺风车方式，用户可以选择是否拼车。如果用户的用车时间恰恰是在高峰时段，那么总费用将上浮40%。用户可以通过充值的方式给自己账户充钱，也可以通过绑定银行卡的方式，结算费用时直接扣去银行卡余额。叫车系统对于司机需要认证，主要通过身份证和机动车驾驶证，同时，根据用户用车后的评价，给予司机奖励和提成，差评率高的司机将进入黑名单，好评率高的司机将优先推荐。
  （1）使用用例图表述系统的功能。
  （2）使用类图表述支撑系统功能的主要分析类和类间关系，每个类要给出必要的属性与操作。

(1)用例图

(2)类图

U8 需求建模：基于场景的方法

U10 需求建模：行为和模式

数据流图

• 数据流图所描述的是实际系统的物理模型
  

• 用户取钱例子

  • 外部实体：储户、日历
  • 处理(数据变换)：检验、登录、付款
  • 数据存储：帐卡、存折

  

• 使用分层的方式表示：

  • 第一个数据流模型 (第0层DFD，也称环境图)表示整个系统，随后的数据流图改进环境图，在每个后续层提供更多的细节。
  • 当把DFD逐步细化时，分析师同时也就完成了系统功能分解。
  • 与此同时，当数据在应用系统中的多个处理间流动时，DFD的精炼结果导致了相应的数据精化。

• 导出数据流图的指导原则：
  (1) 第0层DFD（也称环境层DFD或顶层DFD）将系统描述成一个泡泡；
  (2) 仔细标记主要的输入和输出；
  (3) 通过把选定的处理、数据对象和数据存储分离为下一层表示而开始精化过程，即逐步求精，一次精化一个处理；
  (4) 使用有意义的名称，标记所有的箭头和泡泡；
  (5) 从一层转至另一层时，注意保持信息流的连续性；
  (6) 一次精化一个泡泡。
  

SafeHome案例

• 根据语法解析：
  • 动词是SafeHome的处理，在后续的DFD中用泡泡表示；
  • 名词是外部实体(方框)、数据或控制对象(箭头)、数据存储(双横线)。
• 在任何DFD层次中对某个泡泡的处理叙述文字进行语法解析，可以产生许多如何精化到下一个层次的有用信息。
  • 例如，第0层DFD可以扩展为6个处理

顺序图

• 顺序图将交互关系表示为一个二维图：
  • 用时间函数表明事件如何引发从一个对象到另一个对象的转移。
  • 箭头：代表一个事件；
  • 时间纵向向下度量，消息从左到右排列；
  • 纵向矩形：表示处理某个活动所用的时间。
    

状态图

• 为每个类呈现了主动状态和导致这些主动状态变化的事件
• 每个箭头表示某个对象从一个主动状态转移到另一个主动状态。
• 每个箭头上的标注都体现触发状态转移的事件。
  

数据字典（结构化分析）

• 管理各种关系模型中的信息，具体信息包括：
  • 一般信息：名字、别名、描述等；
  • 定义信息：数据类型、长度、结构；
  • 使用特点：值的范围、使用频率、使用方式；
  • 控制信息：来源、使用它的程序；
  • 分组信息：父结构、从属结构、物理位置等；
• 数据元素组成数据对象的方式：
  • 顺序：两个或多个分量以确定次序进行连接；
  • 选择：从两个或多个可能的元素中选取一个；
  • 重复：把指定的分量重复零次或多次。
• 符号：
  • = 等价于
  • +和
  • [ ]或 (选择一个，用|隔开分量)
    • 字母或数字 = [字母字符 | 数字字符]
  • { } 重复 ，(左右的数字分别为重复次数的上、下界)
    • 字母数字串 = 0{字母或数字}7 (可重复0-7次)
  • ( ) 可选 (即从括号从中任选一项，也可一项都不选)
    
    

判定表

• 如果数据流图的加工需要依赖多个逻辑条件的取值，使用判定表来描述比较合适
• 一个表格，描述条件和条件导致的动作的集合：
  

出卷系统案例

1. 问题描述

   • 系统支持人工辅助出卷和自动出卷：
     • 自动出卷：根据教师出卷要求，抽取题目，自动得到一份试卷；
     • 人工辅助出卷：根据教师出卷要求，抽取符合要求的题目，供教师选择。
     • 出卷要求包括总分，总难度及其比例，总题型及其比例，总知识点及其比例。
   • 系统能进行题库管理：
     • 包括试题录入、修改、删除等；
     • 至少有1000道不同类型的试题；
     • 能容纳足够多的试题；
     • 试题含有内容、答案、题型、难度、知识点和加入时间等信息。
   • 系统能支持不同科目；
   • 系统有一个好的图形界面；
   • 试题不允许重复出现；
   • 试卷符合要求的96%以上即可结束，允许教师调整。
   • 能进行试卷分析。

2. 功能分析

   • 用户：教师、学生、题库维护人员。
   • 用户的各自问题：
     • 教师：出一份合理的试卷，并能根据样式打印与输出；
     • 学生：通过生成一些模拟试题，进行在线学习和检查学习结果；
     • 题库维护人员：添加、更新、删除试题。
   • 精化后的问题：
     • 教师：自动出卷、手动出卷、试卷编辑、试卷输出；
     • 学生：随机抽卷、在线练习、在线评价；
     • 题库维护人员：试题管理。
   • 系统的功能需求：
     • 自动出卷：根据教师要求自动生成一份合理的试卷；
     • 手动出卷：教师手动从候选试题中挑选题目；
     • 试卷编辑：更新试题；
     • 试卷输出：根据某个样式输出试卷。
     • 随机抽卷：随机抽取试题，生成一份试卷；
     • 在线练习：学生可以在线做练习和查看答案；
     • 在线评价：根据测试结果，评价学生的表现；
     • 试题管理：管理人员维护题库中的试题；

• 顶层数据流图
  

• 一层数据流图
  

• 二级数据流图（自动出卷部分）
  

• 出卷功能初步的ER图：
  

• “试卷”的数据字典：
  

• “出卷要求”的数据字典：
  

短信系统案例

1. 问题描述

   • 基本目的：利用快捷的短信业务，发送即时消息以支持企事业单位进行信息通知、通告等各种服务，以及用短信进行客户服务。
   • 短信发送：客户选择若干个目标人员，编辑内容，立即或定时发送通知信息。
   • 短信人工应答：用户查看收到的短信内容，并可回复。
   • 短信自动应答：根据短信询问内容，并依据规则自动回复询问者。
   • 短信接收：接收外部短信。
   • 短信确认：确认接收方是否接收。
   • 客户资料维护：添加、删除和更新用户。
   • 接口要求：支持移动终端通过串口通信，支持与移动网关通信。

2. 功能分析

   • 用户：收发人员、管理人员
   • 用户的各自问题：
     • 收发人员：负责发送短信给用户或接受用户短信；
     • 管理人员：添加、更新、删除用户。
   • 功能需求：
     • 用户：
       • 短信发送：填写发送内容、选择发送用户、指明是否要回执、然后（通过无线终端或短信网关）发送短信；
       • 短信接收：从无线终端或短信网关读取短信内容，并查看；
     • 管理员：
       • 用户管理：添加用户、更新用户、删除用户。
       • 系统设置

• 用例场景：

  • 发送短信的场景描述：
    • 用户输入短信内容；
    • 用户选择若干个发送人员；
    • 系统将明文短消息编码成格式化的短消息串；
    • 系统以串行方式将短信串传入无线移动终端。
  • 接收短信的场景描述：
    • 用户向串口发送指令从无线移动终端读取一组短消息串；
    • 系统将一组短信串解码成明文的短消息；
    • 系统将短消息写入数据库，并显示给用户。
  • 人员维护的场景描述：
    • 管理员添加一个新成员；
    • 管理员更新一个成员的信息；
    • 管理员删除一个成员。
  • 系统设置的场景描述：
    • 管理员修改基本信息：如短信客服中心号码、发送频率、延时等；
    • 系统保存设置信息。

• 类包括：

  • 边界类：用于建立系统与其参与者之间交互的模型，经常代表对窗口、屏幕、打印机接口等抽象：
    • 发送短信界面、接收短信界面、收发接口；
  • 控制类：用于协调、排序、事务处理以及其它的对象控制：
    • 发送短信、接收短信；
  • 实体类：业务实体：
    • 短信编/解码、发送的短信串、接收的短信串；

• 发送短信用例的协作图：
  

• 发送短信用例的顺序图(时序图)：

题目

• 在结构化分析方法中，（ C ）表达系统内部数据运动的图形化技术。
  A、数据字典
  B、实体关系图
  C、数据流图
  D、状态转换图

数据流图（Data Flow Diagram，DFD）是一种图形化的工具，用于描述系统中数据的流动和处理过程。数据流图能帮助分析人员和开发人员更好地理解和描述系统的功能和数据流程，从而进行需求分析、系统设计和功能实现。

• 数据流图(DFD: Data Flow Diagram)描绘系统的逻辑模型。它是软件开发（ D ）阶段经常使用的工具。
  A、软件维护
  B、软件测试
  C、详细(过程)设计
  D、需求分析

数据流图可以通过图形化的方式描述系统的功能、数据流动和处理过程，帮助分析人员和开发团队理解系统的需求和功能。在需求分析阶段，数据流图可以用于捕捉和表示用户需求、业务过程以及数据在系统中的流动和处理。

• （21.综合.4）互联网技术和智能手机的普及，使得人们出行方式发生了改变，人们可以通过叫车系统呼叫或预约汽车，送顾客到目的地，系统根据行程的距离、用车时段、车型以及是否拼车等方式计算出行费用，用户到达目的地后再结算费用并评价司机服务。其中叫车系统提供三种出行方案：快车、出租车和顺风车。其中快车方式，用户可以选择车型，不同车型价格不同；出租车方式，用户可以添加调度费来召唤出租车；顺风车方式，用户可以选择是否拼车。如果用户的用车时间恰恰是在高峰时段，那么总费用将上浮40%。用户可以通过充值的方式给自己账户充钱，也可以通过绑定银行卡的方式，结算费用时直接扣去银行卡余额。叫车系统对于司机需要认证，主要通过身份证和机动车驾驶证，同时，根据用户用车后的评价，给予司机奖励和提成，差评率高的司机将进入黑名单，好评率高的司机将优先推荐。
  （1）使用用例图表述系统的功能。
  （2）使用类图表述支撑系统功能的主要分析类和类间关系，每个类要给出必要的属性与操作。
  （3）分析系统第0层和第1层的数据流图。

(1)用例图

(2)类图

(3)数据流图
第0层数据流图

第1层数据流图

（21.简答.1）请简要说明你对顺序图和状态图使用的看法？

顺序图（Sequence Diagram）：
顺序图主要用于描述系统中对象之间的交互和消息传递顺序。它展示了对象之间的时序关系，有助于理解系统的行为和交互流程。
顺序图适用于以下情况：

• 显示对象之间的消息传递和交互顺序，可以帮助捕捉系统的时序逻辑。
• 描述用例场景或特定操作的流程，以便识别参与者和对象之间的交互。
• 强调时间和顺序对系统行为的影响。

状态图（State Diagram）：
状态图主要用于描述系统或对象的状态和状态之间的转换。它展示了对象在不同状态下的行为和响应，以及导致状态转换的事件和条件。
状态图适用于以下情况：

• 描述对象的生命周期和状态转换，特别适用于具有复杂状态和状态变化的系统。
• 显示系统的不同状态和状态之间的转换条件，有助于识别系统的行为和响应。
• 捕捉对象或系统的状态行为和约束，以便更好地设计和实现系统。

综上所述，顺序图和状态图在软件系统建模中起着不同的作用。
顺序图主要关注对象之间的交互和消息传递顺序，
而状态图主要关注对象的状态和状态之间的转换。
选择使用哪种图取决于想要描述的系统行为和需求，以及希望强调的方面。通常，在系统设计和开发过程中，这两种图经常结合使用，以提供更全面和准确的系统模型。

U11 设计概念

11.1 软件工程中的设计

• 软件的设计是将需求转变为软件陈述（表达）的过程。系统通过逐步求精，使得设计陈述逐渐接近源代码：

  • 第一步是初步设计（Preliminary design），关注于怎么将需求转换成数据和软件框架。
  • 第二步是详细设计（Detail design），关注于将框架逐步精细化为具体的数据结构和软件的算法表达。设计行为、数据、算法和程序设计都需要由现代程序所需的界面设计这一清晰的行为来结合起来。

• 需求模型提供了创建四种设计模型所需信息：

  • 数据/类设计：将类模型转化为设计类以及目标软件的结构；
  • 体系结构设计：定义了软件的主要构造元素间的联系；
  • 接口设计：描述了软件和协作系统之间、软件和使用人员之间的通信；
  • 构件级设计：将软件体系结构的构造元素变换为对软件构件的过程性描述。

11.2 设计过程

11.3 设计概念

抽象

控制复杂性的基本策略，是人类处理问题的基本方法	
过程：从特殊到一般的过程，上层概念是下层概念的抽象，下层概念是上层概念的精化和细化

两种不同的抽象

1. 数据抽象：描述数据对象的数据集合。

   • 定义数据类型和施加于该类型对象的操作。
   • 门的数据抽象包含一组描述门的属性 (例如，门的类型、转动方向、开门方法、重量和尺寸)。

2. 过程抽象：具有明确和有限功能的指令序列。

   • 过程抽象的命名暗示了功能，但是隐藏了具体的细节。
   • 这些功能实际上是由一系列更低级的功能或代码来实现的。
   • 过程抽象“开”将利用数据抽象“门”的属性中所包含的信息。
   • 过程抽象例：函数、功能性的类/对象 (开门包括：走到门前，伸出手并抓住把手，转动把手并拉门，从移动门走开等)。

体系结构

体系结构是程序构件(模块)的结构和组织、这些构件交互的形式以及这些构件所用数据的结构。

体系结构设计的属性

1. 结构特性。
   • 定义了系统的构件(如模块、对象、过滤器)、构件被封装的方式以及构件之间相互作用的方式。例如，对象封装了数据和过程，过程操纵数据并通过方法调用进行交互。
2. 外部功能特性。
   • 应当指出设计体系结构如何满足需求，这些需求包括：性能需求、能力需求、可靠性需求、安全性需求、可适应性需求以及其他系统特征需求。
3. 相关系统族。
   • 体系结构应当能抽取出在一类相似系统开发中经常遇到的重复性模式。本质上，设计应当能够重用体系结构构件。

模式

关注点分离

模块化

信息隐蔽

功能独立

功能独立性的指标：内聚与耦合

内聚度

• 内聚(cohesion)：一个模块内部各个元素彼此结合的紧密程度：

  1. 一个内聚的模块执行一个独立的任务，与程序的其他部分构件只需要很少的交互。一个内聚的模块应该 (理想情况下)只完成一件事情。为了实现良好的设计，应该避免“分裂型”构件 (某个构件执行多个无关功能)。
  2. 尽量高！

七层次

巧合内聚(偶然内聚)：将几个模块中的相同程序代码段独立出来建立的模块 (无明显独立性)。
逻辑内聚（实用内聚）：完成一组逻辑相关任务的模块，由控制型参数来确定执行哪一种功能 (选择其中一个功能，内聚性不强)。
时间内聚：模块中的多个任务必须在一段时间内先后执行 (有时间约束，无明确的过程约束)。
过程内聚：模块内的多个任务必须按指定的过程执行。
通信内聚：模块内所有处理元素都集中在某个数据结构的一块区域中 (例如，对课程进行选、退课和查询)。
顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行 (更加单一的过程内聚)。
功能内聚：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的 (单个功能)。

耦合度

• 耦合(coupling)：模块之间相互关联的程度：
  1. 尽量低！

七层次

内容耦合：一个模块可以直接访问另一个模块的内部数据或内部功能。
公共耦合：多个模块共同访问某些公共数据元素。
外部耦合：多个模块间需要遵循同样的外部约束，例如通信协议、数据格式等。(遵循全局的约束)
控制耦合：模块间的交互参数包含控制信息，可影响另一个模块的执行逻辑。
标记耦合：模块间传递特定的数据结构。
数据耦合：模块间仅传递简单数据。
非直接耦合：两个模块可以相对独立工作。

11.4 设计模型

题目

• 软件详细设计的主要任务是确定每个模块的（ A ）。
  A、算法和使用的数据结构
  B、外部接口
  C、功能
  D、编程
• 软件设计 (Software Design) 是软件开发的关键步骤，直接影响软件的质量。下述（ D ）不是软件设计阶段所应包含的工作？
  A、软件(体系)结构
  B、软件过程(构件)
  C、用户接口
  D、软件风险分析
• 软件设计是软件开发的关键步骤，直接影响到软件的质量。软件设计复审是和软件设计本身一样重要的环节，其最主要的目的是（ C ）。
  A、减少测试工作量
  B、减少编程工作量
  C、避免后期付出高代价
  D、缩短软件开发周期

U12 体系结构设计

什么是体系结构

体系结构的概念
  也称架构，它是系统的一个或多个结构。它包括：构件，构件的外部可见属性以及它们之间的相互关系。

体系结构类型

• 单主机结构：
  • 界面、数据和程序集中在单台主机上；
  • 不需要考虑多用户并发操作的问题。
• C/S (Client/Server)结构：
  • 常见的服务器端体现为关系数据库；
  • 客户端负责显示和业务逻辑处理；
  • 在部署和扩展性方面存在不足：系统升级需要一一更新所有客户端。
• B/S (Browser/Server)结构：
  • 瘦客户端：浏览器或客户端程序(Applet等)

体系结构风格

以数据为中心的体系结构：

• 也称仓库。
• 数据存储驻留在体系结构的中心，其他构件访问该数据存储，并进行各种数据操作(更新、增加、删除或修改)。
• 黑板(变种)：当用户感兴趣的数据发生变化时，它将通知客户软件。
  

数据流体系结构

• 当输入数据经过一系列的计算构件和操作构件的变换形成输出数据时，可应用该体系结构。例如管道—过滤器模式：
  • 拥有一组称为过滤器的构件，这些构件通过管道连接，管道将数据从一个构件传送到下一个构件。
  • 每个过滤器独立于其上游和下游的构件而工作，过滤器的设计要针对某种形式的数据输入，并且产生某种特定形式的数据输出 (到下一个过滤器)。
  • 然而，过滤器没有必要了解与之相邻的过滤器的工作。
    
• 优点：
  • 易理解；
  • 容易并行运行。
• 问题：
  • 适用于批处理，不易交互；
  • 流的协作需要考虑。

管道—过滤器模式

• 如果数据流退化成单线的变换，则称为批序列。这种结构接收一批数据，然后应用一系列连续的构件(过滤器)完成变换。

调用和返回体系结构

• 该体系结构风格能够设计出一个相对易于修改和扩展的程序结构，存在以下子风格：

  • 主程序/子程序体系结构：将功能分解为一个控制层次结构，其中的**“主”程序调用一组程序构件，这些程序构件又去调用别的程序构件** (此时，对于被调者来说，这些主调者就是主程序)。
    

  • 远程过程调用体系结构：构件分布在网络的多个计算机上。

面向对象体系结构

• 系统的构件封装了数据和应用到该数据上的操作。
• 构件间通过消息传递进行通信与合作。

层次体系结构

• 定义了不同的层次，各个层次完成各自操作；
• 每一层为上层提供服务，又接受下层的服务；
• 优点：明确的抽象层次、易于增减或修改层次；
• 问题：系统并不是总能分层。

U13 构件级设计

设计原则

有4种适用于构件级设计的基本设计原则，使用这些原则使得产生的设计在发生变更时能够适应变更并且减少副作用的传播。

• 单一职责原则：每个类只干一件事
• 开闭原则 (The Open-Closed Principle, OCP)：模块应该对外延具有开放性，对修改具有封闭性；
• Liskov（里氏）替换原则：子类可以替换它们的基类；
• 依赖倒置原则：依赖于抽象，而非具体实现 ；
• 接口分离原则：多个用户专用接口比一个通用接口要好。

开闭原则

• 设计者应采用一种无需对构件自身内部(代码或内部逻辑)做修改就可以进行扩展的方式来说明构件。
• 解决方法：抽象、多态，引入抽象基类，构件的变化通过引入新的派生类来完成。
  
• 对于各种不同的传感器，Sensor接口都向Detector构件呈现一致的视图。如果需要添加新类型的传感器，对Detector类无需进行任何改变

Liskov替换原则

• 子类可以替换它们的基类。

• Liskov原则要求源自基类的任何子类必须遵守基类与使用该基类的构件之间的隐含约定：

  • “约定”既是前置条件—构件使用基类前必须为真；
  • 又是后置条件—构件使用基类后必须为真。
  • 当设计者创建了导出类 (子类)，则要确保这些导出类必须遵守前置条件和后置条件。

• 好处：

  • 第一、保证系统或子系统有良好的扩展性。子类能够完全替换父类，可以保证系统或子系统在运行期内识别子类就可以了。
  • 第二、实现运行期内绑定 (编译时就可以确定对象使用的形式，而不必到执行阶段)，既保证了面向对象多态性的顺利进行，又节省了大量的代码重复或冗余。避免了类似instanceof这样的语句，或者getClass()这样的语句，这些语句是面向对象所忌讳的。
  • 第三、有利于实现契约式编程。契约式编程有利于系统的分析和设计，指在分析和设计的时候，定义好系统的接口，然后在编码的时候实现这些接口即可。在父类里定义好子类需要实现的功能，而子类只要实现这些功能即可。

依赖倒置原则

• 依赖倒置原则，即父类不能依赖子类，它们都要依赖抽象类：
  • 一旦类的使用者依赖某个具体的类，那么对该依赖的扩展就无从谈起；
  • 而依赖某个抽象类，则只要实现了该抽象类的子类，都可以被类的使用者使用，从而实现了系统的扩展。
• 一个系统或子系统要拥有良好的扩展性和实现运行期内绑定，有两个必要条件：
  • 第一是里氏替换原则(子类可以替换父类，例如运动员可以替换人，人的所有属性与操作运动员都具备)；
  • 第二是依赖倒置原则(父类不能依赖于子类，例如人不能依赖于运动员，运动员的某些属性与操作有些人不具备)。

接口分离原则 (Interface Segregation Principle, ISP)

• ISP原则建议设计者应该为每个主要的客户类型都设计一个特定的接口。只有那些与特定客户类型相关的操作才应该出现在该客户的接口说明中。
• 一个肥接口（包含众多接口的总接口）应该分解成多个专门接口
  

内聚性

• 内聚性
    描述为构件的专一性。
    内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。

• 内聚性分类
  

1. 功能内聚：
     主要通过操作来体现，当一个模块中的各个部分只完成某一组特定操作并返回结果时，就称此模块是功能内聚的。(最好的内聚)
2. 顺序内聚
     模块中各个处理元素密切相关，必须顺序执行，前一功能元素的输出就是下一功能元素的输入。
3. 过程内聚：模块内的多个任务必须按指定的过程执行。
4. 通信内聚：模块内所有处理元素都集中在某个数据结构的一块区域中。（模块中所有成分引用共同的数据）
5. 时间内聚
     模块各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。
6. 逻辑内聚
     模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能。
7. 实用内聚
     逻辑上不能纳入其他内聚类型的相关实用程序放在一起，形成实用内聚 (巧合内聚)。（将多处出现的相同的一组语句用函数或者类进行封装）

耦合性

构件之间彼此联系紧密程度的一种定性度量。随着构件相互依赖的增加，构件的耦合程度也会增加。

内容耦合：一个模块可以直接访问另一个模块的内部数据或内部功能。
公共耦合：多个模块共同访问某些公共数据元素。
外部耦合：多个模块间需要遵循同样的外部约束，例如通信协议、数据格式等。(遵循全局的约束)
控制耦合：模块间的交互参数包含控制信息，可影响另一个模块的执行逻辑。
标记耦合：模块间传递特定的数据结构。
数据耦合：模块间仅传递简单数据。
非直接耦合：两个模块可以相对独立工作。

• 耦合性的分类

1. 内容耦合 (耦合度最高，最不推荐)
   包括下列情形：
    (1) 一个模块直接访问另一个模块的内部数据；
    (2) 一个模块不通过正常入口(调用或顺序执行)转到另一模块内部；
    (3) 一个模块有多个入口。
2. 共用耦合
     若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为共用(公共)耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
     缺点：进行变更时，会导致不可控制的错误蔓延和不可预见的副作用
3. 外部耦合：多个模块间需要遵循同样的外部约束，例如通信协议、数据格式等。(遵循全局的约束)
4. 控制耦合
     如果一个模块通过传送开关、标志、名字等控制信息，控制选择另一模块的功能，就是控制耦合。
     缺点：模块B中的一个不相关变更，可能会导致模块A所传递的控制标记的意义也必须发生变更。
5. 标记耦合（特征耦合）
     一个数据结构被作为参数传递。并且被调用模块只使用了部分而非全部数据。
     问题：传送了不必要的数据：
6. 数据耦合
     如果一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量)来交换信息的，则称这种耦合为数据耦合。(推荐使用的方式)
7. 非直接耦合
     两个模块可以相对独立工作。

• 模块关联的评价指标
  • 扇出：一个模块直接控制的模块数目。扇出过大意味着模块过分复杂，需要控制和协调过多的下级模块。理想的平均扇出为3-4（上限为5-9）。
  • 扇入：有多少个上级模块直接调用它。扇入越大意味着共享该模块的数目越多。
  • 设计得好的软件结构通常顶层扇出高，中层扇出少，底层高扇入。

题目

• 为了提高模块的独立性，模块内部最好是（ C ）。
  A、逻辑内聚
  B、时间内聚
  C、功能内聚
  D、通信内聚
  
• 如果一个模块完成的功能必须在同一时间内执行（如系统初始化），但这些功能只是因为时间因素关联在一起，则称为（ C ）
  A、控制内聚
  B、通信内聚
  C、时间内聚
  D、功能内聚

时间内聚是指模块中的功能被组织在一起，是因为它们必须在同一时间内执行，而不是因为它们在逻辑上紧密相关。
控制内聚是指模块中的功能紧密相关，共同实现一个控制目标。
通信内聚是指模块中的功能紧密相关，共同处理相同的输入和输出数据。
功能内聚是指模块中的功能紧密相关，共同实现一个特定的功能或者完成一个明确的任务。

class JobQueueClass
{
	public:
		int queueLength;
		int queue[25];
	public:
		void initializeJobQueue();
		void addJobToQueue();
		void removeJobFromQueue();
}

• （21.选择.1）JobQueueClass 定义如上图，则该类的内聚情况属于（ B ）。
  A、实用内聚
  B、功能内聚
  C、顺序内聚
  D、通信内聚

顺序型内聚：模块内的成分按照顺序连接，前一个成分的输出作为后一个成分的输入。这种内聚性是一种比较强的内聚性，模块的功能被划分为一系列顺序执行的步骤。
通信型内聚：模块内的成分之间通过共享数据进行通信。这种内聚性表示模块内的成分之间通过传递消息或共享数据来实现某个共同的功能。
功能型内聚：模块内的成分执行一组相关的功能，彼此之间紧密联系，共同完成一个明确的任务或功能。这种内聚性是一种比较强的内聚性。
偶然型内聚：模块内的成分之间没有明确的关联，它们被放在同一个模块中是由于历史原因、技术限制或其他非功能性因素。这种内聚性是一种较弱的内聚性，模块内部的成分之间缺乏明确的联系或目标。

U17 软件测试策略

17.1 软件测试的策略性方法

软件测试

17.2 策略问题

17.3 传统软件的测试策略

单元测试

• 概念

  • 指对软件中的最小可测试单元进行检查和验证。
  • 单元：
    • 单元就是认为规定的最小被测试的模块。
    • 一般应根据实际情况判定其具体含义，如，C中，单元指1个函数；java中，单元指1个类；图形化软件中也可以是1个窗口、1个菜单等。

• 主要对模块的五个基本特性进行评价：
  

  • 执行控制结构中的所有独立路径 (基本路径)以确保模块中的所有语句至少执行一次。

• 单元测试的特点

  • 测试驱动开发：先编写测试代码，再进行开发；进行得越早越好
  • 模块接口测试是基础：只有数据能正确流入、流出模块的前提下，其他测试才有意义。
  • 驱动模块和桩模块都是额外的开销，虽然在单元测试中必须编写，但并不需要作为最终的产品提供给用户。
  • 侧重于软件设计的最小单元的验证工作；
  • 侧重于构件中的内部处理逻辑和数据结构；

何时进行单元测试

• 通常在编码完成后进行，在前期应提前准备如：单元测试计划、编测试用例、单元测试代码等。一般由白盒测试工程师、开发人员完成。
• 单元测试的依据：源程序 (包括代码和注释)，项目的《详细设计》文档。

单元测试的一般步骤

• 编译运行程序，进行语法正确性验证；
• 静态测试，检查代码是否符合规范，参看“编码规范”；
• 动态测试，深入检查代码的正确性、容错性和边界值等。主要用白盒测试。

集成测试

单元测试的下一个阶段，指将通过测试的单元模块组装成系统或子系统，再进行测试

• 内容：
  • 单元组装后的功能正确性：是否实现预期功能；
  • 单元之间的接口：调用关系、数据传递是否正确；
  • 集成后的系统性能：集成后系统资源使用情况。

简单集成

• 问题：不推荐

一步到位的集成

所有的构件都连接在一起，全部程序作为一个整体进行测试。

• 缺点
  1. 需要所有单元就绪，由于集成测试不可以和单元测试重叠并行，因此不利于开发进度；
  2. 问题定位比较困难，集成后一旦出现问题，很难判定出错的具体原因和位置。
  3. 适合于规模较小的应用。

增量集成

程序以小增量方式进行构造和测试(更容易进行问题的定位,适合于规模较大的应用)，

• 特点
  • 增量式测试方式不需要所有单元就绪，使单元测试与集成测试的重叠并行是可行的；
  • 测试时，若发现问题，一般可定位于新加入的单元， 更容易进行问题的定位。
  • 适合于规模较大的应用。
  • 增量式测试比非增量式测试具有一定的优越性。

自顶向下测试

从主控模块开始，沿着控制层次结构逐步向下，利用深度优先或广度优先的方式将从属于主控模块的模块集成到结构中去；

• 优点：可以自然地做到逐步求精，一开始就能让测试者看到系统的框架。能较早发现高层模块的错误；

• 缺点：需要提供桩模块，并且在输入/输出模块接入系统以前，在桩模块中表示测试数据有一定困难

• 两类

  • 广度优先（横向）方式的集成：
    • 首先沿着水平方向，每一次把每一层中所有直接隶属于上一层的模块集成起来，直到底层。
  • 深度优先（纵向）方式的集成：
    • 首先集成在结构中的一个主控路径下的所有模块，主控路径的选择是任意的。

• 特点
  - 可能要编写很多桩程序
  - 主控模块错误可能发现得比较早
  

• 这种组装的方式是从程序模块结构的最顶层的模块开始组装和测试。

• 因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）并没有全部组装并测试完成，所以需要桩模块。
  

自底向上测试

从原子模块开始进行构造和测试；

• 优点：容易直接使用测试数据，易于设计测试用例；

• 缺点：直到最后一个模块被加进去之后才能看到整个程序（系统）的框架。上层模块错误发现得晚，影响范围大；

• 特点
  - 要写驱动程序
  - 主控模块错误发现得比较迟
  

• 这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。

• 因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。
  

组合方法（三明治）

用自顶向下方法测试程序结构较高层，用自底向上方法测试其从属层。

回归测试

• 在程序有修改的情况下，保证原有功能正常的一种测试策略。
• 重新执行已进行测试的某个子集，以确保变更没有传播不期望的副作用，是减少“副作用”的重要方法：
  • 这种方式采取自顶向下的方式测试被修改的模块及其子模块;
  • 然后将这一部分视为子系统，再自底向上测试。
• 每次对软件做重要变更时（包括：新构件的集成、删除、修改），要进行回归测试。

冒烟测试

• 冒烟测试主要用于在对软件进行全面测试之前，快速验证系统的基本功能和稳定性。

• 冒烟测试是一种常用的集成测试方法，被设计为一种时间关键的项目步进机制，允许软件小组经常性地评估其软件项目。冒烟测试包括以下活动：

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

• 冒烟测试应该对整个系统进行彻底的测试。它不一定是穷举的，但应能暴露主要问题。冒烟测试应该足够彻底，以使得若构建 (build)通过测试，则可以假定它足够稳定以致能经受更彻底的测试。

17.4 面向对象软件的测试策略

17.5 确认测试

• 确认测试始于集成测试的结束，那时已测试完单个构件，软件已组装成完整的软件包，且接口错误已被发现和改正。
• 软件确认是通过一系列表明与软件需求相符合的测试而获得的

α测试

α测试是由有代表性的最终用户在开发者的场所进行。软件在自然的环境下使用，开发者站在用户的后面观看，并记录错误和使用问题。α测试在受控的环境下进行

β测试

β测试在一个或多个最终用户场所进行。与α测试不同，开发者通常不在场，因此， β测试是在不为开发者控制的环境下软件的“现场”应用。最终用户记录测试过程中遇见的所有问题，并定期地报告给开发者。

17.6 系统测试

• 系统测试实际上是对整个基于计算机的系统进行一系列不同考验的测试。虽然每个测试都有不同的目的，但所有测试都是为了验证系统成分已正确地集成在一起且完成了指派的功能。
• 一些典型的系统测试包括：
  • 恢复测试
  • 安全测试
  • 压力测试
  • 性能测试
  • 部署测试

17.7 调试技巧

题目

（21）你现在正在测试一个学籍管理系统。假设你已经完成“学生选课“功能的测试，正在对“课程设置”功能进行测试。现在你发现“课程设置"功能中有一个错误，并进行了改动。按照软件工程测试的要求，此时你应该做（ B ）。
A、冒烟测试
B、回归测试
C、集成测试
D、确认测试

回归测试是在对软件进行更改或修复后重新运行现有的测试用例，以确保已修复的错误没有引入新的错误或没有破坏现有的功能。在这种情况下，你已经发现并更改了“课程设置”功能中的错误，现在需要对整个系统进行回归测试，以确保修复过程中没有引入其他问题，并且之前通过的测试用例仍然能够通过。
冒烟测试主要用于在对软件进行全面测试之前，快速验证系统的基本功能和稳定性。
集成测试是用于测试多个组件或模块在一起协同工作的测试。
确认测试是由最终用户或客户进行的测试，旨在确认软件是否符合其需求和期望。在这种情况下，回归测试是最适合的选择。

• 软件测试分成几个步骤，其中的（ A ）是在模拟的环境下，运行黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。任务是验证软件的功能和性能及其他特性是否与用户的要求一致。
  A、确认(有效性)测试
  B、集成(组装)测试
  C、模块(单元)测试
  D、并行(平行)测试

确认(有效性)测试：确认测试是一种验证软件是否符合需求的测试方法，旨在确保软件满足用户的期望和规格说明书的要求。
集成(组装)测试：集成测试是在将多个模块或组件组装在一起后进行的测试，以验证它们在联合工作时是否正常运行。
模块(单元)测试：模块测试是对软件中的独立模块或单元进行测试，以验证其功能的正确性和预期行为。
并行(平行)测试：并行测试是指在相同环境中同时运行两个或多个版本的软件，以比较它们之间的性能、功能和其他特性的差异。

• 下面哪一个选项不属于系统测试（ A ）。
  A、回归测试
  B、安全测试
  C、性能测试
  D、压力测试

回归测试：回归测试是在进行系统修改或更新后执行的测试，旨在确保新的修改不会影响现有功能的正确性。是集成测试的一种
安全测试：安全测试是验证系统在安全方面的漏洞和弱点的测试，以保护系统免受未经授权的访问、数据泄露或其他安全威胁。
性能测试：性能测试是评估系统在各种负载和压力条件下的性能表现，包括响应时间、吞吐量和资源利用率等方面。
压力测试：压力测试是通过将系统置于负载或压力的最大限度下进行测试，以评估系统的稳定性和可靠性，以及在超负荷条件下的性能表现。

• 软件测试分成几个步骤，其中的集成测试一般要在（ C ）完成后才能进行。
  A、确认(有效性)测试
  B、验收(接收)测试
  C、模块(单元)测试
  D、并行(平行)测试

• ( D )是软件投入市场前由支持软件预发行的客户对FLURPSS进行测试，是软件的多个用户在实际使用环境下进行的测试，开发者通常不在测试现场。
  A、验收测试
  B、功能测试
  C、α测试
  D、β测试

验收测试：验收测试是在软件开发完成后，由用户或客户进行的测试，以确认软件是否满足其要求和期望。验收测试是软件开发的最后阶段，开发者和用户共同参与。
功能测试：功能测试是验证软件的功能是否按照规格说明书和需求定义进行设计和实现的测试。它主要关注软件的功能是否符合预期，功能测试可以在开发过程的各个阶段进行。
α测试：α测试是在软件开发的早期阶段由开发者或内部测试团队进行的测试。它主要用于发现和修复软件中的缺陷和问题，在软件投入市场前的内部测试阶段进行。
β测试：β测试是软件的多个用户在实际使用环境下进行的测试，通常由终端用户或特定目标用户参与，开发者通常不在测试现场。

• 单元测试的测试用例主要根据（ D ）的结果来设计。
  A、需求分析
  B、源程序
  C、概要设计
  D、详细设计

• (21)以下是三个类的代码片段，请根据代码信息，说说在 RootedTreeClass 类已经通过测试的情况下，BinaryTreeClass 和 BalanceBinaryTreeClass 该如何测试。

class RootedTreeClass
{	...
	void displayNodeContents(Node a);
	void printRoutine(Node b);
	//...
}

class BinaryTreeClass extends RootedTreeClass
{	...
	void displayNodeContents(Node a);
	//...
}

class BalanceBinaryTreeClass extends BinaryTreeClass
{	...
	void printRoutine(Node b);
	//...
}

根据代码片段提供的信息，可以进行以下测试：
 BinaryTreeClass 的测试：
 由于 BinaryTreeClass 是 RootedTreeClass 的子类，并继承了 displayNodeContents(Node a) 方法，可以针对该方法进行测试，以确保在 BinaryTreeClass 中的实现是否正确。测试时可以创建一个 BinaryTreeClass 的实例，调用 displayNodeContents(Node a) 方法，并验证输出结果是否符合预期。
 BalanceBinaryTreeClass 的测试：
 BalanceBinaryTreeClass 是 BinaryTreeClass 的子类，并继承了 printRoutine(Node b) 方法。在测试 BalanceBinaryTreeClass 时，需要对 printRoutine(Node b) 方法进行测试，以验证其在 BalanceBinaryTreeClass 中的实现是否正确。测试时可以创建一个 BalanceBinaryTreeClass 的实例，调用 printRoutine(Node b) 方法，并检查输出结果是否符合预期。
 需要注意的是，由于 BalanceBinaryTreeClass 是 BinaryTreeClass 的子类，而 BinaryTreeClass 又是 RootedTreeClass 的子类，所以在测试 BalanceBinaryTreeClass 时，也应该考虑继承自父类的方法和功能是否正常工作。可以选择一些典型的测试用例，对继承自父类的方法进行测试，以确保继承关系的正确性。
 总结：
 在RootedTreeClass 类已经通过测试的情况下，针对 BinaryTreeClass 和 BalanceBinaryTreeClass，主要测试继承自父类的方法的正确性。对于 BinaryTreeClass，测试 displayNodeContents(Node a) 方法；对于 BalanceBinaryTreeClass，测试 printRoutine(Node b) 方法，并确保继承关系的正确性。

U18 测试传统的应用程序

18.1 软件测试基础

18.2 测试的内部视角和外部视角

• 黑盒测试：
  • 在软件接口处进行测试，检查系统的功能方面，不需了解软件的内部结构。
• 白盒测试：
  • 检查软件的过程细节，测试贯穿软件的逻辑路径和构件间的协作。
  • 将获得“百分之百正确的程序”？
  • 百分之百的正确性的测试前提是：通过所有的逻辑路径和相应的所有用例——几乎不可能。

18.3 白盒测试

• 把测试对象看做一个透明盒子，利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对目标逻辑路径进行测试——也称为玻璃盒测试、结构测试或逻辑驱动测试。在测试早期进行。
• 主要对程序模块进行如下的检查：
  • 对模块的所有独立的执行路径至少测试一次；
  • 对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；
  • 在上下边界和可操作的范围内执行所有的循环；
  • 测试内部数据结构的有效性。

白盒测试主要内容（控制结构测试）

• 逻辑覆盖

  • 语句覆盖
  • 判定覆盖
  • 条件覆盖
  • 判定/条件覆盖
  • 条件组合覆盖
  • 路径覆盖

• 基本路径测试

  • 利用流图表示控制逻辑
  • 确定覆盖测试路径上界的计算（环路复杂度计算）
  • 根据流图标识独立路径
  • 用基本路径法导出测试用例

18.4 基本路径测试

• 它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合。
• 设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。

控制流图

• 一种简单的控制流表示方法；
• 圆：流图结点，表示一个或多个过程语句。
  • 处理框序列和一个菱形判定框可映射为单个结点(相对于流程图)
• 箭头：边或连接，表示控制流，一条边必须终于一个节点，即使该结点并不代表任何过程语句。
• 由边和节点限定的区间称为域，计算区域时不要忘记区域外的部分，图的外部作为一个域。
  

独立程序路径

• 独立程序路径是任何贯穿程序的，至少引入一组新的处理语句或一个新条件的执行路径。(不能由其它独立路径组合而成)
• 在图示的控制流图中，一组独立的路径是：
  path1：1 - 11
  path2：1 - 2 - 3 - 4 - 5 - 10 - 1 - 11
  path3：1 - 2 - 3 - 6 - 8 - 9 - 10 - 1 - 11
  path4：1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11
• 路径1 - 2 - 3 - 4 - 5 - 10 - 1 - 2 - 3 - 6 - 8 - 9 - 10 - 1 – 11不是独立路径。
• 路径1、2、3和4构成流图的基本集合。若设计测试强迫执行这些路径 (基本集合)，则可以保证程序中的每条语句至少执行一次，且每个条件的取真和取假都被执行。
• 基本集合不是唯一的。

环路复杂性

• 程序的环路复杂性给出了程序基本路径集合的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。
• 从流图来看，一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径。
• 计算环路复杂性
  • 流图的区域数量应该对应于环路复杂度 V(G)；
  • 给定流图G的环路复杂度 V(G)定义为：V(G) = E – N + 2
    • 其中：E为流图中的边数量，N为流图中的节点数量
  • 给定流图G的环路复杂度 V(G)也可以定义为：
    • V(G) = P + 1，其中：P为流图中的判断节点数量；

例子.导出测试用例步骤

1. 以设计或源代码为基础，画出相应的控制流图：
   ★ 合并顺序执行的语句；
   ★ 分离判定语句中的不同条件；
2. 确定所得流图的环路复杂性：确定线性独立路径的数量；
3. 确定独立路径的基本集合；
4. 准备测试用例集，强制执行基本集合中的每条路径；

• 测试用例格式：
  • 某些独立路径不能单独进行测试。也就是说，遍历路径所需的数据组合不能形成程序的正常流。在这种情况下，这些路径作为另一个路径的一部分进行测试。

基本路径	[输入的(A, B, X), 输出的(A, B, X)]
1 - 4 - 5 - 7	[(0, 1, 0), (0, 1, 0)]
1 - 4 - 5 - 6 - 7	[(0, 1, 2), (0, 1, 3)]
1 - 4 - 6 - 7	（不可能）
1 - 2 - 4 - 6 - 7	[(2, 1, 1), (2, 1, 2)]
1 - 2 - 3 - 4 - 6 - 7	[(2, 0, 2), (2, 0, 2)]

18.5 控制结构测试

18.6 黑盒测试

18.7 基于模型的测试

题目

• 软件测试分成几个步骤，其中的（ D ）通常应该先进行“桌前检查"和/或“步行检查"，再以白盒法为主，辅以黑盒法进行动态测试。该类测试可以并行进行。
  A、确认(有效性)测试
  B、验收(接收)测试
  C、模块(单元)测试
  D、并行(平行)测试

• 在白盒测试技术测试用例的设计中，（ B ）是最强的覆盖标准。
  A、语句覆盖
  B、路径覆盖
  C、条件组合覆盖
  D、判定覆盖

• 在白盒测试技术测试用例的设计中，（ A ）是最弱的覆盖标准。
  A、语句覆盖  
  B、路径覆盖
  C、条件组合覆盖
  D、判定覆盖

• 黑盒测试在设计测试用例时，主要研究（ A ）。
  A、需求规格说明于概要设计说明
  B、详细设计说明
  C、项目开发计划
  D、概要设计说明与详细设计说明

• (21.综合.3)现有一段程序如下图，要求：
  （1）给出以上程序对应程序控制流图（自行在代码上标出测试节点编号）。
  （2）本段程序存在多少个独立路径？
  （3）给出一组包含全部独立路径的测试集。

void task(int x, int y)
{
	int a;
	while(x<y)
	{
		if( (x<1)&&(y<10) )
		{
			y = x + y;
		}
		if( (x == 5)||(y>8) )
		{
			a = x*y;
		}
		x++;
	}
	printf("%d, %d, %d", x, y, a);
}

（1）以下是给定程序的控制流图（包括标注的测试节点编号）：

（2）该程序存在 6个独立路径。
V(G)=E-N+2=13-9+2=P+1=5+1=6
path1:1-9
path2:1-2-3-4-5-6-7-8-1-9
path3:1-2-5-6-7-8-1-9
path4:1-2-3-5-6-7-8-1-9
path5:1-2-3-4-5-6-8-1-9
path6:1-2-5-7-8-1-9
方法：
找到所有两两之间矛盾的判断条件（2-3,5-7）（3-6,6-8）
找到存在合理测试用例（不含矛盾条件判断）的最短路径和最长路径，把每条捷径依次替换到最长路径中找到其他路径。
（3）给出一组包含全部独立路径的测试集：

输入数据（x,y,a）	预期输出结果(x,y,a)	覆盖的独立路径
(1,1,0)	(1,1,0)	路径1
(0,9,0)	(9,9,72)	路径2
(8,9,0)	(9,9,72)	路径3
(0,10,0)	(10,10,90)	路径4
(0,8,0)	(8,8,40)	路径5
(5,6,0)	(6,6,30)	路径6

2. 下图的代码片段，请你采用基本路径测试方法进行测试。要求：
   1. 画出相应的程序控制流图。
   2. 分析该段程序的环路复杂性；
   3. 什么是独立路径？给出该程序的一组独立路径。
      
      环路复杂度V(G)=P+1=5+1=6
      1,3,6,9,10
      

void quick_ sort(int data[], int low, int high)
{
	int i, j, pivot;
	if (low < high)
	{
 		pivot=data[low]; 
 		i=low;
 		j=high;
		while(i<j)
		{
 			while(i<j && data[j]>=pivot)
 			 j--;
 			if(i<j)
  				data[i++]=data[j]; //将比枢轴记录小的记录移到低端
 			while (i<j && data[i]<=pivot)
 				 i++;
 			if(i<j)
  				data[j--]=data[i]; //将比枢轴记录大的记录移到高端
		}
		data[i]=pivot; //枢轴记录移到最终位置
 		quick_sort(data, low, i-1);
 		quick_sort(data, i+1, high);
	}
}

以上为一个快速排序算法的代码段，请你采用基本路径测试方法进行测试。
要求：
①画出相应的程序控制流图；
②分析该段程序的环路复杂性；
③什么是独立路径？给出该程序的一组独立路径。

（1）

（2）程序的环路复杂性为4，表示需要至少执行4条独立路径才能覆盖所有的语句和分支。
（3）以下是一组独立路径：

• Start -> if (low < high) -> while (i < j) -> while (i < j && data[j] >= pivot) -> if (i < j) -> data[i++] = data[j] -> while (i < j && data[i] <= pivot) -> if (i < j) -> data[j–] = data[i] -> data[i] = pivot -> quick_sort(data, low, i-1) -> Return
• Start -> if (low < high) -> while (i < j) -> while (i < j && data[j] >= pivot) -> if (i < j) -> data[i++] = data[j] -> quick_sort(data, low, i-1) -> quick_sort(data, i+1, high) -> Return

这是两个独立路径的示例，覆盖了程序中的所有语句和分支。

U19 测试面向对象的应用

题目

• U19课后习题
  （1）黑盒测试是从（）观点出发的测试，白盒测试是从（）观点出发的测试
  A、开发人员，管理人员
  B、用户，管理人员
  C、用户，开发人员
  D、开发人员，用户

答案：C

（2）使用白盒测试时，确定测试用例应根据（）和指定的覆盖标准

A、程序的内部逻辑
 B、程序的复杂结构
 C、使用说明书
 D、程序的功能

答案：A

（3）软件测试的目的是（）

A、证明软件的正确性
 B、找出软件中存在的所有错误
 C、证明软件中存在错误
 D、尽可能多地发现软件中的错误

答案：D

（4）从下列叙述中，选出依次分别与需求分析、设计、编码相对应的软件测试：
A、集成测试，确认测试，单元测试
 B、单元测试，集成测试，确认测试
 C、单元测试，确认测试，集成测试
 D、确认测试，集成测试，单元测试

答案：D

（5）一般来说，与测试数据无关的文档是（）
A、需求规格说明书
 B、设计说明书
 C、源程序
 D.、项目开发计划

答案：D

U21 软件配置管理

软件配置管理概述

软件维护

• 软件维护(也称软件支持)的类型有三种：

  • 改正性维护：为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的不当使用。
  • 适应性维护：为使软件适应外部环境和数据环境的变化，而去修改软件的过程就叫做适应性维护。
  • 完善性维护：为满足在软件使用过程中，用户对软件提出新的功能与性能要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、提高软件的可维护性。

• 实践表明，在几种维护活动中，完善性维护所占的比重最大。即大部分维护工作是改变和加强软件，而不是纠错。

题目

• 软件维护时(maintenance) ，为扩充功能和改善性能而进行的修改，主要对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征，这种为改善性能、可维护性或其他软件属性而进行的维护一般被称为（ C ）。
  A、适应性维护
  B、纠错性维护
  C、完善性维护
  D、逆向(再生)工程

适应性维护：指为了适应环境变化或新需求而对软件进行修改的维护类型，通常是通过添加新功能或进行适应性调整来应对变化。
纠错性维护：指修复已经发现的软件缺陷或错误的维护类型，旨在使软件恢复到预期的功能状态。
完善性维护：指对已有软件进行修改以改进其性能、可读性、可维护性或其他非功能特征的维护类型。
逆向(再生)工程：指对已有软件系统进行分析和研究，以获取其内部结构、功能和设计原理等信息的过程。

• 下列哪种维护类型是针对已有软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征，为改善性能、可维护性或其他软件属性而进行的维护？（ C ）
  A、更正性维护
  B、适应性维护
  C、完善性维护
  D、预防性维护

完善性维护：针对已有软件系统增加功能与性能特征的维护类型
更正性维护：修复已有软件系统中的错误或缺陷
适应性维护：为了适应环境变化或用户需求变更而对软件进行修改
预防性维护：为了预防潜在的问题或故障而进行的维护活动

U22 管理软件项目

22.1 管理涉及的范围

22.2 人员

软件团队

软件团队四种范型

1. 封闭式范型。按照传统的权利层次来组织团队。当开发与过去已经做过的产品相似的软件时，这种团队十分有效。但在这种封闭式范型下难以进行创新性的工作。
2. 随机式范型。松散地组织团队，团队工作依赖于团队成员个人的主动性。当需要创新或技术上的突破时，按照这种随机式范型组织的团队很有优势。但当需要“有次序地执行”才能完成工作时，这种团队就会陷入困境。
3. 开放式范型。试图以一种既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队。良好的沟通和根据团队整体意见做出决策是开放式范型的特征。开放式范型的团队结构特别适合于解决复杂的问题，但可能不像其他类型团队那么有效率。
4. 同步式范型。 依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么主动的交流。

组织结构

• 主程序员式组织结构

  • 优点：
    —实现了项目人员分工专业化；
    —降低了管理的复杂性，提高了工作效率。
  • 缺点：
    —现实社会中，缺乏同时具备高超管理才能和技术才能的“全才”。

• 随机式组织结构

  • 随机式范型主张建立具有独立创新性的团队，其工作方式可恰当地称为创新的无政府状态。为了建成一支绩效良好的团队：
    • 团队成员必须相互信任。
    • 团队成员的技能分布必须适合于要解决的问题。
    • 如果要保持团队的疑聚力，必须将坚持将个人己见的人员排除于团队之外。

• 民主式组织结构

  • 特点：
    —成员之间关系平等；
    —根据每个人的能力和经验适当分配任务；
    —通过全体人员协商决定项目工作。
  • 优点：
    —同等项目参与权，可以激发大家的创造力，利于攻克难关；
    —适用于小规模、能力强、有共同工作经历的团队。
  • 缺点：
    —缺少权威人士，在意见分歧的情况下很难解决。

22.3 产品
22.4 过程
22.5 项目
22.6 W5HH原则
22.7 关键实践

题目

• 在一个信息系统组织中，你被指派为项目管理者。你的工作是建造一个应用，类似于你的小组以前已经做过的项目，虽然这一个规模更大且更复杂一些。需求已经由用户写成文裆。你会选择那种团队结构？
  

U23 过程度量和项目度量

23.1 过程领域和项目领域中的度量
23.2 软件测量

23.3 软件质量度量

缺陷排除效率

• 缺陷排除效率（DRE）是对质量保证及控制活动中滤除缺陷能力的一个测量，这些活动贯穿于所有过程框架活动。
• 当把项目作为一个整体来考虑时，DRE按如下方式定义：
  DRE = E /（E ＋ D）。
  • 其中： E = 软件交付之前所发现的错误数，D = 软件交付之后所发现的缺陷数
• DRE也能够用于在项目中评估一个团队在错误传递到下一个框架活动或软件工程任务之前发现这些错误的能力。DREi = Ei / ( Ei ＋ Ei+1 )。
  • 其中： Ei = 软件工程活动i中所发现的错误数，Ei+1 = 软件工程活动 i+1中所发现的错误数，这些错误起源于软件工程活动i中未能发现的错误。

题目

（计算机.20.选择8）

DRE=30/(30+20)=0.6 选B

• 根据缺陷排除效率的定义，假设一个软件项目在发布前发现了100个缺陷，而发布后又发现了50个缺陷。计算该项目的缺陷排除效率（DRE）是多少？（ C ）
  A、0.33
  B、0.5
  C、0.67
  D、0.75

根据缺陷排除效率的公式，E为发布前发现的缺陷数，D为发布以后发现的缺陷数。代入数据，我们有E = 100，D = 50。
 根据公式 DRE = E / (E + D)，将数据代入得到 DRE = 100 / (100 + 50) = 0.67。

U24 软件项目估算

基于问题的估算

计算三点估算

• 先确定规模的乐观值 (Sopt)、可能值 (Sm)和悲观值 (Spess)，再将它们结合起来 (加权平均)
• 期望值S = (Sopt + 4Sm + Spess) / 6
• 假定实际的规模结果落在乐观值与悲观值范围之外的概率很小
  

开发小组人数与软件生产率的关系

• 几个人共同承担某一任务时，他们必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。通信需花费时间，会引起错误，降低软件生产率
• 若两人之间需要通信，则称在这两人之间存在一条通信路径。如果一个软件开发小组有n人，每两人都要通信，则通信路径有n(n-1)/2(条)。
  

经验估算模型

COCOMO II模型

• 一种层次结构的估算模型，主要应用于以下领域：

  • 应用组装模型：在软件工程的前期阶段使用，使用对象点（应用点）进行估算。
  • 早期设计阶段：在需求已经稳定并且基本的软件体系结构已经建立时使用，使用FP进行估算。
  • 体系结构后阶段：在软件的构造过程中使用，使用LOC（代码行数）或FP（功能点)来进行估算。

• 对象点的计算：

  • 与功能点一样，对象点也是一种间接的软件测量。
  • 计算对象点时，使用如下计数值：
    • (1) (用户界面的) 屏幕数；
    • (2) 报表数；
    • (3) 构造应用系统可能需要的构件数。
  • 复杂度分为3个等级 (即简单、中等或困难)，将每个对象实例 (例如，一个屏幕或一个报表)分别归类到一个等级上。

• 一旦确定了复杂度，就对屏幕、报表和构件的数量进行加权。

• 首先将初始的对象实例数与表中的加权因子相乘就确定了对象点数，求和后就得到了总的对象点数。

• 当采用基于构件的开发或一般的软件复用时，还要估算复用的百分比，并调整对象点数：

  • 新对象点 = 对象点 * [(100-复用的百分比) / 100]

• 必须先确定“生产率”的值。如下表：
  

• 根据计算得到的新对象点值进行工作量估算：

  • 估算工作量 = 新对象点 / 生产率

COCOMO II模型（例）

• 使用COCOMO II模型来估算构造一个困难的ATM软件所需的工作量，
  它产生12个屏幕、10个报表，将需要大约80个软件构件。
  假定该软件具有困难复杂度和平均开发者/环境成熟度。
  要求使用基于对象点的应用组装模型计算工作量。
  • 对象点 = 12 × 3 + 10 × 8 + 80 × 10 = 916
  • 工作量 = 对象点 / 生产率 = 916 / 13 = 71 /人月
    

题目

• 设一个人单独开发软件，生产率是5000行／人年；如果多人开发软件，在每条通信路径上耗费的工作量是 250 行／人年。

  • 若 4 人组成一个小组共同开发这个软件，则需要6条通信路径，则小组中每个人的软件生产率降低为：
    5000 - 6 × 250／4 = 4625 行／人年
  • 若 10 人组成一个小组共同开发这个软件，则需要45条通信路径，则小组中每个人的软件生产率降低为：
    5000 - 45 × 250／10 = 3875 行／人年

• (21)对于一个项目的工作量，给出的乐观、可能和悲观估计分别是10、25、60人月。基于三点估算，这个项目的工作量为（ C ）人月。
  A、25
  B、31.7
  C、28.3
  D、30

  基于三点估算，可以使用PERT（Program Evaluation and Review Technique）来计算项目的工作量。PERT计算公式如下：
  工作量 = (乐观估计 + 4 * 可能估计 + 悲观估计) / 6
  在这个例子中，乐观估计为10人月，可能估计为25人月，悲观估计为60人月。
  工作量 = (10 + 4 * 25 + 60) / 6
  工作量 ≈ 28.3人月
  因此，这个项目的工作量约为28.3人月。

• (21)假设你在开发团队有3个人，每个人的生产率是3000 LOC/月，每条通信路径上的生产率开销为300 LOC/月，但是现在表明你们已经落后于进度。如果加入2个人，每个人的生产率至少是（ B ）才能使得小组能够赶上进度。
  A、1350
  B、1050
  C、2700
  D、2100

首先，需要计算目前的总生产率，即每月能完成多少LOC的代码。根据题目，一共有3个人，每个人的生产率是3000 LOC/月，但是每条通信路径上的生产率开销为300 LOC/月。通信路径是指团队成员之间的沟通和协作，如果团队有n个人，那么通信路径的数量是n * (n - 1) / 2。所以，目前的总生产率是：
(3 * 3000) - (3 * (3 - 1) / 2 * 300) = 8100 LOC/月
然后，需要计算还需要完成多少LOC的代码，才能赶上进度。假设已经完成了M LOC的代码，还剩下N LOC的代码没有完成，那么需要的时间是：
N / 8100 个月
 接下来，需要计算如果加入2个人，这两人的生产率为X LOC/月，那么总生产率会变成多少。根据题目，如果加入2个人，那么团队有5个人，通信路径的数量是5 * (5 - 1) / 2 = 10。所以，总生产率变为：
(3 * 3000 + 2 * X) - (10 * 300) = 2X + 6000 LOC/月
 最后，需要计算这两人的生产率至少是多少，才能使得小组能够赶上进度。为了赶上进度，需要在相同的时间内完成N LOC的代码，所以有以下等式：
N / (2X + 6000) = N / 8100
 解得：
X = 1050 LOC/月
 所以，如果加入2个人，每个人的生产率至少是1050 LOC/月才能使得小组能够赶上进度。

（计算机.20.选择）
D
“当采用基于构件的开发或一般的软件复用时，还要估算复用的百分比，并调整对象点数：新对象点 = 对象点 * [(100-复用的百分比) / 100]”
复用率仅作为对象点的修正参数，不直接作为估算选择

U25 项目进度安排

25.5 进度安排

关键路径法(Critical Path Method，CPM）

1. 根据指定的网络图逻辑关系和单一的历时估算，计算每一个活动的单一的、确定的最早和最迟开始和完成日期。
2. 计算浮动时间。
3. 计算网络图中最长的路径。
4. 确定项目完成时间。

• 网络图中任务进度时间参数说明
  • 最早开始时间(Early start)
  • 最晚开始时间(Late start)
  • 最早完成时间(Early finish)
  • 最晚完成时间(Late finish)
  • 自由浮动（Free Float）
  • 总浮动（Total Float）
  • 超前(Lead)：允许提前后置任务的时间
  • 滞后(Lag)：允许推迟后置任务的时间
    

关键路径（Critical Path）

• 关键路径是决定项目完成的最短时间。
• 是时间浮动为0（Float=0）的路径。
• 网络图中最长的路径。
• 关键路径上的任何活动延迟，都会导致整个项目完成时间的延迟
• 关键路径可能不止一条。
• 在项目的进行过程中，关键路径可能改变

路径2是项目X的关键路径

甘特图（时序图）

• 时序图 (timeline charts)，也叫做甘特图 (Gantt chart)。可以为整个项目建立一个时序图，或者，也可以为各个项目功能或各个项目参与者分别建立各自的时序图。
  

项目表

• 输入了生成时序图所需的信息之后，大多数软件项目进度安排工具都能生成项目表—列出所有项目任务的表格，项目表中列出了各个任务计划的开始与结束日期和实际开始与结束日期以及各种相关信息。
• 通过项目表与时序图，项目管理者就可以跟踪项目的进展情况。
  

25.6 挣值分析

• 挣值分析是在软件小组按项目进度表工作时，定量分析项目进展的技术
  • 挣值系统为每个(软件项目)任务提供通用的值尺度，可以估算完成整个项目所需要的总小时数。并且可以根据各个任务所估算的小时数占总小时数的百分比来确定该任务的挣值
• 更简单地说，挣值是对项目进展的测量。它使得计划者能够不依赖于感觉，采用定量的分析方法来评估一个项目的“完成百分比”

• 挣值确定的步骤：（都是预算，预估的工作量）

  1. 为进度表中的每个工作任务确定计划的预算成本BCWS(Budgeted Cost of Work Scheduled)：
     • 一个工作任务有一个BCWS值，特定时间点的BCWS值是在项目进度表中，该时间点应该完成的所有工作任务的BCWS值之和
     • 人话：该时刻计划完成的任务的预估工作量之和
  2. 所有任务的BCWS值相加，得工作总预算BAC (Budget At Completion)，也就是总工作量（xx 人·日）
     • 人话：所有任务的预估工作量之和
  3. 计算完成工作的预算成本BCWP (Budgeted Cost of Work Performed，也称Earned Value 获得值)：
     • 特定时间点的BCWP值，是该时间点实际完成的所有工作任务的BCWS值之和 （十分易错！！，是实际完成的任务的BCWS值之和，不是BCWP，因此和ACWP是有可能存在差异的）
     • 人话：该时刻已经完成的任务的预估工作量之和

• 进度情况评估：

  • 进度表执行指标 SPI = 实际完成工作量BCWP / 计划完成工作量BCWS
    • SPI是效率指标，指出项目使用预定资源的效率，SPI值越接近1，说明项目的执行效率越高
  • 进度表偏差 SV = BCWP - BCWS
    • SV表示与计划进度的偏差。
  • 预定完成百分比 = BCWS / 总预算BAC
    • 表示在时间点 t 应该完成工作的百分比值。
    • 人话：该时刻预估的工作完成进度（该时刻应该完成的任务的预估工作量占总预估工作量的百分比）
  • 完成百分比 = BCWP / BAC
    • 表示在特定时间点 t 实际完成工作的百分比值。
    • 人话：该时刻实际完成任务的预估工作量占总预估工作量的百分比

• 预算准确性评估：（比较预估的工作量和实际的工作量）

  • 已完成工作的实际成本ACWP (Actual Cost of Work Performed)
    • 为项目进度表中某个时间点已经完成的任务的实际工作量之和
  • 成本执行指标 CPI = BCWP / ACWP
    • CPI值越接近1.0说明项目与预算越接近。
  • 成本偏差 CV = BCWP - ACWP
    • CV表示在项目特定阶段的成本节省(相对于计划成本)或短缺

• 挣值分析在可能出现问题之前就指出了进度安排的难点，这使得软件项目管理者能够在项目危机出现前采取有效措施

题目

课堂练习
作为项目经理，你需要给一个软件项目做计划安排，经过任务分解后得到任务A，B，C，D，E，F，G，假设各个任务之间没有滞后和超前，下图是这个项目的PDM网络图。通过历时估计已经估算出每个任务的工期，现已标识在PDM网络图上。假设项目的最早开工日期是第０天，请计算每个任务的最早开始时间，最晚开始时间，最早完成时间，最晚完成时间，同时确定关键路径，并计算关键路径的长度，计算任务F的自由浮动和总浮动.

• U25 课后习题

  • 1、软件计划是软件开发的早期和重要阶段，此阶段要求交互和配合的是（ B ）
    A、设计人员和用户
    B、分析人员和用户
    C、分析人员和设计人员
    D、编码人员和用户
  • 2、在软件工程项目中，不随参与人数的增加而使生产率成比例增加的主要原因是（ D ）
    A、工作阶段的等待时间
    B、产生原型的复杂性
    C、参与人员所需电脑数
    D、参与人员之间的通信困难
  • 3、编写程序的工作量通常占用软件开发总工作量的（ D ）
    A、80%
    B、60%
    C、40%
    D、20%
  • 4、描述软件项目进度安排的甘特图能够表示（ D ）
    A、多个任务之间的复杂关系
    B、任务之间的相互依赖制约关系
    C、哪些任务是关键任务
    D、子任务之间的并行和串行关系
  • 5、可行性研究要进行的需求分析和设计应是（ C ）
    A、详细的
    B、全面的
    C、简化、压缩的
    D、彻底的

• （21）用于找到关键路径的方法是（ C ）。
  A、UP
  B、UML
  C、CPM
  D、DFD

用于找到关键路径的方法是：CPM（Critical Path Method，关键路径法）
CPM是一种项目管理技术，用于确定项目中的关键路径和关键活动。关键路径是指在项目网络图中，连接起始节点和结束节点，且具有最长时间的路径。关键路径上的活动对于项目的完成时间具有重要影响，延误任何一个关键路径上的活动都会延误整个项目的完成时间。CPM通过计算活动的最早开始时间、最晚开始时间、最早完成时间和最晚完成时间等参数，确定关键路径和项目的总工期。
UP（Unified Process，统一过程）是一种软件开发过程框架；UML（Unified Modeling Language，统一建模语言）是一种图形化建模语言；DFD（Data Flow Diagram，数据流程图）是一种描述系统功能和数据流的图形化表示方法；它们与关键路径的计算无直接关系。

（21）假定你是一个项目管理者，受命为一个小型软件项目进行挣值统计。这个项目共计划需要 200 人日才能完成，下面给出相关进度安排数据（单位：人日）。
 目前有5个工作任务已经完成，但是按照项目进度，现在应该完成7个工作任务。
 请计算：该项目的计划完成任务 BCWS、实际完成任务 BCWP、进度表执行指标 SPI、进度偏差 SV、预定完成百分比、完成百分比、已经完成任务 ACWP、成本执行指标 CPI和成本偏差 CV，并说说你认为该团队的现状如何。

任务	计划工作量	实际工作量
1	6	8
2	16	18
3	4	5
4	12	9
5	5	3
6	16	——
7	13	——

根据给出的进度安排数据，我们可以计算以下指标：

• 计划完成任务（BCWS）：该时刻，按照项目进度，目前应该完成的任务的预算成本（BCWS）之和。
  BCWS = 计划完成任务的预估工作量之和 = 6 + 16 + 4 + 12 + 5 + 16 + 13 = 72 人日
• 实际完成任务（BCWP）：目前已经完成的任务的预估工作量之和。
  BCWP = 已完成任务的预估工作量之和 = 6 + 16 + 4 + 12 + 5 = 43 人日
• 进度表执行指标（SPI）：衡量实际完成任务与计划完成任务的比例。
  SPI = BCWP / BCWS = 43 / 72 ≈ 0.597
• 进度偏差（SV）：实际完成任务与计划完成任务之间的差异。
  SV = BCWP - BCWS = 43 - 72 = -29 人日
• 预定完成百分比：该时刻应该完成的任务的预估工作量之和占总预估工作量的百分比。
  预定完成百分比 = (BCWS / BAC) * 100% = 72/200* 100% ≈ 36%
• 完成百分比：该时刻实际完成的任务的预估工作量之和占总工作量的百分比。
  完成百分比 = (BCWP / BAC) * 100% = (43 / 200) * 100% ≈ 21.5%
• 已经完成任务（ACWP）：该时刻实际完成的任务的实际工作量之和。
  ACWP = 实际工作量之和 = 8 + 18 + 5 + 9 + 3 = 43 人日
• 成本执行指标（CPI）：实际完成工作量与预算之间的比例。
  CPI = BCWP / ACWP = 43 / 43 = 1
• 成本偏差（CV）：实际完成工作量与预算之间的差异。
  CV = BCWP - ACWP = 43 - 43 = 0

根据计算的指标：

• 进度表执行指标 (SPI) 小于 1，表示项目进度滞后于计划。
• 进度偏差 (SV) 为负值，表示项目进度落后于计划。
• 预定完成百分比小于完成百分比，也说明项目进度滞后于计划。
• 成本执行指标 (CPI) 等于 1，表示实际完成工作量与预算相符。
• 成本偏差 (CV) 为零，表示实际成本与预算相符。

综上所述，该团队目前的现状是项目进度滞后于计划，但成本控制良好，实际完成工作量与预算一致。需要采取措施加快进度，以保证项目按时完成。

U26 风险管理

26.1 被动风险策略和主动风险策略
26.2 软件风险
26.3 风险识别

26.4 风险预测

评估风险影响

• 风险显露度 (risk exposure, RE)：RE = P * C
  • 其中P是风险发生的概率，C是风险发生时带来的项目成本；
    例如，假设软件团队按如下方式定义了项目风险：
    • 风险识别。计划可复用的软件构件中只有70%将集成到应用系统中，其他功能必须定制开发。
    • 风险概率。80%
    • 风险影响。计划了60个可复用的软件构件，如果只能利用70%，则18个构件必须从头开发。平均每个构件的程序行数是100 LOC，本地数据表明每个LOC的软件工程成本是$14.0，开发构件的总成本将是 C = 18 * 100 * 14 = $25200
      • 风险显露度。RE = 0.8 * $25200 = $20200

26.5 风险求精
26.6 风险缓解、监测和管理
26.7 RMMM计划

题目

• (21)团队正在开发一个智慧停车场系统，结合团队实际情况，其中一个风险为：原定复用的构件必需要自行开发，且该风险发生的概率为60%。假设该项目需要复用40个构件，每个构件预估的代码行为200 LOC，每代码行成本为15 元/LOC。则针对此风险的RE是（ D ）。
  A、1800
  B、120000
  C、48000
  D、72000

  针对风险的RE（Risk Exposure）是根据风险概率和风险影响来计算的。在这种情况下，风险是原定复用的构件必需要自行开发，且该风险发生的概率为60%。
   首先，计算风险发生的影响：
   影响 = 复用构件数量 * 每个构件的代码行数 * 每代码行的成本
   影响 = 40 * 200 LOC * 15 元/LOC = 120,000 元
  然后，计算风险的RE：
  RE = 风险概率 * 影响
  RE = 0.6 * 120,000 元 = 72,000 元
  因此，针对该风险的RE为72,000 元。