jmsjjyl@com 1 引言1.1 文件目的1.2 文件范围2 项目概述3 项目组织结构4 项目依赖性分析5.1 项目关键路径分析和安全措施5.2 项目依赖性分析5.3 项目关键成功因素5.3 技术方法和工具5 可交付成果6 项目计划6.1 项目里程碑计划6.2 项目WBS计划（高层计划） 7 人员和技能要求8 项目所需的其他资源9.1 主要材料需求计划9.2 实验室设备和环境资源计划9 数据开发计划10 外部合作计划11 外包任务10.1 分包商信息10.2 外包任务范围10.3 里程碑、可交付成果12 预算/分配（可选） 13 批准标准（可删除） 14 质量计划（单独记录） 12.1 项目流程的定义12.2 质量目标12.3 通过技术手段保证质量12.4 质量控制活动12.5 质量保证活动15 项目沟通计划14.1 项目团队会议14.2 项目报告机制16 项目重用计划15.1 现有重用组件15.2 新的可重用组件17 配置管理计划18 问题19 风险管理计划20 客户参与21 培训计划22 计划更新策略
1 引言1.1 文件目的本节应解释文件的目的并确定目标受众。
1.2 文件范围表明项目计划的范围并阐明文件包括的内容。
本产品项目必须完成的工作活动和工作目标、项目采用的生命周期、项目可交付成果、相关人员的角色和职责、主要里程碑、进度计划、质量计划、配置管理计划，简要说明您的风险计划。 ETC
2 项目概述简要描述项目类型（新产品/改进/维护）、项目目的、范围和目标（例如项目市场地位、产品需求等）。
3 项目组织结构PDT组织结构图
PDT及系统分析设计组成员、产品开发成员的建议
在决策审查点之前，将这些列表的结果传达给相应的PRB 成员和相关资源部门经理。
描述项目的组织结构。我们建议使用图表。
您还可以参考以下示例：
下表定义了项目成员的角色和职责。 l 项目经理必须在审查之前指定所有文档和代码的审查者。 l 可以根据项目的实际情况添加各个角色的职责定义。 l 下表应至少在项目每个阶段结束时更新。
对于项目期间或阶段之间发生的组织结构变更，项目经理必须通过电子邮件通知所有相关人员并更新项目计划。表4 项目组织结构
4 项目依赖性分析5.1 项目关键路径分析及安全措施本节分析影响项目进展的主要步骤/环节和关键因素，并提出安全措施建议。
5.2 项目依赖关系分析本节描述项目的内部依赖关系（如开发和测试工具、人力资源等）和外部依赖关系（如项目之间以及与客户之间的技术和资源）。
可用依赖项列表、活动网络图的方法描述。
列出影响项目计划的所有假设（相对于已知因素）。如果这些假设不正确、未被使用或发生变化，项目就会受到影响。另外，如果你的项目是整个更大系统的一部分，可能需要其他部分提供接口定义，或者PDT可能在开发过程中提供模拟性能测试工具来替代真实环境测试项目对外部因素的依赖关系，例如。这样的。
请参阅以下示例。 表1 项目依赖关系
5.3 项目成功的关键因素5.3 技术方法和工具本节介绍开发方法、组织结构，并讨论其他指标。项目、工具、技术和方法。此外，还应直接或参考其他文件对所使用的技术标准、政策和流程进行解释。
参考以下示例，下表列出了生产项目所需的硬件、软件以及其他工具和设备。 表2 技术方法和工具
5 可交付成果本节描述必须交付给下游部门的工作产品及其要求。这些交付成果应包括各种设计文件、图纸、文件等。工作产品的交付应分解为可管理的粒度。 （如果这部分内容在配置管理计划或文档计划中，可以指出相关文档名称或提供链接。）可以使用列表。
一个例子是： 表3 项目实施工作成果
6 项目规划6.1 项目里程碑规划 主要里程碑规划可以采用图形形式。请在下面的时间表上标记该项目的所有里程碑和主要活动。注意：如果有早期功能子集测试版和/或ESP 可交付成果，PDT 必须对可交付成果进行TR4A/TR5 审核，并对GA 层中的产品可交付成果进行TR4A 和TR5 审核。在PDT中，不必为每个组件标记TR4；标记第一个TR4的日期就足够了。如果您需要标记所有里程碑和主要活动，请将您的时间表划分为如上所示的阶段。
里程碑计划也可以按照以下示例格式编写：表5 项目里程碑计划
6.2 项目WBS计划（上层计划）参见项目WBS计划。请指定具体的存储位置。
6.3 软件详细规划
6.4 硬件详细规划
6.5 结构详细规划
7 才能和技能要求 您还可以使用以下表格格式。
列出项目所需的人员和技能要求
为项目组成员提供可能影响项目进度的技能要求，如CPU应用技能、VxWorks BSP技术等。
8 项目所需其他资源9.1 关键材料需求计划详细说明各阶段关键材料的需求计划。
《关键物料需求计划》可单独成型。
或可单独组成《供应商物料选择计划》
您还可以使用下表。 表6 主要物资需求计划
注：项目组必须充分预估每种材料的采购周期，主动向关键点的采购下达采购需求。
增加提前采购和供应商选择
预购计划模板：参见《新物料提前采购清单》。有些材料可以从此表中复制。
项目组必须在首次量产前对所有材料（包括工程样机、中试样机、首次量产）进行规划，并根据数量和时间提出后续量产和市场规划的建议。
9.2实验设备与环境资源规划详细介绍了不同阶段各种环境的需求规划。专业硬件平台、测试设备、软件工具等标准办公硬件无需在此列出。
示例如下。 表6 实验设备及环境资源规划
9 数据开发计划表7 数据开发计划
10 外部协作计划是需要外部协作的部分清单，参考总体设计文件《委托响应规范》。
描述合作细节及进展情况。
11 外包任务本节仅适用于您的项目有外包的情况。
11.1 分包商信息11.2 工作范围是指委托给分包商的项目工作内容，可以用功能、要求、模块等形式表达。
11.3 里程碑和可交付成果表示分包商经过协商确定的里程碑和可交付成果。
12 预算/分配（可选） 估算产品预算和分配
讨论重要的未解决问题，例如资金的及时性和性质。将实际日期的项目资源、成本和时间安排与整个项目的估计资源、成本和时间安排进行比较。
13 验收标准（可删除） 客户的验收标准是产品满足需求规范中列出的要求。系统测试和验收测试确保产品符合要求的规格。
请在此处注明您的客户特定的接受标准。验收标准基于客户需求，应由客户制定，并在必要时得到项目团队的支持。可交付的属性包括质量目标、测试标准、如何处理验收后发现的缺陷、文档等。
14 质量计划（可以是单独的文档） 12.1 定义项目过程1） 选择开发模型的开发类、扩展类和维护类。 2）在此基础上可以进一步调整流程。
指出与标准制定过程的任何偏差并解释减少的原因。
12.2 质量目标可以定性或定量描述为了提高可控性，应尽可能使用定量质量指标描述。
如果可以定量地解释的话，请参考下表。
直接引用或引用项目指标表的质量目标部分的数据。
表9 项目质量目标
12.3 通过技术措施保证质量采用哪些技术措施来保证质量目标和关键绩效指标的实现？例如，静态代码分析工具和自动化软件测试工具可以有效提高软件质量。
12.4 质量控制活动列出所执行的质量控制活动。
12.4.1 技术评审活动产品开发过程中需要哪些技术评审活动以及可以组合哪些技术评审点？ 为每个技术评审点定制评审要素的描述：技术评审1和技术评审2以整合评审TR1 和TR2 的要素，并重点关注审查要素。和。方面元素可以省略。技术评审3TR3评价因素需要调整，评价因素需要突出重点。和。方面元素可以省略。技术审查4TR4的评价要素无需削减。技术回顾5TR4的评测要素无需删减。
12.4.2 正式检查活动（同行评审） 产品开发过程中正式检查活动应设定哪些输出？ 软件模块测试计划软件总体设计软件代码软件测试报告硬件总体设计硬件电路图和PCB 图硬件测试报告
12.4.3 测试测试策略和测试活动描述：也可纳入文档《产品测试与验证计划》。 l 您可以组合和协调测试活动。例如，您可以组合扩展项目、集成测试和系统测试。 l 单元测试测试质量目标测试依赖分析测试停止标准集成测试测试质量目标测试依赖分析以测试为中心的回归测试策略测试停止标准系统测试测试质量目标测试依赖分析以测试为中心的回归测试策略
12.5 质量保证活动列出要执行的质量保证活动。
一个例子是：
12.5.1 内部审核每个项目在其开发生命周期中将至少接受一次内部审核。
12.5.2 可交付成果审核（分阶段） 技术审查后1 技术审查后2 技术审查后3 技术审查后4 技术审查后5 技术审查后6
12.5.3 规划基线审核在哪个阶段需要进行基线审核？技术审查后1 技术审查后2 技术审查后3 技术审查后4 技术审查后5 技术审查后6
15 项目沟通计划15.1 项目组会议列出项目跟踪和监控会议的类型、频率和参与者。
请参阅以下示例。 表7 项目组会议
15.2 项目报告机制列出了项目跟踪监测过程中必须生成的报告类型、频率、报告者以及报告者信息。
请参阅以下示例。
表8 项目报告机制
16 项目的重用规划需要分析该产品如何与公司的其他产品重用以及该产品是否可以与公司的其他产品共享和重用。可以直接链接或解释相应的文档。这里。
15.1 现有的可重用组件15.2 新的可重用组件注意：重用资源库中已有的组件
2 项目生成的新的可重用组件
17 配置管理计划项目的配置管理活动必须根据配置管理计划进行。参见《XXX项目配置管理计划》。
18 问题描述与当前版本相关或以前版本遗留的问题
列出项目早期阶段发现的任何其他问题，包括小组之间的协调、实验环境和工作场所等问题。
19 风险管理计划根据风险管理程序管理项目风险。享健《XXX项目风险管理计划》。
本节详细介绍项目风险项目、风险描述、风险级别、解决方法、应急计划和触发条件。具体操作方法请参见相关风险评估和管理文件。
存在哪些技术、市场和财务风险？
已确定的风险和假设是否已得到解决？是否还存在任何问题？
是否有任何新的风险或假设？
提供简明的风险管理计划。如果这些风险无法在计划的时间内得到解决，每个阶段必须采取哪些措施来降低风险？
如果没有这些风险，会对项目产生什么影响？
与产品包装相关的风险包括：
市场/客户风险。
技术风险。
财务风险。
创造风险。
采购风险。
技术支持风险。
项目风险
20 客户参与21 培训计划明确说明相关人员目前的水平、所需技能、培训方法以及如何评估培训效果。一个例子是： 表10 培训计划
该培训计划还必须包括指导计划，并且该计划必须在“培训方法”栏中标记为“指导员培训”。
22 计划更新策略本节介绍了项目计划更新策略，并清楚地展示了如何发布项目计划更新。它还描述了项目计划变更控制和管理的机制和手段。以下文字仅供参考。
当发生以下事件时，项目经理将修改项目计划和支持文件：
达到特定的里程碑并在每个阶段后根据需要修改项目计划。
项目范围变更
当风险发生时采取适当行动
当进度和工作量超出控制限制并需要采取纠正措施时。
如果与前一阶段的尺寸变化超过15%。
内部或外部审计产生的纠正措施
修改后的项目计划按照项目管理程序批准并公布。
项目计划更新有两种类型：阶段驱动更新和事件驱动更新。阶段驱动的更新意味着在每个阶段结束时，如果计划或工作量估算变化超过10%，则必须更新项目计划。事件驱动的更新是指当项目突然发生变化或者项目执行时必须更新项目计划。在计划执行期间，会发生其他影响项目正常运行并需要更新项目计划的事件。
更新项目计划需要更新规划文件和更新项目里程碑计划。
无论是阶段驱动更新还是时间驱动更新，项目更新计划的审核都需要PDT经理、PQA和功能区代表的参与。
