8A版PRD产品开发项目文档管理规范.docx
《8A版PRD产品开发项目文档管理规范.docx》由会员分享，可在线阅读，更多相关《8A版PRD产品开发项目文档管理规范.docx（15页珍藏版）》请在冰豆网上搜索。
8A版PRD产品开发项目文档管理规范
产品开发项目文档管理规范
文档编号：
COSHIP-CMMI-PRD-PDPDM
密级：
机密
版本信息：
1.8
批准日期：
编辑软件：
MicrosoftWord20XXMicrosoftVisio20XX
同洲电子股份有限公司版权所有
内部资料注意保密
文档修订记录
序号
版本编号
变化状态
变更（+/-）说明
作者
日期
1
V1.0
C
20XX年
2
V1.5
M
根据实际情况进行优化阶段代号和文档密级等
王岩
20XX-11-9
3
V1.8
M
根据评审意见进行修改
王岩
20XX-11-20
G变化状态：
C――创建，A——增加，M——修改，D——删除
文档审批信息
版本
过程改进组（EPG）审核
会签
批准
备注
1概述1
1.1目的1
1.2适用范围1
2产品开发文档体系1
3文档质量的度量准则3
4主要角色和职责3
4.1文档作者3
4.2项目经理4
4.3PPQA4
4.4配置管理工程师4
4.5评审组4
4.6部门经理4
5文档审核流程5
5.1审核流程5
5.2归档签名6
5.3纳入基线6
6文档保密制度7
7文档编号7
7.1文档编号规则7
7.2阶段代号8
8文档版本9
1概述
1.1目的
规范公司产品开发项目的文档体系，加强文档的标准化管理。
1.2适用范围
公司内所有产品开发项目。
2产品开发文档体系
在产品开发项目开发过程中，各阶段都有相应的文档输出，文档的编写应先于或同步于开发工作。
产品开发项目过程中的文档体系如表1所示。
表1.产品开发项目文档体系
序号
文档名称
文档作者
备注
立项
1
可行性研究报告
项目经理
2
产品规格书
项目经理
3
立项报告
项目经理
需求
4
系统需求规格说明书
需求分析师
5
软件需求规格说明书
软件工程师
6
硬件需求规格说明书
硬件工程师
7
结构需求表
结构工程师
8
电源需求规格说明书
电源工程师
9
需求管理矩阵
项目经理
计划
10
系统总体设计说明书
系统设计师
11
项目计划书
项目经理
121
质量保证计划
PPQA
13
配置管理计划
配置管理工程师
14
进度计划
项目经理
设计
15
软件概要设计说明书
软件工程师
16
结构概要设计说明书
结构工程师
17
硬件概要设计说明书
硬件工程师
实现
18
软件模块详细设计说明书
软件工程师
19
单元测试计划
软件工程师
20
单元测试用例
软件工程师
21
单元测试报告
软件工程师
22
电路原理图
硬件工程师
23
PCB设计图
PCB设计工程师
24
结构图纸
结构工程师
25
BOM
硬件工程师
研发BOM
26
产品集成计划
项目经理
27
集成测试计划
项目经理
28
接口说明书
软件工程师
29
集成测试用例
软件工程师
30
集成测试报告
软件工程师
验证
31
系统测试计划
测试工程师
32
系统测试用例
测试工程师
33
产品缺陷列表
测试工程师
34
认证性测试报告
测试工程师
研发中心出具
35
系统测试报告
测试工程师
发布
36
验证测试报告
认证代表
37
回归测试报告
测试工程师
38
缺陷报告
测试工程师
39
用户使用文档
技术资料工程师
交付结项
40
项目总结报告
项目经理
41
项目结项表单
项目经理
42
系统测试报告
测试工程师
43
产品缺陷列表
测试工程师
3文档质量的度量准则
评审文档质量的度量准则有以下六条：
完整性：
所承担产品开发任务的项目组，需按照公司文档体系的规定编写相应的文档，以保证在项目结束时其文档是齐全的。
正确性：
在项目各个阶段所编写的文档的内容，必须真实的反映阶段的工作且与该阶段的需求相一致。
文档与所述的对象保持一致，必要时应进行实时的文档版本升级。
可读性：
文档应该表达清晰、逻辑条理分明、表现形式通用。
简明性：
在项目各个阶段所编写的各种文档的语言表达应该准确简练。
规范性：
文档的规范性是指采用当前最新的模板。
其完整性及内容的充实程度应不低于模板的要求。
可追溯性：
在项目各个阶段所编写的各种文档应该具有良好的可追溯性。
由于各开发阶段编制的文档与各阶段完成的工作有着密切的关系，前后阶段生成的文件，随着开发工作的逐步扩展，具有一定的继承关系。
在一个项目各开发阶段之间提供的文件必定存在着可追溯的关系。
4主要角色和职责
4.1文档作者
文档作者包括公司内的项目组成员以及外协人员。
文档作者在文档方面的主要工作为：
1）在项目开发过程的各个阶段中，按照规定及时地完成项目文档的编写工作，文档作者有责任保证文档编写与开发同步。
2）文档作者不仅要审核文档字面上有无错漏，还要审核所陈述的技术内容是否精确，及表达方式上是否清晰易懂。
文档作者对文档的正确性、可读性和规范性全面负责。
3）文档作者保证所编写的文档与所描述的对象保持很好的一致性，必要时及时更新文档，便于以后维护工作和后续开发工作的开展。
4.2项目经理
项目经理是控制文档准确性的关键环节，项目经理与文档作者一起构成文档正确性的直接责任人。
项目经理在文档方面的主要工作为：
1）项目经理制定整个项目的文档计划（包含在项目计划中），并督促落实文档计划的实施。
2）负责对技术内容正确性的检查并校对文档内容与所述对象最新版本是否保持一致。
3）定义项目文档的密级。
4.3PPQA
PPQA的主要工作为：
1）对文档作者提供的文档进行编号。
2）检查项目各阶段文档计划的执行情况，确保文档的三级审核制度得到执行直至最后归档。
3）对文档进行规范性审查。
4）根据文档计划，组织评审组对文档进行评审。
5）确认项目经理定义的文档密级，并确保文档的保密性得到有效控制。
4.4配置管理工程师
将评审通过或是部门经理审核通过的文档纳入基线管理，根据密级确认相应的权限。
4.5评审组
对需要评审的文档（可行性研究报告、项目计划书、需求规格说明书、概要设计书等）的内容进行质量把关。
4.6部门经理
文档作者所属部门的部门经理对不需评审的文档进行最终审核。
5文档审核流程
对每一份文档要求在纳入基线前，从项目经理、PPQA、部门经理或评审组，进行三级审核，这样，分别从文档质量的完备性、正确性、可读性、简明性、规范性、可追溯性等方面进行分层把关，并最后签字确认其文档质量合格。
产品开发项目的文档管理层次结构如图1所示：
图1文档管理层次结构
5.1审核流程
产品开发项目文档在归档前均要经过多级审核，各审核一般都对应到文档封面的签名。
文档的审核归档流程如图2所示。
图2文档的审核流程
5.2归档签名
开发阶段文档在纳入基线之前需要经过三级审批，包括文档作者在内共四级签名：
Ø文档作者：
为文档的主要思想提供者和写作者。
如果有多人参与，则记录主要人员。
Ø项目经理：
为在立项评审时指定的项目负责人。
Ø审核：
PPQA。
Ø批准：
如果此文档需评审，则批准人为评审组长；否则为文档作者所属部门的部门经理。
5.3纳入基线
产品开发项目文档在经过三级审批通过后，由配置管理工程师纳入基线进行管理。
6文档保密制度
为确保产品开发项目文档的安全性，防止技术资料的外泄以及维护公司的权益，对每种文档还应划定它们各自的保密级别。
每份文档的密级原则上根据其所含技术的保密要求以及产品进入市场的程度，由项目经理负责指定。
文档是按照与开发同步的原则写作，所以大多数文档在第一次纳入基线时，其密级一般为“机密”，然后随着产品的逐渐成熟，其保密程度会逐渐放开，所以每份文档的密级标志是动态的。
纳入基线后的文档密级若需要改变，可由项目经理提出申请，配置管理工程师责对文档所在配置库重新分配权限。
文档密级共分为四级：
Ø绝密：
指只有极少数人可以查阅的文档。
如：
核心技术的文档、预研项目的文档等。
此类文档应严格保密，配置库权限一般只分配给研发领导指定人员，须签订保密协议。
Ø机密：
指只有项目组的人可以查阅的文档。
如：
《软件概要设计说明书》、《硬件概要设计说明书》等。
对此类文档，配置库权限分配给项目组成员，其他人如需申请权限，需经项目经理批准。
Ø普通：
指在公司范围内开放的文档。
如：
《产品规格》等。
此类文档可在公司范围内进行传阅。
Ø公开：
指对外开放的文档。
如：
《产品说明书》及相关宣传资料等。
对此类文档不做权限控制。
以上密级归类仅供参考，各项目经理应根据产品竞争策略需要等实际情况确定归入哪个密级，做到在保密基础上的资源共享。
7文档编号
文档以产品和项目为单位进行划分，对每篇文档根据其所属产品、项目和具体描述内容定义一个唯一的编号。
文档编号由PPQA分配。
注：
硬件原理图、PCB图、结构图纸、BOM等文件编码不在此编号范围内。
7.1文档编号规则
文档编号由五部分组成，各部分由‘-’分隔，其构成如下：
产品型号_项目编号_阶段代号_模块代号
对文档进行编号时，各组成部分最好都有对应的代号及含义。
如果不需区分模块，则以‘&’代替模块代号。
其中：
Ø产品型号：
一般对应于产品型号（外部型号）。
Ø项目编号：
所开发产品的项目编号。
Ø阶段代号：
此文档对应的项目阶段代号，请参见7.2。
Ø模块代号：
软件功能模块或硬件单板的缩写。
如：
新华社项目设计阶段的设计文档《MPE模块概要设计书》的文档标号为：
CDVB5110G_DC-P071114-21_PD.SW_MPE。
7.2阶段代号
阶段代号由2～4位英文字母和一位“.”字符表示，构成如下：
主阶段代号.子阶段代号
1～2位1～2位
例如，“可行性研究报告”文档对应的阶段编号为I.R,“系统测试计划”文档对应的阶段代号为SA.TP。
文档各阶段代号如表2所示。
表2.文档阶段代号
项目阶段
文档名称
主阶段代号
子阶段代号
立项
可行性研究报告
I（Initialization）
F（Feasibility）
产品规格说明书
I（Initialization）
S（Specification）
立项报告
I（Initialization）
R（Report）
需求
系统需求规格说明书
R（Requirement）
S（System）
软件需求规格说明书
R（Requirement）
SW（Software）
硬件需求规格说明书
R（Requirement）
HW（Hardware）
结构需求表
R（Requirement）
ST（Structure）
电源需求规格说明书
R（Requirement）
P（Power）
需求管理矩阵
R（Requirement）
M（Management）
计划
系统总体设计说明书
P（Planning）
SL（Solution）
项目计划书
P（Planning）
I（Integration）
质量保证计划
P（Planning）
QA（QualityAssurance）
配置管理计划
P（Planning）
CM（ConfigurationManagement）
进度计划
P（Planning）
S（Schedule）
设计
软件概要设计说明书
PD（PreliminaryDesign）
SW（Software）
硬件概要设计说明书
PD（PreliminaryDesign）
HW（Hardware）
结构概要设计说明书
PD（PreliminaryDesign）
ST（Structure）
实现
软件详细设计说明书
IM（Implementation）
SW（Software）
单元测试计划书
IM（Implementation）
UP（UnitTestingPlan）
单元测试用例
IM（Implementation）
UC（UnitTestingCase）
单元测试报告
IM（Implementation）
UR（UnitTestingReport）
产品集成计划
IM（Implementation）
IP（IntegrationPlan）
集成测试计划书
IM（Implementation）
TP（TestingPlan）
接口说明书
IM（Implementation）
I（Interface）
集成测试用例
IM（Implementation）
TC（TestingCase）
集成测试报告
IM（Implementation）
TR（TestingReport）
验证
系统测试计划书
V（Validation）
TP（TestingPlan）
系统测试用例
V（Validation）
TC（TestingCase）
产品缺陷列表
V（Validation）
BL（Buglist）
认证性测试报告
V（Validation）
AT（AuthenticationTesting）
系统测试报告
V（Validation）
TR（TestingReport）
发布
验证测试报告
RL（Release）
V（Validation）
回归测试报告
RL（Release）
TR（RegressionTestingReport）
缺陷报告
RL（Release）
BL（Buglist）
用户使用文档
RL（Release）
U（User）
交付结项
项目总结报告
PF（ProjectFinish）
R（Report）
项目结项表单
PF（ProjectFinish）
L（List）
系统测试报告
PF（ProjectFinish）
TR（TestingReport）
产品缺陷列表
PF（ProjectFinish）
BL（Buglist）
8文档版本
版本编号由2位数字组成，以“.”来分割。
格式为：
×.×
主版本副版本
例如：
V3.1表示：
主版本为3，副版本为1，开发文档初始版本为V1.0。
具体请参见《PRD-版本管理规范》。
升级会员 