做题:3000题
做题一定要做没有答案的
二是要将错误的和当时做题有疑问的题画下来,然后回头再看
最好依赖于纸质的书题
变更控制系统算不算项目管理信息系统
变更控制系统属于项目管理信息系统
因为配置管理系统包含变更控制系统
变更控制管理系统是属于事业环境因素
配置管理系统是事业环境因素
工作授权系统是事业环境因素
工作授权程序设是项目管理资产
变更控制流程是组织过程资产
可交付成果一定是可以验证的,但是不一定就是有形的
版本化,基准化,后边需要执行变更控制系统
问题日志,即使和干系人沟通,也是需要产生问题日志的
经验教训登记册
资源日历也是,
知识通常分为两部分:显性的和阴性的
显性的是指可以通过文字表达的
阴性的是指不是文字方式的,比如信念,思想等
知识分享中,信任是基础
经验教训登记册,还不是文件
进一步归档总结,最终纳入企业的经验教训知识库
组织过程登记册的风险库,有原来的风险登记册,rbs,风险单
监控工作贯穿于项目的始终
向管理层汇报也是监控过程的工作
工作绩效报告包括进展报告和进展报告
状态报告:实际上是截止到当前,项目的状态,那个模块完后了,那个模块没有完成
进展报告:实际上是一个时间段,近期是什么,下一个时间段要做什么。
这一周来的进展是什么情况
实施整体变更控制
拒绝的变更以及实施的变更
产品库,静态库,存放最终开发出来的产品,产品库也是需要受控的
开发库,动态库,在开发过程中的东西
受控库,基准化的了东西,受控库里边的东西就一定需要进行变更
任何干系人都可以进行提变更,而且变更可以口头进行提,但是最终都需要书面化
而且需要进行书面化
项目经理——CCB——项目发起人
基准类的变更要走CCB
重大的变更要走发起人
变更控制委员会是一个正式的团体,CCB可以一个人,也可以两个人,也可以很多人
发起人不一定在CCB里边,就是一个变更的机构
变更控制工具就是用来做变更的。
变更状态,功能审计,物理审计,
支持的活动:识别,跟踪,变更
变更的过程,首先要了解变更
客户提出了变更需求,但是项目经理或者项目管理人说服客户放弃这个变革
结束项目或者阶段
最终报告:在项目最后的项目总结会
最终报告需要进行签字的
验收的呃可交付成果要进行移交,成为移交的可交付成果
结束合同,行政等
确认范围就是正式验收可交付成果
产品范围和项目范围
需求管理计划,说明怎么来管理这些需求
收集需求:亲和图,头脑风暴,原型法
在质量管理里边也需要用到亲和图
访谈,名义小组技术
收集需求,按照说明挖掘方法
名义小组技术就是对头脑风暴的结果进行排序
引导技术,用户故事,QTD,ZAD
用户故事就是描述,描述那个相关方
46.33
数据流,相当于测试用例。
原型法,在软件中叫做开发方法,先搞几个界面,确认需求,然后不断的反馈和完善,然后再做真正的开发。
原型法有助于确认需求
需求清单,需求规格说明书
业务需求,高层级的需要。
相关方需求,用户或者用户群体对于这个系统要求
功能需求,这个产品必须要具有什么样的功能
假设和约束,必须是Windows操作系统还是Linux操作系统
其他需求:ISO认证,或者3C认证
定义范围,定义范围是将
项目范围中的除外责任,是指告诉项目干系人,什么东西我们是做的,什么东西是我们不做的,有助于控制范围。减少范围蔓延。
wbs工作分解,最终确定到工作包。通常情况下,工作包是最底层的。
工作包是可以滚动式规划的。
规划宝,是需要做,但是本次还是分不了那么细。
级别:4~6级
880法则,最小不要小于8小时,最大不要大于80个小时
可以以可交付物作为第二层,也可以将该项目作为第二层。
外包的wbs,通常有承包方有助于帮忙分解。
分解原则:100%原则
两个“凡是”,即凡是该项目范围之内的都是必须要做的,凡是不在该范围内的都是不能做的。
责任要清洗,要分清责任人。
工作包要可比,因为要进行分项目责任人。
wbs,obs,rbs
wbs:在工作包上指定责任人
obs:在该组织结构上指定责任人
rbs:组织责任人,技术要求等
范围基准,凡是在范围里边的是必须要做的,凡是不在该范围之内的,是一定不能做的
工作包是最底层,带有工作标识的
控制账户,通常是一个管理控制点
实际成本,一般是要由财务给出的
项目上还有很多的间接费用,这些费用将是要由财务提供的。
财务上的办公费,水电费,招待费
规划包,等到有了基础数据之后才知道的
wbs词典,包含了很多的具体的描述
确认范围就是做验收
间接费用是不可控的
正式验收是要交付可交付成果的,来自于控制指令,验收的可交付成果,移交的可交付成果
验收的时候,通常要投票,到底是同意还是不同意
控制范围
范围蔓延,未经控制的项目的范围逐渐扩大