PP项目计划.docx
- 文档编号:8492615
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:13
- 大小:78.52KB
PP项目计划.docx
《PP项目计划.docx》由会员分享,可在线阅读,更多相关《PP项目计划.docx(13页珍藏版)》请在冰豆网上搜索。
PP项目计划
CMMI过程域-PP项目计划
(2008-06-1920:
56:
43)
转载▼
标签:
cmmi
pp
项目计划
it
分类:
CMMI评估
SG1:
建立估计计划:
要建立和维护项目计划参数的估计数据
∙SP1.1估计项目的范围
∙SP1.2建立项目属性的估计
∙SP1.3定义项目生命周期
∙SP1.4确定工作量和成本的估计
项目范围的估计可以通过建立顶层WBS分解,WBS分解一般是面向产品结构,需要分解到工作包这个层次。
由于WBS面向产品结构,使我们容易遗忘在WBS分解中包括风险缓解,配置管理,集成,培训,非开发管理等任务。
我们仍然强调的是WBS加上工作包的描述是项目范围的一个全集。
规模是许多用于估计工作量、成本和进度的模型的主要输入。
SP1.2提到的项目属性估计的重点就是先要有任务或工作产品的规模和复杂度的估计,这个是后续工作量,成本和进度估算的基础。
对应软件产品衡量规模的单位常用的有功能点,代码行,需求页数,用例数,需求条目数等。
三级的IPM集成项目管理强调了项目的过程是从组织标准过程定义裁剪出来的,一个重点大的裁剪就是选择项目生命周期模型。
SP1.3定义项目生命周期在二级的时候还没有上升到组织级。
项目生命周期模型的定义是确定工作量和成本的基础,不同的生命周期工作量的分布往往是不同的,而且我们的项目历史数据也是在一定的生命周期模型下得到的。
在这里把生命周期模型放到SP1.3,是否说明顶层WBS分解更多的是项目产品结构,和采用的生命周期模型关系不大?
工作量和成本的估计一般基于使用模型或历史数据分析规模、活动和其他计划参数的结果。
不可预测的工作量是更危险的,需要更多研究来开发合理的估计基础,并需要预留更多的管理工作。
在软件工程领域,已经开发许多参数化模型来辅助成本和进度。
历史数据包括来自先前已执行项目的成本、工作量和进度的数据,加上考虑不同规模和复杂度的调整数据。
再对SG1进行总结,大致遵循的一个步骤如下:
SOW和用户需求->顶层WBS分解->规模和复杂度估算->生命周期模型确定->估算参数确定->工作量和成本
SG2:
开发项目计划:
要建立和维护项目计划,并作为管理项目的基础
∙SP2.1建立预算和进度
∙SP2.2标识项目风险
∙SP2.3计划数据的管理
∙SP2.4计划项目的资源
∙SP2.5计划所需的知识和技能
∙SP2.6计划项目相关人员的参与
∙SP2.7建立项目计划
在这里我们要注意,CMMI里面的PP过程域和PMBOK里面的制定进度过程有些小的区别。
SG1的重点是项目范围管理里面内容,SG2重点是项目时间管理内容,有一个大的不同就是规模和工作量的估算是在WBS一建立后就可以开始的工作,而不是要先进度活动定义和排序后再开始。
从SG2内容可以看到PP项目计划强调的内容仍然是一个项目综合计划的内容,SP2.2涉及到初步的风险管理计划制定,SP2.3涉及到数据管理计划;SP2.4涉及到人力资源计划,SP2.5涉及到培训计划等。
到了IPM集成项目管理后更加强调了集成计划,会再增加入质量保证计划、配置管理计划,测试计划等。
SP2.1+SP2.4基本就涵盖了PMBOK中时间管理过程组的所有内容。
最终的目的仍然是要有一个进度表出来,这个进度表考虑了活动间的依赖关系,每个活动的复杂度和持续时间,关键路径,资源的分配和平衡等各个方面的内容。
在这个过程中我们看到关于活动和任务的所有属性基本上都得到了确定了完善,包括任务的依赖关系,开始和结束时间,分配的资源,输入,产出定义。
SP2.1还有个重要内容就是要确定项目的重要里程碑,里程碑的一个重点是来保证度量的准确性,另外就是在里程碑点的时候我们要及时的检查计划和实际执行的偏差情况,当偏差超出了某一个范围的时候就要考虑是否采取相应的纠正措施。
在三级有专门的RSKM风险管理过程域,三级的风险管理更加强调了组织级的风险管理流程和风险参数的定义,组织级的历史风险库等内容。
在二级PP里面的风险管理一般做到能够能够识别风险,优先级排序和文档化排序,并没有对文档的分析方法,风险的应对和跟踪过多的进行要求。
注意SP2.4可能是在项目一开始的时候就确定的,也可能是我们更多强调的进度和质量要求,对于资源的投入没有明确的要求。
但是要注意的是能够排进度计划的时候资源和资源的分配都应该是基本确定的了。
在SP2.4的子实践中也强调了,项目的人员配置取决于为完成项目需求而将项目需求分解为在WBS工作包内任务、角色、职责的分配。
人员配置需求应该考虑每个已标识职位要求的知识和技能(像在计划需要的知识和技能特有实践中定义的)。
在项目计划中要计划项目需要的知识和技能,评估当前项目成员是否具备这些技能,如果没有达到则需要安排相应的培训进行学习或者避免使用一些新技术。
这也是一个风险管理的过程。
在二级这个工作主要是在项目层面进行的,在项目是可重复的,到了三级后提升到组织层面,有专门的OT过程域进行对应。
我们都知道干系人分析和管理是项目管理的一个重要内容,在项目计划阶段我们需要识别项目干系人,分析项目各个阶段活动和干系人之间的关系,知道项目干系人对项目的影响以平衡干系人的期望。
对于SP2.6可行的一个方法是通过标识项目中人员和功能需要代表的类型来标识项目生命周期所有阶段的项目相关人员,并描述他们的相关性和在特定项目活动的交互程度。
用两维矩阵来描述,一个轴是项目相关人员,另一个轴是项目活动,这是实现这种标识的方便的格式。
有了以上活动后,最终就是要形成一个整体的项目计划。
项目计划的意思就是到了项目执行阶段后所有的活动都是事先有所计划进行的,而不是太多的临时任务。
为项目产生的计划确定了所有方面的工作:
项目生命周期考虑;技术和管理任务;预算和进度;里程碑;数据管理;风险标识;资源和技能需求;项目相关人员的标识和交互。
基础设施的描述包括项目人员、管理和支持组织的职责和授权关系。
SG3:
获得对计划的承诺:
要建立和维护对项目计划的承诺
∙SP3.1评审项目的附属计划
∙SP3.2协调工作和资源
∙SP3.3获得计划的承诺
对应SG3主要说明项目计划指定完成后,必须得到项目识别的所有干系人对计划的承诺。
而要获取计划承诺的一个重要方式就是对项目计划进行评审,包括项目的附属计划。
当出现了相关干系人利益冲突的时候,需要考虑平衡和对计划进行调整。
相关的通用实践和PP过程域的关系
GP2.2:
制订活动的计划(做项目计划前要先有计划的计划)
GP2.3:
提供资源(提供进行项目计划活动的资源,你制定项目计划需要哪些资源参与)
GP2.4:
明确职责
GP2.5:
培训员工(员工知道如何做计划,估算的方法和原理,风险识别方法等)
GP2.6:
管理配置(计划活动的内容是受控的)
GP2.7:
识别和争取相关干系人的参与(和SP2.6的区别?
)
GP2.8:
对活动进行监控(对计划活动进行监控)
三级对PP项目计划的一些要求
1.根据组织标准过程进行过程定义和裁剪,首先要先选择生命周期模型
2.在项目计划中要有风险管理计划,能定性分析风险,对关键风险有缓解措施的制定
3.项目的估算参数来源于组织级的基线数据,但是项目可以根据需要进行调整
4.项目计划是集成计划,要考虑和质量保证计划,配置管理计划,测试计划等配合和集成
5.项目计划有了组织提供的标准规程和模板形成的最佳实践,制定项目计划时候要遵循
四级对PP项目计划的一些要求
1.通过项目历史数据已经分析了项目自身哪些过程或子过程是稳定的。
2.根据业务和客户的目标在项目计划中要确定项目的哪些子过程要进行量化管理。
3.确定要量化管理的子过程采取的方法,工具和技术。
4.通过组织提供的PPM对项目的目标进行量化的预算,如工作量,周期和缺陷情况等。
5.对风险管理进行了量化,比如引入蒙特卡洛方法对风险分析进行了量化。
6.根据总的质量目标分析和定义了可量化的过程性能指标(目标值,控制上下限)
CMMI过程域-PMC项目监督控制
(2008-06-2020:
14:
39)
转载▼
标签:
cmmi
pmc
项目监控
it
分类:
CMMI评估
提供对项目进展情况的了解。
当项目的性能与其计划严重偏离时,采取适当的纠正行动。
在这里注意跟踪的依据是项目计划,而且项目计划必须要文档化和基线。
跟踪的内容不仅仅涉及到项目的四要素:
进度,成本,质量,需求范围等,同时还涉及到问题风险监控,承诺达成情况监控,干系人参与情况监控,人力资源情况跟踪等。
在计划过程中我们会定义为了保证项目目标,我们能够容忍的计划和实际偏差的限度,当我们在跟踪过程中发现了偏差超出范围的时候我们就必须要采取各种纠正措施。
纠正措施可能涉及到计划的变更,自然就涉及到了配置和变更管理的相关内容。
SG1:
对照计划监督项目:
对照项目计划监督项目的实际性能和进展
∙SP1.1监督项目计划的参数
∙SP1.2监督承诺
∙SP1.3监督风险进行
∙SP1.4监督数据管理
∙SP1.5监督项目相关人员的参与
∙SP1.6执行进展评审
∙SP1.7执行里程碑评审
文档化的项目计划是作为跟踪活动、交流状态以及采取纠正行动的基础。
我们需要按照计划中记录的内容来监督承诺。
首先看SP1.1监督项目计划的参数,而这些参数正好就是我们针对WBS分解后定义的各项活动和任务进行的估算。
估算包括了规模,工作量,进度和周期,缺陷等各方面的内容,这些内容都是需要进行监控的,因此我们就需要收集想执行过程中的实际数据,这个自然涉及到MA度量这个过程域的内容。
我们可以将我们度量的数据通过一些系统自动化的工具放入到过程度量数据库中,一方面是为了监控目的,一方面是为项目的后续版本提供可行的估算参数。
再看后面几个SP特定实践,可以看到监督基本涵盖了项目在执行阶段的所有活动。
监督承诺既包括了对外部客户的承诺,也包括了内部上游客户对下游客户的承诺,这个监督的依据是在项目计划中定义的依赖承诺表。
监督风险进行,一方面是监督风险的概率和影响程度等重要的风险参数是否有变化,好对风险优先级进行重新评估;一方面是监督我们制定的风险缓解措施的执行情况。
我们在项目计划中会定义数据管理计划,包括项目的日常输出和产品产出具体的存放位置和管理方式,相关的配置管理计划等,这些也是需要监督的内容。
监督干系人的参与,一个重要监督点就是监督评审的情况,监督项目的周报月报等沟通既要相关干系人的反馈情况。
监督的目的是平衡各方干系人的利益,及时发现项目执行情况和干系人期望之间的偏差。
监督的频度可以是每天,每周和每月。
另外一些重要的监督点就是在项目计划制定时候我们确定的项目分为的几个阶段,各个阶段对应的里程碑。
在里程碑点我们会输出里程碑报告,里程碑报告里面应该包括对所有项目重要要素的监督数据。
具体应该包括:
需求规模,进度,工作量,成本投入,缺陷,缺陷泄露和移除,生产率
∙人力资源和人员技能情况
∙项目成员对承诺的达成情况
∙问题和风险情况
∙干系人的参与和评审的执行情况
SG2:
管理纠正行动直至解决:
当项目的性能和结果与计划由重大偏离时,要管理纠正行动直至解决
∙SP2.1分析问题
∙SP2.2采取纠正行动
∙SP2.3管理纠正行动
监督的目的是发现问题,而纠正行动的目的的分析和解决问题。
发现问题的问题应该主要包括项目的计划和项目的实际执行出现显著的偏差;另外就是我们在验证和确认过程中发现的问题,涉及到三级的VER和VAL两个过程域。
问题除了通过项目经理通过监督数据发现外,还可以通过评审,周报月报,检查点和里程碑报告,平时的沟通,干系人的反馈等多种驱动来收集。
采取纠正行动前一定要对问题的根源进行分析,我们的纠正措施是造成问题根源的,这样才可能避免类似的问题重复发生。
另外在分析问题的时候要避免单向思维,要了解到项目各要素直接的相互作用和影响。
比如当我们发现了进度的问题后采取的纠正措施往往是进度满足了,但是我们的质量目标却又出现了明显的问题。
对应项目进度出现严重的偏差,我们可能采取的纠正措施是缩小项目范围,增加资源,变更过程和计划。
对于项目质量发生重大偏差,我们要加强员工技能培训,评审和走查等各种活动。
对应监督风险中发现了新的优先级高的关键风险,我们需要及时的制定相应的风险缓解措施。
当你发现发现的问题已经很难通过平衡项目各要素来满足,则必须要对项目目标进行变更,通过新的项目目标重新修订计划,否则我们后面的监控就会变得没有意义。
四五级对项目监控的要求
1.首先是监控要到子过程。
项目->阶段->过程->子过程。
测试是过程,单元测试是子过程。
评审是过程,需求的评审是子过程,对评审规模的监控是子过程。
需求是阶段,软件需求是过程,软件需求中的需求收集可以理解为子过程。
2.引入了统计和量化的方法对项目进行监控,比如控制图。
四级监控的目的是发现特殊原因,保证过程稳定和受控。
五级的要求是通过监控和分析发现一般原因,收缩上下限范围。
3.在监控过程中增加了通过模型对项目目标的重新预测。
4.对风险的监控加强,包括对风险的概率,后果等各个风险参数的监控,对风险缓解措施效果的监控。
5.监控更加体现量化数据和统计学方法,以反应子过程是否受控。
6.更加强调了对发现问题后的问题分析和纠正的流程,方法和工具的使用。
组织也该提供这些内容。
CMMI过程域-MA度量和分析
(2008-06-2022:
54:
41)
转载▼
标签:
cmmi
ma
度量
it
分类:
CMMI评估
度量过程框架:
度量和分析过程域包括:
∙详细说明度量和分析的目的,使其与已标识的信息需要和目的一致
∙详细说明度量、数据采集、存储机制、分析技术以及报告和反馈机制
∙实现数据的采集、存储、分析和报告
∙提供可用于作出可靠决策的客观结果,并采取适当的纠正行动
将度量和分析活动与项目的其它过程集成,以支持:
∙客观的计划和估计
∙按已制定的计划和目的跟踪实际的性能
∙标识和解决与过程相关的问题
∙提供将度量合并到未来的附加过程中去的基础
注意二级的度量集中在项目级别,项目可以把特定的项目数据和结果存放在项目专用的库中。
当数据在项目间广泛共享时,数据可以驻留在组织级度量仓库中。
要建立组织级的度量数据库,应该参考三级的过程域OPD组织过程定义,对于度量中的分析到了四级后需要使用统计学的相关方法和工具进行定量的分析,涉及到四级QPM量化项目管理过程域的内容。
SG1调整度量和分析活动(度量的目的和活动要与已标识的信息需要和目的相一致)
∙SP1.1建立度量目的
∙SP1.2详细说明度量
∙SP1.3详细说明数据采集和存储规程
∙SP1.4详细说明分析规程
在进行度量计划和实施度量前,必须要搞清楚度量的目的,度量的目的是通过采集的数据分析,改进我们的过程的有效性,提高效率和改善质量。
度量目的的来源可以是管理、技术、项目、产品或过程等方面实现的需要,来源于企业的战略和商业计划,项目计划,管理和技术问题,过程改进计划等。
关于度量信息的分类,可以分为
∙进度和进展(里程碑的实现和工作单元的执行情况)
∙资源和费用(项目分配的人力资源和其它费用)
∙产品规模和稳定性(软件的规模,软件功能范围和数量的变更)
∙产品质量(缺陷密度,现场缺陷)
∙过程性能(评审效率,缺陷泄露情况,过程符合度,不合格项)
∙技术有效性(软件架构和软件重用)
∙客户满意度(交付的产品与服务满足客户期望的程度)
在SP1.2重点是度量本身要是精确的,可量化的度量。
度量可能是基本度量,或者是派生度量。
基本度量数据由直接度量获得。
派生度量数据来自其它数据,通常是由两个或多个基本度量组合而来。
如缺陷数是基本度量,而缺陷密度则是派生度量。
在建立了度量的目的和确定了度量的方法后,进入SP1.3要解决度量数据的收集,度量数据的存储两个问题。
要明确地说明数据如何采集,从何处采集,和何时采集。
要指定采集有效数据的规程。
为了分析数据,数据要按可访问的方式存储,并且要确定是否为可能的重新分析或文档目的而保存。
当采集和存储了数据后,就需要选择合适的数据分析方法和工具,到了QPM量化管理后就会更加强调对于不同的子过程该采用哪些统计学的方法和工具。
SG2提供度量结果以处理已标识的信息需要和目的
∙SP2.1采集度量数据:
获得特定的度量数据
∙SP2.2分析度量数据
∙SP2.3存储数据和结果
∙SP2.4交流结果
注意在SG1是制定具体的方法和规程,在SP2是实际的度量执行活动。
在SP2.1首先是按照度量规程采集我们需要度量的活动的执行数据,在数据采集到后必须对数据进行完整性的检查,以保证数据的准确有效。
度量很多时候无效或没有起到实际的作用,最大的原因不是在于度量的方法和工具上面,而是在于我们采集到的数据本身是不准确或错误的,导致最终分析出来的结果也是错误的。
在SP2.2是讲按照计划对度量数据进行分析,必要时要进行额外的分析,结果由有关的项目相关人员评审,并指出将来要对分析作必要的修订。
在完成了度量数据的采集和分析后,我们需要对度量后的数据进行存储,以作为项目的历史数据后续可以作为项目计划和估算的重要参数。
度量数据的存储主要包括了:
∙度量计划
∙度量的规格说明
∙已经采集的数据集
∙分析报告和陈述
在二级项目的度量数据主要是服务于项目和个人的需要。
到了三级后项目度量数据要存储到组织级的度量数据库中,以方便建立组织级的度量基线。
具体内容在三级的OPD过程域。
SEI建议的度量元
∙进度性能(里程碑性能、工作单元进展)
∙成本性能(实际与计划的对照,不一致情况)
∙工作量性能(实际与计划的对照,不一致情况)
∙需求管理(增加的、删除的、修改的,需求易变性)
∙程序规模(源码行数、页数,实际与计划的对照)
∙测试性能(需要的测试,通过的测试)
∙缺陷数据状态(未解决的问题,解决完成的问题,缺陷密度,缺陷来源)
∙过程性能(完成的任务,行动项数)
∙计算机资源利用率(内存占有量,CPU占有量)
∙管理计划项目过程的性能(对照实际进展做估计,重计划,项目总结数据)
在三级我们主要到度量要上升到组织级,在GG3中也谈到要将度量活动制度化为组织级已经定义的过程,组织可以通过各个项目度量数据的收集来建立组织过程能力基线。
在四级中注意重点是度量需要到我们需要监控的各个子过程粒度,同时在度量数据分析的时候需要采用统计学的相关方法和工具进行。
具体一些CMMI四级中涉及到度量的要求:
1.根据商业目标确定项目目标,根据项目目标
2.根据质量性能目标选择最有价值的子过程进行量化管理,粒度到子过程
3.采用统计学的方法和思想而不仅仅是应用SPC
4.可以应该QFD逐层分解来选择度量技术和子过程
5.度量是使过程受管理的基础,而不仅仅是为将来收集和跟踪数据
6.更好的根据过程能力基线PPB管理当前项目性能,过程受控
7.更好的根据过程能力模型PPM预测将来
CMMI过程域-RSKM风险管理
(2008-06-2116:
34:
45)
转载▼
标签:
cmmi
rskm
风险管理
it
分类:
CMMI评估
SG1进行风险管理准备
建立并维护用于识别、分析和缓解风险的战略。
这个战略一般编写成项目风险管理计划。
风险管理战略处理的是适用于控制风险管理大纲的具体措施、资源和管理方法;包括对风险来源、风险分类方案以及风险的评价、界定和控制参数等的策划。
相应的惯例:
∙SP1.1确定风险来源和类别
SP1.2定义风险参数
SP1.3建立风险管理战略
风险的来源是多方面,对于IT项目的风险比较常见的来源是不确定的需求,人员流动,使用新技术,不合理的进度,开发人员技能不足等方面的内容。
风险的类别也是多方面的,比较大的分类可以分为项目管理类的风险,业务风险,技术类风险等。
注意确定风险来源和分类的目的一方面是提供一种收集和归纳风险的机制,以确保风险能够引起管理者的关注。
一方面的不同的风险类别和来源所具备的风险概率,影响,干系人,风险阈值等基础参数可能是不一样的。
定义风险的参数主要是要确定风险的定义,评估和排序的准则。
里面有一个重要的内容就是确定各类风险的阈值。
风险的阈值是给出风险的监督和控制点,当风险最终评估影响超过阈值的时候就必须要考虑实施风险缓解计划。
风险缓解计划的实施可以是在我们评估的关键风险立刻实施,一种就是虽然现在还不是关键风险,但是如何风险超过了阈值就必须要实施缓解计划。
对应SP1.3的内容可以直接理解为风险管理计划,该计划应该是项目计划的重要组成部分。
风险管理计划需要定义项目风险管理小组的成员,项目采用的风险参数,风险识别的方法和工具,项目可能会采用的风险缓解策略,项目如何对风险进行监控等内容。
SG2识别和分析风险
识别风险并对其进行分析,以确定它们的相对重要性。
风险的程度影响到为处理风险而进行的资源分配和确定何时需要相应的管理者关注。
对风险进行分析也就是给内部和外部来源的风险加上标识,然后评估每个风险,确定其发生的可能性和后续结果。
根据已建立的风险分类办法和针对风险管理战略拟订的判据确定风险的类别,将为风险的处理提供所需的信息。
可以把相关的风险分组,以便有效地处理风险和使用风险管理资源。
相应的惯例:
∙SP2.1识别风险
SP2.2对风险进行评价、分类和排列先后顺序
风险的识别有多种方法,头脑风暴,调查表,风险检查单,风险库等都是可以考虑的内容。
对于产品和技术的风险一定要借助于WBS工作分解结构来识别。
在风险识别阶段我们就会形成风险登记册,要完成风险的名称,来源,类别等基本风险属性的录入。
在SP2.2主要是PMBOK中谈到的风险定性分析的内容。
主要是要确定每个风险的影响,风险值=风险发生的概率*风险产生的影响。
对我们识别的每个风险都应该得到最终风险值然后对风险进行优先级排序。
在定性风险分析中引入了风险概率影响矩阵,组织和项目都可以根据概率影响矩阵来定义风险值在哪个范围即是项目关键风险。
当一个风险被评估我项目关键风险后就必须要考虑对风险进行应对和缓解。
SG3 缓解风险
处理风险并且在适当时缓解风险,从而降低对实现项目目标的不利影响。
处理风险的步骤包括提出风险处理意见、监督风险和在规定的阈值被超出时执行风险处理活动。
针对所选择的风险拟订并实施缓解风险的方案,主动降低风险发生时的潜在影响。
这类方案可能包括用于处理所选风险万一发生时的影响的应急方案,这与缓解风险的意图无关。
用于启动风险处理活动的判据、闽值和参数由风险管理战略规定。
相应的惯例:
∙SP3.1制订风险缓解计划
SP3.2实施风险缓解计划
风险管理战略规定的判据、阈值和参数用于确定在什么时候需要采取风险处理行动。
风险缓解计划只是针对项目的关键风险,对于一般风险仅进行监督即可。
对于风险的应对常用的措施有减轻,接受,规避,转移等,建议对于关键风险要有一种以上的缓解应对方法。
在SP3.1中要确定风险的级别和阈值,它们指出风险在什么情况下将变得不可接受并且将启动风险处理行动。
另
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- PP 项目 计划