项目名称：
编 制 人：
日 期：
| 初版 | 日 期 | ||
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） | |||
在本节中，应描述需要交付给下游部门的工作产品及其需求。这些交付工作产品应包括各种设计文件、图纸、文档等。交付工作产品应分解成可管理的大小粒度。（这部分内容如在配置管理计划或文档计划中给出，则可以指出相关文档名称或者给予链接即可。）可以采用列表方式。
举例如下：
表3 项目交付工作产品
| 交付工作产品名称 | 产品描述 | 质量保证活动 | 验收标准 | 交付件形式 |
| 总体设计文档 | XXX项目XX总体设计方案 | 正规检视及评审 | 归档/发布 | 文档 |
| 详细设计文档 | XXX项目XX详细设计 | 归档/发布 | 文档 | |
| 归档/发布 | ||||
| 归档/发布 | 文档 | |||
| 归档/发布 | 文档 | |||
| 归档/发布 | 文档 | |||
| 归档/发布 | 文档 | |||
| …… | …… | …… | …… | …… |
项目计划
5.1 项目的里程碑计划
▪关键里程碑计划可采用图形方式。
将项目的所有里程碑和关键活动标注在下面的时间轴上。注意：如果存在早期功能子集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计划，请指出具体存放位置。
6.3软件调研详细计划
6.4软件设计详细计划
6.5软件开发详细计划
9.1实验设备和环境资源计划
详细描述在不同阶段对不同的环境的需求计划。如特殊的硬件平台、测试设备、软件工具等。标准的办公硬件不必在这里列。
举例如下：
表6 实验设备和环境资源计划
| 阶段 | 描述 | 数量 | 计划使用时间区段 | 说明 |
| 概念分析 | ||||
| 计划阶段 | ||||
| 开发阶段 | ||||
| 验证阶段 | ||||
12.1 项目过程定义
1）选择开发模型
开发类，增强类，维护类
2）并可在此基础上进一步流程裁剪：
提供与标准开发流程的偏差，并说明裁剪原因。
12.2 质量目标
可以定性或定量描述，为提高可控制性，尽量采用定量质量指标描述。
若能定量描述，请参考下表：
参考或直接引用项目度量表中质量目标部分的数据。
表9 项目质量目标
| NO. | 项目质量目标 | 目标 | 基线 （暂不填） | 上限 （暂不填） | 下限 （暂不填） | 说明 |
| 1 | 进度偏差率 | 80% | ||||
| 2 | 需求稳定性 | 90 | ||||
| 3 | 硬件第一次样机制作完成前缺陷发现数目 | <=3 | ||||
| 4 | 样机投板次数 | 20% | ||||
| 5 | 软件发布前缺陷发现密度 | |||||
| 6 | 编码缺陷发现密度 | |||||
| 7 | 硬件/软件总体设计缺陷发现数目 | |||||
| 8 | 硬件/软件详细设计缺陷发现数目 | |||||
| 9 | 需求更改/设计更改/工程更改数 | |||||
| 10 | 文档齐套性 | |||||
| 11 | 返修率 | |||||
| ...... | ||||||
通过哪些技术手段可以保证质量目标和关键性能指标的达成。
例如：通过静态代码分析工具和自动化软件测试工具可以有效提高软件质量。
12.4 质量控制活动
罗列执行的质量控制活动。
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 质量保证活动
罗列应该执行的质量保证活动。
举例如下：
12.5.1 内部审计
每个项目在开发生命周期中至少进行一次内部审计。
12.5.2 交付件审计(按阶段)
♦技术评审1之后
♦技术评审2之后
♦技术评审3之后
♦技术评审4之后
♦技术评审5之后
♦技术评审6之后
12.5.3 基线审计
规划在哪些阶段点需要进行基线审计。
♦技术评审1之后
♦技术评审2之后
♦技术评审3之后
♦技术评审4之后
♦技术评审5之后
♦技术评审6之后
项目沟通计划
14.1 项目组会议
列举项目跟踪、监控的会议类型、频率以及参加人员，可以采用列表形式。
参考下例：
表7 项目组会议
| No | 会议 | 频度 | 参加人 | 跟踪机制 |
| 1. | 阶段结束会议 | |||
| 2. | 项目总结会议 | |||
| 3. |
列举项目跟踪、监控过程中需要出示的报告类型、频率、报告人、汇报人信息。
参考下例：
表8 项目报告机制
| No. | 报告 | 准备人 | 频度 | 向谁汇报 |
| 1. | 项目状态报告 | |||
| 2. | 项目阶段结束报告 | |||
| 3. | 项目总结报告 | |||
| 4. |
项目的配置管理活动应该按照配置管理计划来执行。参见《XXX项目配置管理计划》。
问题
<描述与当前版本有关的问题或从前一版本继承而来的问题>
列出项目初期任何其他已经发现的问题，包括组间协调、实验环境、工作场所等问题。
| Sl. No | 问题 | 责任人 | 状态（打开/关闭） | 最早关闭日期 |
| 1 | ||||
| 2 |
按照风险管理规程来管理项目的风险。祥见《XXX项目风险管理计划》。
在此详细说明项目的风险项、风险描述、风险级别、规避措施、应急计划、触发条件。具体操作办法请参考风险评估和管理相关文档。
存在哪些技术、市场和财务风险？
已确认的风险和假设是否已解决？有无遗留问题？
有无新的风险和假设？
提供简洁的风险管理计划。为了减少风险，在各阶段必需做些什么？如果在计划的时间范围内，这些风险不能解决，有没有准备其它的计划？
如果没有这些风险，对项目会有哪些影响？
与产品包相关的各方面的风险包括：
市场/客户风险；
技术风险；
财务风险；
制造风险；
采购风险；
技术支持风险；
项目风险
客户的参与
| Sl. No序号 | 在哪些方面（阶段、工作产品等）参与 | 期望客户承担的职责 | 最大响应时间 | 说明 |
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 |
在本节中，明确说明相应人员现有的水平、需要的技能 、培训方式和培训效果评估方式信息。
举例如下：
表10 培训计划
| No | 培训领域 | 需要的技能水平 | 项目组成员 | 已具备的技能水平 | 培训方式 | 培训效果评估方式 |
| 1 | ||||||
| 2 | ||||||
| 3 | ||||||
计划更新策略
在本节中，应描述项目计划的更新策略，明确说明项目计划更新的发布方法。还要说明对项目计划进行变更控制和管理的机制以及其载体。以下文字仅供参考：
在发生如下事件时，PM修订项目计划和参考文档：
到达某里程碑，在每个阶段结束后如果必要的话修订项目计划。
项目的范围发生变化
当风险成为现实时采取了相应的行动
当进度、工作量超出控制的范围并需要采取纠正行动时。
当与上阶段规模变化超过+/-15%。
内部或外部审计导致的纠正活动
对修订后的项目计划按照项目管理规程来批准和签发。
项目计划的更新，存在阶段驱动性更新和事件驱动性更新两种类型。阶段驱动性更新是指在每一阶段结束时，如果计划或者工作量估计的变动超过10％，就需要对项目计划进行更新；事件驱动性更新是指在计划执行过程中遇到项目突然变动或者其他影响项目正常运行的事件发生，需要对项目的计划进行更新。
项目计划更新需要对计划文档更新和项目里程碑计划的更新。
不论是阶段驱动性更新还是时间驱动性更新都需要对项目的更新计划进行评审，评审需要PDT经理、PQA以及功能领域代表参加。
Copyright © 2019-2025 51dongshi.net 版权所有
违法及侵权请联系：TEL:177 7030 7066 E-MAIL:11247931@qq.com 本站由北京市万商天勤律师事务所王兴未律师提供法律服务
