TA的每日心情 | 开心 2024-2-1 15:09 |
---|
签到天数: 58 天 [LV.5]常住居民I
|
现在软件行业的发展可谓日新月异,新的开发方法、技术层出不穷,尤其近几年,软件行业的发展速度甚至比一直以来作为“IT发展标志”的硬件还要略胜一筹。但是,作为长期从事软件开发和技术研究的业内人士,似乎一点也没轻松,相反,正像一本书中描述的原油坑一样,“越是挣扎、陷得越深”。
关于“软件危机”,已经是老话题了。国内在这方面已经大张旗鼓地开始前所未有的“管理上的革命”——软件项目管理。经过近两年的不懈努力,CMM可以说遍地生花,PMP人才涌现,项目管理的思想“深入人心”,笔者有幸也参加到了这次变革中。但是,在本文中,笔者不想做什么高瞻远瞩的畅想,只是谈一个很基本的话题——配置管理。“配置管理”的观念很多人都是在CMM中接触到的,所以对配置管理的作用理解也仅限于CMM的要求,其实,配置管理作为相对独立的管理分支,有着其自身特殊的作用和要求。
在一个软件开发项目中,会有大量的所谓“产品”产生,典型的如代码、文档(包括技术文档、产品文档、管理文档)、数据、脚本、执行文件、安装文件、配置文件、甚至一些参数等,这些产品实际上都是软件项目的直接产品,同时也都是项目资产。但随着软件技术的不断更新、软件系统功能的日趋复杂、以及参与人员数量的大规模增加,上述产品的数量也急剧增加。这些产品还有一个独特的特征,就是,由于所有的产品都以“信息”的形式存放在计算机中,因此,和硬件相比较而言,极容易被修改(不考虑权限问题)和变化。这样虽然有助于灵活性的提高,但随之而来的是管理复杂性也急剧增加。如何有效地管理这些产品以及它们之间的关系就成为一个棘手的问题。
另一方面,软件开发往往都是在“变化”中进行的。可以毫不夸张地说,对软件开发项目而言,“变化是持续的、永恒的”,找不到不会变化的项目。需求会变,技术会变,系统架构会变,代码会变,甚至连环境都会变,所有的变化最终都要反映到上述的项目产品。如何应对这些变化,如何在受控的方式下引入变更,如何监控变更的执行,如何检验变更的结果,如何最终确认并固化变更,如何使变更具有追溯性,这一系列问题都将直接影响项目的进行。有趣的是,许多使用过配置管理的人都将配置管理方法应用在诸如个人的文档处理之类的问题上,以保证个人工作不会面临类似的问题。
另外,软件项目最终的目标是提交“高质量”的软件产品给最终用户。但是,我们经常面临的一个问题是,“提交了些什么?”为什么会产生这个问题,是因为,最终的“高质量”“可运行的”软件产品是由上千个甚至更多的“部件”按照某种特定的规则编译在一起完成的,但是每个部件都有自己特定的变化生命周期(Change Lifecycle),产生了一系列的版本,这么许多的部件以及各自的许多版本,就形成天文数字般的组合。
遗憾的是,其中只有一种组合才是我们真正想要的。没有足够的信息,没有合理的管理手段,我们将面临危机(事实上,在许多项目中已经一再地出现了)。
还有另外的一些问题对项目同样会产生影响。比如说,在现在的软件项目组中,往往是许多人一起配合工作。这时会出现一种需求:每个人要求工作在一个“独立”的工作环境中,也就是要求每个人进行工作时,不能影响和干扰其他人的工作和成果。但同时,当经过一定的授权或者认定后,还要求可以比较便捷地和其他人的工作进行配合。这种既独立又联系的关系,使得通常的管理手段显得力不从心。
综合上面的问题可以看出,大量的问题已经不再是单纯的技术问题了,而是需要一项专门的管理手段来处理。这个管理手段直接的目的就是保持项目的稳定性(虽然也能间接提高质量),减少因上述原因引起的项目混乱而造成的负面影响。这就是“配置管理”的产生原因。
根据IEEE的定义,“软件配置管理(Software Configuration Management , SCM)是一门应用技术、管理和监督相结合的学科,通过标识和文档来记录配置项的功能和物理特性,控制这些特性的变更,记录和报告变更的过程和状态,并验证它们与需求是否一致。”从定义可以看出,软件配置管理(SCM)是一门综合性的学科,其中不仅包含管理,同时也包含一些技术手段。另外,SCM通过管理配置项,控制变更,并验证变更,使项目的混乱减到最小,使错误达到最小,并最大限度地提高生产率。实施软件配置管理的目的是保证软件项目的工作产品在整个项目周期中的“完整性”。所谓完整性是指,工作产品要求有完整的变更历史记录,要求有正式的变更过程,而且还要求保证工作产品能和需求以及变更保持一致性。
从上述的定义中,我们已经可以归纳出要实施软件配置管理,需要进行哪些活动了。 |
|