基于CMMI的软件配置管理模型研究

作者:杜丽 刊名:硅谷 上传者:杞俊洪

【摘要】软件配置管理贯穿于软件的整个生命周期,是CMMI中的一个关键过程域,对软件实施配置管理是为了解决软件开发和维护过程中产品出现的不完整性、不一致性和不可追踪性等问题。文中对软件配置管理的基本概念做了简要的论述,重点研究了基于CMMI配置管理的模型,以期对软件开发工程起到一些推动作用。

全文阅读

40 硅谷 技术研发 ECHNOLOGY R&DT 就当前的实际情况来看 ,软件工程所面临的主要问题是质量较差、软件开发过程漫长以及经费难以控制等 ,文中提出了一种基于 CMMI 的软件配置管理模型 ,实现了对软件开发全过程实施配置管理的目标 ,解决了软件开发过程中产品的完整性、不一致性以及不可追溯性。 1 软件配置管理的概念和模型研究 软件配置管理是一种按规则实施管理软件开发和维护以及软件产品的方法 ,它贯穿于软件的整个生命周期 ,对软件质量控制有着重要的作用 [1]。软件配置项是软件配置管理下的实体元素 ,其可以单独对软件生命周期的数据进行配置管理 ,包括 :软件的需求、设计、测试数据和代码等。而软件配置管理模型是以配置项为基础的管理域 ,随着软件功能的不断增加 ,一个配置项可能承载软件产品的多个功能要求 ,因此可以看出 ,配置项与软件的功能是一种多对多的关系 ,而基于 CMMI 的软件配置管理模型可以准确的获知某一功能与相关配置项版本之间的对应关系 ,实现了目标管理与基本管理的追踪。 2 基于 CMMI 的配置管理模型的应用研究 1)配置管理模型在同一产品的维护与开发中的应用。软件配置管理可以高效有序的协调在同一款软件产品中的维护和开发工作 ,以下为例进行说明。某一软件当前使用的版本为3.0Version,以当前的版本为基线创建两个相互独立且并行的分支 :分支 3.0Patch 和分支 4.0,以此来完成旧版本软件的维护工作和软件新版本的开发工作 ,维护的工作基线为 3.0PBL1 和 3.0PBL2,而开发现产品的工作基线则是 4.0PBL0、4.PBL1 和PBL2,而3.0Patch可以作为3.0Version版本的补丁来发布,但是由于 4.0 和 3.0Patch 两者之间是相互独立的 ,在 4.0 版本中仍然存在 3.0Version 版本中出现的缺陷 ,因此需要将 3.0Patch 内容合并到 4.0 当中 ,这样才能够更好的让配置管理模型在相同产品中得到维护以及开发。如图 1。 图 1 同一产品的维护与开发 2)配置管理模型在同一产品不同版本之间的并行开发。假 如 3.0Version 版本的开发工作并没有完全结束 ,当前的基线为3.0BETA,则可以直接创建新的分支 3.1,以此来实现3.0和3.1 两个版本的并行发布 ,当 3.0Version 版本开发工作完成 ,则发布该版本 ,同时要将 3.0BETA 到 3.0Version 的变为部分合并到 3.1 当中 ,这样使得 3.1 版本中包含了 3.0Version 的全部功能 ,然后就继续进行 3.1 的后续研发。图 2 主要是表明并发配置管理策略的实现机制。 图 2 同一产品不同版本之间的并行开发 3 基于 CMMI 的配置管理模型的最佳实践 1)配置管理系统的建立和维护。在软件开发过程中需要建立项目的开发库、受控库和产品库 ,而且配置管理人员要严格按照《软件配置管理计划》中明确的角色和职责对配置管理系统的访问角色进行设置 ,在软件开发的生命周期以内 ,配置项存储于开发库、受控库以及产品库当中 ,项目人员则可以根据不同的授权对相关配置库进行访问 [2]。 2)创建和发布基线。在 CMMI 的要求当中 ,建立基线模型共存在五种类型 :功能基线、分配基线、设计基线、测试基线以及产品基线 ,在基线开发完成之后要经过确认再交给软件开发人员 ,由软件开发人员负责将基线产品交给配置管理人员 ,配置管理人员要根据以下步骤发布产品 :①申请建立基线 ,软件开发人员申请建立基线 ;②审

参考文献

引证文献

问答

我要提问