配置开发库文档的命名表

做为项目组的人员比较关心一下几个问题：

1. 按照CMMI3的标准，项目组要提交到SVN的文件清单（识别配置项）。
2. 每个文件的命名规范，比如：封面和修改记录中的版本命名规则。在SVN库中应该如何使用？

1. 到底是《XXXX项目用户需求说明书v0.2》还是《XXXX项目_用户需求说明书V0.2》?
2. 文档传到SVN库中，到底是《XXXX项目用户需求说明书V0.1》还是《XXXX项目用户需求说明书》？
3. 一个500页的《概要设计说明书》，能不能拆成若干模块进行撰写？如果可以拆成不同模块撰写，那么如何命名？比如《概要设计说明书_模块1》；如果拆分成了不同的模块撰写，设计基线应该包括哪些内容？

1. 项目配置库的命名要求是什么？中文命名、英文首字母缩写、拼音首字母缩写？如果第三方自己管理配置库，而且使用了旧的配置库，那么应该如何管理？是否要建立单独的统一配置库？
2. 有哪些基线？基线是如何命名的？不同的产品有不同的基线，如何保持各个产品集成时，版本能够保持一致？
3. 配置库的地址是什么？配置库的目录结构和人员权限是怎么样的？
4. 项目有哪些基线？每个基线命名规则是什么？什么时候应该打基线？打完基线怎么通知项目组？
5. 配置审计什么时候做？多久做一次比较合适？发现的问题应该怎么处理？
6. 需求变更，如果引起了项目进度、成本变更应该如何处理项目计划？
7. 测试阶段需求变更，如果引起了需求规格说明书的变更、设计说明书的变更、代码变更，应该如何处理？
8. 版本发布应该如何操作？比如：多久发布一次？项目组发布程序，应该有哪些配套的文档做运维？版本的命名规则和方法是什么样子的？发布以后应该通知谁？
9. 体系文件因为不停的修订，如何保证每个EPG成员及时修改了自己的版本？如何保证各个参与体系建设的人员都知道体系文件的版本发生了修订和变更？如何发布基线版本？
10. 不同的项目组先后拿到的是体系文件不同的基线版本，应该如何保持体系文件的版本不混乱？最新版可用，还是使用最稳定的版本？如何保证QA检查时，项目组使用的不同版本的模板都可以通过检查？