软件配置管理实施的若干问题研究

　　摘要：本文以软件配置管理在软件质量体系中的作用为切入点，以我国软件企业在软件开发、维护过程中忽视软件配置管理为着手点，从而过渡到软件企业要实施软件配置管理所要面临与考虑的问题，以及如何应对与处理这些问题作些具体探讨。

　　关键字：配置项　配置库　基线　软件配置

　　随着计算机应用的深入,软件项目的规模越来越大,复杂性越来越高。传统的二、三个人搞定一个项目的情况越来越少,稍大一点的项目已经不再是靠某个"技术高手"从头到尾一手操办。从而在我们平时的软件项目中一些混乱现象往往是屡见不鲜，比如：

　　编那个程序的人现在离开本公司了，留下的程序因缺文档而导致无人能接上手。

　　多个程序员对一个模块操作，出现了怪异现象：一个程序员对该模块所作的变更消失了。

　　在一个模块中作了修改，导致另一模块不能正常运行。

　　上个星期已经把这个错误改正了，现在又出现了。

　　采用科学的配置管理思想，辅之以先进的配置管理工具，可以很容易的解决项目开发过程中由于管理上引起的问题。我国软件企业可以从以下几方面思路去实施软件配置管理。

1、列出软件开发、运行、维护各阶段所需的软件配置项

　　所谓软件配置项就是在软件开发工作进展中得到的许多工作产品、阶段产品、使用的工具软件等信息项。表一中列举了若干类软件配置项及其生成的阶段。

表一

　　只有明确了各阶段有哪些软件配置项，软件企业才能在实施软件配置管理时胸有成竹、游刃有余。

2、对现有软件配置项进行分类、补充，进一步完善软件配置

　　软件企业在实施某一软件时，针对不同的用户都有不同的需求。表二是不同用户的工作环境：

　　为了满足各个用户的使用要求，我们的软件产品必须考虑到这些差异。在产品的设计时我们尽可能的作成表三所示的安排：

　　为了实现这两种不同的软件配置，在实际开发应用中，我们完全可以将各个配置项分别开发出来，再根据用户的需求，组合成不同的产品，如图一所示：

3、对软件项目的变更要实行有效的控制和管理

　　软件企业在软件的开发、运行、维护过程中必然要遇到软件的变更。引起软件的变更主要有两方面的因素：一方面是用户，如用户要求修改工作范围和需求等；另一方面是软件开发人员自身，如他们在工作中发现前期工作中的错误而修改源码甚至设计。对于以上两种情况软件企业可以从以下几方面加以解决：

3.1、明确实施变更的双方人员

　　事先应该明确用户有权提出需求变更申请的人员和软件企业项目开发组有权受理变更的人员，并且对双方人数要加以控制。这样做的好处是可以约束需求方，使需求方每提一个需求都要经过仔细讨论 。而项目开发组收到用户的需求变更时，通过有权实施变更人员讨论后，可以兼顾全局，对涉及到的相关文档、程序、计划都随之变更。

3.2、 对变更进行严格的审核

　　并不是所有的变更都要修改，也不是所有变更都要立刻修改，审核的目的就是为了决定是否需要修改和什么时候修改。比如涉及到界面风格问题，就可以先不修改，或者规划一下修改的时间待到以后进行优化。另外，对于核心模块的修改要严格审核把关，否则会引起全局问题。

3.3、 对变更的影响进行评估

　　变更都是有代价的，应该评估一下变更的代价和对项目的影响，要让用户了解变更的后果，并与用户一起做判断。

3.4、让客户确认是否接受变更的代价。在评估代价并且与客户讨论的过程中，可以请用户一起做判断：“我可以修改，但您能接受后果吗？”，并且对用户一一列出修改的后果。

4、对软件版本进行有效的管理

　　软件企业开发的软件产品为了适应不同的运行环境、不同的平台、不同用户的使用要求，导致同一软件产生或演化出不同的版本。软件企业可以通过以下两种常用的方法进行软件版本控制。

4.1、号码版本标识

　　以数字表示，如第一版，表示为V1.0。第二版表示为V2.0。一般认为V1.0，V2.0是基础版本号，V1.1、V1.2是对基础版V1.0的第一次修订和第二次修订。显然这些修订都是少量的修改。若有重大变动或因多次修订导致的全局性的重要变动，则应提高版本号，如V2.0。号码版本标识可以如图二所示：

4.2、符号版本标示

　　这种版本表示法是把版本的重要信息提炼出来。如V1/VMS/DB SERVER，表示一个在VMS操作系统上运行的数据库服务器版本。对于软件企业可以用‘人事管理系统单机版’、‘人事管理系统网络版’等来表示。

5、实施有效的配置审核

　　软件企业在实施配置审核时可以从以下两方面进行：

5.1、“配置管理活动审核”

　　“配置管理活动审核”用于确保项目组成员的所有配置管理活动，遵循已批准的软件配置管理方针和规程，如检入（Check in）/检出（Check Out）的频度、工作产品成熟度提升原则等。

5.2、“基线审核”

　　要保证基线化软件工作产品的完整性和一致性，并且满足其功能要求。基线的完整性可从以下几个方面考虑：基线库是否包括所有计划纳入的配置项？基线库中配置项自身的内容是否完整？（如，文档中所提到的参考或引用是否存在？）此外，对于代码，要根据代码清单检查是否所有源文件都已存在于基线库。同时，还要编译所有的源文件，检查是否可产生最终产品。一致性主要考察需求与设计以及设计与代码的一致关系，尤其在有变更发生时，要检查所有受影响的部分是否都做了相应的变更。审核发现的不符合项要进行记录，并跟踪直到解决。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有