CMMI规范中项目策划(PP)
项目策划(PP)
项目策划(Project Planning, PP)的目的，在建立并维护用以定义项目活动的计划。
项目策划过程域包括：
• 开发项目计划
• 与干系人适当的互动
• 取得对计划的承诺
• 维护项目计划规划开始于用以定义产品与项目的需求。
规划包括：估计工作产品及工作项目的属性、决定资源需求、协商承诺、产生进度，以及识别和分析项目风险。订定项目计划可能需要反复上述活动。项目计划提供执行及控制项目活动的基础，以完成对项目客户的承诺。
项目进行时，项目计划常因下列情况而须修订：需求及承诺变更、不准确的估计、纠正措施及过程变更。说明规划及重新规划的特定实践，包含在本过程域之内。
在本过程域的通用与特定实践中，全部使用「项目计划」这个术语，来描述控制项目的全盘计划。
有关产品及其组件之需求开发，请参考需求开发过程域，以获得更多信息。产品及产品组件之需求与需求变更，是规划及重新规划之基础。
有关规划及重新规划所需的管理需求，请参考需求管理过程域，以获得更多信息。
有关风险识别与管理，请参考风险管理过程域，以获得更多信息。
有关把需求转成产品及其组件解决方案，请参考技术解决方案过程域，以获得更多信息。
SG 1 建立估计值
SP 1.1 估计项目范围
SP 1.2 建立工作产品与工作项目属性的估计值
SP 1.3 定义项目生命周期
SP 1.4 决定工作量与成本的估计值
SG 2 开发项目计划
SP 2.1 建立预算和进度
SP 2.2 识别项目风险
SP 2.3 规划数据管理
SP 2.4 规划项目资源
SP 2.5 规划所需知识和技能
SP 2.6 规划干系人之参与
SP 2.7 建立项目计划
SG 3 取得对计划的承诺
SP 3.1 审查影响项目的各种计划
SP 3.2 调整工作和资源水平
SP 3.3 取得计划承诺
建立并维护项目策划参数的估计值。
项目策划参数包括项目从事下列活动所需之所有信息：规划、组织、用人、督导、协调、报告及预算。
规划参数的估计值应有可信赖的基础，以逐渐建立信心，使得任何以此估计值为基础所做的计划，都有能力支持项目目标。
估计这些参数值时，通常考虑的因素举例如下：
• 项目需求，包括产品需求、组织需求、客户需求及可影响项目的其它需求
• 项目范围
• 已识别的工作项目及工作产品
• 技术方法
• 已选定的项目生命周期模型(例如：瀑布式、渐进式、螺旋式等)
• 工作产品与工作项目的属性(例如：规模大小或复杂度)
• 进度
• 把工作产品与工作项目属性转换成投入工时与成本的模型或历史性数据
• 决定所需材料、技能、工时及成本的方法(模型、数据、算法) 为了干系人对项目计划的审查与承诺，以及在项目执行过程中维护项目计划，记录估计理由与支持性的数据是必要的。
SP 1.1 估计项目范围
建立高层工作分解结构（WBS），以估计项目的范围。
工作分解结构随项目进行而渐进开发。初始期的最高层WBS用于初期估计。开发WBS时，把整个项目分成一组可管理的相互连结的组件。WBS通常是产品导向的结构，提供一种纲要结构，以识别与安排工作管理的逻辑单元，该逻辑单元称之为「工作包(work packages)」。通常，WBS 提供工作分配、进度安排及权责的参考与组织的机制，并作为规划、安排及控制项目工作的基本架构。
有些项目会使用「合同WBS 」一词，以代表合同中的WBS(可能是整个的WBS)。并非所有的项目都会有「合同WBS」(例如公司内部资助的开发案)。
典型的工作产品
1. 工作项目描述
2. 工作包描述
3. 工作分解结构
子实践
1. 以产品架构为基础，开发工作分解结构。
工作分解结构提供纲要结构以安排项目工作，该工作环绕所支持的产品。工作分解结构应确认下列事项：
•识别风险与风险降低工作
•项目交付项目，及支持活动所需的工作
•为了获得技能与知识的工作项目
•开发工作所必须的支持计划，如：配置管理、质量保证及验证等计划
•非开发类项目的集成与管理工作
2. 识别工作包，须详细到足以估计项目工作项目、责任及进度。
在工作项目及组织角色与责任方面，最高层的WBS用来协助度量项目工作量。至于细节则描述于更低层的WBS，有助于开发实际可行的进度计划，从而减少预留管理空间的需要。
3. 识别会从外部取得的工作产品(或者是工作产品的组件)。
有关从项目外部来源获得工作产品，请参考供应商协议管理过程域，以获得更多信息。
4. 识别将再使用的工作产品。
SP 1.2 建立工作产品与工作项目属性的估计值
建立并维护工作产品与工作项目属性的估计值。
规模大小是许多模型用来估计工作量、成本及进度的主要输入。这些模型也可根据连结、复杂度及结构作为输入的基础。
规模大小估计的工作产品种类，举例如下：
• 交付类及非交付类工作产品
• 文档与档案
• 可运作及支持的硬件、刃体和软件
规模大小之度量方式，举例如下：
• 功能数
• 功能点
• 原始码行数(SLOC)
• 类别(Class)与对象(Object)数量
• 需求数
• 接口的数目与复杂度
• 文档页数
• 输出及输入数
• 技术风险项目数量
• 资料数量
• 集成电路逻辑闸的数目
• 零件的数目(例如以洗好的电路板、组件与机械零件)
• 物理限制(例如重量与容量)
这些估计值应与项目需求一致，俾决定项目之工作量、成本及进度。每个规模大小属性，均应指定一个相对困难度与复杂度的等级。
典型的工作产品
1. 技术方法
2. 工作项目及工作产品的规模大小及复杂度
3. 估计模型
4. 属性估计值
子实践
1. 决定项目的技术方法。
技术方法决定产品开发的高层策略。它包括架构特性的决策，例如采用分布式或主从式架构；应用最先进的技术或较成熟的技术，例如机器人、复合材料、或人工智能；以及对产品更广泛的功能期望，例如安全性、机密性及人体工学等方面的需要。
2. 使用适当方法决定工作产品及工作项目的属性，以估计资源需求。
决定规模大小及复杂度的方式，应以经过确认之模型或历史数据为基础。
我们对产品特性与属性的关系了解越多，决定属性的方法也将随之渐进开发。
现行方法，举例如下：
• 用于IC 设计的逻辑闸数目
• 用于软件的LOC 或功能点数
• 用于系统工程的需求数量/复杂度
• 用于标准住宅的平方呎数
3. 估计工作产品及工作项目之属性。
SP 1.3 定义项目生命周期
定义项目生命周期阶段，并据此建立规划工作的范围。
决定项目生命周期的阶段，为评估与决策之规划阶段作准备。这通常与资源及技术方法重大承诺的合理决策点有关。这样的决策点在修订项目方向与决定未来工作范围与成本上，提供可达成的计划结果。
项目生命周期各阶段的定义，有赖于需求的范围，项目资源的估计，以及项目的本质。较大型的项目可能包含多个阶段，例如观念探索、开发、制造、操作与配置。在这些阶段中，可能会需要子阶段。开发阶段可能包含的子阶段有需求分析、设计、制造集成与验证。软件项目阶段之决定，通常包含软件开发模型的选择与改进，以说明项目活动间的相互关系与适当次序。
根据开发策略，也可能还需要有下列中间阶段：原型制作、功能渐进或螺旋模型周期。
了解项目生命周期对下列工作是必要的：决定规划工作的范围、决定开始规划的时机及决定计划修订之时机与准则(关键里程碑)。
典型的工作产品
1. 项目生命周期阶段
SP 1.4 决定工作量与成本的估计值
依据估计理由，估计工作产品和工作项目所需项目工作量和成本。
工作量及成本的估计值，通常根据模型分析的结果，或应用于规模大小、活动及其它规划参数的历史资料而来。对这些估计值之信心，是来自估计模型的逻辑原理及历史数据的本质。有时候历史数据不适用，例如工作欠缺前例或工作项目类型与模型不合。所谓工作欠缺前例(在某种程度)，是指以前从未有人做过相似的产品或组件，或是开发小组以前从未做过。
欠缺前例的工作风险通常较大，必须多做一些研究以便建立合理的估计基线，通常在管理上也须多预留一些空间。当使用这些模型时，必须记录项目的独特性，以确保在初始规划阶段所做的假设均达成共识。
典型的工作产品
1. 估计理由
2. 项目工作量估计值
3. 项目成本估计值
子实践
1. 收集估计模型或历史数据，俾用于将工作产品及工作项目的属性，转换成工时及成本的估计值。
在软件工程领域，已开发出许多参数化模型，以协助估计成本及进度。并不建议只使用这些模型作为估计的单一来源，因为它们所依据的历史项目资料，可能并不适合你的项目。使用多种估计模型及(或)多种估计方法可以确保估计上的高度信心。
来自于先前执行项目的历史数据，包括成本、工作量及进度，以及考虑不同项目规模及复杂度的调整因素。
2. 估计工作量及成本时，应纳入支持基础环境所需的项目。
支持的基础环境包含从产品开发及维护的观点所反映的资源需求。
在评估人力与成本时，应考虑在开发环境、测试环境、制造环境、用户终端环境，以及上述任何组合所需的内在基础资源。
内在基础资源包含如下：
• 重要的计算机资源(例如：硬盘及网络容量)
• 开发环境与工具(如原型工具、装配、计算机辅助设计与仿真)
• 设施、机械与设备(如测试平台与记录的仪器)
3. 用估计模型及(或)历史资料，估计所需工作量及成本。
用来估计工作量及成本的输入，通常包括：
• 专家(群)所提供的判断估计(例如：Delphi 预估法)
• 风险因素，包括工作欠缺前例的影响程度
• 执行工作所需之核心能力与关键角色
• 产品与产品组件需求
• 技术方法
• 工作分解结构
• 工作产品与预期变更之规模大小估计
• 对外采购工作产品之成本
• 已选定之项目生命周期模型与过程
• 生命周期成本估计
• 在工程环境下的工具提供能力
• 执行工作的管理人员与幕僚人员之技能水平
• 所需知识、技能和培训
• 所需设施(例如：办公室、会议室及工作站)
• 所需工程设施
• 编程能力
• 差旅
• 工作项目、工作产品、硬件、软件、人员及工作环境之安全程度
• 客服中心及产品保证之服务等级协议
• 直接人工与间接费用
SG 2 开发项目计划
建立并维护项目计划，以作为管理项目的基准。
项目计划以项目需求及已建立的估计值为基础，是用来控制项目执行的正式核定文档。
项目计划应考虑所有项目生命周期的各阶段。项目策划时应确保所有影响项目的计划与主计划之间的一致性。
SP 2.1 建立预算与进度
建立并维护项目预算与实践。
项目预算及进度，要依据已开发的估计值来安排，并确保预算分配、工作复杂度、工作项目的依存关系均已适当考量。
事件驱动且有资源限制的进度安排，已被证明能有效处理项目风险。若工作开始之前，就清楚识别完成时将要展示的成果，则有下述好处：提供事件处理的时间弹性、对预期成果的共识、较佳的项目状态愿景，以及较精确的项目工作项目状况掌握。
典型的工作产品
1. 项目进度表
2. 进度相依关系
3. 项目预算
子实践
1. 识别重要的里程碑。
里程碑用来协助确定交付项目能如期完成。里程碑可以事件或日期为基线。若以日期为基线，一旦决定日期就很难更改。
2. 识别进度安排的假设前题。
当开始开发进度时，通常需要假设某些活动的期程。这些假设通常涉及一些缺少估计数据的工作项目。识别这些假设前题，可提供对全程之信心程度(不确定性)的洞察力。
3. 识别限制条件。
应尽早识别影响管理方案弹性的限制因素。检验工作产品与工作项目的属性，常会促使这些因素浮现。这些属性可包括：工作项目之工期、资源需求、输入及输出。
4. 识别工作项目的相依关系。
项目工作项目若依某一次序进行，通常可缩短完工时间。这需要先识别工作项目的先后顺序，以决定最佳的次序。
可用于决定工作项目最佳次序的工具，举例如下：
• 关键路径法(CPM)
• 计划评核术(PERT)
• 资源限制编程法
5. 定义预算与进度。
建立并维护项目预算及进度通常包括下列事项：
• 定义资源与设施已承诺或已预期的可用时段
• 决定项目活动的时间阶段
• 决定附属进度的分类
• 定义项目活动间的相依关系(先后顺序关系)
• 定义支持精确进度度量所需的编程活动及里程碑
• 识别交付客户产品的里程碑
• 定义适当工期的项目活动
• 定义适当时间间隔的里程碑
• 根据满足进度与预算要求之信心度，定义管理上需预留的空间
• 用适当的历史数据来验证进度
• 定义渐增的经费需求
• 记录项目的假设与理由
6. 建立纠正措施准则。
建立构成严重偏离项目计划的判断准则。度量的议题与问题对决定何时采取纠正措施十分重要。纠正措施可能需要重新策划，重新策划包括修订原计划、建立新协议，或减少目前计划内的活动。
SP 2.2 识别项目风险
识别并分析项目风险。
有关风险管理活动，请参考风险管理过程域，以获得更多信息。
有关风险监测活动，请参考项目监控过程域的特定实践，以获得更多信息。
须识别或发现风险，并进行分析以支持项目策划。本特定实践必须延伸到影响项目的所有计划，以确保与所识别之风险相关的相关干系人之间的接口，已有适当的安排。项目策划风险的识别与分析，通常包括下列各项：
• 识别风险
• 分析风险以决定其影响程度、发生机率及可能发生问题的时间点
• 排列风险的优先级
典型的工作产品
1. 已识别的风险项目
2. 风险的影响程度及发生机率
3. 风险的优先级
子实践
1. 识别风险。
风险识别包括识别会负面影响工作成果与计划的各种潜在问题、危险、威胁及弱点。在分析风险之前，必须先以容易了解的方式，识别及描述风险。识别风险时，最好能采用定义风险的标准方法。可使用风险识别及分析工具，以协助识别可能的问题。
风险识别及分析工具，举例如下：
• 风险分类
• 风险评价
• 查核表
• 结构化访谈
• 头脑风暴
• 绩效模型
• 成本模型
• 网络分析
• 质量因素分析
2. 记录风险。
3. 与相关的干系人审查已记录风险之完整性与正确性，并取得其同意。
4. 适当地修订风险。
已识别的风险须要修订的情况，举例如下：
• 新风险已被识别
• 当风险变成问题
• 风险已消失<
评论