大家好，又见面了，我是你们的朋友全栈君。
第一章.软件项目管理概述
1.实现项目目标的制约因素有：
- 项目范围
- 成本
- 进度计划
- 客户满意度
2.项目管理包括：
- 启动过程组
- 计划过程组
- 执行过程组
- 控制过程组
- 收尾过程组
3.什么是项目：
为了创造一个唯一的产品或者提供一个唯一的服务而进行的临时性的努力，所以说项目具有临时性特性
4.过程管理就是对过程进行管理，目的是要让过程能够被共享，复用，并得到持续的改进
5.项目与日常运作的区别与共同点：
项目 | 日常运作 |
|---|---|
以目标为导项 | 通过效率和有效性的体现 |
通过项目经理及其团队工作完成的 | 职能式的线性管理 |
项目是一次性的 | 日常运作可以重复进行 |
共同点：
都需要人来做；而且都受资源限制；都需要规划，执行，控制
6.项目的特征：项目均是有时间范围的，所以最能表现项目特征的是确定期限
7.请简述项目管理的 5 个过程组及其关系
（1）启动过程组：主要是确定一个项目或一个阶段可以开始了，并要求着手实行；定义 和授权项目或者项目的某个阶段。 （2）计划过程组： 为完成项目所要达到的商业要求而进行 的实际可行的工作计划的设计、 维护， 确保实现项目的既定商业目标。 计划基准是后面跟踪 和监控的基础。 （3）执行过程组：根据前面制定的基准计划，协调人力和其他资源，去执行 项目管理计划或相关子计划。 （4）控制过程组： 通过监控和检测过程确保项目达到目标， 必 要时采取一些修正措施。 集成变更控制是一个重要的过程。 （5）收尾过程组： 取得项目或阶 段的正式认可并且有序地结束该项目或阶段。 向客户提交相关产品， 发布相关结束报告， 并 且更新组织过程资产并释放资源。 关系：各个过程组通过其结果进行连接，一个过程组的结果或输出是另一个过程组的输入。 其中，计划过程组、执行过程组、控制过程组是核心管理过程组。
8.项目的特征是什么
目标性、相关性、临时性、独特性、资源约束性、不确定性
第二章.项目确立
1.项目立项之后，项目负责人会进行自造购买决策，确立待开发产品的哪些部分的应该采购，外包开发，自主研发等
2，项目经理的主要职责是：
- 开发计划
- 组织实施
- 项目控制
3.在（立项）阶段，应该明确项目的目标、时间表、使用的资源和经费，而且得到项目发起人的认可。注意：项目立项是需求方（甲方）提出的需求
4.项目招标阶段
- 甲方过程：
（招标书定义） 、（供方选择）、（合同签署）
- 乙方过程：
（项目分析） 、（竞标）、（合同签署） 总而言之：甲方：客户（上帝），乙方：软件开发方
5.项目建议书是项目立项阶段（项目的初始阶段）开发的文档
6.甲方（顾客，需求方）招标阶段的任务是：
- 招标书定义
- 供方选择
- 合同签署
7.某公司希望开发一套软件产品， 如果选择自己开发软件的策略， 公司需要花费 30000 元，根据历史信息，维护这个软件每个月需要 3500 元。如果选择购买软件公司产品的策略，需要 18000 元，同时软件公司为每个安装的软件进行维护的费用是 4200 元/月。该公司该如何决策？
自制方案： 制造费 30000 元 维护费 3500 元/月 购买方案： 购买费 18000 元 维护费 4200 元/月 制造差额： 30000-18000=12000 元 服务差额： 4200-3500=700 元 自制方案承受月份： 12000/700=17.14 如果产品在 17 个月以内可以选择购买方案，如果超过 17 个月选择自造方案。
8.什么是项目章程？
项目章程是项目执行组织高层批准的一份以书面签署的确认项目存在的文件， 包括对项 目的确认、对项目经理的授权和项目目标的概述等。
9.招标书主要包括那几部分内容？
招标书主要包括三部分内容：技术说明、 商务说明和投标说明。技术说明主要对采购的 产品或者委托的项目进行详细的描述， 商务说明主要包括合同条款。 投标说明主要是对项目 背景、标书的提交格式、内容、提交时间等做出规定。
第三章.生存期模型
1.瀑布模型 生存期模型中， 要求项目所有的活动都严格按照顺序进行，一个阶段的输入是下一个阶段的输入。
2.敏捷开发通过迭代和快速用户反馈应对管理的不确定性和变更
3，每日站立会议是（Scrum）模型敏捷开发实践
4.瀑布模型适合短期项目
5.增量式模型可以避免一次性投资太多带来的风险
6.各个模型的优缺点：
模型 | 特点 | 缺点 | 使用范围 |
|---|---|---|---|
瀑布模型 | 线性,阶段计划分明,以项目的阶段评审和文档控制为手段有效的对整个开发过程进行指导 | 缺乏灵活性，无法解决需求不明确或者不准确的情况;（2）由于开发是线性的，只有到末期才能见到开发成果,增加了开发的风险;（3）早期的错误到后期才能发现 | 适用于需求明确，解决方案明确的项目 |
V模型 | 纠正了人民不重视测试阶段的重要性的错误认识,将测试分等级,并且和前面的开发阶段对应 | 仍然将测试作为一个独立的阶段,并没有提高抗风险能力 | 与瀑布模型类似 |
快速原型模型 | 有助于增进软件人员和用户对系统服务需求的理解 | 文档容易被忽略,建立原型的许多工作会被浪费掉，项目难以规划和管理 | 适用于需求不明确,动态变化的项目 |
增量模型 | 增强了客户使用的信心，逐步提出对后续增量的需求;增量由高到低的优先级确定保障了系统重要功能部分的可靠性;项目总体失败的风险比较低 | 增量粒度选择问题，确定所有的基本服务比较苦难 | 适用于需求大部分明确，系统较为复杂,有一定的技术风险 |
渐进式模型:
- 缺点：需要精心规划各个阶段目标，每个阶段提交的是正式版本，所以工作量会增加
- 使用范围：主要适用于中型或者大型项目，是目前开发中最常用的开发模型 敏捷生存模型：通过迭代和快速的用户反馈管理不确定性和应对变更 敏捷开发宣言：
个体和交互胜过过程和工具；可以工作的软件胜过面面俱到的文档；客户合作胜过合同谈判；相应变化胜过遵循计划 适用于需求不明确的情况下采用
7.三种你熟悉的生存期模型，并说明这些模型适用于什么情况下的项目
（1）瀑布模型 适用于软件需求很明确的软件项目， 即一般适用于功能明确、 完成、 无重大变化的软件系统 的开发，即： 1） 在项目开始前，项目的需求已经被很好的理解、也很明确，而且项目经理很熟悉为实现 这一模型所需要的过程。 2） 解决方案在项目开始前也很明确。 3） 短期项目可采用瀑布模型。 （2）V 模型 适用于项目需求在项目开始前很明确、解决方案在项目开始前也很明确，项目对系统的 安全很严格，如航天飞机控制系统、公司的财务系统等。 (3)快速原型模型 适用于项目的需求在项目开始前不明确，需要减少项目的不确定性的时候。
第四章 软件项目范围计划——需求管理
1.需求管理包括:
- 需求获取
- 需求分析
- 需求规格编写
- 需求验证
- 需求变更
2.原型分析方法 是其中一种需求建模方法。
3.结构化分析方法是一种自下而上逐步求精的分析方法
4.软件项目管理需求过程:
- 需求获取
- 需求分析
- 需求规格编写
5.数据字典组成部分:
- 数据项
- 数据流
- 数据文件
6.下列不属于 UML 需求视图的是?
甘特图(甘特图用于做计划的视图) 属于需求的视图的是：用例图，状态图，顺序图
7.属于需求建模的方法：
- 原型方法
- 面向对象的用例分析方法
- 功能列表方法
8.（需求变更）软件项目的一个突出特点，可以导致软件项目的蔓延
9.结构化方法设计有：
- 数据流图
- 数据字典
- 系统流程图
10.我们常常从哪些方面着手处理需求不明确的问题？
(1)让用户参与开发 (2)开发用户界面原型 (3)需求讨论会议 (4)强化需求分析和评审
第五章 软件项目范围规划——任务分解
1.任务分解是将一个项目分解为更多的工作细目或者 子项目 ，是项目变得更小、更易管理、更易操作
2.一般来说，进行项目分解时，可以采用 清单 或图表 两种形式来表达任务分解的结果。
3.WBS的全称是 任务分解结构 ：Work Breakdown Structure。
4.WBS最底层次可交付成果是 ：工作包 work package。
5.WBS提供了项目范围基线
6. 一个工作包可以分配给另一个项目经理去完成。(注：工作包应当由唯一主体负责，可以分配给另外一位项目经理通过子项目的方式完成。)
7.对于一个没有做过的项目，开发 WBS时可以采用自底向上方法。
8. 在任务分解结果中，最底层的要素必须是实现项目目标的充分必要条件。
9.任务分解是将一个项目分解为更多的工作细目或者子项目， 使项目变得更小、 更易管理和操作。
10.一个工作包应当由唯一主体负责。
11.WBS的最底层任务是能分配到一个人完成的任务。
12…WBS非常重要，因为：
帮助组织工作,防止遗漏工作,为项目估算提供依据 但是不包括确定团队成员责任
13.WBS中的每一个具体细目通常都指定唯一的编码
14.创建 WBS的方法有：
自顶向下 ,自底向上 ,模板参照,不包括控制方法
15.任务分解时，
（自底向上）方法从特殊到一般的方向进行，首先定义一些特殊的任务，然后将这些任务组织起来，形成更高级别的 WBS层。 (自顶向下)方法从一般到特殊的方向进行，从项目的大局着手，然后逐步分解子细目，将项目变为更细、更完善的部分
16.WBS的定义：
(1)WBS是任务分解的结果;(2)不包括再 WBS中的任务就不是该项目的工作;(3)可以采用清单或者图表的形式标识WBS的结果
17.检验 WBS分解结果的标准：
- 最底层的要素是否是实现目标的充分必要条件
- 最底层元素是否有重复
- 最底层要素是否有清晰完整定义
18.WBS是对项目由粗到细的分解过程，它的结构是:分级的树形结构
19.任务分解的方法和步骤
任务分解的基本步骤：
- 确认并分解项目的组成要素 (WBS编号 ) 。
- 确定分解标准，按照项目实施管理的方法分解，而且分解的标准要统一。
- 确认分解是否详细，是否可以作为费用和时间估计的标准，明确责任。
- 确定项目交付成果（可以编制 WBS字典）。
- 验证分解正确性。验证分解正确后，建立一套编号系统。
任务分解方法：
- 模板参照方法
- 类比方法
- 自上而下
- 自下而上
20.当项目过于复杂是，可以对项目进行任务分解，这样做的好处是什么?
将一个项目分解为更多的工作细目或者子项目， 使项目变得更小、 更易管理、 更易操作，这样可以提高估算成本、时间和资源的准确性，使工作变得更易操作，责任分工更加明确。
21.检验任务分解结果的标准是什么？
检验任务分解结果的标准有：
- 最底层的要素是否是实现目标的充分必要条件
- 最底层要素是否有重复的
- 每个要素是否清晰完整定义
- 最底层要素是否有定义清晰的责任人
- 是否可以进行成本估算和进度安排
第六章 项目成本计划
1.软件项目成本包括直接成本和间接成本，一般而言，项目人力成本归属于直接成本。
2.再在项目初期，一般采用的成本估算方法是类比估算法。
3.功能点方法中 5 类功能组件的计数项是外部输入、外部输出、外部查询、内部逻辑文件、外部接口文件。
4.软件项目的主要成本是人的劳动的消耗所需要的代价。
5.用例点方法通过分析用例角色、场景和技术与环境因子等来进行软件估算
6.人的劳动消耗所付出的代价是软件产品的主要成本。
7.估算时既要考虑直接成本又要考虑间接成本。
8.（规模）是成本的主要因素，是成本估算的基础
9.常见的成本估算方法：
代码行，功能点，类比法；记住不包括关键路径法
10.UFC的功能计数项：
UFC:未调整功能点计数 包括：外部输出，外部文件，内部文件
11.成本预算的目的是：产生成本基线
12.估算的基本方法包括：
1）代码行，功能点；2）参数估算法；3）专家估算法；记住不包括函数估算法
13.在项目初期，进行竞标合同时，一般采用的成本估算方法是类比估算法
14.软件项目规模单位有：
- 代码长度（LOC）
- 功能点（FP）
- 人天，人月，人年 不包括小时
15.在成本管理过程中，每个时间段中等各个工作单元的成本是（预算）
16.项目经理正在进行一个图书馆信息查询系统的项目估算，他采用 Delphi 的专家估算方法，邀请了 3 位专家进行估算， 第一位专家给出了 2 万元、 7 万元、 12 万元的估算值， 第二位专家给出了 4 万元、 6 万元、 8 万元的估算值，第三位专家给出了 2 万元、 6 万元、 10 万元的估算值，试计算这个项目的成本估算值
专家一： Ei=(ai 4mi bi)/6= （2 47 12）/6=7 专家二： Ei=(ai 4mi bi)/6=（4 46 8）/6=6 专家三： Ei=(ai 4mi bi)/6= （2 4*6 10 ）/6=6 Ei=（7 6 6）/3=6.33 （万元）
17.如果某软件公司正在进行一个项目，预计有 50KLOC的代码量，项目是中等规模的半嵌入型的项目，采用中等 COCOMO模型，项目属性中只有可靠性为很高级别（即取值为 1.3），其他属性为正常 （书上说， 正常就是 1），计算项目是多少人月的规模， 如果是 2 万元 /人月，则项目的费用是多少？
Effort=a* (KLOC)b F 查表 a=3，b=1.12，F=1 Effort=3.050 1.12 1.31=311.82 （人月） 所以项目的费用为 2* Effort=623.64 万元
18.已知某项目使用 C语言完成，该项目共有 85 个功能点，请用 IBM 模型估算源代码行数、工作量项目持续时间、人员需要量以及文档数量。
C 语言代码行与功能点的关系近似为 150LOC/FP，所以， 85 个功能点代码行数为 L=85150=12750 行=12.75KLOC,则:工作量估算 E=(5.2L)的0.91次方 =（5.212.75）的0.91次方≈52.725（人月） 项目时间 D=（4.1L）的0.36次方 =(4.112.75)的 0.36次方 ≈10.25（月） 人员需求量 S=（0.54E）的 0.6次方 =0.5452.725的0.6次方 ≈5.829（人） 文档数量 DOC=49L 的1.01次方 =49*12.75的1.01次方≈640.857（页）
第七章软件项目进度计划
1.关键路径 决定了项目在给定的金钱关系和资源条件下完成项目所需的最短时间
2.时间 是一种特殊的资源，以其单向性、不可重复性、不可替代性而有别于其他资源，是项目计划中灵活性最小的因素 。
3.在 ADM 网络图中，箭线表示 活动（任务）,结点表示前一个任务的结束，同时表示后一个任务的开始 。
4.应急法 和平行作业法 都是时间压缩法。
5.任务（活动） 之间的排序依据主要有 强制性依赖关系、 软逻辑关系、 外部依赖关系 等。
6.工程评估评审技术采用加权平均的公式是 PERT历时 =(O P 4M)/6 ，其中 O 是乐观值， P是悲观值， M 是最可能值。
7.一个工作也可以通过多个活动完成。
8.在项目进行过程中，关键路径是可变的
9.在 PDM 网络图中，箭线表示的是任务之间的逻辑关系，节点表示的是活动。
10.在资源冲突问题中，过度分配也属于资源冲突。
11.浮动是在不增加项目成本的条件下，一个活动可以延迟的时间量
12.在使用应急法压缩时间时，要在关键路径上选择活动来进行压缩，因为能够压缩的都是关键路径。
13.时间是项目规划中灵活性最小的因素。
14.常用的公式：
- EF(最早完成时间)=ES(最早开始时间) duration(任务的历时时间)
- LS(最晚开始时间)=LF(最晚完成时间)-duration(任务的历时时间)
- TF(总浮动：在不影响项目最早完成时间)=LS(最晚开始时间)-ES(最早开始时间)=LF(最晚完成时间)-EF(最早完成时间)
- FF(自由浮动：在不影响后置任务最早开始的时间)=ES(最早开始时间)-EF(最早完成时间)-lag(本任务与后置任务之间的之后时间)
15.常见的依赖关系：
- 强制性依赖关系
- 软逻辑关系
- 外部依赖关系
- 里程碑
16.（甘特图）可以显示任务的基本信息，使用该类图能方便的查看任务的工期、开始时间、结束时间以及资源的信息。
17.(进度问题)是项目冲突的主要原因，尤其在项目后期。
18.编制进度的基本方法：
- 关键路径法
- 时间压缩法
- 资源平衡法 注：系统图法不是
19.快速跟进是指采用并行执行任务，加速项目进展
20.（lag）将延长项目的进度
21.(总浮动)可以决定进度的灵活性
22.对一个任务进行进度估算时， A 是乐观者，估计用 6 天完成， B 是悲观者，估计用 24天完成， C是有经验者，认为最有可能用 12 天完成，那么这个任务的历时估算介于 10天到 16 天的概率是多少？
E=(6 24 4*12)/6=13 ， δ=(24-6)/6=3 E-δ =10 E δ=16 查表(p139)得任务历时估算介于 10—— 16 天的概率为： 68.3%
23.请将下图所示的 PDM（优先图法）网络图改画为 ADM（箭线法）网络图。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RbSNI3en-1589334555768)(1.png)]
上图对应的 ADM 图如下所示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wJ2BirqS-1589334555770)(2.png)]
24.根据下面任务流程图和下表给出的项目历时估算值，采用 PERT方法估算，求出项目在14-57 天内完成的概率的近似值。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Tpm3FGPR-1589334555772)(3.png)] [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-p2qjSfsr-1589334555774)(4.png)]
标准差：δ=（P-O）/6;
第八章软件项目质量计划
1.（审计）是对过程或产品的一次独立质量评估。
2.质量成本包括预防成本和（缺陷成本）。
3.质量管理包括（软件质量计划） 、（软件质量保证） 、（软件质量控制）等过程。
4.（软件质量）是软件满足明确说明或者隐含的需求的程度。
4.McCall 质量模型关注的 3 个方面是（产品运行） 、（产品转移） 、（产品修改）。
5.质量管理总是围绕着(质量保证)和（质量控制）过程两个方面进行。
6.质量保证的主要活动是（项目执行过程审计）和（项目产品审计）
7.质量是满足要求的程度 ,包括符合规定的要求和满足顾客隐含需求
8. 软件质量是软件满足明确说明或者隐含的需求的程度。
9.质量形成于产品或者服务的开发过程中， 而不是事后的检查 （测试） 把关等。
10.质量计划可以确定质量保证人员的特殊汇报渠道。
11.质量管理过程：
- 质量计划
- 质量保证
- 质量控制
12.项目质量管理的目标是满足（项目）的需要
13.质量成本：
- 预防成本（评估费用和评估费用）
- 缺陷成本（内部费用和外部费用）
14.软件质量模型：
- Boehm 质量模型
- McCall 质量模型
- ISO/IEC 9216质量模型
15.质量控制非常重要，但是进行质量控制也需要一定的成本， （使用抽样统计）可以降低质量控制的成本。
16.McCall 质量模型包含：
- 产品修改
- 产品转移
- 产品运行
- 不包括产品特点
17.质量计划中可以采用哪些方法？
质量计划中可以采用以下几种方法： （1）试验设计：试验设计是一种统计学方法，确定哪些因素可能会对特定变量产生影响。 （2）基准对照：是一种寻找最佳实践的方法，是利用其他项目的实施情况作为当前项目性能衡量的标准。 （3）质量成本分析：质量计划必须进行质量成本的综合分析，以便决定质量活动。 （4）流程图方法：可以显示系统的各种成分是相互的关系，帮助我们预测在何处可能发生何种质量问题。 （5）因果分析图：也称鱼刺图。描述相关的各种原因和子原因如何产生潜在问题或影响，将影响质量问题的 “人员、 设备、参考资料、 方法、环境”等各方面的原因进行细致的分解，方便地在质量计划中制定相应的预防措施。
18. 简述质量保证的主要活动，以及质量保证的要点。
质量保证的主要活动是项目执行过程审计和项目产品审计。 质量保证的要点是：对项目进行评价、推测能否达到质量指标、建立对项目的信心
19.简述质量保证与质量控制的关系。
质量保证（ QA）是通过评价项目整体绩效 ,建立对质量要求的信任，提供项目和产品可 视化的管理报告。 这个任务本身并不能提高产品的质量， 但是通过质量保证的一系列工作可 以间接地提高产品的质量。质量保证一般由质量保证部门人员实施。 质量控制（ QC）是确定项目结果与质量标准是否相符 ,同时 ,确定消除不符的原因和方法，它 控制产品的质量，及时纠正缺陷。这个任务本身提高产品的质量，一般由开发人员实施。 质量保证是后期质量活动，质量控制是前期质量活动。它们是有区别的 :质质量保证是针对 项目实施过程的管理手段，质量控制是针对项目产品的技术手段 ;实施质量保证是针对过程 改进和审计的， 强调的是过程改进和信心保证。 实施质量控制是按照质量要求， 检查具体可 交付成果的质量，强调的是具体的可交付成果。
第九章软件配置管理计划
1. 配置管理最终保证软件产品的（完整性） 、（一致性）、（追溯性）、（可控性）。
2.（完整性和可跟踪性）是软件配置管理的核心功能。
3.（基线）标志开发过程中一个阶段的结束和里程碑。
4. 基线变更控制包括（变更请求） 、（变更控制） 、（变更批准 /拒绝）、（变更实现）等步骤。
5.（版本管理） 、（变更管理）是配置管理的主要功能。
6. 基线变更时，需要经过（ SCCB）授权。
7. SCCB的全称是（软件配置控制委员会） 。
8.基线提供了软件生存期中各个开发阶段的一个特定点(记住是各个开发阶段，不是单独的某一个开发阶段)
9.一个（些）配置项形成并通过审核，即形成基线。
10.变更控制系统包括从项目变更申请、 变更评估、 变更审批到变更实施的文档化流程。
11. 基线修改应受到控制，而且一定要经 SCCB授权。
12.基线产品是可以修改的
13.基线的修改需要每次都按照正式的程序执行。
14. 软件配置项是项目需定义其受控于软件配置管理的款项， 每个项目的配置项不一定是相同的。
15.SCCB的职责：
- 评估变更
- 与项目管理层沟通
- 对变更进行反馈
- 注意：提出变更申请不是sccb的职责
16.为了更好地管理变更， 需要定义项目基线， 关于基线:
可以变化，但是必须通过基线变更控制流程处理
17.软件配置管理可以确保软件产品完整性，一致性，可控性，但是无法确保产品的正确性
18.变更控制需要关注的是：标识变更，提出变更，管理变更
19.配置管理的基本过程：
（1）配置项标识、跟踪； （ 2）配置管理环境建立； （3）基线变更管理； （4）配置管理审 计；（5）配置状态统计； （ 6）配置管理计划。
20.软件配置控制委员会（ SCCB）的基本职责：
评估变更、批准变更申请、在生存期内规范变更申请流程、对变更进行反馈、与项 目管理层沟通。
21.配置管理在软件 开发中的作用，并列举至少两种配置管理工具
软件配置管理是软件项目管理的重要内容，也是保证软件质量的重要手段。它能 够对软件开发过程进行有效管理和控制， 从而实现软件产品的完整性、 一致性、可控性，使 产品极大程度地与用户需求相吻合。 它能够控制、 记录、追踪对软件的修改并形成规范文档， 方便日后维护和升级，更重要的是能够保护代码资源，积累软件财富，提高软件重用率。 配置管理工具有： Harvest、 Perforce、ClearCase、PVCS、CVSSVN、 VSS
22.写出几个常见的软件配置项
软件项目计划、需求分析结果、软件需求规格说明书、设计规格说明书、源代码清 单、厕所规格说明书、 测试计划、 测试用例与实验结果、 可执行程序、 用户手册、 维护文档。
第十章软件项目人员与沟通计划
1. 沟通管理的基本原则是及时性、准确性、完整性、可理解性。
2.可以充分发挥部门资源优势集中的组织结构为职能型组织结构
3. 沟通计划用于确定谁需要信息，需要什么信息，何时需要信息，以及如何将信息分发给他们。
4. 组织结构的主要类型:
- 职能型(适用于主要由一个部门完成的项目或技术比较成熟的项目组织结构，是目前最普遍的项目组织形式，它是一个标准的金字塔型组织形式)
- 项目型(在这种组织结构中项目成员没有安全感)
- 矩阵型(项目涉及多的领域和特性)
5. 会议形式 沟通最有可能协助解决复杂的问题。
6.当项目中有 20 个人时，沟通渠道最多有 190。
代码语言：javascript复制公式：N(N-1)/2 其中N:表示人员总数7.项目干系人是项目计划的一部分。
8.项目沟通的基本原则是及时性、准确性、完整性和可理解性
9.在 IT 项目中，成功的最大威胁是沟通的失败
10.责任分配矩阵是明确项目团队成员的角色与职责的有效工具
11.对于紧急的信息， 应该通过口头的方式沟通； 对于重要的信息， 应采用书面的方式沟通
12.人员计划描述项目的团队人员什么时候，以及如何加入和离开团队
13.沟通计划包括确定谁需要信息， 需要什么信息， 何时需要信息， 以及如何接收信息等
14.人员管理计划没有明确的具体体现形式， 作为项目计划的一部分， 其详细程度因项目而异
15.项目经理花在沟通上的时间是 75%-90%
16.干系人：
- 影响项目决策的个人、群体或者组织
- 影响项目活动的个人、群体或者组织
- 影响项目结果的个人、群体或者组织
- 注意只有这三种，并不是适应所有的项目人员
17.编制沟通计划的基础是沟通需求分析
18. 团队：
- 是一定数量的个体成员的集合
- 团队应注重个人发挥，应该将某项任务分工给擅长该技术的职员
- 团队的目的是开发出高质量的产品
- 团队包括自己组织的人、供应商、分包商，注意没有客户
19.写出 5 种以上项目沟通方式
沟通方式主要有书面沟通和口头沟通、 语言沟通和非语言沟通、 正式沟通和非正式沟通、 单向沟通和双向沟通、网络沟通等
20.矩阵型项目组织结构的优缺点是什么
优点是： 1、专职的项目经理负责整个项目，以项目为中心，能迅速解决问题。在最短的时间内调配人才，组成一个团队，把不同职能的人才集中在一起。 2、多个项目可以共享各个职能部门的资源。在矩阵管理中，人力资源得到了更有效的利用，减少了人员冗余。 3、既有利于项目目标的实现，也有利于公司目标方针的贯彻 4、项目成员的顾虑减少了，因为项目完成后，他们任然可以回到原来的职能部门，不用担心被解散，而且他们能有更多机会接触自己企业的不同部门。 缺点是 1、容易引起职能经理和项目经理权利的冲突。 2、资源共享可能引起项目之间的冲突 3、项目成员有多位领导，即员工必须要接受双重领导，因此经常有焦虑与压力
第十一章软件项目风险计划
1.风险评估的方法包括
- 定性风险分析
- 定量风险分析。
2.决策树分析是一种 形象化的图表分析 方法。
3.项目风险的三要素是
- 风险事件
- 风险事件发生的概率
- 风险造成的影响
4.(回避)风险是指尽可能地规避可能发生的风险， 采取主动放弃或者拒绝使用导致风险的方案
5.风险规划的主要策略(应对风险的常见策略)是:
- 回避风险
- 转移风险
- 损失控制
- 自留风险
6.软件项目风险识别常采用 德尔菲方法、头脑风暴法、情景分析法、风险条目检查表、其他等方法。
7.定量风险评估主要包括 访谈、盈亏平衡分析、决策树分析、模拟法、敏感性分析 等方法。
8.风险管理的 4 个过程:
- 风险识别
- 风险评估
- 风险规划
- 风险控制
9.风险的三要素:
- 一个事件
- 事件发生的概率
- 事件的影响
10.险评估方法:
- 盈亏平衡分析
- 模拟法
- 决策树分析
11.一个项目在进行规划的时候，碰到了一个风险问题，项目经理决定是否采用方案 A。如果采用方法 A 需要使用一个新的开发工具，而能够掌握这个工具的概率是 30%，通过使用这个工具可以获利 5 万元，如果采用方案 A 而不能掌握这个工具，将损失 1 万元。利用决策树分析技术说明这个项目经理是否应该采用这个方案 A？（绘制决策树）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tZxOV8Nj-1589334555777)(5.png)] EMV:损益期望值 公式:EMV=(outcome(回报)*成功概率-亏本 * 亏本概率) EMV=(50000 * 30%-10000 * 70%) =8000
12.某企业在今年有甲乙两种产品方案可以选择，每种方案的状态、收益和概率如表 11-11 所示，绘制决策树时，判断哪种方案将有更大收益。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ya7FxaAB-1589334555778)(6.png)] [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-M7GW4oxz-1589334555780)(7.png)]
第十二章软件项目合同计划
1.买房风险最高的合同类型： FFP（固定总价合同）
2.为执行项目而从项目团队外获取产品、服务或者成果的过程称为：采购
3.合同双方当事人承担不同角色，这些角色包括：甲方、乙方
4.软件外包的基本步骤：竞标邀请、评估候选乙方的综合能力、确定承包商
5.如果 CPPC合同类型中成本百分比是 10%，估计成本是 10 万元，当实际成本是 20 万元是，合同金额应该为： 22 万元
20 10% * 20=22万
6.一个 CPFF合同类型，估计成本是 10 万元，固定费用是成本 1.5 万元，当成本提高至 20万元是，合同金额为： 21.5 万元
20 1.5=21.5万
7.合同类型有：
- 成本补偿类合同(CPCC)
- 固定价格类合同(FFP)
- 单价类合同()
- 成本加奖金（ CPIF）合同
- 成本加成本百分比(CPPC)
- 固定成本加奖金(FPIF)
8.招标书可以是合同计划的输出
9.对于甲方来说，风险最高的是 CPCC合同类型，风险最低的是 FFP合同类型，乙方则相反
10.某项目采用成本加奖金的成本补偿类合同，当预算成本为 20 万元，利润 4 万元，且奖励分配为 80/20 时，如果实际成本降至 16 万元，则项目总价为
项目总价=成本 奖金（节约成本 * 20%） 利润=16 （节约成本=20-16=4）4 * 20% 4=20.8万
11.合同是需要靠（ 相关法律法规）约束的
12.项目预计成本 10 万，成本百分比 20%，如实际成本 8 万，则合同金额：
8 20%*8=9.6
13.成本加奖金合同，激励比 80/20; 估计成本 12 万，利润 1 万。如实际成本 12 万，则合同金额为： 12 1=13 万；如实际成本为 11 万，则合同金额为
11 1 （12-11）20%=12.2
第十三章项目集成计划
1.软件项目管理最终要的 4 个要素是：
- 范围
- 质量
- 进度
- 成本
2.质量和成本成一定的正比关系,进度和成本成一定的反比关系,范围和成本成一定的正比关系
3.为了加快项目进度，可以适当见减低过程中的质量标准
4.项目集成管理包括:
- 对计划的集成管理和项目跟踪控制的集成管理
- 保证项目各要素协调
- 在相互影响的项目目标和方案中做出权衡
- 没有软件设计文档
5.设成本 C 是范围 S、质量 Q、进度 T的一个函数 C=F（S，Q，T），在成本或时间不充足的情况下，可以通过减小范围或者（ 降低质量）来解决。
6.项目管理过程中的进度目标，成本目标，质量目标，范围目标等各个目标之间是(相互关联和制约的)
7.软件项目管理要素:
- 范围
- 质量
- 成本
- 不包含交互
8.项目集成计划的特点：
- 综合性
- 全局性
- 内外兼顾性
- 不包含针对性
第十四章项目集成计划执行控制
1.项目执行控制的基本步骤：
1）建立计划标准； 2）观察项目的性能； 3）测量和分析结果； 4）采取必要措施； 5）做好计划修订工作，控制反馈。
第十五章项目核心计划执行控制
1.软件项目中的软件开发成本是总成本的主要部分。
2.当 SV=BCWP-BSWS<0时，表示项目进度落后。
3.代码评审由一组人对程序进行阅读、讨论和争议，它是质量控制过程。
4.挣值分析法也称为已获取价值分析，是对项目的实施进度、成本状态进行绩效评估的有效方法。
5.从质量控制图的控制上限和控制下线，可以知道接受的过程的偏差范围。
6.范围控制的重点是避免需求的变更。
7. 一个任务原计划 3 个人全职工作 2 周完成，而实际上只有 2 个人参与这个任务，到第二周末完成了任务的 50%，则 CPI=？
CPI(成本效能指标)=BCWP(已经完成工作的成本预算)/ACWP（到目前为止花了多少钱） * 100% * ＣＰＩ＞１：低于预算 ；＝１：按照计划进行；＜１：超过预算
8.记录反映当前项目状态的项目性能数据是控制项目的基础。
9. 项目进度成本控制的基本目标是在给定的限制条件下，用最短时间、最小成本、以最小风险完成项目工作。
10.代码走查是在代码编写阶段，开发人员自己检查自己的代码。
11. 在使用应急法压缩进度时，能够进行压缩的只有关键路径。
12. 累计费用曲线中某时间点 ACWP(到目前为止花了多少钱)比 BCWS（到目前为止本应该完成的工作是多少）高，意味着在这个时间点为止，实际的成本要比计划的高，二者之间的差值就是成本差异。
13. 技术评审的目的是尽早发现工作成果中的缺陷，并帮助开发人员技师消除缺陷，从而有效的提高产品质量。
14. 项目原来预计于 2014.5.23 完成 1000 元的工作，但到 2014.5.23 只完成 850 元工作，而为了这些工作花费 900 元，则成本偏差和进度偏差分别是
SV(进度差异)=BCWP(到目前为止实现了多少价值)-BCWS(到目前为止应该完成多少) 所以SV=850-1000=-150 CV(费用差异)=BCWP(到目前为止实现了多少价值)-ACWP(到目前为止花了多少钱) 所以CV=900-850=50
15.如果成本效能指标 CPI=90%，他说明投入 1 元产生 0.9 元的效果
16.进度控制重要的一个组成部分是确定进度偏差是否需要采取纠正措施
17.资源平衡最好用于（非关键路径）活动
18.当项目进展到（20%）左右时， CPI处于稳定
19.抽样统计的方法中,以小批量的抽样为基准进行检验
20.质量控制的3 个要点：
- 检查项目结果
- 依据相关质量标准进行跟踪检查
- 确定消灭质量问题的措施
21.某项目由 1、2、3、4 四个任务构成，该项目目前执行到第 6 周末，各项工作在其工期内的每周计划成本、每周实际成本和计划工作量完成情况下表所示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8g7YrGmu-1589334555781)(8.png)]
1.根据提供的信息，计算截至第 6 周末该项目的 BCWS、ACWP、BCWP
BCWS=10 15 5 10 10 10 20 10 10 5 5=100; ACWP=10 16 8 10 10 12 24 12 5 5=112 BCWP=10 15 5 (10 10 10 20 10 10)/2 (5 5 25 5)/2=95
2.计算第 6 周末的成本偏差 CV、进度偏差 SV，说明结果的实际意义
CV=BCWP-ACWP= -17 SV=BCWP-BCWS= -5
3.照目前情况，计算完成整个项目实际需要投入多少资金？写出计算公式。
CPI=BCWP/ACWP=84% EAC=BAC/CPI=170/84% = 202
22.某项目正在进行中，下表是项目当前运行状况的数据，任务 1、2、3、4、5、6 计划是按顺序执行的，表中也给出了计划完成时间和实际的执行情况。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Pqy65eOI-1589334555782)(9.png)]
1.计算 BAC
BAC=5 25 120 40 60 80=330
2.计算截至 2014 年 4 月 1 日的 BCWP、BCWS、 ACWP、 SV、SPI 、 CV、CPI等指标。
BCWP=5 25 40=70 BCWS=10 20=30 ACWP=10 20 50=80 SV=BCWP-BCWS=40 SPI=BCWP/BCWS=175% CV=BCWP-ACWP=-10 CPI=BCWP/ACWP=87.5%
23.试述 Pareto 规则
80%的问题是由 20%的原因引起。
第十六章项目辅助计划执行控制
1.项目周例会是一种正式沟通方式。
2.在马斯洛的需求层次理论中，最高层需求是自我实现。
3. Y理论属于参与理论
4.风险管理是连续的过程。
5.管理干系人参与和控制干系人参与都是干系人管理的任务。
6.敏捷生存期模型中的每天站立会议是很有效的一种沟通方式。
7.对于冲突而言，冲突常常是有利的事情
8.项目培训特点：
- 时间短
- 针对性强
- 见效快
9.冲突解决方法:
- 解决问题（ confrontationorproblemsolving ）
- 妥协（ compromise ）
- 强迫方式（ forcingmode ）
- 撤退（ withdrowal ）
10.项目中的小组成员要同时离开公司，项目经理首先应该（ 实施风险计划 ）。
11.一个软件项目团队中一般有哪些人员角色？
项目经理、架构分析师、系统分析师、 DBA、程序开发人员、测试人员、系统工程师、 质量管理人员
十七章 项目结束过程
1.项目目标已经成功实现，可交付成果已经出现；或者项目无法继续进行，这时项目可以 终止 了。
2.项目结束过程包括
- 制定结束计划
- 完成收尾工作
- 项目最后评审。
3.是否在预算成本内完成项目、是否实现目标、是否达到项目客户的期望等都是检验项目成功与失败的标准。
4. 项目验收过程是甲方对乙方交付的产品或服务进行验收检验，以保证它满足合同条款的要求。
5. 项目计划中确定的可交付成果已经出现， 项目的目标已经成功实现时， 可终止项目。
6.一个项目的交付验收，意味着项目的结束
7.当一个项目的目标已经实现，或者明确看到目标已经不可能实现时，项目就应该终止。
8. 客户接受项目的交付结果之前，项目经理应该检查交付结果的质量
9.不包括在项目验收过程中的是 项目总结
10.项目终止的条件:
- 项目计划中确定的可交付成果已经出现，项目的目标已经成功实现
- 项目已经不具备实用价值
- 项目由于各种原因而导致无限期拖长
- 不包括项目需求发生了变化
11.项目成功与失败的标准是：
- 是否实现目标
- 可交付成功如何
- 是否达到项目客户的期望
- 不包括项目人数庞大
12. 在项目的末期，与卖方的合同还有尚未解决的索赔，项目经理（进行合同收尾，合同收尾之后，可能采取法律行动）。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/136414.html原文链接：https://javaforall.cn
