PRD产品开发综合项目文档管理标准规范.doc

产品开发项目文档管理规范

文档编号：COSHIP-CMMI-PRD-PDPDM
密级：机密
版本信息：1.8
同意日期：

编辑软件：Microsoft Word Microsoft Visio

同洲电子股份 版权全部
内部资料 注意保密

文档修订统计
序号
版本编号
改变状态
变更（+/-）说明
作者
日期
1
V1.0
C

2
V1.5
M
依据实际情况进行优化阶段代号和文档密级等
王岩
-11-9
3
V1.8
M
依据评审意见进行修改
王岩
-11-20

*改变状态：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.3 PPQA 4
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
项目计划书
项目经理

12 1
质量确保计划
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.3 PPQA
PPQA关键工作为：
1） 对文档作者提供文档进行编号。
2） 检验项目各阶段文档计划实施情况，确保文档三级审核制度得到实施直至最终归档。
3） 对文档进行规范性审查。
4） 依据文档计划，组织评审组对文档进行评审。
5） 确定项目经理定义文档密级，并确保文档保密性得到有效控制。
4.4 配置管理工程师
将评审经过或是部门经理审核经过文档纳入基线管理，依据密级确定对应权限。
4.5 评审组
对需要评审文档（可行性研究汇报、项目计划书、需求规格说明书、概要设计书等）内容进行质量把关。
4.6 部门经理
文档作者所属部门部门经理对不需评审文档进行最终审核。
5 文档审核步骤
对每一份文档要求在纳入基线前，从项目经理、PPQA、部门经理或评审组，进行三级审核，这么，分别从文档质量完备性、正确性、可读性、简明性、规范性、可追溯性等方面进行分层把关，并最终签字确定其文档质量合格。
产品开发项目标文档管理层次结构图1所表示：

评审组

部门经理

PPQA

项目经理

文档作者

图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(Quality Assurance)
配置管理计划
P(Planning)
CM(Configuration Management)
进度计划
P(Planning)
S(Schedule)
设计
软件概要设计说明书
PD(Preliminary Design)
SW(Software)
硬件概要设计说明书
PD(Preliminary Design)
HW(Hardware)
结构概要设计说明书
PD(Preliminary Design)
ST(Structure)
实现
软件具体设计说明书
IM(Implementation)
SW(Software)
单元测试计划书
IM(Implementation)
UP(Unit Testing Plan)
单元测试用例
IM(Implementation)
UC(Unit Testing Case)
单元测试汇报
IM(Implementation)
UR(Unit Testing Report)
产品集成计划
IM(Implementation)
IP(Integration Plan)
集成测试计划书
IM(Implementation)
TP(Testing Plan)
接口说明书
IM(Implementation)
I(Interface)
集成测试用例
IM(Implementation)
TC(Testing Case)
集成测试汇报
IM(Implementation)
TR(Testing Report)
验证
系统测试计划书
V(Validation)
TP(Testing Plan)
系统测试用例
V(Validation)
TC(Testing Case)
产品缺点列表
V(Validation)
BL(Buglist)
认证性测试汇报
V(Validation)
AT(Authentication Testing)
系统测试汇报
V(Validation)
TR(Testing Report)
公布
验证测试汇报
RL(Release)
V(Validation)
回归测试汇报
RL(Release)
TR (Regression Testing Report)
缺点汇报
RL(Release)
BL(Buglist)
用户使用文档
RL(Release)
U(User)
交付结项
项目总结汇报
PF（Project Finish）
R(Report)
项目结项表单
PF（Project Finish）
L（List）
系统测试汇报
PF（Project Finish）
TR(Testing Report)
产品缺点列表
PF（Project Finish）
BL(Buglist)

8 文档版本
版本编号由2位数字组成，以“.”来分割。
格式为：×.×

主版本 副版本
比如：V3.1表示：主版本为3，副版本为1，开发文档初始版本为V1.0。
具体请参见《PRD-版本管理规范》。