软件工程复习

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. 问题描述

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