软件项目管理期末知识点复习（最新版）

第一章；概述

1．项目的概念：项目是为完成某个独特的产品或服务所做的一次性任务

项目特征：

目标性，其结果只可能是一种期望的产品或服务。

独特性，每一个项目都是唯一的。

一次性，有确定的起点和终点。

约束性，每一个项目的资源、成本和时间都是有限的。

关联性，所开展的活动是密切相互关联的。

多方面性，一个项目涉及多个相关利益者

不可逆转性，不论结果如何，项目结束了，结果也就确定了。

2.项目管理的定义

项目管理，简单地说就是对项目进行的管理，即有计划地有序的有控制的做事。

项目管理就是以项目为对象的系统管理方法，通过一个特定的柔性组织，对项目进行高效率的计划、组织、指导和控制，不断进行资源的配置和优化，不断与项目各方沟通和协调，努力使项目执行的全过程处于最佳状态，获得最好的结果。项目管理是全过程的管理，是动态的管理，是在多个目标之间不断地进行平衡、协调与优化的体现。

本质：保证质量的前提下，寻求任务、时间、成本三者之间平衡。

项目管理的对象-3P

People 人员

必须被组织成有效率的团队，他们的潜力需要被激发出来，我们要为项目团队及其成员建立有效的沟通途径和方法，以实现人员之间，团队之间，管理者和被管理者之间的有效沟通，有效的团队应建立合适的组织结构和工作文化，并通过一系列活动，提高团队的凝聚力和战斗力，贡献团队的目标和文化，并最终圆满的完成任务。

Problem 问题

在项目管理里表现为流程不清楚或控制不严密，应用领域知识不足，需求不断变化和不一致，沟通不流畅等，其解决办法是找出引起问题的根本原因在哪里，然后针对问题本质找到解决办法，以求彻底解决问题，如果项目管理者具有缺陷预防意识，对问题具有预见性，能够避免问题的发生，防范风险，防患于未然，项目的成本就会大大降低，项目成功的机会就会更大。

Process 过程

必须适应于人员的需求和问题的解决，人员的需求主要体现在能力、沟通、协调等上，问题能够在整个项目实施过程中得到预防、跟踪、控制和解决，也就是说一套规范且有效的流程是保证项目平稳顺利运行的基础。

项目管理基本方法：

阶段化管理 ：将项目的生命周期分为若干个阶段，再根据不同段所具有的不同特点来进行针对性的管理。

量化管理 ：针对影响项目成功的因素制定指标、收集数据、分析数据，从而完成对项目的控制和优化。

优化管理：分析项目每部分所蕴涵的知识，不断吸取教训、总结经验，将知识和实践更好地融合在一起，从而对项目的计划、实施办法等进行优化，获得项目的最佳效益。

项目管理的生命周期——“启动、计划、执行、控制、结束”演进顺序

软件项目管理的知识体系：PMBOK、PRINCE2、WWPMM

3.软件项目管理特点：

1. 软件项目是设计型项目
2. 软件过程模型
3. 需求变化频繁
4. 难以估算工作量
5. 主要的成本是人力成本
6. 以人为本的管理

第二章：项目准备和启动

1.项目建议书的内容

项目的背景

项目的意义和必要性

项目产品或服务的市场预测

项目规模和期限

项目建设必需的条件、已具备和尚不具备的条件分析

投资估算和资金筹措的设想

市场前景及经济效益初步分析

其它需要说明的情况

2.可行性分析因素

3.软件过程模型 p40页

为避免一次性投资太多带来的风险，最好选择（A ）生存期模型，

A. 增量式模型 B. 原型 C. 螺旋模型 D. V模型

可以构建一部分系统的模型，通过用户试用提出优缺点，最好选择（B ）生存期模型，

A. 增量式模型 B. 原型 C. 螺旋模型 D. V模型

对于风险比较大的项目，最好选择（C ）生存期模型，

A. 瀑布模型 B. 原型 C. 螺旋模型 D. V模型

4. 项目组织结构

1. 职能型：经营活动按照职能划分成部门。项目功能都在本职能部门内部讨论完成再递交到下一个部门。如果完成期间涉及其他职能部门的问题，只能报告给本职能部门经理，由各职能部门经理 进行协调和沟通。
2. 纯项目型：项目经理拥有领导权，项目内所有成员直接向项目经理汇报。每个项目就是一个独立自主单位。它就如同一个子公司 那样运作，拥有完整的人员配备-像技术人员，行政人员，财务 人员等。
3. 矩阵型：它是职能型和纯项目型的结合体。但是项目内的成员受项目经理和职能经理双重领导。

5.软件项目经理能力

自身素养（亲和力、号召力、威信力）、管理能力、技术能力

6.QA与QC

QA-质量保证，通过建立和维持质量管理体系来确保产品质量没有问题， 是过程质量审计者。在我们软件开发过程中，QA也就是质量组成员。 QA所关注的是软件产品质量保证体系。

QC-质量控制，检验产品的质量，保证产品符合客户的需求；是产品质 量检查者。在我们软件开发过程中，QC其实就是测试组成员。QC所关 注的是产品，而非系统（体系）。

7. 软件项目干系人

指积极参与项目或 其利益在项目执行中或成功后受到积极或消极影响的组织和个人

第三章：项目计划

1.软件项目计划的内容

目标、策略、流程、标准、质量、进度安排、预算、资源、风险、配置管理

2.项目计划的方法

滚动计划方法：按照“近细远粗”的原则制定一定时期内的计划，然后按照计划的执 行情况和环境变化，逐步细化、调整。

滚动计划方法的要点：

分而治之：分为多个阶段，针对不同的阶段制定不同的计划。

逐步求精：随着时间的推移，预测计列逐步变成实施计划。

动态规划：以计划的“变（调整）”来主动适应用户需求和软件开 发环境的变化，即“以变应变”。

和谐过渡：可以解决生产的连续性与计划的阶段性之间的矛盾

WBS方法

WBS方法是（Work Breakdown Structure，工作分解结构）一种将复杂的问题分解为简单的问题，然后再根据分解的结果进行计划的方法。

WBS步骤：

分解工作任务

定义各项活动/任务之间的依赖关系

安排进度和资源

3.计划的输入 77页

4.确定项目的范围

软件产品规范，即一个软件产品应该包含哪些功能特性，这就是产品 需求文档（Product requirement document，PRD）所描述的。 更具体的要求就是功能规格说明书， 但这是在计划过程中或之后产生。一般在确定PRD的过程中，就开始 进行项目计划。

项目工作范围，即为了交付具有上述功能特性的产品所必须要做的工 作。工作范围在一定程度上是产生项目计划的基础

5.策略的制定 82页

6.资源计划

项目资源计划，是指通过分析和识别项目的资源需求， 确定出项目需要投入的资源。

资源计划包括人力资源计划、软硬件资源计划。

项目资源计划重点在人力资源计划，采用有效的方法 进行人力资源计划。

7.成本计划

成本构成

按费用分类：力资源成本、资产类成本、管理费用、项目特别费用 软件项目

按成本：

直接成本是项目本身的任务所引起的成本，包括为该项目购买的设 备和软件工具、参与该项目工作的人员工资等。

间接成本是许多项目共享的成本，例如办公楼的租金、水电费用、 公司管理费用、网络环境和邮件服务等各种间接费用。

成本计划

费用预算，在成本估算基础之上，针对各项成本来估算可能产生的其他费用，从而确定费用预算

费用控制是为了保证实际发生的费用低于预算。一般会采用阶段 性控制和单项费用控制相结合的方法，更关键是需求变更控制和 质量控制。

风险识别、风险评估和风险对策计划:

风险计划并不是在资源计划、进度计划和成本计划之后再制定，而是 和这些计划同时进行，因为软件项目的风险会来自于各个方面，包括 人力资源风险、进度风险和成本风险等，而且在如何应对风险或针对 风险采取相应的对策时，对资源计划、进度计划都有影响

课后习题：

为什么说项目计划不是一个文档，而是一个持续的策划过程？

1.变化管理和调整：在项目执行过程中，可能会出现新的信息、风险或挑战。因此，项目计划需要根据实际情况进行调整和更新，以确保项目可以继续朝着既定目标前进。

2.资源和需求的变化：项目执行过程中，资源的可用性、需求的变化或者团队成员的变动等因素都可能影响项目的进展和计划。因此，项目计划需要灵活应对这些变化，以最大程度地优化资源利用和达成项目目标。

3.进度和里程碑的监控：项目计划不仅仅是制定一个时间表或者流程图，它还需要在执行过程中对项目进度和关键里程碑进行实时监控。这样可以及时发现偏差或者风险，采取必要的纠正措施，保证项目按时交付。

4.团队合作和沟通：项目计划是团队协作和沟通的重要工具。通过持续的策划过程，团队成员可以更好地理解项目目标和各自的角色，从而提升整体执行效率和质量。

5.持续改进和学习：项目计划的持续策划过程促使团队在项目执行中不断学习和改进。通过反馈机制和经验总结，团队可以优化项目管理方法和策略，提升未来项目的成功率和效果。

综上所述，项目计划不是一次性的静态文档，而是一个需要持续更新、调整和监控的策划过程，以适应项目执行中的变化和挑战，确保项目能够顺利实施并达到预期的目标和成果。

第四章：项目估算

1.项目估算的基本内容

规模估算：如代码行数、功能点数、对象点或特征点等

工作量估算：任务分解并结合人力资源水平来估算

进度估算：通过工作量估算、有效资源分配等对项目 进度给出正确的评估。

风险估算：一般通过风险发生的“概率和所带来的损失”来评估风险。

其他估算：如需求稳定因子、资源利用效率、文档复审水平等

2.基本估算方法

1. 分解方法：采用“分而治之”的策略，对软件项目进行分解，再采用逐步求精的方式进行估算，最后通过累加获得 整体的估算结果
2. 算术模型：通过估算模型来产生估算
3. 专家判断或经验法：如德尔菲法
4. 比例法：是基于类比的估算技术，根据过去类似的项目，直接进行类比获得当前项目的估算结果。

WBS估算法

自顶向下估算模式，首先估算出项目一级的工作量，然后层层往下分摊，把上一层工作量分摊到下一层的阶段、活动或任务。通常使用 FPA方法或 COCOMO II 来估算项目一级的工作量

自底向上估算模式，要求先估算出底层任务/活动一级的工作量，然后层层向上汇总到阶段和项目级。通常使用 QIF 估算方法或专家判断来 估算项目低层 WBS 元素的工作量

3.软件项目估算

德尔菲法 99页

代码行估算方法：LOC指所有可执行的源代码行数，包括控制语句、数据 定义、数据类型声明、等价声明、格式声明等

功能点分析方法 102页

功能点分析法(FPA)是在需求分析阶段基于系统功能的一种规模估算方法，其国际标准

功能点计算元素

外部输入数(EI)：计算每个用户输入

外部输出数(EO)：计算每个用户输出(报表、屏幕、出错信息等)

内部逻辑文件(ILF)：计算每个逻辑的主文件，如数据的一个 逻辑组合

外部接口文件(EIF)：计算所有机器可读的接口，如磁带或磁 盘上的数据文件。

外部查询数(EQ)：一个查询被定义为一次联机输入，它导致 软件以联机输出的方式产生实时的响应

标准构件法

软件由若干不同的“标准构件”组成，这些构件对于一个特定的应用领域而言是通用的。项目计划者估算每一个标准构件的出现次数，然后使用历史项目数据来确定每个标准构件交付时的大小。

综合讨论

一般在项目层次上，缺少可比性，但在模块或组件层次 上、阶段性任务上具有可比性，可以基于历史数据来进行比较来获得数据

在实际估算工作中，一般先采用分解的方法，将项目分 解到某个层次上，然后再采用对比分析方法和经验方法，任何估算方法都要结合实际来考虑

4.工作量估算

COCOMO方法

构造性成本模型是一种精确、易于使用的基于模型的成本估算方法：

基本COCOMO模型，静态单变量模型，用已估算出来的源代码行数 (LOC)为自变量的函数来计算软件开发工作量。

中间COCOMO模型，在用LOC为自变量的函数计算软件开发工作量的 基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素 来调整工作量的估算。

详细COCOMO模型，包括中间COCOMO模型的所有特性，但用上述各种 影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设 计等各步骤的影响。

COCOMO基本变量

DSI(源指令条数)，定义为代码行数，包括除注释行 以外的全部代码。若一行有两个语句，则算做一条 指令。KDSI即为千代码行数。

MM(估算单位为人月)表示开发工作量。

TDEV(估算单位为月)表示开发进度，由工作量决定。

COCOMO模型影响因素

产品因素：软件可靠性、数据库规模、产品复杂性。

硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周 转时间。

人的因素：分析员能力、应用领域实际经验、程序员能力、虚 拟机使用经验、程序语言使用经验。

项目因素：现代程序设计技术、软件工具的使用、开发进度限制

公式：E = a * (KLOC)^b * (EF)

其中：

E 是估算的开发工作量（人月）

a 和 b 是模型参数，取决于项目的类型

KLOC 是项目的代码行数（以千行为单位）

EF 是工作量调整因子，它是多个项目属性（如可靠性、可维护性等）的乘积

例题：

如果某软件公司正在进行一个项目，预计有50KLOC的代码量，项目是中等规模的半嵌入

式类型的项目，采用中等COCOMO模型，项目属性中只有可靠性为很高级别（即取值为1.3），其他属性为正常，计算项目是多少人月的规模？如果2万元/人月，则项目的费用是多少。已知，中等COCOMO模型，参数取值为： 有机型，a=3.2， b=1.05； 半嵌入式，a=3.0， b=1.12； 嵌入式，a=2.8， b=1.2.

答：该项目为中等规模的有机类型的项目，因此系数a=3.2， b=1.05

工作量估算为：Effort=3.0×（50）1.12×（1.3） =239.865×（1.3） =311.8 人月

项目费用为：

311.8 人月×2=623.6万元

多变量模型

通过用例来描述系统的需求更清楚，可以在功能点和用例之间建立良好的映射关系，项目的估算会更准确些。

基于用例的工作量估计

用例的层次

集成系统，由多个系统构成综合系统；

独立的系统，由多个子系统组成；

子系统，由多个模块或组件构成；

模块/组件，由多个类组成，例如可假定平均8个类构成一个组件。

类，无需用例来描述。

用例估算方法

基于用例的估算，最好还是和 WBS方法结合起来使用

一般认为用例的数量在10－50 个范围比较合适，而每个用例可 以带有几十个相关场景

假定每一层的每一个组件平均有 10 个用例

考虑总的工作量规模时，需要对个别用例的小时数做进一步调整

IBM RMC估算方法

RMC 的工作量估算采用的是 QIF（定量影响因子）估算方法和 自底向上估算模式，对项目的任务、活动、阶段、子项目、项目 等进行自底向上的层层估算

可以定义多个估算模型

每个估算模型可以定义任意数量的估算因子

每个估算因子都会关联估算公式

使用估算公式来计算该估算因子对应的工作量

IBM RMC估算步骤 109页

创建估算模型，定义相关的估算因子；

把估算模型的估算因子应用到 WBS 底层元素，计算出它 们的工作量；

层层向上汇总，计算出项目 WBS 上层元素（包括项目本 身）的工作量。

不同场景的估算法

1. 合同签订之前，了解的需求比较有限，只能了解到项目的总 体需求，主要采用“类比分析和经验判断”等方法
2. 基于WBS估算的多维验证，获得类似项目的历史数据、软件 生命周期的生产率数据和详细需求，从而可以从不同的路径 来估算工作量，获得多个结果，这些结果可以互相印证，以 发现估算过程中的不合理之处，使估算 更准确。
3. 需求变更的工作量估计，关键是需求变更的波及范围分析

5.资源估算

基本过程

1. 根据WBS进行估算
2. 由工作量和开发周期来估算

人员数量（人）=工作量估算（人日）/工期估算（日）

1. 资源特征描述
2. 资源分配给任务
3. 定义项目角色
4. 人员分配

工期估算方法：

常用方法是专家（经验）估算法、基于历史数据的类比法

当面临高度不确定性任务时，可以采用三点估算法来进行工期估算

计划时间 =（T乐观 + 4×T可能 + T悲观）/6

工期估算中还要预留一定比例作为冗余时间以应付 项目风险。随着项目进展，冗余时间可以逐步减少。 在分析标识项目活动的时候，活动资源和历时的分 析其实是同时进行的。

特殊场景

工期估算（日） = 工作量估算（人日） / 人员数量（人）

使用这个公式时，避免人月估算的错误。要对每个人的能力进 行分析，确定他们自己的等价关系，这样，“人员数量”不是 人员的自然数量，而是更客观反映人力的等价数量

按照历史数据来估算开发周期，其准确度是可以接受的

在实际使用历史数据估算法时，组织应建立一个历史项目数据库是必要的

6.成本估算方法

同样可以使用专家评估办法、经验法、比例法和WBS方法等

成本估算过程中，要紧密结合项目进度计划。

避免过于乐观或者过于保守的估算。

在费时较长的大型项目中，还应考虑到今后的职工工资结 构、设备费用以及管理费用是否发生较大变化等

在有新员工的项目中，还应考虑其培训成本

人力资源成本是随着团队开发效率的变化而变化的。

第五章：项目进度和成本管理

1.表5-1 129页

2.前导图、箭线图130页

3.关键路径、缓冲期计算132页

4.里程碑137页

5.进度编制策略145页

6.进度编制方法148页PERT方法

7.影响软件项目进度的因素152页

8.挣值分析 160页

成本绩效指数（CPI）：

定义：衡量实际成本和计划成本之间的比率。

公式：CPI = 挣值（EV）/ 实际成本（AC）。

解释：CPI大于1表示项目开销低于预算，CPI小于1表示项目开销超出预算。

成本偏差（CV）：

定义：计算实际成本与计划成本之间的差异。

公式：CV = 挣值（EV）- 实际成本（AC）。

解释：CV为正值表示项目成本低于预算，CV为负值表示项目成本超出预算。

进度偏差（sv）=挣值（ev）-计划价值（pv），进度绩效指数（spi）=ev/pv
成本偏差、进度偏差大于0是好的，成本绩效指数（cpi）、进度绩效指数（spi）大于1 是好的

例题：一个项目在某一时间点的挣值（EV）为80,000，实际成本（AC）为75,000，计划价值（PV）为$85,000。请计算该项目的成本绩效指数（CPI）、成本偏差（CV）、进度偏差（SV）和进度绩效指数（SPI），并判断项目的成本和进度状态。

解答：

CPI = EV / AC

= 80,000/75,000

≈ 1.07

CV = EV - AC

= 80,000−75,000

= $5,000

SV = EV - PV

= 80,000−85,000

= -$5,000

SPI = EV / PV

= 80,000/85,000

≈ 0.94

解释：

CPI大于1，表示项目开销低于预算。

CV为正值，表示项目成本低于预算。

SV为负值，表示项目进度落后于计划。

SPI小于1，表示项目进度慢于计划。

第六章：项目质量管理

1.SQA、SQC、SQM区别（164页）

2.项目质量的组织保证165页

3.如何制定有效质量计划170页

4.软件评审方法和过程171页

5.分层评审、分类评审 177页

6.缺陷产品度量公式 185页

第七章：项目风险管理

1.风险的三要素：风险事件、风险事件发生的概率、风险造成的影响。

2.风险管理过程：就是分析风险4个要素的过程。旨在识别出风险，然后采取措施使他们对项目的影响最小化。4要素：风险识别、风险评估、风险计划、风险应对。

3.风险评估应对策略：规避、转移、弱化、接受。

4.风险识别的方法和工具204页

5.风险度量内容206

6.风险分析技术期望值法207

7.风险监控210

8.关键链技术215

第八章：项目团队与干系人

1.知识传递与培训232页

2.沟通原则 235页图8-7  236页

1. 学会倾听
2. 表达准确
3. 及时沟通
4. 双向沟通
5. 换位思考

3.项目干系人管理 244页

例题：

提出具体的沟通管理策略，以改善团队内部的沟通效果：

明确沟通目标：确保每次沟通都有明确的目标和期望结果。

建立沟通渠道：利用项目管理软件、邮件、会议等方式确保信息流通。

定期团队会议：定期召开团队会议，同步进度，解决问题。

加强培训：针对技术背景差异，组织内部培训，统一术语。

建立信任：通过团队建设活动，增强团队凝聚力，建立信任。

第九章：项目监督与控制

变更控制 流程

1. 变更提交
2. 变更接收
3. 变更评估
4. 变更决策
5. 变更实施与验证

例题：

某软件开发公司正在开发一款新的客户关系管理系统（CRM）。项目已经进行了三个月，但最近客户提出了一些新的功能需求，这些需求并未在最初的项目范围和需求文档中定义。

1. 作为项目经理，你如何评估这些新的功能需求对项目的影响？

答：作为项目经理，我会首先明确新功能需求的具体内容和范围，然后评估这些需求对项目进度、成本、资源分配和质量的潜在影响。评估过程可能包括分析需求变更的复杂性、所需的工作量和时间，以及是否需要额外的技术资源或培训。此外，我还会考虑变更对项目目标、用户满意度和市场竞争力的影响。

2. 你将如何制定一个变更控制流程来管理这些新的需求？

答：制定变更控制流程时，我会遵循以下步骤：

接收变更请求，并收集所有相关信息，包括变更的原因、目的、内容和预期影响。

对变更请求进行评估，包括分析其对项目目标、进度、成本和质量的影响，并考虑技术可行性和风险。

将评估结果提交给变更控制委员会（CCB）或相关决策者进行审批。

如果变更被批准，更新项目计划、预算和文档，以反映变更的影响。

通知所有相关干系人，确保他们了解变更的内容、时间和影响。

在实施过程中持续监控和记录变更的执行情况，确保变更得到正确执行。

3. 如果客户坚持要求立即实现这些新功能，你将如何处理？

答：如果客户坚持要求立即实现新功能，我会与客户进行进一步沟通，解释项目当前的进度、资源和时间限制，以及立即实现新功能可能对项目造成的潜在影响。同时，我会提出替代方案，如分阶段实施新功能或调整项目计划以腾出更多资源和时间来满足客户需求。如果客户仍然坚持，我会考虑与上级管理层或CCB讨论并寻求解决方案。

第十章：项目收尾

项目总结和改进目的

1. 分享经验
2. 避免犯同样的错误
3. 提出合理化建议
4. 提升项目流程改进
5. 激励项目队员成员
6. 最佳实践的积累