高项软考之其他重要项目管理知识点
2025-08-01 11:13:48 0 举报AI智能生成
高项已过，分享知识点，共勉
作者其他创作
大纲/内容
文档管理
开发文档
可行性研究报告和项目任务书
需求规格说明书
设计规格说明书
开发计划
软件集成和测试计划
质量保证计划
安全和测试信息
产品文档：交付或运营时给客户使用
培训手册
参考手册和用户指南
软件支持手册
产品手册和信息广告
管理文档
开发过程每个阶段的进度和进度变更记录
开发团队的职责定义
项目计划、项目阶段报告
变更管理
变更分类
根据变更性质：通过不同审批权限控制
重大变更：顾问委员会
重要变更：CCB
一般变更：PM
根据变更的迫切性：通过不同变更处理流程进行
紧急变更
非紧急变更
根据变更内容
项目变更管理原则是项目基准化、变更管理过程规范化
决策机构包含的人员
项目经理（受业主委托对项目经营过程负责，监督变更的执行，更新相关文档，对变更负最终的责任）
CCB（通过评审手段来决定项目基准是否能变更，但不提供变更方案）
客户（提出合理需求，验收项目的交付成果，并支付项目款项）
决策方的实施人员（变更执行人，负责实施变更内容，并确保可以保质保量完成任务）
变更流程
提出与接受变更申请：变更提出及时以正式方式进行，并留下书面记录
对变更的初审：对变更的提出方施加影响，确认变更的必要性，确保变更是有价值的，确保与干系人达成共识
变更方案论证：对变更方案是否可行可实施进行论证，如果可行，则将技术要求转为资源需求，供CCB决策
项目管理委员会进行审查：决策是否需要变更项目基准
发出变更通知并组织实施
变更实施监控
PM负责基准监控
CCB监控变更的结果、里程碑进度等，也可以由监理单位代为完成
变更效果的评估
首要评估依据是项目的基准
还需要结合变更初衷来看，变更所要达到的目的是否已达成
变更收尾：判断发生变更后的项目是否已纳入正常轨道
其他知识领域变更控制流程
项目范围（需求）变更控制流程
提出变更申请：确定变更已经发生，防止蔓延
变更影响分析（需要从高层到底层，对被影响的需求文件进行处理）
批准或否决变更
执行变更
监控变更实施
结束变更
对进度变更的控制
对成本变更的控制
对造成费用基准变更的因素施加影响（确保变更请求获得同意）
当变更发生时管理这些实际的变更 （保证潜在的费用超支不超过授权的项目阶段资金和总体资金）
监督费用绩效，找出与费用基准的偏差（确保变更请求获得同意）
防止错误的、不恰当的或未批准的变更被纳入费用或资源使用报告中（就审定的变更通知干系人）
采取措施，将预期的费用超支控制在可接受的范围内
知识管理
知识类别
知识管理定义：对有价值的信息进行管理，包括对知识的识别、获取、分解、存储、传递、共享、价值评判和保护，以及知识的资本化和产品化
知识管理工作包括的内容
常用方法和工具
显性知识管理方法
战略过程步骤
采集
过滤
组织
传播
应用
四点必须做到
创造成员之间交流机会
索引
高层参与支持
与绩效结合
隐性知识管理方法
隐性知识特点
默会性
个体性
非理性
情境性
文化性
偶然性与随意性
相对性
稳定性
整体性
可共享性
方法
编码化
面对面交流
人员轮换
网络
工具
知识生成工具
知识获取
知识合成
知识创新
知识编码工具
知识转移工具：传播、共享和使用
时间差异
空间差异
社会差异
知识产权保护
著作权法，著作权人对作品享有5中权力
发表权
署名权
修改权
保护作品完整权
使用权、使用许可证和获取报酬权、转让权
著作权期限
公民个人（终生及其死亡后50年）
单位（50年，50年内未发表不予保护）
以下情况使用，可以不经著作权人许可、不向其支付报酬，但应指明作者姓名和作品名称
个人学习、研究、欣赏，教学或科研使用，但不得发行出版
为介绍或评论而引用
各传播媒体已发表的社论或评论员文章
国家机关执行公务使用已发表作品/馆藏陈列保存的作品
免费表演已经发表的作品
对公共场所的艺术作品进行临摹、绘画、摄影以及录像
翻译作品、改成盲文等
测试管理
测试类型划分
按开发阶段划分测试类型
单元测试又称模块测试
集成测试又称组装测试、联合测试、子系统测试或部件测试 (在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成子系统或系统进行的测试活动)
系统测试（已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等是否满足其规约所指定的要求)
确认测试（软件产品完成功能测试和系统测试之后、产品发布之前所进行的软件测试活动，用于验证软件的功能、性能和其他特性是否与用户需求一致）
内部确认测试
开发方测试，又称为验证测试或α测试（由一个用户在开发环境下进行的测试，公司内部的用户在模拟实际操作环境下进行的受控测试）
用户测试，又称β测试（在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求）
验收测试也称为交付测试、发布测试
按照测试技术划分测试类型
黑盒测试，也称功能测试
通过测试来检测每个功能是否都能正常使用，着眼于程序外部结构，不考虑内部逻辑结构
还适用于对需求分析阶段的软件文档进行测试
两种基本方法
通过测试
失败测试
测试用例设计方法
测试区域确定法
组合覆盖法
逻辑推断法
业务路径覆盖法
白盒测试又称为结构测试或逻辑驱动测试
（按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能）
（按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能）
灰盒测试
按照测试执行方式划分
静态测试，又称静态分析技术
桌前检查（程序员自检）
代码走查（程序员与架构师）
代码审查（代码评审，找其他程序员）
动态测试
白盒测试
黑盒测试
信息系统测试管理（过程）
测试计划：测试经理管理
测试设计
测试执行
测试监控管理
任务和目的
记录和管理测试用例的执行状态
根据当前的执行状态，判定测试用例的设计质量和效率
根据发现的缺陷分布，判定结束测试的条件是否成熟
评估测试软件的质量，根据缺陷的数量、严重程度和种类来判断质量
评估开发过程的质量，根据缺陷的分布、修复缺陷的时间、回归测试中发现的缺陷数来判断质量
评估测试工程师的表现，如是否按计划完成测试任务，发现的缺陷的数量级质量
测试监控主要内容
测试用例执行进度=已执行数目/总数目
缺陷的存活时间=缺陷从open到close的时间
缺陷的趋势分析：按照测试执行的时间顺序，统计被发现的缺陷数量和分布情况
缺陷分布密度=对应于一项需求的总缺陷数/对应于该需求的测试用例总数
缺陷修改质量=每次修改后发现的缺陷数量（重现的缺陷+因为修改而引发的新缺陷）
测试风险管理
需求风险
对软件需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式
需求变更导致测试用例变更，同步时存在误差
测试用例风险
测试用例设计不完整，忽视了边界条件、异常处理等情况，用例没有完全覆盖需求
测试用例没有得到全部执行，有些用例被有意或者无意的遗漏
缺陷风险（某些缺陷偶发，难以重现，容易被遗漏）
代码质量风险（软件代码质量差，导致缺陷较多，容易出现测试的遗漏）
测试环境风险（有些情况下测试环境与生产环境不能完全一致，导致测试结果存在误差）
测试技术风险（有些项目存在测试技术难度，测试能力和水平导致测试进展缓慢，项目延期）
回归测试风险（一般不运行全部测试用例，可能存在测试不完全）
沟通协调风险（测试过程中涉及的角色较多，存在不同人员、角色之间的沟通、协作，难免存在误解、沟通不畅的情况，导致项目延期）
其他不可预计风险（一些突发状况、不可抗力等也构成风险因素，且难以预估和避免）
系统测试方案
测试目的（进行完成测试，验证软件正确性，保证性能满足要求）
测试对象（程序、文档）
测试内容（功能测试、性能测试、源代码测试、界面测试、文档测试）
测试过程（制定测试计划、测试设计、测试实施、测试评估）
测试用例设计依据（需求规格说明书，设计的各种规范、标准和协议）
测试技术（白盒测试、黑盒测试）
法律法规和标准
政府采购法
政府采购是指各级国家机关、事业单位和团队组织，使用财政性资金采购依法制定的集中采购目录以内的或者采购限额标准以上的货物、工程和服务的行为
遵循的原则
公开透明原则
公开竞争原则
公正原则
诚实信用原则
采购类型
集中采购：采购范围
由省级以上人民政府公布的集中采购目录确定
属于中央预算的政府采购项目，其集中采购目录由国务院确定并公布
属于地方预算的政府采购项目，其集中采购目录由省、自治区、直辖市人民政府或者其授权的机构确定并公布
分散采购
采购方式
公开招标
政府采购的主要采购方式
因特殊情况需要采用公开招标以外的采购方式的，应当在采购活动开始前获得设区的市、自治州以上人民政府采购监督管理部门的批准
邀请招标
具有特殊性，只能从有限范围的供应商处采购
采用公开招标方式的费用占政府采购项目总价值的比例过大
竞争性谈判
适用场景
招标后没有供应商投标或者没有合格标的或者重新招标未能成立的
技术复杂或者性质特殊，不能确定详细规格或者具体要求的
采用招标所需时间不能满足用户紧急需要的
不能事先计算出价格总额
应当遵循的流程
成立谈判小组
制定谈判文件
确定邀请参加谈判的供应商名单
谈判
确定成交供应商
单一来源采购
只能从唯一供应商处采购
发生不可预见紧急情况，不能从其他供应商采购
必须保证原有采购项目一致性或服务配套要求，需要继续从原供应商处添购，且添购资金总额不超过原合同采购金额的10%
询价
采购货物规格、标准统一、现货货源充足且价格变化幅度小
遵循的流程
成立询价小组
确定被询价的供应商名单
询价
确定成交供应商
国务院政府采购监督管理部门认定的其他采购方式
标准
分类
国际标准（ISO）
国家标准（国务院标准化行政主管部门）
行业标准
地方标准
企业标准
代号
生存周期管理标准GB/T 8566-2007
主要过程
支持过程
组织过程
质量与测试标准：外部和内部质量模型，六个质量特性
功能性
适合性
准确性
互用性
依从性
安全性
可靠性
容错性
易恢复性
成熟性
高可用性和高可靠性量化方法
可用性使用平均无故障时间MTTF度量，可维护性使用平均维修时间MTTR度量
可用性定义公式
MTTF/(MTTF+MTTR)×100%
可用性战术
错误检测：命令/响应、心跳、异常
错误恢复：表决、主动冗余、被动冗余
错误预防：可能引起错误的组件从服务中删除、引入进程监视器
易用性
易学性
易理解性
易操作性
效率
时间特性
资源特性
维护性
可测试性
可修改性
稳定性
易分析性
可以移植性
适应性
易安装性
一致性
可替换性
项目集管理（收益为王）
项目集成员组成
三个经理的关系
项目组合经理：理解项目集经理的角色，以及项目集经理与项目组合经理之间的关系和接口
项目集经理：使他们理解自己的角色
项目经理：理解项目集经理的角色及项目经理与项目集经理之间的关系和接口
项目集管理团队成员：理解其作为个体领导者的角色，以及整体上与项目集经理和项目集的关系
干系人：理解项目集经理的角色，以及他们如何争取不同的干系人群体的支持
发起人和收益人
项目集生命周期
项目集定义阶段
构建项目集
获得项目集资金（项目集指导委员会负责）
进行范围、资源和成本的初始研究和估算
进行项目集初始风险评估
开发项目集章程及项目集路线图
项目集准备
建立项目集治理结构
组建初始的项目集组织
制订项目集管理计划
项目集收益交付阶段
不断迭代的过程，在该过程中项目集组件被不断规划、整合和管理，达成项目集预期收益的交付
具体内容
组件规划和授权
组件监管和整理
组件移交和收尾
项目集收尾阶段
保证项目集按照预定和受控的过程进行收尾
具体内容
项目集移交
项目集关闭
项目集治理
项目集指导（治理/监督）委员会建立
项目集指导委员会职责
保证项目集和组织愿景目标一致性
项目集批准和启动：批准项目集章程和商业论证
项目集筹资
建立项目集治理计划
批准项目集绩效方法和计划
项目集指导委员会成员（共同负责批准和监督项目集的人员，是项目集的重要干系人，也是项目集相关重要决策的参与者）
项目集指导委员会职责界定
项目集治理＞项目集管理之间关系
与项目集治理相关的个人角色
项目集组件治理（项目集治理主体）
其他支持项目集管理的治理活动
项目集管理办公室PMO
项目集管理信息系统PMIS
项目集知识管理及审计支持
项目集管理资源池
项目集管理教育和培训
配置管理
配置项
配置项状态
草稿
正式（经过审批后）
修改
配置项版本号
草稿：0.01~0.99
正式：1.0~1.9
修改：X.YZ，正在修改只增大Z值，X.Y不变，修改完毕经审核为正式，Z改为0，增加X.Y
配置基线
由一组配置项组成，一个产品可以有多个基线，也可以有一个基线
分类
发行基线（给外部客户的基线）
构造基线（内部开发使用的基线）
配置库
开发库/动态库/程序员库/工作库
受控库/主库（当前的基线+对基线的变更）
产品库/静态库/发行库/软件仓库
角色
变更控制委员会CCB（决策机构）
对配置项评估、审批和监督已批准变更的实施
建立在项目级，不是常设机构，可以只有一人，可以兼职
控制配置变更+更多的配置管理任务（配置管理计划审批、基线设立审批、产品发布审批等）
配置管理员CMO
编写配置管理计划
CCB审批
建立和维护配置管理系统
建立和维护配置库
配置项识别
建立和管理基线
CCB审批
版本管理和配置控制
配置状态报告
配置审计
发布管理和交付
配置管理负责人（配置经理）
配置项负责人
日常配置管理活动
制订配置管理计划（CMO编写，CCB审批）
配置标识（配置项识别）
选择配置项并记录其功能和物理特征，是CMO的工作
基本步骤
识别需要受控的配置项
为每个配置项指定唯一性的标识号
定义每个配置项的重要特征
确定每个配置项的所有者及其责任
确定配置项进入配置管理的时间和条件
建立和控制基线
维护文档和组件的修订与产品版本之间的关系
配置项控制
变更申请
相关人员如PM填写变更申请表，说明变更的内容、原因、受影响的关联配置项和有关基线、变更实施方案、工作量和变更实施人
变更评估
CCB评估确定变更内容
通告评估结果
CCB把批准、否决或推迟的决定通知到受影响的每个干系人
变更实施
PM组织修改相关配置项，并在文档或程序代码中记录变更信息
变更的验证和确认
PM对变更后的配置项进行测试和验证
PM将结果提交CCB确认
变更的发布
CMO将变更后的配置项纳入基线
CMO将变更内容和结果通知相关人员并做好记录
基于配置库的变更控制
将要升级的基线从产品库中取出，放入受控库
程序员将予修改的code段从受控库中检出，放入自己的开发库进行修改。代码被检出后即锁定，保证只有一人修改
程序员将修改后的code段检入受控库，这时锁定解除，其他程序员可以检出
代码段修改工作全部完成后，将受控库新版本存入产品库（旧版本不删除，继续在产品库保存）
配置状态报告（统计）
配置审计/配置审核/配置评价
为了确保项目配置管理的有效性，体现配置管理的最根本要求，即不允许出现任何混乱的现象
防止向用户提交不合适的产品
发现不完善的实现
找出各配置项间不匹配或不相容的现象
确认配置项已在所要求的质量控制审核之后纳入基线并入库保存
确认记录和文档保持着可追溯性
分类
功能配置审计（一致性）
配置项的开发已圆满完成
配置项已达到配置标识中规定的性能和功能特征
配置项的操作和支持文档已完成并且符合要求
物理配置审计（完整性）
要交付的配置项是否存在
配置项中是否包含了所有必需的配置项目
发布管理和交付
存储
复制
重建
打包
交付
流程管理
业务流程管理BPM六要素
输入（人、财、物、信息、关系、计划等）
活动
活动之间相互作用
输出
客户（流程服务对象，对外是单位服务的个人或组织，对内来讲是流程的下一个环节）
价值（流程运作为客户带来的好处，不一定是货币价值，比如提高效率、降低成本）
业务流程的实施
对现有业务流程进行全面的功能和效率分析，发现存在问题
设计流程改进方案，并进行评估
业务流程方案评估(增值性分析)
业务流程实施条件评估
业务流程实施效果评估(成果必须体现在经营管理的绩效上)
产品和服务质量
顾客满意度
销售增长率
成本
员工工作效率
带来企业文化，特别是员工价值观变化
制订与业务流程改造相配套的组织结构、人力资源配置和业务规范等方面的规划，形成系统的业务流程实施方案
组织实施与持续改善
业务流程分析步骤和方法
步骤
调查掌握基本情况
描述现有业务流程
确认现有业务流程
对业务流程进行分析
发现问题并提出解决方案
提出优化后的业务流程
方法
价值链分析法
客户关系分析法
供应链分析法
基于ERP的分析法
增值性分析
业务流程设计工具
程序流程图PFD
用一些图框表示各种操作，它独立于任何一种程序设计语言，比较直观、清晰，易于学习掌握
IPO图
用来描述每个模块的输入I、数据加工P、输出O。IPO图是系统设计中重要的文档资料之一，其主体是处理过程说明
NS图
为避免流程图在描述程序逻辑时的随意性与灵活性，提出了为N-S图或盒图
五种控制结构
顺序型
选择型
WHILE循环性（当型循环）
NUTIL循环型（直到型循环）
多分支选择型
问题分析图PAD
一种支持结构化程序设计的图形工具,PAD也包含五种基本控制结构，并允许递归使用
过程设计语言(PDL)也称为结构化语言或伪代码
它是一种混合语言，采用自然语言的词汇和结构化程序设计语言的语法，用于描述处理过程怎么做，类似于编程语言
判定表
采用表格形式来表达逻辑判断问题
四个部分
左上部分为条件说明
左下部分为行动说明
右上部分为各种条件的组合说明
右下部分为各条件组合下相应的行动
判定树
用来表示逻辑判断问题的一种常用的图形工具,它用树来表达不同条件下的不同处理流程，比语言、表格的方式更为直观
业务流程重构BPR
对企业业务基本问题进行反思，并对它进行彻底的重新设计
四个核心内容
根本性
彻底性
显著性
流程性
遵循的原则
以流程为中心的原则
团队管理原则
以客户为导向的原则
实施步骤
敏捷与传统项目管理流程的比较
构想代替启动
推测代替计划
探索代替管理（开发）
适应（监控）
结束阶段收尾
项目收尾管理
项目验收
验收测试
对信息系统进行全面的测试，依照双方合同约定的系统环境，以确保系统的功能和技术设计满足建设方的功能需求和非功能需求，并能正常运行
系统试运行
信息系统通过验收测试后开通系统试运行，系统试运行包括数据迁移、日常维护，以及缺陷跟踪和修复等方面的工作内容
系统文档验收
系统验收测试后，系统的文档应当逐步、全面地移交给客户。在最终交付系统前，所有的文档都应验收合格并经双方签字认可
包括的文档内容
系统集成项目介绍
系统集成项目最终报告
信息系统说明手册
信息系统维护手册
软硬件产品说明书
质量保证书
项目终验
在系统经过试运行以后的约定时间，启动项目的最终验收工作。项目最终验收合格后，应由双方的项目组撰写验收报告提请双方工作主管认可。这标志着项目组开发工作的结束和项目后续活动的开始
项目总结
准备工作
收集整理项目过程文档和经验教训
经验教训的收集&形成项目总结会议的讨论稿
项目总结大会
要求：项目总结会需要参与项目的全体成员都参加，并由全体讨论形成文件，文件要经过所有人确认
内容
项目绩效
技术绩效
成本绩效
进度计划绩效
项目的沟通
识别问题和解决问题
意见和建议
系统维护
软件项目后续工作
BUG修改
软件升级
后续技术支持
系统集成项目的后续工作
信息系统日常维护工作
硬件产品更新
满足信息系统的新需求
项目后评价（团队成员、审计、PMO)
信息系统目标评价
是信息系统后评价的重点所在，评价信息系统是否成功的重要依据就是信息系统是否实现了信息系统规划之初所设置的各种目标
信息系统过程评价
是从过程分析和审查的角度来评价过程的符合性及合理性。重点关注信息系统的全过程管理是否按照计划进行，是否针对过程管理中出现的重大偏差进行了原因分析和及时应对
信息系统效益评价
是信息系统后评价的主要内容，它是对信息系统的运行效果进行评价，并为信息系统的可持续性提供判断依据
内容（可行性研究内容）
信息系统技术评价
信息系统经济效益评价
信息系统管理效益评价
信息社会效益评价
信息系统环境影响评价
信息系统可持续性评价
主要评价信息系统持续运营和发展的可能性
项目结项的相关工作
产品核实，确认全部工作都按项目产品的既定要求完成
财务收尾，完成财务结算
更新项目记录，完成最终的项目绩效报告和项目团队成员的业绩记录
总结经验教训，进行项目完工后评价
收集、整理和归档各种项目资料，进行内部组织过程资产更新
结束项目干系人在项目上的关系，最后解散项目组
战略管理
战略主要内容
组织战略因素
战略目标
战略方针
指导组织行动的纲领和组织战略计划的基本依据
实施能力
组织战略实施的物质基础
战略措施
实现战略目标的具体方法和步骤
战略实施过程分解（自上而下的动态管理过程）
自上而下：高层达到一致，中下层传达，并在各项工作中得以分解、落实
循环动态：分析-决策-执行-反馈-再分析-再决策-再执行
组织事业战略（产品创新战略）
防御者战略
成熟行业中的成熟组织，组织内部产品线较窄，组织高层也不愿意积极探索领域外的机会
探索者战略
成熟行业中的成熟组织，发现和发掘新技术、新产品、新市场可能给组织带来的机会，注重创新，成为行业标杆
分析者战略
组织在规避风险同时，又能提出创新的产品和服务，即跟踪、抄袭和优化
反应者战略
对外环境缺乏控制，不敏感组织类型
战略组织类型
组织战略层次
组织级项目管理OPM
项目治理架构，进行有机融合
项目组合管理
项目集管理
单项目管理
框架内容
第一部分：最佳实践
组织级项目管理SMCI最佳实践（标准化、度量、控制和持续改进）
组织运行潜能方面的最佳实践，包括组织文化、结构、技术、人力资源，支持OPM流程实施的低层要素
第二部分：组织能力
组织内，组织应必须具备的一种特定的胜任资格
第三部分：成果
有形和无形成果
项目管理成熟度模型
成熟度模型三个组成部分
Kerzner成熟度模型5个梯级
通用术语
通用过程
单一方法
基准比较
持续改进
能力成熟度模型CMMI
OPM3成熟度评测的四个阶段（PMI项目管理协会的）
第一维度是成熟度四个梯级SMCI
标准化
可测量
可控制
持续改进
第二维度是项目管理的十大知识领域和五大过程组
第三维度是组织级项目管理三个版图层次
项目组合
项目集
单项目
项目组合管理
项目组合、项目集和项目之间的关系
特性及关联
对比
项目组合组件
项目组合与项目组合中的组件是父子依赖关系
项目组合中的组件或项目之间没有逻辑关系
项目组合经理的职责
总体上指导和监控整个项目组合的执行
提供日常的项目组合的监督工作
定期复审项目组合的健康情况和业务发展目标一致性分析
确保准确收集到组合分析所需的项目组合组件的信息
项目组合管理过程
评估项目组合管理过程的当前状态
识别和评估现有的项目组合管理知识
评估现有的项目组合管理过程来确定它们是否支持组织愿景、使命、战略和目标
评估当前项目组合管理结构和资源的成熟度及充分性
评价现有的项目组合组件来确定它们是否支持当前的组织策略和目标
评估当前项目组合组件的资源可用性和根据整体进度计划分配资源
了解每个战略目标和项目组合组件的干系人
评审现有的项目组合报告过程和程序
定义项目组合管理的愿景和计划：符合组织愿景，支持组织战略和目标
实施项目组合管理过程
关键步骤
为项目组合管理过程的实施定义角色和职责
沟通项目组合管理实施计划
定义和部署详细的项目组合管理过程，并为参与人员和干系人提供培训
实施项目组合管理的方法
实施的起点和方向
自上而下
自下而上
混合法
实施范围
分阶段法
全面导入法
实施项目组合管理的收益
使项目更容易按照预先确定的时间、预算和范围完成，带来成本节约
识别项目风险和资源约束，从而降低成本，带来成本节约
提供项目组合报告，为资源与投资分配划分优先级，从而使资源和资金的使用效率更高
改进项目组合管理过程：项目组合管理过程改进计划
项目组合管理过程组和知识领域
制定/定义=>定义过程组
管理/优化=>调整过程组
授权/规定=>授权与控制过程组
项目组合风险管理
关键要素
风险计划
风险评估
风险响应
管理项目组合风险四阶段内容
风险识别
风险分析
风险响应
风险监控
项目组合治理
0 条评论
下一页
