CMMI-module2-项目计划
浅析 CMMI 2 级的项目策划过程域

浅析 CMMI 2 级的项目策划过程域
赵贵成
【期刊名称】《电子技术与软件工程》
【年(卷),期】2014(000)012
【摘要】本文叙述了 CMMI 模型中 2 级项目策划(PP)过程域所涉及到的软件活动,目的是为执行软件工程和管理活动而制定合理计划,以此作为项目跟踪和监督的基础。
在项目实际操作过程中,不可能一次性就把项目的详细进度确定下来,项目软件策划应采取“近细远粗”的原则,初步策划时依据顶层 WBS 分解结构,每个阶段初期再对 WBS 进行细分,结合估算结果,进行详细的策划。
【总页数】1页(P112-112)
【作者】赵贵成
【作者单位】天津电子信息职业技术学院,天津市300350
【正文语种】中文
【中图分类】TP311.5
【相关文献】
1.浅析城市土地成片开发项目前期策划过程管理 [J], 李依勐
2.CMMI2级中配置管理过程域的研究和实施 [J], 杨丽红;李志蜀;袁晓玲;肖静
3.CMMI2级中配置管理过程域的研究和实施 [J], 杨丽红;李志蜀;袁晓玲;肖静
4.DO-178C与CMMI软件项目策划过程浅析 [J], 廖鹏程;
5.浅析CMMI 2级的项目策划过程域 [J], 骆明伟;刘韶凤;
因版权原因,仅展示原文概要,查看原文内容请购买。
CMMI-项目开发计划模板

[打印时忽略本页]变更履历修订类别:C = 创立,A = 增加,M = 修改,D = 删除【项目名称】项目开发计划广东×××技术股份有限公司目录1概述 (4)1.1项目标识 (4)1.2项目简介 (4)1.3缩写和术语 (4)1.4参考文档 (4)2项目目标 (4)2.1工作范围 (4)2.2过程和质量约束 (4)2.3交付物 (5)2.4过程和标准 (5)3项目团队 (5)3.1组织结构 (5)3.2人员、角色和职责 (6)3.3干系人和关键依赖 (6)3.4人力资源需求 (7)4主控时间表 (7)5资源与工作环境 (8)5.1软硬件资源 (8)5.2工作环境 (8)6项目监视和沟通 (9)6.1项目会议 (9)6.2状态报告 (9)7附件 (10)1概述1.1项目标识项目名称:项目简称/别名:项目编号/代号:[或者根据公司项目管理制度所获得的其它标识]1.2项目简介[概要性介绍本项目的背景、产品、商业目标,等]1.3缩写和术语[如果存在读者可能不熟悉的术语、缩写语等,请在这里逐条进行解释]1.4参考文档[编制本文档所参考的文档,可能包括本项目的合同、项目任务书、需求文档、技术方案,等等]2项目目标2.1工作范围[本项目的主要工作任务说明。
概要性的][如果有技术协议、合同或合同附件、客户/产品需求等文件声明了工作范围,则这里只做概要性描述,然后声明引用该文件]2.2过程和质量约束[项目在工作量、成本、时间、质量等方面的目标][项目任务书中已经明确这些目标的,也在这里重新将这些目标列明,以保持本文件的独立性][这些目标还可能来源于合同]2.3交付物[本项目交付给客户的产品中包含的交付物列表,包括工程性产品、也包括管理性产品(例如阶段性总结报告需要提交给客户)][项目不同,交付物可能迥异][如果需要,为交付物附加特别说明]2.4过程和标准[声明本项目将参考的过程和产品标准][可给出成体系的过程集合的版本号,另外附加裁剪说明文件,如:项目执行过程标准遵循:Soft Tech OSSP V2.1,裁剪说明参考《…项目过程定义》] 3项目团队3.1组织结构[团队组织结构图,表达角色、人员、及一定程度的授权和报告层次][组织结构图应包含:●项目经理、项目上级经理●客户代表●其它相关干系人(用户代表、市场人员、运维人员、采购人员、DBA、工具管理人员、第三方监理、…)●项目组和项目成员][组织结构图重点是“结构”,不一定能够列出所有项目成员的姓名,因为可能还没有具体的人员加入项目组,但需要说明结构,譬如一个项目组下含有“程序员4名”] [暂时不能确定具体人员姓名的,以后逐步更新本计划][如下图]3.2人员、角色和职责[项目成员的角色和职责][]3.3干系人和关键依赖[一般项目都至少会有上级经理、客户代表两个关键外部干系人][视项目情况不同,需要考虑是外部干系人的例子,还有销售代表、用户代表、运维人员、数据管理人员、工具支持人员、…可能有很多][本部分需列明本项目的外部干系人,并且项目对这些外部干系人的依赖事项也需要识别并逐项描述。
CMMI_L2标准体系详解

CMMI L2标准体系详解序:一个处于“无序化”生产的软件公司,要进行过程改进,首要是改进什么呢?做任何事情都需要计划,做软件开发这样复杂的工作更加需要计划,所以2级中有项目计划(PP)以及项目计划跟踪与控制(PMC)两个PA,分别对指定计划以及计划的执行给出了详细的标准。
人是会死的,需求是会变的。
需求变更是每个软件公司最头疼的问题,需求变更也是导致项目进度拖延、成本高涨的主要原因。
如何管理好需求呢?需求管理(RM)给出了详细的指引。
软件生产越来越复杂,有时候我们需要采购一些组件,用于项目中。
另外一个方面,纯软件的项目比例也慢慢缩小,很多软件是基于一定的硬件的,而不少硬件也是需要采购的。
如何采购到合适的软硬件,如何保证采购工作不影响项目成功呢?供应商协议管理(SAM)会给你一个解答。
软件是比较难进行量化管理的,但作为公司的管理者,总会想知道成本、进度、缺陷方面的一些数据,以了解项目的情况。
CMMI2级,已经对度量提出了要求,详细情况见度量(MA)这个PA。
如何保证软件生产过程中各类工作产品协调一致,配置管理(CM)会给出指导。
如何保证每个工作产品以及生产工作产品的过程是遵照规定执行的呢?产品与过程质量保证(PPQA)有明确的指引。
CMMI L2级一共有以下PA:1)项目计划(PP)2)项目计划跟踪与控制(PMC)3)需求管理(RM)4)供应商协议管理(SAM)5)度量(MA)6)配置管理(CM)7)产品与过程质量保证(PPQA)每个PA有什么乾坤呢?我们会详细向大家阐述。
目录一章:需求管理(Requirements Management) (2)二章:项目计划(Project Planning) (4)三章:项目跟踪和控制(Project Monitoring and Control) (6)四章:供应商协议(Supplier Agreement Management) (8)五章:过程与产品质量保证(Process and Product Quality Assurance) (9)六章:配置管理(Configuration Management) (10)七章:度量(Measurement and Analysis) (13)一章:需求管理(Requirements Management)人是会死的,需求是会变的。
浅析 CMMI 2 级的项目策划过程域

随着 科技水平 的进步及社 会经济 的发展, 人类已经进入数字化时代,计算机在园林设计 中的应用越来越广泛 。 Au t o C AD软件的应用 ,
改 变和 丰 富 了 传 统 的 手 绘 设 计 方 式 ,使 园 林 设
3 总 结
综上所述 ,人类在进入数字时代 以后 , 园林 设计这 一块也在计算机等数字设备的应用 下进入 了一 个新 的发 展阶 段。Au t o C AD软件 在园林平面 设计中的应用 ,把园林设计师从笔
墨 、 色 彩 、 纸 张 、 以及 大 量 的 重 复 绘 图 中解 放
方 ,就可 以及时 的在 局部 改进 ,不用 像传 统 手绘那样 需要 重复绘制。经过初级概念方案设 计阶 段,在 加上设计师的反复推理测算 ,全方 位的进行 了解 ,敲定 了方案之后 ,就可 以通过
A u t o C AD 软 件 对 定 稿 的 方 案 进 行 细 化 , 利 用
设计 中的平 面软 件,本 文下面 就对 Au t o C AD 软件在园林设计中的应用进行简单介绍。
矢量 图的绘制方式 ,精确 的表现 出方案 中的每
一
1 A u t o O A D 软 件简介
A u t o C AD软 件是 园林设 计 中的 “ 二维 ” 软件 , 即多被 园林 设计 师用 于平 面 设计 ,其
成 的,它 对于 提高 园林 设计 质量 和效 率有 着 很大 的作 用。
计 更规 范更科 学,而且从一定程度上减少 了设 计 师的劳动强度,提高了作品设计的效率和质 量 。Au t o C AD软 件 已经成 为 园林设 计师 必不
可 少 的 设 计 工 具 之 一 ,它 是 一 款 广 泛 应 用 园林
CMMI+L2标准体系详解

CMMI L2标准体系详解序:一个处于“无序化”生产的软件公司,要进行过程改进,首要是改进什么呢?做任何事情都需要计划,做软件开发这样复杂的工作更加需要计划,所以2级中有项目计划(PP)以及项目计划跟踪与控制(PMC)两个PA,分别对指定计划以及计划的执行给出了详细的标准。
人是会死的,需求是会变的。
需求变更是每个软件公司最头疼的问题,需求变更也是导致项目进度拖延、成本高涨的主要原因。
如何管理好需求呢?需求管理(RM)给出了详细的指引。
软件生产越来越复杂,有时候我们需要采购一些组件,用于项目中。
另外一个方面,纯软件的项目比例也慢慢缩小,很多软件是基于一定的硬件的,而不少硬件也是需要采购的。
如何采购到合适的软硬件,如何保证采购工作不影响项目成功呢?供应商协议管理(SAM)会给你一个解答。
软件是比较难进行量化管理的,但作为公司的管理者,总会想知道成本、进度、缺陷方面的一些数据,以了解项目的情况。
CMMI2级,已经对度量提出了要求,详细情况见度量(MA)这个PA。
如何保证软件生产过程中各类工作产品协调一致,配置管理(CM)会给出指导。
如何保证每个工作产品以及生产工作产品的过程是遵照规定执行的呢?产品与过程质量保证(PPQA)有明确的指引。
CMMI L2级一共有以下PA:1)项目计划(PP)2)项目计划跟踪与控制(PMC)3)需求管理(RM)4)供应商协议管理(SAM)5)度量(MA)6)配置管理(CM)7)产品与过程质量保证(PPQA)每个PA有什么乾坤呢?我们会详细向大家阐述。
目录一章:需求管理(Requirements Management) (2)二章:项目计划(Project Planning) (4)三章:项目跟踪和控制(Project Monitoring and Control) (6)四章:供应商协议(Supplier Agreement Management) (8)五章:过程与产品质量保证(Process and Product Quality Assurance) (9)六章:配置管理(Configuration Management) (10)七章:度量(Measurement and Analysis) (13)一章:需求管理(Requirements Management)人是会死的,需求是会变的。
项目计划CMMI项目管理模板

项目计划(Project Planning)文件修改版本控制更新状态: 用字母表示。
C——创建,A——增加,M——修改,D——删除目录1、目的与范围 (6)1.1目的 (6)1.2项目范围 (6)2、定义与缩写词 (6)2.1定义 (6)2.2缩写 (7)3、角色与职责 (7)4、流程图 (8)5、步骤 (9)5.1建立项目软件过程 (9)5.1.1入口条件 (9)5.1.2输入 (9)5.1.3相关干系人 (9)5.1.4过程描述 (9)5.1.5出口条件 (10)5.1.6输出 (10)5.2初步分解WBS (10)5.2.1入口条件 (10)5.2.2输入 (10)5.2.3相关干系人 (11)5.2.4过程描述 (11)5.2.5出口条件 (12)5.2.6输出 (12)5.3项目估算 (12)5.3.1入口条件 (12)5.3.2输入 (12)5.3.3相关干系人 (12)5.3.4过程描述 (12)5.3.5出口条件 (13)5.3.6输出 (13)5.4建立项目基线计划 (13)5.4.1入口条件 (13)5.4.2输入 (13)5.4.3相关干系人 (14)5.4.4过程描述 (14)5.4.5出口条件 (14)5.4.6输出 (14)5.5评审项目基线计划 (14)5.5.1输入条件 ........................................................................................ 错误!未定义书签。
5.5.2输入 (14)5.5.3相关干系人 (15)5.5.4过程描述 (15)5.5.5出口条件 (15)5.5.6输出 (15)5.6制定项目附属计划 (15)5.6.1输入条件 ........................................................................................ 错误!未定义书签。
CMMI基础知识2-2和3级

项目计划(Project Planning)(PP)
Project Planning的目的:
建立和维护计划,计划规定了项目需要做 的活动。
那么,需要做到怎样的程度,才算把 PP做好考虑,发表一下?
4
1.基础工作
1. 2. 3. 4.
分解项目任务,做WBS 列出工作产品和工作任务 考虑采用怎样的软件开发生命周期 确定工作量、费用等
8
2级特点小结
软件开发的一些细节没有定义:如需求 开发、设计、编码、测试 全部的PA都是针对项目这一级的,没 有组织级的PA。
9
2级和我们的水平比较
我们完全达到了2级的水平! 大家充分理解了2级所需要做的各项工 作!
10
3级的特点
项目管理水平升级 细化了软件工程的各个环节 增加了决策流程 加入了组织级方面的要求
27
组织级方面的要求
组织过程聚焦(Organizational Process Focus)(OPF) 组织过程定义(Organizational Process Definition)(OPD) 组织培训(Organizational Training)
28
3级小结-1
项目管理水平升级
这类工作,就是要满足项目计划的第一个目 标(Goal):建立评估(Establish Estimates) 而以上每一项,就是一个实践(Practice)
5
2.写计划
1. 2. 3.
4.
5. 6. 7.
建立预算和进度 识别项目风险 计划好如何管理各类文档、代码等 计划好软硬件资源 计划好需要哪些培训或者技术支援 计划好与用户、外单位的交涉 把以上内容文档化 这是项目计划的第二个Goal:开发一个项目 计划(Develop a Project Plan)
CMMI简介及CMMI2级的实施方案设计(DOC)

CMMI简介及CMMI2级的实施⽅案设计(DOC)CMMI简介及CMMI2级的实施⽅案设计第⼀部分 CMMI简介:CMMI 全称是Capability Maturity Model Integration,,即软件能⼒成熟度模型集成模型,是由美国国防部与卡内基-梅隆⼤学和美国国防⼯业协会共同开发和研制的。
CMMI (CMMI-SE/SW/IPPD)1.02 版本在部分国家和地区被SEI 开始推⼴和试⽤,主要应⽤于软件业项⽬,帮助提升对软件项⽬的管理能⼒。
随着模型本⾝的发展与应⽤的推⼴,CMMI 逐渐演变成为了⼀种被⼴泛采⽤的综合性模型。
在业界⼴泛使⽤的传统软件研发流程会带来⼀个严重的问题:存在于设计阶段的⼀个微⼩缺陷可能会直到后期的测试阶段才能被发现,⽽整个公司可能会花费数⼗倍甚⾄百倍的代价来改正这个缺陷。
为此,⼈⼒资源管理、软件采购、集成产品和过程开发、以及系统⼯程等等,多元化覆盖范围越来越⼴的能⼒成熟度模型应运⽽⽣。
1.1 CMMI 的作⽤软件能⼒成熟度集成模型(CMMI)经过长期积累和不断地优化,已经成功地发展并被认可为软件研发领域的标准过程体系,通过CMMI 可以增强企业核⼼竞争⼒、有效地提⾼软件企业产品质量,国内乃⾄国际上的⼴⼤软件⼚商都已经见证了CMMI 为企业带来的成功。
⽬前众多业界的软件企业纷纷试图使⽤CMMI 来达到过程改进的趋势,怎样才能将过程改进有效地实施,使其能实质地对软件研发过程起到优化效果,并带来⾏之有效地经济价值,已经逐渐成为了软件企业的决策者们最为关⼼的问题。
由最新SEI 评估报告中的数据显⽰,在进⾏了CMMI 的评估的企业中,⼤部分都是商业组织,并且其中近⼀半的企业⼈员规模都是在100 ⼈以下。
种种迹象均表明,CMMI 评估已经不仅仅吸引了⼤型IT 企业的注意⼒,同样存在⼤量的中⼩型企业也对此抱有浓厚的兴趣。
对软件企业来讲,CMMI 可以主要应⽤在两个地⽅:企业软件过程的改进和企业软件过程能⼒的评估。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
3
获取人员的参与
组建项目组
识别出项目要牵涉的人(角色) 及早让相关人员参与项目 清晰的定义角色和职责 安排人员要注意提供成长的机会 建立有效的沟通机制
7
项目组成员可能包括
开发人员 用户 测试人员 技术文档人员 质量保证 配置管理 技术支持 管理人员 ————
8
Copyright ©2006 袁庆平 All rights reserved.
管理/支持活动的工作拆分结构的开发方 法和工程活动大致相同 管理/支持活动的工作拆分结构中有些任 务是“投入水平”的任务 (Level of Effort),一般只有每周投入工时的信息
18
Copyright ©2006 袁庆平 All rights reserved.
9
渐进法
WBS和估算均可使用渐进法,逐阶段细化 总体计划。 随着项目进入新的阶段,对下一个阶段进 行详细计划,新的阶段的估算使用详细的 WBS结构中每项任务的估算值累加得到。
裁剪 CMMI3级的要求
支持过程
配置管理 质量保证 度量分析
11
生命周期模型重在阶段划分
无论采用何种生命周期模型
阶段定义是最重要的 阶段分大小
大阶段处应定义里程碑 小阶段的工作产品应执行正式的评审
应明确每个阶段的进入和退出标准 阶段定义识别出了工程活动的首层拆分
12
Copyright ©2006 袁庆平 All rights reserved.
17
估算表样例
35
估算会议
主持人收集所有人的匿名估算数据,并且用图形 表示
36
Copyright ©2006 袁庆平 All rights reserved.
18
估算会议 - 2
参与者讨论被估算对象,使用的假设,需要澄清的问题等
管理/支持活动
项目管理 计划 跟踪 支持 QA CM
项目
阶段1 组件1 组件2
工程活动
阶段2
15
工作拆分结构– 工程活动
第一个级别是技术活动的阶段 应将过程和系统特征(即功能)结合
结合裁剪结果识别出工程活动 结合需求将子系统、模块、窗口或页面、控件逐层分 解 组合到一起形成WBS
更细的任务随着项目的进展而逐步得到定义 最底层结构的定义可以在项目阶段的详细计划活 动中完成 每一项最底层的任务都应该有一个任务描述
16
Copyright ©2006 袁庆平 All rights reserved.
8
工作拆分结构的2周原则
所有的项目活动最终都要拆分成由一个人 在2周内完成的任务 任务划分的比较细有利于精确的估算 目进度和成本的时候及时更新状态 信息成为可能
17
工作拆分结构 – 管理和支持活动
5
需求定义了项目的范围
项目范围的界定是以项目需求的定义为标 志的 需求既包含项目的技术要求,也包含项目 的非技术要求(例如交货日期等) 需求是所有项目估算、计划、执行和跟踪 的基础 项目大纲或者包含了对需求的概要总结, 或者对客户需求建立了引用
6
Copyright ©2006 袁庆平 All rights reserved.
6
识别项目的工作产品
项目阶段和活动
工作产品
客户需求规格说明书 软件需求规格说明书 概要设计规格说明书 详细设计规格说明书 代码
定义 系统分析 × × × 系统测试 计划 需求分析 概要设计
设计 详细设计 集成测 试计划
编码 编码和单元 测试 集成测 试
测试 系统测 试 文档 发布
× ×
系统测试计划 集成测试计划 单元测试计划
启动会议
主持人的职责:
为估算的参与者提供: 输入文件 估算活动的目标 假设和限制 在必要的时候,需要向参与者解释Delphi方法 检查提供的信息,确定是否需要额外信息。 如果没有任务列表或者WBS,则需要准备一份 确定估算中所用的度量单位(如人时,源代码行等)
―
参与者的职责:
― ― ―
33
个人准备
根据过程模型识别出要开发的所有工作产品 把工作拆分到易于管理和估算的粒度 确保拆分出来的每一个技术活动都产生一个可以识别的结 果 还需要界定管理和支持活动
管理活动包括计划,跟踪等 支持活动包括QA, CM等
14
Copyright ©2006 袁庆平 All rights reserved.
7
WBS的示意图
×
× × ×
单元测试报告 集成测试报告 系统测试报告
× × ×
用户文档 – 初始 用户文档 – 最终
× ×
发布文档(版本说明) 安装介质
× ×
13
拆分思路及要点
仅拆分任务,与何人负责完成任务、任务起止时间以及工 作量无关 过程活动拆分的起点是项目的过程模型
选定的生命周期模型 选择的开发方法,即裁剪的工程过程
10
Copyright ©2006 袁庆平 All rights reserved.
5
定义项目流程
定义项目的生命周期模型
瀑布、增量、螺旋、快 速应用开发等
OSSP •1…… •2….. •3…… •4……
项目类型及特征定义 技术过程
系统分析、需求分析、 设计、编码、测试、评 审等
管理过程
计划过程 项目跟踪与监控过程 风险管理
4
拆分工作
–
神啊,请告诉我 如何吃掉一头大 象吧!!
目的
为进行详细估算和日 程的排定提供基础 确保工作识别的完整 性 增加项目的成功机会
定义项目流程
识别工作产品
工作拆分结构
9
工作拆分结构 - WBS
WBS是一种把项目拆分 成任务或者活动的方法 把过程和产品结合起来 降低漏掉重要任务的可能 性 确保各项任务和它们之间 的逻辑关系得到识别 为估算和日程表的排定提 供基础 可以在项目之间重复使用
定义出最大风险的列表 或采用风险值矩阵
23
为选定的风险选定处理策略
可选择的策略
规避 把风险排除在项目范围之外 转移 把风险转移到能够得到更好的 处理的领域 接受 不采取行动,准备承受风险发 生所带来的影响 缓解 采取行动来减少风险发生的可 能或者发生后产生的影响
24
Copyright ©2006 袁庆平 All rights reserved.
整合 整合
完成 完成
31
为Delphi估算进行计划
确定要进行何种类型的估算 选择主持人 选择参与者
具有相应的知识和经验
制定会议日程 组织估算所需要的输入信息
所需要估算的活动的定义(如需求,设计) 任务列表或者WBS
32
Copyright ©2006 袁庆平 All rights reserved.
16
选择规模的度量单位(LOC或者功能点) 估算整体系统的规模 选择合适的生产力参数获得对应的工作量 通过历史数据获得工程活动各阶段的工作量分布 计算管理、支持活动的工作量 最终获得每个阶段、每类任务的总工作量
自下向上的估算方法
跟踪工作拆分,分别确定工作产品的规模 根据平均生产率,确定每个任务的工作量 汇总各阶段和各类任务的总工作量
两者比较,差异不大即可
27
规模估算单位
规模估算
代码行
在工程软件界比较流行 很难直接从需求出发进行估算
功能点
从客户可见的功能出发 在信息系统界比较流行 具有很好定义的计数标准 与具体技术和语言无关
28
Copyright ©2006 袁庆平 All rights reserved.
14
规模估算方法
有类似的历史项目,应使用类比法进行估 算 全新的开发项目,如果条件允许,可以先 进行局部(典型)模块或子系统的开发, 获得规模及生产效率的指导参数,其他未 开发部分进行类比获得
12
记录风险及其缓解行动
风险缓解行动日志 编 号 1 1 日 期 范 围 可 能 性 % 8 0 影 响 4 责任 人 状 态
风险描述
权值 3.2
缓解行动 1 在设计阶段完成前聘用具有 经验的程序员
项目成员缺少面向 对象技术的经验; 可能造成项目延期 百分之十五
2 如果不能招聘到合适人员, 则进行相应的培训 3 从别的项目抽调合格的人员 对本项目的设计进行辅导 4 进行频繁的技术审核
1
定义项目
建立对项目目标和范围的认识 – 定义项目大纲 定义对项目参与人员的要求,早期获得项目成员 的参与 记录上述内容,作为项目计划的第一部分
定义项目大纲
确立项目范围
人员的参与
3
项目大纲 – Statement of Work
项目大纲是简要的对项目的描述 项目大纲可能会以不同的名字出现,诸如工作综 述,工作要求,或项目建议书 可以来自组织内部,也可以来自外部
25
估算规模,成本和时间
目的:
建立起合理的项目预算和日程表 决定项目的用人水平 建立承诺的基础
要注意的问题
随机的估算方法 过分乐观 屈服于压力 分配法 过度估算工作量
规模估计 工作量估计 进度计划
26
Copyright ©2006 袁庆平 All rights reserved.
13
估算方法
自顶向下的估算方法
项目的初始计划 需求计划 设计计划 项目剩余部分更新的计划 项目剩余部分更新的计划 编码/UT计划 项目剩余部分更新的计划 验收测试和发布计划
19
风险计划
目的
识别出项目中的高风险区域以便进行管理 为计划活动提供输入 为备用方案的评估提供依据 决策支持
风险识别和记录
风险评估及分析
风险策略
20
Copyright ©2006 袁庆平 All rights reserved.