【软件工程】期末知识点整理

软件工程

使用的是沈备军老师的软件工程原理这本书，只是自己期末复习整理的，本来还整理了一些综合题，但是图片太多了，就没有发出来了，也上传了pdf版本，需要可以自取

填空判断

绪论

• 软件组成：程序、相关数据、说明文档（逻辑而不是物理）

• 软件危机表现为供不应求而不是产品过剩

• 软件工程金三角：人、技术、管理

• 软件开发（软件需求、软件设计、软件构造、软件测试）常用建模方法：结构化方法、面向数据方法、面向对象方法、形式化方法、原型方法、敏捷方法

• 软件工程核心技术：系统工程、软件需求（用户角度，黑盒视角）、软件设计（开发人员，白盒）、编码、软件测试（自下而上，单元（程序员）/集成/确认/系统测试（后三个，软件测试工程师））、软件维护

• 软件工程根本目标是创造利益和价值

• 软件开发的复杂性：技术、需求、人（控制方法：抽象、分解、迭代）

  • 抽象：哺乳动物-灵长类动物（-人、猩猩）、啮齿动物——抽取本质 分为过程/数据抽象

  • 迭代：反复循环

软件过程

• 软件过程=软件生命周期：软件实现过程、软件支持过程、软件复用过程

• 软件过程的核心元素：活动、任务、工件、角色

• 软件生命周期模型：瀑布模型、增量模型、演化模型

  • 瀑布：要求给出所有需求、一次开发完成、技术/需求不能发生迅速变化，无法利用中间产品、资源有限

• 软件过程的评估：参考模型（CMM/CMMI、ISO/IEC 15504、ISO/IEC 20000）

  CMMI：开发/服务/采购模型，分为五个等级

  • 初始级：无序混乱、过程无定义、取决于个人努力、管理反应式

  • 已管理级：建立了基本项目管理过程来跟踪费用、进度、功能特性

  • 已定义级：文档化、标准化

  • 定量管理级：分析详细度量数据，定量

  • 持续优化级：过程的量化反馈和先进的新思想新技术促使过程持续改进

• 软件过程改进是软件产品质量改进的活动，应该按照PDCA实施，PDCA循环的四个阶段如下：

  • 计划：制定方针，改进计划书

  • 执行：落实对策

  • 检查：对策实施后把握对策的效果

  • 再行动：总结成功经验，标准化

  IDEAL过程改进模型分别为：初始化、诊断、建立、行动和扩充 P44

软件建模

• 软件模型的三个层次：CIM、PIM（需求分析阶段用）、PSM（详细设计阶段用）

  • 计算无关模型：描述了系统的需求和要被使用的语境

  • 需求

  • 平台无关模型：具有高抽象层次、独立于技术，系统的分析系统

  • 平台相关模型：技术平台

  • 编码：代码由PSM转换而来

• 软件建模方法：结构化方法、面向对象的方法、基于构件的开发方法、面向服务方法、模型驱动开发方法、形式化方法、敏捷建模方法

  • 结构化方法：模块化思想、自顶向下、逐步求精，三种基本控制结构（顺序、选择、循环）、模型的核心是数据字典并由此构建E-R图、数据流图、状态-变迁图 结构化分析的步骤：画出分层数据流图、定义数据字典、定义加工说明（描述工具：结构化语言、判定表、判定树）、画出ER图

    结构化设计的步骤：鉴别DFD的类型（变换型和事务型）、利用变换/事务映射将DFD映射到SC、优化结构设计（两头小中间大）、详细设计

  • 面向对象的方法：核心概念（对象、类、继承、消息） 面向对象的基本原则：抽象、封装（接口、多态）、模块化（高内聚低耦合、类包子系统）和层次（泛化、模式和框架的复用）原则

    用一般和特殊（分类）结构描述继承，用整体/部分（聚合）结构描述事物之间组成关系

    分析基本步骤：用例、类图、交互图

    设计基本步骤：分析设计采用相同表示法和模型结构（区别于结构化方法）

    分类：结构/行为模型P66

  • 基于构件：构件的接口包括构件特性、构件服务、构件引用

    分类：基于重用方式分为白匣子、黑匣子、灰匣子，基于使用范围分为通用、领域共性、应用专用

    不是一切从零开始

  • 面向服务：特征：松散耦合、位置透明、协议独立

    三个角色：服务注册中心、服务消费者、服务提供者 服务和构件不是一一对应关系，构件是业务实体的映射，服务是业务规则的映射

    服务的粒度更粗，不能认为对构建进行包装，注册就可以完成基于构件到服务系统的迁移

    三个主要抽象级别：操作、服务（操作的逻辑分组）、业务流程（包括多个业务调用）

    设计流程：自顶向下分解，自底向上抽象、中间汇合

  • 形式化方法：严密，包含形式化规约/开发/验证

需求工程

• FURPS+模型定义软件需求：

  • 功能性

  • 易用性

  • 可靠性

  • 性能

  • 可支持性

  • 设计约束、实现需求、接口需求、物理需求

• 软件需求的层次：项目干系人需求、前景文档、软件需求规约

面向对象的分析建模（需求）

• 面向对象分析（OOA）主要从需求分析、对象建模、用例建模、交互建模、状态建模和数据建模等方面进行系统分析。通过识别系统中的对象及其关系，设计类和对象之间的交互方式，确保系统功能和结构符合需求，进而为系统的设计和实现提供基础。

• 描述工具：用例图、活动图、类图、时序图、通信图、包图

• 类图：

  • 继承

  • 关联：如人是车的主人，永久的结构型关系

  • 聚合：车队和车，两个类独立存在

  • 组合：一部分依赖另一部分，电脑部件无法离开电脑存在

  • 依赖：一个类的行为影响了另外一个类，例如一个包依赖另一个，一个类/构件依赖于一个接口，分析阶段很少使用，非结构型关系

  • 接口和实现

• 用例建模 举例：

  • 包含：如果一个用例由一部分行为对于了解用例的主要目的不是必需，只有他们的结果才比较有意义，可以将这部分行为分离出来，形成一个新的包含用例，原用例称为基本用例（分离非主要行为）

  • 包含：多个用例存在一段共有的行为，可以将这段行为提炼，实现了复用（例如整车出库（基本用例）和财务结算都include查询购车订单）

  • 扩展：如果用例的一部分行为可选，或者只在特定条件下才执行，那么就可以将那部分分离出来形成一个新的扩展用例。简化了用例事件流的结构从而提高用例的可理解性和可扩展性（如提交购物订单->客户信息管理）

  • 如果多个用例行为结构上具有共同点且再目的上很相似，可以将公共部分分离出来形成父用例，实现了复用

  关系罗列：

  • 包含：基本用例不能单独执行，它依赖于包含用例的行为，被包含用例不孤立存在但是可以独立执行，一个基本用例可以有多个包含用例，一个包含用例可以包含在若干基本用例中（包含用例在不同位置插入） 包含关系是无条件的，如果用例实例到达基本用例中定义的包含关系的位置，就会执行包含，如果要表达包含需要及那个其作为基本用例的一部分来表达

  • 扩展：与包含不同，是隐含形式插入，扩展用例不在基本用例展示 扩展用例不能单独执行，有条件，条件在扩展关系中说明，扩展用例可以访问修改基本用例，但基本用例看不到扩展用例，无法访问他们的属性

  • 泛化：增加覆盖父类行为，子用例不受父用例影响，子用例有相似目的和结构，而包含关系中基本用例目的可以完全不同

  分析类的识别：

  • 边界类：隔离，解耦

  • 控制类：协调

  • 实体类：与外部环境弱耦合

设计工程

• 软件设计的两个阶段：架构设计（概要设计）和详细设计

• 分析模型偏重于软件整体的外向型行为的刻画，模型要素是功能性需求的反馈，比较简单 设计模型包含更多的内向型结构细节，模型要素顾及非功能性要求，即质量要求，比较复杂

• 结构化方法采用结构图(SC图)刻画软件的结构，程序流程图、PAD图、N-S图记录详细设计的结果 面向对象方法用的和分析模型一样，都是类图、时序图、通信图、部署图

• 软件设计原则：

  • 抽象：越高层抽象程度越高，越底层看到的细节越多，最低抽象级别给出实现问题的解（源代码）

  • 分解和模块化：将一个复杂的问题分解成几个较小的问题能够减小解题所需的总工作量 C(P1+P2)>C(P1)+C(P2) 继续分解，总复杂度和工作量变小但是无限分解不会使得总工作量越来越小，因为划分数量变多，模块之间的联系变多

  • 封装和信息隐藏：应该隐藏的不是有关模块的一切信息而是模块的实现细节，接口和实现分离

  • 高内聚和低耦合：模块独立性的两个定性标准（内聚和耦合），从上往下，内聚强度逐步增强： 低内聚：

    • 偶然内聚：有时写完程序发现一组语句在两处或多处出现，放到一个模块节省内存

    • 逻辑内聚：一个模块完成的任务在逻辑上属于相同或者类似的一类（一个模块产生各种类型的输出）

    • 时间内聚：一个模块包含的任务必须在同一段时间内执行（模块完成各种初始化工作）

    中内聚：

    • 过程内聚：一个模块内的处理元素相关，而且必须以特定次序执行（程序流程图）

    • 通信内聚：模块中所有元素都是用同一个输入数据和产生同一个输出数据

    高内聚：

    • 顺序内聚：如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行（通常一个处理元素的输出数据为下一个处理元素的输入数据），模块间的连接简单

    • 功能内聚：模块内的处理元素属于一个整体，完成一个单一的功能

    耦合：高内聚往往意味着低耦合：

    弱耦合：

    • 非直接耦合：相互之间没有信息传递

    • 数据耦合：上下级模块，上级模块调用夏季模块可以通过参数表和他们交换数据，且交换的是简单变量

    • 特征耦合：交换的是数据结构

    中等耦合：

    • 控制耦合：模块间传递的信息不是一般的数据，而是用作控制信号的开关值和标志量，因此控制模块必须知道被控模块的内部逻辑

    较强耦合：

    • 外部耦合：允许一组模块访问同一个全局变量

    • 公共耦合：允许一组模块访问同一个全局性的数据结构

    最高程度耦合：

    • 内容耦合：模块可以直接调用另一个模块中的数据，或者一个模块直接转移到另一个模块中

• 架构风格 P166：架构是宏观的设计模式，高层组织结构的模式

  • 分层架构风格

  • 管道与过滤器架构：过滤器对输入数据进行处理，产生输出数据，管道将过滤器连接在一起

  • 黑板架构：知识源、黑板数据结构、控制流

  • 分布式系统的架构风格：客户端-服务器架构风格、三层架构风格、代理架构风格

  • 交互式系统的架构风格：MVC风格、表示-抽象-控制架构

  • 自适应系统的架构风格：微内核、反射架构

  • 其他架构风格：批处理架构、解释器架构、进程控制架构、基于规则的架构

• 设计模式：按照目的分类（创建型模式——关注对象创建、结构型模式——关注类和对象组合、行为型模式——刻画类或对象的交互方式和职责分布的特性），按照作用域分类（类模式——静态、对象模式——动态） 分类详见P180

面向对象的设计建模

• 包设计原则

  包的粒度，包的内聚性原则：

  • 重用-发布等价原则

  • 共同重用原则

  • 共同封闭原则

  包的稳定性：

  • 无环依赖原则

  • 稳定依赖原则

  • 稳定抽象原则

• 类设计原则

  • 单一职责原则：类的粒度设计原则；每个类只有一种职责，高内聚

  • 里氏替换原则：继承关系设计的依据；子类必须能够替换父类，子类输入参数不会比父类的类型更具体，子类输出参数类型不会比父类更抽象

  • 依赖倒置原则：接口设计的依据；高层模块不应该依赖于底层模块，他们都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象

  • 接口隔离原则：接口粒度设计的依据；客户端不应该被迫依赖他们并不需要使用的接口，类与类的依赖关系应该建立在最小的接口上

  • 开放-关闭原则：软件实体（类、模块、函数）应该对扩展开放，对修改关闭；指明了如何在软件系统中实现增量式设计与开发

软件测试

• 测试的目的：发现程序的错误

• 测试的任务：通过在计算机上执行程序暴露程序潜在的问题

• 调试的目的：定位和纠正错误

• 任务：消除软件故障，保证程序的可靠运行

• 需求分析、设计、编码是软件主要错误来源，软件缺陷的解决也是

• 相关术语定义：

  • 错误(Error)：例如计算、观察、测量的值或者条件与实际、规定、理论的值或条件的差别，不正确的步骤

  • 缺陷(Defect)：缺陷是错误的外部显示，例如一个不满足合理消费者需求的输出或者性能特征

  • 故障(Fault)：例如程序中不正确的语句、步骤、数据定义引发的软件运行故障

  • 失效(Failure)：当一个故障被执行，可能导致一个或多个失效问题，例如系统部件不能按照规定的性能要求执行功能

  • 事故（Incident）：经济损失

• 测试应该从小到大

• 软件测试策略

  • 单元测试：数据结构、边界条件、独立路径、错误处理路径； 涉及到桩模块和驱动模块

  • 集成（组装）测试：整体拼装，增量式集成（自顶向下、自底向上、混合集成）

  • 系统测试：系统是否满足需求规约，功能和非功能测试（可靠性、性能、易用性、可维护性、可移植性）

• 软件质量属性测试+其他P250 P247

• 软件测试技术：通用测试/专用测试技术，更普遍的分类：

  • 白盒测试：内部结构，单元测试 白盒测试分类：控制流测试、基本路径测试、数据流测试

  • 黑盒测试：不考虑内部，系统/验收/\alpha/\beta测试

    黑盒测试分类：等价类划分、边界值分析、随机测试、因果图、判定表、基于有限状态机的测试，基于形式化规约的测试（分类见P255）

  • 灰盒测试：两种结合

软件演化和软件维护

• 软件演化是指对软件进行维护和更新的一种行为

• 按照生命周期的不同阶段可以分为开发（从头到尾）/运行演化

• 软件维护分类：

  • 纠错性维护（被动纠错）：出错了来纠正

  • 完善性维护（积极增强）：根据用户提出的建设性意见，使用一段时间之后，新增三张报表以满足店长的需求

  • 适应性维护（被动增强）：适应环境变化（手机/PC，业务规则、政府政策、工作模式、软件操作平台）

  • 预防性维护（积极纠错）：打了补丁，进行重构，提高模块化程度；代码结构调整、代码优化、文档更新

• 软件维护技术：包括程序理解（高度依赖人的思维）、逆向工程、再工程（属于预防性维护）

决策

分值1*2*5：决策+后续问题解决（开发模型）

软件开发模型

重点模型

• 增量模型：

  特点：

  • 多个版本并行开发

  • 需求在开发早期是明确的，将功能分成若干增量来逐步实现

  不适合增量模型：

  • 需求未被很好地理解

  • 突然提出一些功能

  • 技术发生迅速变化

  • 长时间没有人力资金保证

  适合使用增量模型：

  • 需要早期获得功能

  • 中间产品可以提供使用

  • 系统被自然分割成增量

  • 工作人员/资金可以逐步增加

• 演化模型

  特点：

  • 业务和产品需求在软件开发过程中常常发生改变，一次迭代开发出最终产品不可能

  • 紧迫的市场期限

  • 只需要核心需求被理解，可以渐进式开发

  应用该模型的过程：统一软件过程 敏捷过程(XP、Scrum)

  两种演化模型：

  原型模型

  螺旋模型（大型系统和软件）

  迭代的安排是风险驱动的

• UP：将生命周期分为先启、精化、构建、产品化

• 敏捷过程的适用场景： 需求不确定、易挥发；有责任感和积极向上的开发人员；用户容易沟通并能参与；小于10人的团队

设问方式

• 怎么安排软件开发？

  软件开发的安排通常遵循一系列系统化的阶段，以确保项目按时、高质量地完成。首先，需求分析阶段需要与客户或用户紧密沟通，明确功能需求、性能要求和用户期望，确保开发团队理解项目目标。接下来，进入系统设计阶段，设计高层架构和模块化的系统，定义接口和数据库结构，为开发提供技术蓝图。在此基础上，进行项目规划，设定明确的开发时间表，合理分配资源与任务，并设定里程碑，确保项目按计划推进。然后，进入开发阶段，团队按照设计文档进行编码，实现系统功能，确保遵循代码规范和版本管理流程。开发过程中要保持频繁的集成和测试，确保每个模块的功能和性能满足要求。在完成编码后，进行详细的单元测试、集成测试和系统测试，确保系统的稳定性和无重大缺陷。最终，完成部署和发布，将系统交付给客户或用户，同时提供必要的培训与支持。在系统投入使用后，进入维护阶段，及时修复漏洞并进行系统优化，确保软件长期稳定运行。整个开发过程中，要注重进度的控制和质量的保障，定期评估进度，调整计划以应对突发问题。

• 由于业务和产品需求经常发生变化，以及紧迫的市场期限使得一个完善的软件产品难以一次性交付，请问采用哪种软件过程模型来解决这个问题，为什么？ 针对需求变化频繁和紧迫市场期限的情况，敏捷开发模型是解决问题的理想选择。因为敏捷开发强调软件开发中相关人员之间的信息交流（以人为本），面对面交流低于文档交流的成本，能够快速响应需求和变化，快速和短迭代进行开发，不断产出和演化可运行的软件。

• 项目要延期了怎么办？ 当项目面临延期时，从软件工程的角度来看，需要及时评估延期的原因，并采取有效的应对措施。首先，分析需求变更、资源不足或技术难题等原因，重新调整项目计划和优先级，明确哪些功能可以推迟或调整。其次，增强团队沟通，确保所有成员对延期的原因和调整后的计划有清晰的理解，并优化开发流程以提高效率。最后，要加强风险管理，持续监控项目进度，确保延期后的目标和质量要求能够按时达成，同时保持客户或利益相关者的沟通，管理他们的期望。 当项目面临延期时，从软件开发模型的角度来看，团队应该重新评估当前的软件开发生命周期模型，调整项目计划和资源分配。如果是采用瀑布模型，可能需要重新审视需求和设计阶段，以确定延期的原因并调整后续的实施计划；如果是敏捷开发模型，则可以通过迭代回顾会议识别瓶颈和改进点，灵活调整后续的迭代目标和任务优先级，以确保项目能够逐步向最终目标靠近。重要的是保持沟通透明，及时向所有利益相关者报告项目状态，并寻求他们的理解和支持。

• 在一个严重拖期的项目中，增加新的人手会产生什么后果，是否可以加快软件的开发？ 在一个严重拖期的项目中，增加新的人手并不一定能加快软件开发，反而可能导致效率下降。这是因为新增人员需要时间来熟悉项目、理解需求和架构，尤其是在软件开发的后期阶段，团队成员之间的沟通和协作成本会大幅增加。此外，更多的人手可能导致管理上的复杂性提升，需要更多的协调和资源分配。因此，增加新的人手可能带来短期的生产力提升，但长期来看，可能因增加的沟通成本和管理压力，反而使开发进度变得更加缓慢。

  （龙军）原因：新人学习成本，沟通成本增加，项目管理复杂度

  在软件开发中，增加人力并不总能缩短项目周期，反而可能导致延期。这是因为：

  • 新人学习成本增加，团队成员需要时间熟悉项目代码、需求和流程，从而影响生产效率。

  • 同时，随着人员增多，沟通成本也随之上升，团队成员之间的协调和信息传递变得更加复杂，容易引发误解和重复工作。

  • 此外，项目管理的复杂度也会增加，需要更多的时间来进行任务分配、进度跟踪和问题解决。

  • 人月定律表明，开发工作并不是线性增长的，随着人力增加，工作量和沟通协调的复杂性会呈现出递增的趋势，最终可能导致效率下降，反而拖延项目进度。

• 要求某一个团队做一个软件管理系统，必须在六个月之内做完，应该选择瀑布模型还是敏捷方法，理由是什么？ 在六个月内完成软件管理系统的开发，应该选择敏捷方法。原因是，敏捷方法强调迭代开发和快速交付，能够适应需求的变化，并且可以在较短的时间内交付可用的功能模块。而瀑布模型通常在项目初期就要求明确所有需求，并按顺序进行开发，难以应对需求变化和调整。在时间紧迫的情况下，敏捷能够通过多个迭代周期持续交付，及时获取反馈并做出调整，从而有效保障项目按时交付并满足用户需求。

• 什么是软件？

  软件是在计算机系统的支持下，能够完成特定功能与性能的程序、数据和相关文档

• 什么是软件的复杂性？

  GPT：软件的复杂性是指软件系统在设计、实现、维护和扩展过程中，涉及的组件、功能、交互和逻辑关系的复杂程度。它包括代码的复杂性、系统架构的复杂性、需求变化的复杂性以及人员协作的复杂性。随着系统规模的扩大和功能的增加，软件的复杂性通常会呈指数增长，导致开发和维护的难度加大，也可能影响系统的可理解性、可扩展性和可维护性。 课本P13：

  • 技术的复杂性：软件技术发展，一个软件项目常常同时设计多项技术

  • 需求的复杂性：软件的需求常常是模糊的，而且不断变化，只要项目不结束就会一致变下去

  • 人的复杂性：软件开发人员的复杂性和多变性

• 什么是模型？

  模型是对客观世界的某种简化，是对事物或系统的一种抽象描述

• 抽象的概念 GPT：抽象是从具体事物中提取出共性特征，忽略不相关的细节，以简化问题的复杂性和提高理解能力的过程。在软件开发中，抽象通常意味着通过定义类、接口或模块等方式，将复杂的实现细节隐藏在背后，仅暴露必要的功能或属性，以便用户或其他系统可以更容易地使用和维护。抽象有助于提高系统的可重用性、可扩展性和可维护性，同时减少对实现细节的依赖。

  课本P13：

  抽象是从众多事务中抽取出共同的、本质性的特征，而舍弃非本质的特征

• 逆向工程和再工程的概念？

  逆向工程：基于低抽象层次的软件制品，通过对其进行理解和分析，产生高抽象层次的软件制品

  再工程：通过分析和变更软件的架构，产生更高质量的软件系统的过程，再工程包括逆向工程也包括正向工程

• 软件项目规划内容？软件估算（通常用软件代码行LOC）

  GPT：软件项目规划是指在项目启动阶段，依据项目的目标、需求和资源，制定详细的执行计划，以确保项目按时、按质、按预算完成。其内容通常包括项目范围定义、时间安排、资源分配、成本估算、风险评估、质量控制、沟通计划以及团队角色和责任分配等。规划过程中还需要考虑项目的关键里程碑、任务优先级以及潜在的挑战和应对策略。通过合理的项目规划，能够有效地管理进度、资源和风险，提高项目成功的可能性。

  课本P309：软件项目规划： 目的是为软件项目制定合理的行动纲领，以便所有的项目成员按照项目有条不紊的开展工作，包括明确项目总范围、定义和优化目标以及实现上述目标而指定行动方案。随着项目进行，项目规划可能要改进或者细化，在项目生命周期中发生重大变更也可能会导致项目重新规划。 软件项目规划对项目范围、进度、成本、质量、沟通、风险和采购等各方面做出规定，一般由一个核心的开发计划和若干支持计划（质量计划、测试计划、风险管理计划、配置管理计划、沟通计划、培训计划）组成

  软件项目规划的关键活动：确定项目目标、定义项目的软件过程、软件估算、进度安排、资源配置、成本预算

  PPT：软件项目管理要素

  • 管理软件过程：

    • 明确软件开发活动以及过程（过程定义）

    • 估算软件项目工作量成本（软件度量）

    • 制定计划、跟踪过程、风险控制等

  • 管理软件产品：

    • 明确有哪些产品，是什么形式（规范文档）

    • 质量保证、配置管理、需求管理、风险控制

  • 管理项目人员：

    • 组建开发团队、调动积极性和激情

    • 团队建设与沟通、机制设计、风险控制

• IDEAL过程改进模型

  IDEAL过程改进模型是由卡内基梅隆大学的软件工程研究所提出的一种结构化框架，用于指导组织进行过程改进和优化。该模型包括五个阶段：启动（Initiating）、诊断（Diagnosing）、建立（Establishing）、行动（Acting）和学习（Learning）。通过这些阶段，组织可以识别改进目标，评估当前状态，制定改进计划，实施具体改进措施，并从经验中学习，以形成持续优化的闭环流程。

遵循以下六条需求变更控制策略：P114

• 建立需求基线之后，所有需求的变更请求必须遵从统一的变更控制，通过单一渠道进行核准

• 由CCB决定实现哪些变更，CCB包括用户、市场人员、项目经理组成，对于小的变更可能只需要一名项目经理

• 可行性论证

• 开发计划、设计、代码与新的需求一致

• 项目干系人和项目组相关人员了解需求变更情况

• 采用变更控制工具

可能再进度、成本、质量上不能满足变更：

• 暂时搁置低优先级的需求

• 新增一定数量的项目成员

• 短期内带薪加班

• 延长项目实践，将新的功能排入进度安排

• 为了保证按时交付使质量受到一些影响

一些拓展问题

1. 项目团队成员假设客户将会批准开发功能： 如果项目团队成员在没有事先获得客户同意的情况下假设某个功能会被批准，项目经理应立即介入并澄清这一假设。项目经理应与客户进行沟通，确认需求和期望，并确保所有开发工作都是基于客户的明确批准和要求。项目经理还应加强团队的沟通和审批流程，以防止此类误解和风险再次发生。

2. 项目团队缺乏必要的技能来产生关键可交付成果： 当项目团队缺乏产生关键可交付成果所需的必要技能时，项目经理应采取以下措施：首先，评估当前团队成员的能力和项目的技能差距，然后寻求解决方案。可能的解决方案包括招聘具有相关技能的人员，或者提供适当的培训和技能提升。此外，项目经理还应考虑与外部专家或顾问合作，以确保项目能够顺利进行。

3. 项目经理得知相关方意见不一致，项目可能会失败： 当项目经理得知相关方之间存在严重的意见不一致，可能导致项目失败时，项目经理应主动进行干预。项目经理需要召集相关方进行讨论，明确各方的期望和要求，找出根本分歧并尝试达成共识。如果无法达成一致，项目经理应通过风险管理措施来评估分歧对项目的潜在影响，并寻求通过调解或妥协达成解决方案，从而确保项目继续推进。

4. 项目发起人识别到一个被项目团队忽视的外部风险： 当项目发起人识别到一个被项目团队忽视的外部风险时，项目经理应立即与项目发起人沟通并对该风险进行详细评估。项目经理需要与团队一起分析这个风险的可能影响，并根据项目的风险管理计划采取适当的应对措施。必要时，可以重新审视项目的计划和资源配置，以确保这个外部风险被充分考虑并采取了有效的应对策略。

GPT生成的决策题：

1. 问题：项目即将面临延期，作为项目经理，你应该怎么做？

• 答案：

  • 评估延期原因：首先，分析导致延期的原因，是技术难题、资源不足还是需求变更等。通过详细的分析，找出最根本的问题。

  • 与客户和利益相关者沟通：及时与客户和相关利益方沟通，告知他们项目延期的原因和影响，并协商新的交付日期或方案。

  • 调整项目计划：根据评估结果，调整项目计划，优化资源分配和工作流程，确保剩余任务能够按时完成。

  • 考虑并应用缓解措施：如增加额外的资源、优化开发流程、减少某些非核心功能等，以便加快进度。

  • 风险管理：对延期的风险进行管理，确保项目的最终交付不会受到更大的影响。

1. 问题：项目需求频繁变动，导致开发进度滞后，如何应对？

• 答案：

  • 建立变更控制流程：首先，项目经理应确保项目有一个严格的变更控制流程，所有需求变动都应经过正式的审批和评估。

  • 与客户沟通需求范围：与客户沟通，明确项目的核心目标和交付物，尽量减少需求的变化，或者尽量将需求变动控制在可管理的范围内。

  • 优先级排序：根据需求的优先级进行排序，确保首先完成最关键的功能或特性。

  • 迭代开发：采用敏捷方法，分阶段、分迭代开发，以便快速交付核心功能，并根据需求变化进行调整。

  • 重新评估项目时间和资源：评估需求变动对项目进度的影响，调整项目计划，确保新变动不会进一步拖延项目。

1. 问题：开发团队成员出现矛盾，影响项目进展，项目经理应该如何解决？

• 答案：

  • 了解冲突原因：作为项目经理，首先需要了解团队成员之间的矛盾原因，可能是因为沟通不畅、工作分配不合理或个人问题等。

  • 促进沟通：组织团队会议，让团队成员表达各自的观点和感受，促进开放和有效的沟通，帮助解决误解和冲突。

  • 引导团队达成共识：作为项目经理，要起到调解作用，帮助团队成员找到共同点并达成一致，确保团队目标优先于个人冲突。

  • 明确角色和责任：确保每个团队成员的角色和责任都明确，避免职责重叠或不清楚，减少冲突的机会。

  • 提供支持和反馈：如果冲突难以解决，可以考虑引入外部资源（如HR）进行干预，或者对团队成员进行辅导，帮助他们克服个人问题。

1. 问题：客户突然提出需求增加，且不增加预算和时间，作为项目经理，你该如何应对？

• 答案：

  • 评估影响：首先评估需求增加对项目进度和质量的影响。如果需求增加显著，可能会影响到交付日期和成本。

  • 与客户沟通：与客户沟通需求增加的影响，解释如果不增加预算和时间，可能会影响到最终产品的质量或交付时间。争取客户理解并重新评估需求。

  • 调整项目范围：与客户协商，看看是否有不必要的或低优先级的功能可以延后实现，确保核心需求优先完成。

  • 优化资源配置：如果客户坚持不增加预算和时间，可以考虑重新安排资源，增加开发人员、加班或使用更高效的开发方法。

  • 灵活管理：采用敏捷开发方法，按优先级递增交付客户需求，确保最重要的功能最早实现。

1. 问题：在项目中，开发进度落后于计划，质量出现问题，如何平衡进度和质量？

• 答案：

  • 优先解决质量问题：项目的质量不能被忽视，因为不合格的产品可能会带来更高的修复成本。项目经理应该评估质量问题的严重性，优先解决关键问题，确保最基本的质量要求得到满足。

  • 评估进度和质量的平衡点：项目经理需要根据项目的优先级和客户的期望，做出平衡决定。如果质量问题较为严重，应优先保证质量，并重新评估进度安排。

  • 调整项目范围和功能：如果进度严重滞后，可以考虑对非关键功能进行延期，减少不必要的开发，集中资源解决核心问题。

  • 加强风险管理：根据现有问题，评估可能对项目造成的风险，并采取措施降低风险带来的影响，如调整计划、增加测试资源等。

  • 与客户沟通：及时与客户沟通，解释当前的挑战和调整方案，争取客户的理解与支持，以便在质量和进度之间找到合适的平衡点。

1. 问题：项目阶段性验收时，客户对交付物不满意，如何处理？

• 答案：

  • 了解客户不满意的原因：项目经理应主动与客户沟通，明确客户的不满点。是功能不符合需求，还是质量问题，或是交付标准没有达成。

  • 分析根本原因：一旦知道客户的具体不满，项目经理需要与团队分析，找出问题的根本原因。可能是需求沟通不足，或者是开发过程中的缺陷。

  • 调整交付物：根据客户的反馈，调整交付物，快速修复问题或进行改进。如果客户的需求变化，可能需要重新评估项目的时间和资源。

  • 增进与客户的沟通：与客户建立更加有效的沟通机制，确保后续交付更符合客户期望，避免类似问题再次发生。

7.问题：项目中发现多个未预见的技术难题，开发进度严重滞后，如何处理？

• 答案：

  • 快速识别关键问题：项目经理应组织技术团队快速评估所有技术难题的优先级，确定哪些问题最为关键，哪些可以延后解决。

  • 寻求外部帮助：如果团队缺乏足够的技术能力，可以考虑引入外部专家或顾问，提供专业的支持。

  • 调整开发方式：如果技术难题难以解决，可以考虑采用不同的技术路线或架构，优化开发方式，减少技术难题的影响。

  • 增加资源投入：根据情况，可以增派更多技术人员，增加开发资源以加速问题的解决。

  • 与客户沟通：及时与客户沟通，说明技术问题对进度的影响，商讨可能的解决方案，包括延期或功能删减。

8.问题：团队成员之间的工作协作不顺利，导致项目进展缓慢，如何改善团队协作？

• 答案：

  • 促进沟通：确保团队成员之间有良好的沟通渠道，可以定期举行会议，如每日站会、每周进展回顾等，确保信息的流通和问题的及时反馈。

  • 明确角色和责任：确保每个成员的职责清晰，避免职责重叠或不明确导致的工作混乱。团队成员应了解各自的任务以及其他成员的任务，避免重复工作。

  • 使用协作工具：可以引入团队协作工具（如Jira、Trello、Slack等），提高任务的透明度和团队的协同效率。

  • 增强团队合作精神：组织团队建设活动，增加团队成员之间的信任感，促进合作和相互支持，减少个人冲突和误解。

  • 及时处理冲突：如果团队内有明显的冲突或不和谐现象，项目经理应介入并进行调解，帮助成员解决冲突，恢复团队的良好合作氛围。

9.问题：项目需求过于模糊，客户不断提出新的需求，项目经理该如何应对？

• 答案：

  • 明确需求范围：项目经理应与客户和利益相关方明确项目的需求范围，确保在项目初期通过详细的需求分析来避免后期的频繁变动。

  • 制定变更管理流程：建立严格的需求变更控制流程，所有新增需求必须经过评估、审批和优先级排序，避免不必要的需求增加。

  • 与客户沟通：定期与客户沟通，确保需求不会过度扩展。项目经理可以提醒客户过多的需求变更可能导致项目延期、成本增加或质量下降。

  • 设立需求冻结期：在项目的某个阶段，设立“需求冻结期”，一旦进入开发阶段，需求就不能再轻易变更。这样可以减少需求频繁变化带来的风险。

  • 优先级排序：对于新增需求，项目经理应与客户一起确定优先级，优先实现核心功能，非核心功能可以推迟或取消。

10.问题：项目团队成员对某项决策有异议，导致进展停滞，如何应对？

• 答案：

  • 了解异议根源：项目经理应主动与团队成员沟通，了解他们的异议来源，是对决策的内容不认同，还是对决策过程的质疑。

  • 促进开放讨论：组织团队进行开放讨论，鼓励成员表达自己的意见和建议，并对不同的观点进行讨论，寻找最佳解决方案。

  • 根据事实做决策：项目经理应根据项目的实际情况和数据做出决策，并向团队成员清楚说明决策的依据和理由。

  • 取得团队共识：通过透明的沟通和合理的决策过程，努力让团队达成共识，确保项目继续推进。

  • 必要时进行调解：如果异议无法解决，项目经理可以引导团队进行妥协，或者通过调解来消除不必要的矛盾，恢复团队的协作。

11.问题：在项目执行过程中，团队成员的工作质量不稳定，项目经理应该如何改进？

• 答案：

  • 评估问题根源：项目经理首先需要了解导致团队成员工作质量不稳定的原因。可能是任务分配不合理、资源不足、技术难度高，或是沟通不畅。

  • 加强培训和支持：如果是技能问题，项目经理可以安排培训，帮助团队提升能力。如果是任务过于复杂，可以为成员提供技术支持。

  • 设定质量标准：项目经理应确保团队成员清楚项目的质量标准，并加强代码审核、单元测试等质量保证措施。

  • 进行定期检查：定期进行项目进展和质量检查，及时发现问题并进行调整，确保项目质量不受影响。

  • 建立反馈机制：通过及时反馈机制，让团队成员了解自己的工作表现，及时调整和改进。

往年题

• 设计模式中,迭代器模式属于行为设计模式。T

• 在基于模型的软件生命周期中,针对需求进行分析建模属于平台有关模型。F（平台无关）

• 如果一个软件项目的需求不确定并容易挥发、项目团队成员少而精、用户容易沟通并能参与,最适合这个项目的软件开发过程是敏捷过程。T

• 如果用例中的一部分行为可选,或者只在特定条件下才执行,那么就可以将这部分行为分离出来,形成一个新的用例,它与基本用例之间的关系是包含关系。F

• 如果一个软件系统在运行和维护三年以后,由于打了不少补丁,需要对系统的模块进行重构,已提高模块化程度,这种维护属于完善性维护。F(预防性)

  ---

• 如果模块是相互独立的,当模块变得越小,每个模块花费的工作量越(小);但当模块数增加时,模块间的联系也随之(增多)。

• 面向服务架构中的三个协作角色是什么(服务消费者、服务提供者、服务注册中心）

• 如果一个软件组织建立了基本的项目管理过程来跟踪费用、进度和功能特性,按照CMMI阶梯式模型,该组织的能力成熟度可评估为(已管理级),将来还需要通过(已定义级)、(定量管理级)才能达到持续优化级。