项目管理

考试时间

6月18日 星期三 14：00——15：40

题型

选择题

填空题

判断题

名词解释

简答题

大题 第4章 第7章

选填判

1.项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。

2.项目管理是以项目为对象，通过使用知识、技能、工具和方法来组织、计划、实施并监控项目，使之满足项目目标需求的过程。

4.合同是使卖方负有提供具体产品和服务的责任，买方负有为该产品和产品服务付款的责任的一种双方相互负有义务的协议。

5.技术合同有三种环境：需（甲）方环境、供（乙）方环境和内部环境；

7.合同签署过程就是正式签署合同，使之成为具有法律效力的文件；

8.当项目满足结束的条件，项目经理或者合同管理者应该及时宣布项目结束，终止合同的执行。

10.软件过程是指人们用于开发和维护软件及其相关产品的一系列活动、方法、实践和革新。

11.软件开发过程管理是指在软件开发过程中，除了先进技术和开发方法外，还有一整套的管理技术。

13.软件质量是“所有描述计算机软件优秀程度的特性的组合”

14.质量规划指识别哪些质量标准适用于软件项目，并确定如何满足这些标准的要求。

16.软件项目开发目标是按时、按预算开发出满足用户真实需要的软件。

17.业务需求是从宏观层面阐述软件项目对业务的价值和目标。

19.风险管理是指在项目进行过程中不断对风险进行识别、评估，制定策略，监控风险的过程。

20.风险评估又称风险预测，就是对识别出的风险做进一步分析。

22.项目跟踪控制保证项目能够按照预先设定的计划轨道行驶，使项目不要偏离预定的发展进程。

23.内部因素指项目基本可以控制的因素，例如变更、范围、进度、成本、资源、风险等

25.范围核实是指利益相关者对项目范围的正式接受，包括项目最终产品和评估程序，以及这些产品的满意程度和评估的正确性。

26.软件配置管理是对产品进行标志、存储和控制，以维护其完整性、可追溯性以及正确性，它为软件开发提供了一套管理办法和活动原则。

28.软件项目收尾阶段，需要对项目所有文档进行归档，确保其完整性和规范性，便于后续查阅与知识沉淀。

29.项目团队在收尾时，应通过复盘会议总结项目经验教训，识别成功因素与改进点，为未来项目提供参考。

名词解释

1.软件项目管理

软件项目管理是运用管理知识、工具和技术，对软件项目全生命周期进行计划、组织、协调与控制的过程，旨在确保项目在既定的时间、预算和质量标准内，交付满足用户需求的软件产品或服务。

软件项目管理是运用管理知识、工具和技术，对软件项目全生命周期（包括启动、规划、执行、监控和收尾）进行计划、组织、协调与控制的过程，旨在确保项目在既定的时间、预算和质量标准内，交付满足用户需求的软件产品或服务。其核心目标涵盖范围管理、进度管理、成本管理、质量管理、风险管理等多个维度。

2.敏捷项目管理

敏捷项目管理是迭代增量式开发管理方法，强调响应变化、客户协作与团队自组织，以短周期冲刺推进，优先交付高价值功能，依反馈调整需求，持续交付可用软件，适用于需求多变项目。

敏捷项目管理是一种迭代式、增量式的软件开发管理方法，强调快速响应变化、客户协作和团队自组织。通过短周期迭代（如冲刺）推进项目，优先交付高价值功能，并根据反馈动态调整需求和计划。它注重灵活性，减少文档依赖，以持续交付可用软件为核心目标，适用于需求不确定、变化频繁的软件项目。

4.软件项目合同

软件项目合同是甲乙双方就软件开发、实施、维护等达成的法律协议，明确双方权利义务，涵盖项目范围、交付、工期、费用、知识产权、保密条款、违约责任等关键内容，用以保障项目执行并约束双方行为。

软件项目合同是指发包方（甲方）与承包方（乙方）就软件开发、实施、维护等工作达成的具有法律效力的协议。合同明确规定双方的权利与义务，涵盖项目范围、交付成果、工期、费用支付、知识产权归属、保密条款、违约责任等关键内容，用于保障项目顺利执行并约束双方行为。

5.合同变更管理

合同变更管理是软件项目合同执行中，对需求调整等引发的条款修改进行评估、审批、修订和沟通的流程，需双方书面确认变更、更新条款并记录历史，以规避纠纷，保障合同履行有效合规。

合同变更管理是指在软件项目合同执行过程中，针对因需求调整、技术变更等因素引发的合同条款修改，进行评估、审批、修订和沟通的系统化流程。通过规范的变更管理，需确保变更内容经双方书面确认，同步更新合同条款并记录变更历史，以避免法律纠纷，保障合同履行的有效性和合规性。

7.需求评审

需求评审是软件开发前期对用户及业务需求的系统性审查，组织开发团队、客户等利益方共同验证需求的完整性、一致性和可行性，识别模糊冲突内容并提出修改建议，以确保需求文档准确指导后续工作。

需求评审是在软件开发前期，对收集到的用户需求、业务需求进行系统性审查的过程。通过组织开发团队、客户及相关利益方共同参与，验证需求的完整性、一致性和可行性，识别模糊或冲突的内容，并提出修改建议，确保需求文档能够准确指导后续设计与开发工作。

8.版本控制

版本控制是对软件开发过程中代码、文档等配置项的变更进行管理的技术手段。借助git、svn等系统记录修改历史，支持分支开发、代码合并及版本差异追溯，确保项目资源可追溯、一致并提升协作效率。

版本控制是对软件开发过程中代码、文档等配置项的变更进行管理的技术手段。通过版本控制系统（如 Git、SVN），记录每个文件的修改历史，允许开发者创建分支并行开发，合并代码并追溯不同版本间的差异，保障项目资源的可追溯性、一致性和协作效率。

10.风险识别

风险识别是软件项目风险管理的首要环节，通过头脑风暴、专家访谈等方法系统找出潜在威胁（技术难题、需求变更等）和机会（新技术应用等），形成风险清单明确来源、影响环节及特征，为后续评估应对奠定基础。

风险识别是软件项目风险管理的首要环节，指通过头脑风暴、专家访谈、历史数据分析等方法，系统性地找出项目中潜在的威胁（如技术难题、需求变更、人员流失）和机会（如新技术应用、市场机遇）。该过程需形成风险清单，明确风险来源、可能影响的项目环节及初步特征，为后续风险评估和应对提供基础。

11.风险应对策略

风险应对策略是针对已识别风险制定的处理方案，含规避、减轻、转移、接受四类，需依风险等级、成本及可行性选择。

风险应对策略是针对已识别风险制定的处理方案，主要包括四种类型：规避（改变计划消除风险，如调整技术方案避开技术难点）、减轻（降低风险发生概率或影响，如提前测试关键模块）、转移（将风险后果转移给第三方，如购买保险或外包）、接受（预留应急储备，主动承担风险后果）。选择策略需综合考虑风险等级、成本和可行性。

13.项目偏差分析

项目偏差分析是软件项目跟踪控制中，对比实际执行与计划目标的差异，识别偏差程度及原因，为纠正措施提供依据的关键方法。

项目偏差分析是软件项目跟踪控制中的关键方法，指通过对比项目实际执行情况（如进度、成本、质量）与计划目标之间的差异，识别偏差的程度和原因。例如，通过计算进度偏差（SV）和成本偏差（CV）量化偏差值，并分析是需求变更、资源不足还是技术问题导致偏差，从而为后续纠正措施提供依据。

14.挣值管理（EVM）

挣值管理是综合衡量项目进度与成本绩效的方法，通过计划价值、挣值、实际成本计算 SPI 和 CPI，评估项目进展，预测 EAC 和 ETC，为资源与计划调整提供依据。

挣值管理是一种综合衡量项目进度和成本绩效的方法。它通过三个核心指标：计划价值（PV，计划完成工作的预算价值）、挣值（EV，实际完成工作的预算价值）、实际成本（AC，实际消耗的成本），计算进度绩效指数（SPI）和成本绩效指数（CPI），直观评估项目是否按计划推进，并预测完工估算（EAC）和完工尚需估算（ETC），帮助管理者及时调整资源和计划。

简答

1.简述软件项目团队冲突的常见原因及解决策略 P115

常见原因：

①任务分配不合理②目标不一致③沟通不畅④资源竞争⑤个人性格差异

解决策略：

①明确职责和优先级；②定期开会对其目标；③建立沟通渠道；④优化资源分配；⑤通过团建增强成员间信任。

常见原因包括任务分配不合理、目标不一致、沟通不畅、资源竞争及个人性格差异。解决策略有：通过明确职责和优先级避免任务冲突；定期召开团队会议对齐目标；建立开放沟通渠道，鼓励成员表达想法；采用资源平衡策略优化资源分配；针对性格冲突，可通过团队建设活动增强成员间信任，必要时调整分工或引入第三方协调。

2.说明软件项目团队激励的主要方式 P115

①物质激励，如奖金、分红、补贴；

②精神激励，如公开表彰、颁发证书；

③职业发展激励，提供培训机会、晋升通道；

④工作自主性激励，给成员任务决策权和创新空间；

⑤团队氛围激励，组织团建活动，增强归属感。

软件项目团队激励方式包括：

1、物质激励，如绩效奖金、项目分红、福利补贴；

2、精神激励，通过公开表彰、颁发荣誉证书认可成员贡献；

3、 职业发展激励，提供培训机会、晋升通道、技术分享平台；

4、工作自主性激励，赋予成员任务决策权和创新空间；

5、团队氛围激励，组织团建活动、打造协作文化，增强归属感。

4.简述软件项目需求跟踪矩阵的作用及构建方法 P133

作用：记录需求全生命周期关系，确保需求可追溯、避免遗漏，验证需求变更对项目的影响。

构建方法：

①矩阵架构：以需求文档中的每个需求为行，设计、代码、测试用例等项目产物为列。

②关联映射：明确每个需求对应的模块、文件、用例，建立对应关系。

③动态更新：需求变更时同步修改关联产物，保证一致性和完整性。

需求跟踪矩阵（RTM）是一种记录需求从产生到实现全生命周期关系的工具，作用在于确保需求可追溯、避免遗漏，同时验证需求变更对项目的影响。构建方法如下：

1、以需求文档中的每个需求为行，以设计、代码、测试用例等项目产物为列；

2、建立对应关系，明确每个需求关联的设计模块、代码文件、测试用例编号；

3、持续更新 RTM，当需求变更时，同步修改其关联产物，确保需求实现过程的一致性和完整性。

7.简述软件项目风险识别的主要方法 P171

①文档审查法：分析需求文档、设计方案等，识别范围、技术或进度风险；

②头脑风暴法：团队成员自由讨论，列举风险；

③专家评估法：借助领域专家或历史项目经验，识别类似项目常见风险；

④SWOT 分析法：从优势、劣势、机会、威胁维度梳理内外部风险；

⑤核对单法：基于过往项目的风险清单逐项核查。

软件项目风险识别的主要方法包括：

1、文档审查法：通过分析需求文档、设计方案等，识别潜在的范围、技术或进度风险；

2、头脑风暴法：组织团队成员自由讨论，列举可能的风险（如需求变更、技术瓶颈、资源不足等）；

3、专家评估法：邀请领域专家或借鉴历史项目经验，识别类似项目中常见的风险；

4、SWOT 分析法：从优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）、威胁（Threats）四个维度梳理项目内外部风险；

5、核对单法：基于过往项目积累的风险清单（如技术风险、人员风险、管理风险）逐项核查。

10. 简述挣值管理（EVM）的三个核心指标及其作用 P189

①计划价值（PV）：计划工作量的预算价值，衡量计划进度目标。

②挣值（EV）：实际完成工作量的预算价值，评估实际进度与成果。

③实际成本（AC）：实际完成工作的花费，记录真实成本消耗。

通过对比三者计算偏差，评估进度和成本绩效，预测完工情况。

挣值管理的三个核心指标为：

1、计划价值（PV，Plan Value）：即 “计划工作量的预算价值”，反映项目按计划应完成的工作预算，用于衡量计划进度。

2、挣值（EV，Earned Value）：即 “实际完成工作量的预算价值”，反映项目实际完成的工作对应的预算，用于评估实际进度与质量。

3、实际成本（AC，Actual Cost）：即 “实际完成工作量的实际花费”，反映项目执行的实际成本支出。

作用：通过对比 PV、EV、AC，计算进度偏差（SV=EV-PV）和成本偏差（CV=EV-AC），量化评估项目进度和成本绩效，预测完工情况（如完工估算 EAC）。

11. 说明软件项目变更控制的主要流程

①提交变更申请：申请人书面提出变更请求，说明内容、原因及影响；

②评估影响：技术、管理等人员分析变更对范围、进度、成本、质量的影响；

③审批决策：变更控制委员会根据评估结果决定是否批准；

④实施与更新：批准后更新项目计划，执行变更并通知干系人；

⑤验证与关闭：测试验证变更成果，符合要求后关闭请求并归档。

软件项目变更控制的主要流程包括：

1、变更申请提交：申请人（如客户、团队成员）以书面形式提出变更请求（CR，Change Request），说明变更内容、原因及影响；

2、变更影响评估：由技术、项目管理、测试等相关人员分析变更对范围、进度、成本、质量的影响，形成评估报告；

3、变更审批决策：变更控制委员会（CCB）根据评估结果，决定是否批准变更（需记录审批意见）；

4、变更实施与更新：批准后，更新项目计划（如进度表、需求文档），分配资源执行变更，并同步通知相关干系人；

5、变更验证与关闭：对变更后的成果进行测试验证，确认符合要求后，关闭变更请求并归档记录。

13. 简述软件项目配置管理的主要目标 P199

①版本控制：记录代码、文档等修改历史，支持版本回溯与分支管理；

②变更管理：通过基线控制和审批流程，确保配置项修改可控、可追溯；

③一致性保障：确保需求文档、代码等各阶段产物版本一致，避免混乱；

④协作效率提升：借助 SVN、Git仓库实现并行开发，减少文件冲突；

⑤资产复用与审计：归档配置项为后续项目提供参考，满足合规审计需求。

软件项目配置管理的主要目标包括：

1、版本控制：记录代码、文档等配置项的修改历史，支持版本回溯和分支管理（如 Git 的分支策略）；

2、变更管理：通过基线控制和变更流程，确保配置项的修改可控、可追溯（如基线变更需审批）；

3、一致性保障：确保各阶段工作产品（需求文档、设计文件、代码、测试用例）在版本上保持一致，避免因版本混乱导致的错误；

4、协作效率提升：通过共享存储库（如 SVN、Git 仓库）实现团队成员的并行开发与协同，减少文件冲突；

5、资产复用与审计：归档配置项，为后续项目提供参考，同时满足合规性审计要求（如知识产权归属记录）。

14. 说明软件项目中“基线” 的定义及作用

定义：软件项目中经正式评审和批准的工作产品，作为后续开发基础，变更需遵循严格流程。

作用：

①里程碑标识：标志项目阶段完成。

②变更控制起点：基线建立后修改需经申请和审批，确保变更规范可追溯。

③冲突解决依据：团队对配置项修改有分歧时，以基线版本为基准比对合并。

④进度评估参考：通过基线与当前版本差异，分析项目进展和变更影响。

定义：基线（Baseline）是软件项目中经过正式评审和批准的、作为后续开发基础的工作产品（如需求基线、设计基线、代码基线），其变更需遵循严格的流程。

作用：

1、里程碑标识：作为项目阶段完成的标志（如需求基线通过评审，标志需求分析阶段结束）；

2、变更控制起点：基线建立后，如需修改需通过变更申请和审批，确保变更的规范性和可追溯性；

3、冲突解决依据：当团队对配置项修改存在分歧时，以基线版本为基准进行比对和合并；

4、进度评估参考：通过基线版本与当前版本的差异，评估项目进展和变更影响（如需求基线与当前需求文档的差异分析）。

案例分析

案例一：电商平台搜索功能缺陷导致用户流失

某电商公司开发新款移动端 APP，用户反馈搜索功能存在严重问题：输入 “连衣裙” 时，搜索结果包含大量男装和配饰，且加载速度缓慢。经排查发现，开发团队在需求分析阶段未明确搜索算法的筛选逻辑（如商品类别权重、关键词匹配规则），测试阶段仅验证了基础搜索功能，未覆盖复杂业务场景。

问题 1：分析导致搜索功能质量问题的主要原因

问题 2：提出改进该搜索功能质量的具体措施

答：

问题 1：导致搜索功能质量问题的主要原因

1、需求分析不到位：未明确搜索关键词与商品类别的匹配逻辑。

2、搜索算法设计不合理：缺乏相关性排序、关键词权重设置。

3、测试覆盖不足：仅验证基础功能，未覆盖复杂和真实业务场景。

4、性能优化缺失：未使用缓存或搜索引擎，导致加载缓慢。

问题 2：改进搜索功能质量的具体措

1、明确搜索需求：定义商品分类权重和关键词匹配规则。

2、优化搜索算法：使用 Elasticsearch，支持分词、权重设定和相关性排序。

3、加强测试覆盖：覆盖常见搜索词、组合条件和筛选场景。

4、提升性能：引入缓存机制和倒排索引，加快搜索响应。

5、收集用户反馈：优化搜索模型，持续迭代改进。

案例二：医疗管理系统缺陷导致数据丢失事故

某医院部署的电子病历系统在上线 3 个月后，多次出现患者病历数据丢失问题。经调查发现，开发团队为赶工期跳过了数据库事务处理的单元测试，且版本控制系统中缺少对数据库脚本的版本管理。此外，测试环境与生产环境的配置差异未被识别，导致异常数据未被及时捕获。

问题 1：从质量管理角度分析事故的根本原因

问题 2：设计防止数据丢失的质量改进方案

答：

问题 1：事故的根本原因（质量管理角度）

1、缺乏完整测试流程：跳过数据库事务的单元测试，未验证数据一致性。

2、配置管理不规范：数据库脚本无版本控制，无法回溯或修复数据结构问题。

3、环境不一致：测试与生产环境差异未识别，导致异常情况未被发现。

4、赶工期忽视质量保障：项目周期压缩牺牲了质量验证环节。

问题 2：防止数据丢失的质量改进方案

1、补全测试流程：强化数据库相关的单元测试与集成测试，确保事务正确执行。

2、实施版本控制：对数据库脚本使用 Git 等工具统一管理，保障可追溯性和一致性。

3、环境配置统一：保持测试与生产环境配置一致，使用配置文件管理工具（如Docker、Ansible）。

4、引入自动化监控：部署异常检测、日志监控与数据备份机制，及时发现并修复问题。

5、落实质量保障制度：设立代码评审、上线前质量门禁机制，杜绝“跳过测试”。

案例三：教育平台项目需求蔓延导致计划失控

某公司承接在线教育平台开发项目，初期计划 6 个月交付核心功能（用户管理、课程发布、直播模块）。但在开发过程中，客户多次提出新增需求（如 AI 题库、学习报告、多语言支持），且未经过正式评审。开发团队为满足客户要求直接调整任务，导致进度滞后 2 个月，资源严重超支。

问题 2：提出重构项目开发计划的具体措施

答：

问题 2：重构项目开发计划的具体措施

1、建立变更控制流程：新增需求必须评审、确认优先级后再执行。

2、采用迭代开发模式：分阶段交付，核心功能优先，控制需求范围。

3、明确交付边界：与客户确认本阶段目标，其他需求延后处理。

4、动态资源管理：设置缓冲资源，定期审查进度并调整计划。

5、强化沟通记录：需求确认留存文档，避免随意更改任务。

案例四：物流管理系统进度延误与关键路径失控

某团队开发物流调度系统，计划中 “智能派单算法开发”（原计划 8 周）是关键路径任务。但因开发团队高估技术成熟度，实际耗时 14 周，导致整个项目延期。经复盘发现，该任务依赖的 “地图 API 对接” 任务提前完成，但未被纳入关键路径分析，且缺乏备用方案。

问题 1：分析进度延误的计划管理漏洞

问题 2：设计赶工计划以挽回进度滞后

答：

问题 1：进度延误的计划管理漏洞

1、关键路径识别不准确：遗漏了依赖任务（如地图 API）对整体进度的影响。

2、技术评估失误：高估算法开发难度，未做风险预判。

3、缺乏应急预案：无备用方案，任务延期无法快速响应。

4、项目监控不足：未及时识别任务偏差，错过调整窗口。

问题 2：赶工计划设计措施

1、重新识别关键路径：更新进度网络图，纳入所有依赖任务。

2、增加人力/技术支持：调配更多开发人员或引入外部专家协助算法开发。

3、任务并行处理：将可拆分的工作提前启动，减少串行等待时间。

4、压缩非关键任务工期：在不影响质量的前提下压缩辅助任务时间。

5、设立快速响应机制：建立任务偏差预警，及时调整资源和计划。