在软件开发这个庞大而复杂的过程中，需求涉及到各方面的人员，信息的交流反馈不仅仅是研发小组成员之间及各个研发小组之间，还存在于客户与研发着之间。所有的这些交流反馈意见信息都有可能导致对软件的修改，小的可能只是对某个源文件中的某个变量的定义的改动，大到重新设计程序模块甚至可能是整个需求分析变动。在整个软件生命周期中，会形成众多的版本，但谁也不敢百分百保证不出现错误的修改。版本管理条例，不仅是对源代码的版本进行管理，而且还要对整个项目进行管理。

　公司很早就引进 Microsoft 公司的 Visual SourceSafe 6.0 （ VSS ）版本管理产品进行版本管理。但在使用过程中，存在一定的问题，特别是在项目处于维护阶段时的版本管理不尽人意，经常出现反复的问题。因此，在实行 VSS 上的管理的基础上，特制定企业方案事业部版本管理条例，重点是减少由于版本管理不善而造成的错误。

1. 开发阶段版本管理条例

　1.1数据库、源码和 jsp 页面的一致性问题
　在开发阶段，数据库、源码和 JSP 可能会有团队中不同的成员进行的修改，经常会出现不一致。必须严格执行如下规定：

1. 对涉及与其他共用的数据库、源码和 JSP ，除遵守项目组的约束外，必须在 check out 下的文件进行修改，并避免长时间不 check in ；

2. 对涉及与其他共用的数据库、源码和 JSP check out 、 check in 必须要有注释；

1.2 用户对需要的变更
　在得到用户签字确认的需求文档后，在开发阶段，对用户提出的需求，必须执行如下规定：

1. 修改工作量不大，用户提出的需求不会出现反复的情况下，尽量满足用户的要求，但必须有书面记录，并上传到 VSS 上；

2. 修改工作量较大，或者是工作量不大，但会容易出现反复，如进行修改，则必须得到用户负责人的签字确认或邮件确认，不管是否修改，都必须有书面记录，上传到 VSS 上，并打印到纸质文档中保管；

3. 对修改工作量大，除执行上面规定外，还必须用邮件等方式知会到项目经理、部门经理以及相关人员；

4. 对在后期提出的需求，涉及数据库或者源程序的大量修改，尽可能不作修改；

1.3 开业人员对需求的变更
　在得到用户签字确认的需求文档后，在开发阶段，如在技术上或者工作量等方面由开发人员提出的需求变更，必须执行如下规定：

1. 对在需求文档范围内，缩小需求范围的需求变更，必须得到用户负责人的签字确认或邮件确认，并形成文档，上传到 VSS 上

2. 对可能影响回款，用户验收意见等的需求变更，必须用户公章，还必须用邮件等方式知会到项目经理、部门经理以及相关人员；

2. 维护阶段版本管理条例

　2.1 维护管理必备资料
　项目在用户验收后，进行系统维护期，必须具备如下资料：

1. 由项目经理编写竣工资料；

2. 由项目尽量与测试组中共同编写维护规定；

3. 用户验收运行环境及数据库备份；

2.2 用户问题反馈
　用户反馈的问题，属于软件质量范围内的问题，统一提交到测试组中。对用户反馈的问题，必须执行如下规定：

1. 对确认的缺陷，必须按需求变更、完善系统方式进行分类， OA 问题、业务问题（可细分到子模块中），并记录到 XX 项目缺陷 .xls 的表“最新 BUG 报告”中，并上传到 VSS 上；

2. 测试组通知项目经理，项目经理从 VSS 上取“最新 BUG 报告”（强制要求行为），确认哪些内容是需要修改的，并在“最新 BUG 报告”上填写修改人，解决时间；对属 OA 问题，由项目经理整理到“ OA 缺陷提交报告”中，并与电子政务协调修改；

　2.3 修改人员管理
　为了避免同一个问题反复出现，源代码在经过多人修改后，无人相信 VSS 的局面，修改过程中必须如下规定：

1. 从 VSS 上获取用户最新的运行环境；

2. 对修改内容必须从 VSS 上 check out ；

3. 对不执行 check out 而造成的对他人修改的影响，罚款 100 元作为项目活动经费；

4. 缺陷修改完，必须将所修改的内容 check in 到 VSS 上，制定修改清单，清单中必须说明经编译后的类文件的路径；

5. 从新从 VSS 上获取最新的运行环境，根据修改清单对开发环境进行升级；

6. 将修改清单提交到测试组中；

2.4 测试组测试
　1. 在修改内容的文件夹下，建立以修改日期命名的文件夹；在修改结果的文件夹下，建立以修改日期命名的文件夹；

2. 根据清单，从 VSS 上取得相应的文件 ，并将写上当日修改日志，总的修改日志；

3. 利用 Ant 将 *.java 编译成 *.class 文件；

4. 将 *.class ，将文件复制到 jar 包及 classess 的目录下，将其他文件复制到相应目录下，在修改的修改日期文件下夹应该只有一个 public.war 文件夹， jar 包， * 。 sql 文件，并将写上当日修改日志，总的修改日志；

5. 从新从 VSS 上获取最新的运行环境；

6. 根据修改结果步骤，在对内服务器对应的应用上进行升级；

7. 还原数据库，测试，如有问题，返回修改人员进一步修改，重复上述步骤 ；如开发人员提供的修改清单名称错误超过两次，罚款 100 元作为项目活动经费；

　8. 如无问题，则将修改结果整理到用户升级文件中，提交给项目经理；

9. 测试组将“最新 BUG 报告”中修改确认正确的缺陷转到已修改 BUG 报告，并将内容上传到 VSS 上；

2.5 升级及备份
　1. 项目经理收到测试组提交的用户升级文件后，根据项目作进一步检查；

2. 项目经理联系用户负责人进行升级，填写升级记录，并将与用户交流的电子邮件等上传到 VSS 上；

3. 升级后，应将用户环境、数据库进行备份，如情况不允许，应将对内服务器的对应的环境尽心备份，将部分内容上传到 VSS 上；用户环境应是不包括附件外的所有环境；

4. 过一段时间后，与用户联系，确认缺陷是否解决；

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号