华为产品开发项目打算模板.docx
《华为产品开发项目打算模板.docx》由会员分享，可在线阅读，更多相关《华为产品开发项目打算模板.docx（23页珍藏版）》请在冰豆网上搜索。
华为产品开发项目打算模板
密级ConfidentialityLevel
报告版本ReportVersion
页数TotalPages
报告编号：
产品开发计划
项目号：
项目名称：
编制人：
部门：
日期：
初审Pre-Reviewedby
日期Date
复审Reviewedby
日期Date
批准Approvedby
日期Date
版权所有XX
AllCopyrightReserve
内容简介
1.1文档目的
这部份要描述文档的目的，应该指明读者。
1.2文档范围
<描述项目打算的范围，明确文档涉及的各项内容>
简要描述本打算需要在该产品项目中完成的工作活动及其工作目标、项目采纳的生命周期、项目交付物、相关人员的角色和职责、要紧里程碑、进度打算、质量打算、配置治理打算、风险打算等。
项目概况
简要描述本项目的类型（新产品/改良/保护类）、项目的目的、范围、目标（例如：
项目的市场定位，产品需求等）。
项目组织结构
PDT组织结构图
PDT及系统分析与设计组成员建议，产品开发成员建议
在决策评审点前与适当的PRB成员及相关资源部门领导对这些列表进行沟通的结果
描述项目的组织结构，建议采纳图表的表示方式。
也可参考下例：
下表概念了项目成员的角色和职责。
●在审核之前项目领导需指定所有文档和代码的审核人。
●关于各个角色的职责概念可依照项目实际情形进行补充。
●下表内容应当至少在项目的每一个时期终止时进行更新。
关于项目时期中/时期间发生的组织结构的转变，项目领导应当通过邮件周知所有相关人员，然后更新项目打算。
表4项目的组织结构
No.
角色
姓名
向谁报告
备份资源
1
客户代表
2
产品QA（PQA）
3
PDT经理
版本经理1
版本经理1
4
市场代表（MKTPDT）
5
技术支持代表（TSEPDT）
6
制造代表（MNFPDT）
7
采购代表（PROPDT）
8
财务代表（FPDT）
9
开发代表（RDPDT）
系统工程师（SE）
软件经理
硬件经理
结构经理
开发组长（PL）1
开发组长（PL）2
10
变更控制委员会（CCB）
11
技术评审专家（Reviewer）
项目依托关系分析
项目关键路径分析及保障方法
在本节中，分析阻碍项目进度的关键步骤/环节、关键因素，并提出保障方法
项目依托关系分析
在本节中，说明项目的内部依托关系（如：
开发测试工具、人力资源等）和对外部的依托（如项目之间、与客户之间的技术、资源等方面）。
可用依托性列表、活动网络图的方式描述。
列出所有阻碍项目打算的假设因素（相关于已知的因素）。
若是这些假设因素有误，或没有利用到假设因素，或假设因素发生转变都会使项目受到阻碍。
另外还要描述项目对外部因素的依托关系，例如，如项目作为整个大系统的一部份，需要其他部份提供接口概念或PDT提供正在开发的仿真性能测试工具以代替实际环境测试等等>
请参考下例：
表1项目依托关系
Sl.No
依赖于（通常指接口等）
责任人
状态OPEN（正在进行）/CLOSE（已经关闭）
最早提供日期
验收条件（如果有）
1
2
3
项目关键成功因素
关键成功因素
影响
高/中/低
依赖关系
行动计划
技术方式和工具
在本节中，描述对产品项目进行需求分析、设计、实现、测试、文档写作、发布、修改、或保护进程中采纳的开发方式、组织结构和其他标记、工具、技术和方式。
另外，对利用的技术标准、方针和流程也要用直接描述或参考到其它文档的方式进行说明。
参考下例，关于产品项目所需要的硬件、软件和其他工具设备用下表描述：
表2技术方式和工具
分类
名称
型号
数量
开始使用日期
结束使用日期
仪表
专用仪表
开发工具
交付件
在本节中，应描述需要交付给下游部门的工作产品及其需求。
这些交付工作产品应包括各类设计文件、图纸、文档等。
交付工作产品应分解成可治理的大小粒度。
（这部份内容如在配置治理打算或文档打算中给出，则能够指出相关文档名称或给予链接即可。
）能够采纳列表方式。
举例如下：
表3项目交付工作产品
交付工作产品名称
产品描述
质量保证活动
验收标准
交付件形式
总体设计文档
XXX项目XX总体设计方案
正规检视及评审
归档/发布
文档
详细设计文档
XXX项目XX详细设计
归档/发布
文档
归档/发布
归档/发布
文档
归档/发布
文档
归档/发布
文档
归档/发布
文档
……
……
……
……
……
项目计划
项目的里程碑计划
▪关键里程碑打算可采纳图形方式。
将项目的所有里程碑和关键活动标注在下面的时刻轴上。
注意：
若是存在初期功能子集Beta和/或ESP交付件，PDT需要对交付件进行TR4A/TR5评审，和对GA层产品交付件进行TR4A和TR5评审。
PDT不需要对每一个构件标注TR4，只需要标示第一个TR4的日期。
若是需要将所有里程碑和关键活动标注出来，可将时刻轴划分成时期，如上所示。
▪也可采纳如下例子的形式描述里程碑打算。
表5项目里程碑打算
阶段
估计结束日期
交付件
验收准则
（可去掉）
TR1（需求评审）
和概念DR
市场调研报告（立项阶段输出）
市场需求清单（立项阶段输出）
初始业务计划（立项阶段输出）
产品需求规格书
TR2（总体方案评审）和计划DR
产品可行性分析报告/产品业务计划
产品开发计划
总体设计方案书/产品设计说明书
产品测试与验证计划
工艺总体方案
装备总体方案
初始物料清单
供应商和物料选择计划
物料认证计划
提前采购决策
TR3（模块级概要设计评审）
模块级概要设计/总体设计
各模块级测试报告
目标成本跟踪表
市场教育和培训计划
测试方案
TR4（原型机评审）
原型机
原型机测试报告
TR5（设计定型评审）
中试样机验证报告
制造系统验证报告
BETA测试结束
BETA测试报告
外部认证结束
系统认证和标杆测试报告
TR6（转产评审）
和发布DR
产品可行性分析报告/产品业务计划（优化后）
市场发布材料清单
受控销售阶段评估报告
试产验证测试报告
制造系统验证报告
量产点GA
量产检查点确认通知
项目WBS计划（highlevel打算）
参见项目的WBS打算，请指出具体寄存位置。
软件详细打算
硬件详细打算
结构详细打算
人力资源和技术需求
▪也可采纳下表格式：
<罗列项目需要的人力资源及技术要求>
对项目组人员提出可能会阻碍项目进度的技术要求，例如：
CPU应用技术、VxWorksBSP技术等。
Sl.No.
资源名称
阶段1
（人数、技能要求）
阶段2
（人数、技能要求）
阶段3
（人数、技能要求）
阶段4
（人数、技能要求）
说明
1
项目经理
2
XX业务代表
3
硬件组
4
软件组
结构组
测试组
▪也可采纳下表格式：
<罗列项目需要的人力资源及技术要求>
Sl.No.
资源名称
人数
起始日期
结束日期
技能要求
说明
1
2
3
4
项目所需其它资源
9.1关键物料需求打算
详细描述在不同时期对关键物料的需求打算。
可单独形成《关键物料需求打算》。
或可单独形成《供给商※物料选择打算》
也可采纳下表：
：
表6关键物料需求打算
关键物料描述
计划采购到货时间
预期最长采购周期
计划采购数量
概念、计划阶段物料
XXX器件
开发阶段物料
XXX器件
验证与发布阶段物料
XXX器件
注：
项目组应充分估量各物料的采购周期，在各关键点应提早下达采购需求给采购部门。
增加提早采购，供给商选择
参见提早采购打算表模板：
《新物料提早采购清单》，部份物料能够从该表COPY过来
项目组应该打算好第一次量产前（包括工程样机、中试样机、第一次量产）的所有物料，并依照后续量产的数量、时刻结合市场的打算等给出建议。
9.2实验设备和环境资源打算
详细描述在不同时期对不同的环境的需求打算。
如特殊的硬件平台、测试设备、软件工具等。
标准的办公硬件没必要在那个地址列。
举例如下：
表6实验设备和环境资源打算
阶段
描述
数量
计划使用时间区段
说明
概念分析
计划阶段
开发阶段
验证阶段
资料开发打算
表7资料开发打算
资料类别
资料名称
责任人
计划完成时间
验收准则
1.用户类资料
用户手册
客户产品布XXX
评审
2.营销类资料
市场部YYY
评审
3技术支持类资料
开发/测试
评审
4应用开发资料
开发/测试
对外合作打算
参照整体设计文档“外包外购的相应规格”列出需要对外合作的部份。
包括合作内容，进度要求等
外包任务
<本部份仅当项目中有外包时适用>
10.1子承包商资料
子承包商名
联系人
通讯地址
<其它>
10.2外包任务的范围
<指明项目外包给子承担商的工作内容，能够采纳特性、需求、模块等来讲明>
10.3里程碑、交付件
<指明协商后确信的子承包商的里程碑、交付件>
里程碑
分配给子承包商的工作产品
计划开始日期
计划完成日期
给公司的交付件
预算/分派（可选）
估量产品的预算及分派
讨论要紧的未解决问题，包括资金投入的及时性及性质。
将实际日期的项目资源、本钱和时刻进度与估量的整个项目的资源、本钱和时刻进度进行比较。
验收标准（可去掉）
客户的验收标准确实是产品应知足在需求规格文档中描述的需求。
系统测试和验收测试将证明产品与需求规格维持了一致。
<请在那个地址注明客户特殊的验收标准。
验收标准是基于客户的需要，因此应由客户来制定，在需要的时候由项目组协助。
交付件的属性如：
质量目标，测试标准，验收终止后发觉故障的处置方式，文档等。
>
质量计划（也可单独成文档）
项目进程概念
1）选择开发模型
开发类，增强类，保护类
2）并可在此基础上进一步流程裁剪：
提供与标准开发流程的误差，并说明裁剪缘故。
质量目标
能够定性或定量描述，为提高可操纵性，尽可能采纳定量质量指标描述。
若能定量描述，请参考下表：
参考或直接引用项目气宇表中质量目标部份的数据。
表9项目质量目标
NO.
项目质量目标
目标
基线
（暂不填）
上限
（暂不填）
下限
（暂不填）
说明
1
进度偏差率
80%
2
需求稳定性
90
3
硬件第一次样机制作完成前缺陷发现数目
<=3
4
样机投板次数
20%
5
软件发布前缺陷发现密度
6
编码缺陷发现密度
7
硬件/软件总体设计缺陷发现数目
8
硬件/软件详细设计缺陷发现数目
9
需求更改/设计更改/工程更改数
10
文档齐套性
11
返修率
......
通过技术手腕保证质量
通过哪些技术手腕能够保证质量目标和关键性能指标的达到。
例如：
通过静态代码分析工具和自动化软件测试工具能够有效提高软件质量。
质量操纵活动
罗列执行的质量操纵活动。
12.4.1技术评审活动
产品开发进程中需要哪些技术评审活动，哪些技术评审点能够归并？
各技术评审点的评审要素的裁剪说明t
♦技术评审1和技术评审2归并
TR1与TR2的评审要素归并，并裁剪，评审要素重点放。
。
。
，而。
。
。
方面要素可免去。
♦技术评审3
TR3的评审要素需裁剪，评审要素重点放。
。
。
，而。
。
。
方面要素可免去。
♦技术评审4
TR4的评审要素需不裁剪；
♦技术评审5
TR4的评审要素需不裁剪；
♦技术评审6
TR4的评审要素需不裁剪；
12.4.2正规检视活动（同行评审）
产品开发进程中需要设置对哪些输出的正规检视活动？
♦软件模块测试打算
♦软件概要设计
♦软件代码
♦软件测试报告
♦硬件整体设计
♦硬件电路原理图和PCB图
♦硬件测试报告
12.4.3测试
对测试策略和测试活动进行说明：
也可合入文档《产品测试与验证打算》
●测试活动归并裁剪
例如：
增强类项目，集成测试和系统测试能够归并。
●单元测试
测试质量目标
测试依托关系分析
测试停止准则
●集成测试
测试质量目标
测试依托关系分析
测试重点
回归测试策略
测试停止准则
●系统测试
测试质量目标
测试依托关系分析
测试重点
回归测试策略
质量保证活动
罗列应该执行的质量保证活动。
举例如下：
12.5.1内部审计
每一个项目在开发生命周期中至少进行一次内部审计。
12.5.2交付件审计（按时期）
♦技术评审1以后
♦技术评审2以后
♦技术评审3以后
♦技术评审4以后
♦技术评审5以后
♦技术评审6以后
12.5.3基线审计
计划在哪些时期点需要进行基线审计。
♦技术评审1以后
♦技术评审2以后
♦技术评审3以后
♦技术评审4以后
♦技术评审5以后
♦技术评审6以后
项目沟通计划
项目组会议
列举项目跟踪、监控的会议类型、频率和参加人员，能够采纳列表形式。
参考下例：
表7项目组会议
No
会议
频度
参加人
跟踪机制
1.
阶段结束会议
2.
项目总结会议
3.
项目报告机制
列举项目跟踪、监控进程中需要出示的报告类型、频率、报告人、汇报人信息。
参考下例：
表8项目报告机制
No.
报告
准备人
频度
向谁汇报
1.
项目状态报告
2.
项目阶段结束报告
3.
项目总结报告
4.
项目的重用计划
需要对公司其他产品在本产品中实现重用进行分析和本产品能够共享给公司的其他产品以供重用，能够直接链接相应的文档或在此加以说明。
15.1现有重用构件
Sl.No
构件/文档名
采用阶段
（Ifapplicable）
重用构件的资产ID
1
2
15.2新增重用构件
序号
构件/文档名
需求/文档id
说明
1
2
注：
资产库中已有的重用构件
2项目产生的新的重用构件
配置治理计划
项目的配置治理活动应该依照配置治理打算来执行。
参见《XXX项目配置治理打算》。
问题
<描述与当前版本有关的问题或之前一版本继承而来的问题>
列出项目初期任何其他已经发觉的问题，包括组间和谐、实验环境、工作场所等问题。
Sl.No
问题
责任人
状态（打开/关闭）
最早关闭日期
1
2
风险治理计划
依照风险治理规程来治理项目的风险。
祥见《XXX项目风险治理打算》。
在此详细说明项目的风险项、风险描述、风险级别、规避方法、应急打算、触发条件。
具体操作方法请参考风险评估和治理相关文档。
存在哪些技术、市场和财务风险？
已确认的风险和假设是不是已解决？
有无遗留问题？
有无新的风险和假设？
提供简练的风险治理打算。
为了减少风险，在各时期必需做些什么？
若是在打算的时刻范围内，这些风险不能解决，有无预备其它的打算？
若是没有这些风险，对项目会有哪些阻碍？
与产品包相关的各方面的风险包括：
市场/客户风险；
技术风险；
财务风险；
制造风险；
采购风险；
技术支持风险；
项目风险
客户的参与
Sl.No序号
在哪些方面（阶段、工作产品等）参与
期望客户承担的职责
最大响应时间
说明
1
2
3
4
培训计划
在本节中，明确说明相应人员现有的水平、需要的技术、培训方式和培训成效评估方式信息。
举例如下：
表10培训打算
No
培训领域
需要的技能水平
项目组成员
已具备的技能水平
培训方式
培训效果评估方式
1
2
3
导师打算也应包括在本培训打算中，该类打算在“培训方式”一栏需标识“导师培训”。
打算更新策略
在本节中，应描述项目打算的更新策略，明确说明项目打算更新的发布方式。
还要说明对项目打算进行变更操纵和治理的机制和其载体。
以下文字仅供参考：
在发生如下事件时，PM修订项目打算和参考文档：
抵达某里程碑，在每一个时期终止后若是必要的话修订项目打算。
项目的范围发生转变
当风险成为现实时采取了相应的行动
当进度、工作量超出操纵的范围并需要采取纠正行动时。
当与上时期规模转变超过+/-15%。
内部或外部审计致使的纠正活动
对修订后的项目打算依照项目治理规程来批准和签发。
项目打算的更新，存在时期驱动性更新和事件驱动性更新两种类型。
时期驱动性更新是指在每一时期终止时，若是打算或工作量估量的变更超过10％，就需要对项目打算进行更新；事件驱动性更新是指在打算执行进程中碰到项目突然变更或其他阻碍项目正常运行的事件发生，需要对项目的打算进行更新。
项目打算更新需要对打算文档更新和项目里程碑打算的更新。
不论是时期驱动性更新仍是时刻驱动性更新都需要对项目的更新打算进行评审，评审需要PDT领导、PQA和功能领域代表参加。
升级会员 