UML软件工程组织

 

 

版本管理条例
 
作 者:网友推荐  摘 自: 学知识
 

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

 公司很早就引进 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号