软件项目文档管理与版本控制的初步报告

软件项目文档管理与版本控制的初步报告

一、现阶段的问题：

版本与文档管理中常见或可能存在的现象：

Item 1. 项目的逻辑结构不严谨

Item 2.多人修改同一个文件

Item 3.用户权限混乱或无权限控制

Item 4.上传文档的命名随意

Item 5.从服务器上获取最近版本时的疏忽

二、文档与版本管理衡量标准：效率与质量（软件的一致性、冗余程度等）

三、解决方向：

1、项目文档、文件夹结构化分类管理

2、文档命名规范化

3、操作权限控制

4、注意服务器唯一有效版本，本地备份辅助

四、初步解决办法

创建文档储存库，基于工具的资料库或是一个共享目录里建立的简单的“文件夹/文件”结构。

1、管理范围：开发库、项目文档、产品库、构建库

1）开发库包括：A、源代码B、执行程序

2）文档管理：

A、项目文档包括——可行性研究报告(愿景)，项目开发计划(立项)，需求(说明书)，

评审，软件设计说明书，开发进度月报，测试，相关开发文档，参考资料，文档模板，用户（操作）手册，项目开发总结报告

B、相关设备

C、参考资料（开发人员与客户会谈的材料，参考文献，项目结束归档时电子邮件

3）产品库

2、建立规范的目录体系

目录体系结构图如下：

3、版本与文档命名规则

1）版本V1.0至版本V2.0之间可少设过渡版本，变更量积累之一定量或阶段之后再进行版本变更。对于计划性文档、技术文档和用户文档，其版本按修改的先后顺序确定，新生成的文档第一次发行是第一版，修改后第二次发行是第二版，以此类推。

2）建立规范的文档与版本命名规则，文档控制级别为中、低的文档是不需要进行版本控制的，这些文档大都是临时性的、一次性的、中间性的文档，比如：需求调研报告，会议纪要，项目报告等。文档控制级别为高的文档要进行版本控制。如：用户需求说明书，概要设计说明书，用户手册等，无论修改有多少次，都要求留版本记录，尤其是项目产品。

①控制级别高的文档命名：

《项目编号_文档名与版本号_日期_作者》，

如《SPMS_需求说明书V1.0_YYMMDD_李明》

②控制级别为中、低的文档命名：

《项目编号_文档名_日期_作者》，如《SPMS_第六周问题报告_YYMMDD_李明》

3）最终完成的软件版本用二位符号表示：“ s.xy”，含义如下：

①“ y ” 为第二次版本号，表示纠正错误时的版本升级，用一位数字表示：“ 1-

9 ” 对上一次产品或项目的缺陷做修正，第二次版本号增加；

②“ x ” 为第一次版本号，表示增加功能时的版本升级，用一位数字表示：“ 1-

9 ” ，与上一产品或项目相比，功能进行了小量的增加或修正时，第一次版本号增加，第二次版本号为零，第二版本号为零时可以省略不写；

③“ s ” 为主版本号，用一位数字表示：“ 1-9 ” ，对产品作重大调整，或与已发行的上一产品相比，在功能与性能上有较大改善时主版本号增加，次版本号为零，产品或项目概念全新，第一次完成，版本号为1.0。

4、人员职责与维护、更新

文档管理的人员可以由一个或多个团队成员兼职担任，有经验最好，职责包括：

建立、管理和执行文档标准并监控它们的状态；

确认并解决文档库中存在的问题；

确定对哪些文件进行存档或对哪些旧文件（如每周的状态情况报告在三个月以后可能就会作废）进行定期、阶段性的清理；

创建资料库的访问规则、权限；

定期对资料库进行检查，并对文档管理流程进行评估，应当确保文档管理流程工作正常而且符合公司、项目组和利益相关方的需求；

5、关于项目开发与测试等其他人员，同样需要注意文档提交、更新、维护等的规范，建议如下：

1）开发和测试人员在提交相关文档后，自己应有备份。

2）软件开发和测试人员可根据工作需要在自己手中保存一些个人文档。这些一般应是主文本的副本，并注意和提交的主文本保持一致，在作必要的修改时，也应及时通知文档管理人员。

3）在新文档取代旧文档时，管理人员应及时清理旧文档。在文档内容有改动时，管理人员应随时修订主文本，使其及时反映更新了的内容。

4）项目开发结束时，文档管理人员应及时收集开发和测试人员的个人文档。发现个人文档与主文本有差别时，应立即着手解决。这常常是未及时修订主文本造成的。

5）在软件开发过程中，可能发现需要修改已完成的文档，特别是规模较大的项目，主文本的修改必须特别谨慎。修改以前要充分估计可能带来的影响，并且要按照：提议、评议、审核、批准和实施等的步骤加以严格控制。

其他建议：

1）版本控制管理可包括工具软件的使用和人为规范的遵循——有控制意识、对工具的熟练使用，认为的良好习惯，和规范的制度的保证。

2）版本控制管理员——设置一人或数人兼顾此角色，没必要是全职，保证安全性问题，控制认为任意操作。

3）向版本控制过渡时一个循序渐进的、持久的过程——需要逐步转变，制订一系列的循序渐进的措施，使版本控制的意识逐步得到认可，使人员逐渐养成良好习惯。

4）分为开发库、文档库、产品库、构建库，这四个库分别是独立的单库，版本不相互影响。

开发库下项目一的相对路径为：/dev/pro1，在pro1下为该项目的具体源码结构树；

文档库下项目一的相对路径为： /doc/pro1，在pro1下为该项目的文档树结构（包括且不限于项目立项、项目结项、项目计划、项目监控、风险管理、配置管理...），相应的文档放入到相应的文件夹中；

构建库下项目一的相对路径为:/db/pro1，在pro1下为该项目不同时期的构建版本（格式：项目缩写_阶段_主版本.次版本.修订版本-YYYYMMDD.后缀名）；

产品库下项目一的相对路径为：/pd/pro1，在pro1下为该项目不同时期的基线发布，如1.0基线包括的所有发布内容（交付文档和源码）统一保存在/pd/pro1/1.0/路径中。