软件配置管理工作总结

软件配置管理工作总结

篇一：软件配置管理实施体会

软件配置管理实施体会

陈越，fashi@

随着软件产业的崛起，软件工程技术正吸引着越来越多关注的目光。作为软件工程的一个重要的领域，软件配置管理（Software Configuration Management）也日益受到人们的重视。在这里，笔者并不打算对软件配置管理的细节进行讨论，几乎任何一本关于软件工程的教材中都有专门的章节对此进行介绍，而是想从一个实践者的角度来阐述关于软件配置管理的一些想法。

一．软件配置管理的目的

对于任何一个软件组织（企业）来说，开发出满足用户需求的、高质量的软件产品是其追求的目标。而要实现这一目标的关键是建立起一个稳定、可控、可重用的软件流程（Software Process）。因为某一软件产品的成败可能维系于关键技术的突破和创新；但对于软件组织而言，要想永葆竞争优势并不断取得成功，那就必须不断地改进它的软件流程。要进行软件流程改进（Software Process Improvement）就需要有明确的、量化的对现状的分析和对未来的预期，这些数据来源于对软件过程的度量，而进行度量的前提和基础就是软件配置管理。

与一般制造业相类似，软件流程就像是一条流水线，在它的各个环节上都会有“零部件”产生，它们就是我们所熟悉的程序、相关文档以及数据。这些正是软件配置管理的对象——（软件）配置项。它们不仅是大量人力物力投入的结晶，更是开发经验的积累，是软件组织最宝贵的财富。软件配置管理贯穿于软件开发活动的始终，覆盖了开发活动的各个环节，它的重要作用之一就是要全面的管理保存各个配置项，监控各配置项的状态，并向项目经理及相关的人员报告，从而实现对软件过程的控制。

那么我们对这些配置项进行管理只是为了保存这些信息吗？众所周知，人员的高流动性和知识和技术的快速更新是软件业的重要特点。应对这样的特点我们只有努力地把开发人员个人的成功经验转化为团队的以及整个组织的经验。在这样的一个转化过程中，软件配置管理也起着极其重要的作用。因为对于一个大型的软件企业来说，它的配置库有如一个巨大的图书馆，随着产品版本的不断演进，越来越多的配置项会充斥其间，以至于没有任何一个人能了解其中的全部内容。当我们需要在开发组织内部迅速的共享以往的成果时，配置管理就能发挥作用了。它就像常见的图书编目法那样，帮助图书管理员（配置管理员）迅速的找出所需的资料（配置项），而不必彻底了解其中的确切内容。这样工作效率大为提高，很多常见的容易引起混乱的问题都能尽量得以

避免。

所以，我们在从事软件配置管理工作时应以整个软件流程的改进为目标，为软件项目管理和软件工程的其它领域打好基础，以便于稳步推进整个软件组织的能力成熟度。

二．工具的选择

古语有云：“工欲善其事，必先利其器。”软件配置管理是一项十分繁琐的工作，同时又和整个软件的开发活动紧密地联系在一起，所以在实际工作中更需要有得力的工具辅助。目前常用的配置管理工具主要有MS SourceSafe、Rational ClearCase等，这些工具各有所长，因而只有根据项目的预算和开发组织的些实际情况出发来选择，正所谓“好用就好”。在这里，笔者提出一些个人的看法供大家参考。

首先，配置管理工具应该提供完善的版本管理的功能。在该工具的所管理的配置库中，所有的配置项都应清晰、完整的得到保存，相应的操作纪录完备，使得开发组织中的任何人员都能迅速的了解任一配置项的演进过程，并快捷的找到所需的资源。

其次，配置管理工具应具备一定的工作空间的管理功能。正如前文指出的那样，一个软件企业往往有多个项目同时进行着开发，为了最大程度的利用组织的经验、共享成果，我们有必要在一个共同的配置库里提供多视角的观察手段，在

逻辑上按照不同的角色分工来组织信息的选取规则和显示方式，从而能根据需要，在开发人员间灵活的进行分工合作。

由于我们把配置管理工作立足于软件过程的改进，那么我们所选用的工具最好能具有一定的过程控制的能力，能利用它按照企业本身的开发流程来灵活的建立相应的电子流，并在此过程中记录用于过程度量的相关数据，整合软件过程管理的各个环节，以便于客观的发现问题，高效的解决问题。

另外，我们选取得工具一定要操作简便，不能给开发人员增加过多的负担，因为过多的形式化的约束往往带来人们的反感，使得大家不约而同的选择规避的措施，其结果只能是事倍功半，甚至和我们的目标南辕北辙。

三．实现的策略

笔者所在的软件组织从事的通信软件的研发，我们把配置管理作为推进软件过程改进的一个很重要的工作领域。我们明确定义了配置管理相关的角色、工作职责和工作流程，通过一段时间的努力，已经取得了明显的效果。 1．配置库的设置

决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。

按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，它适用于通用的应用软件开发组织。这样的组织一般产品的继承性较强，工具比较统一，对并行开发有一

定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。而按任务建立相应的配置库则适用于专业软件的研发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格的分类存储，人为增加目录的复杂性。因此，笔者认为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵活。

2．分支的划分

在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，我们基本上为每个配置项从建立开始就划分成3个不同的分支，让它们分别对应3类工作空间。

l 私有分支

私有分支对应的是开发人员的私有开发空间。开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素。

l 集成分支

集成分支对应的是开发团队的公共空间。凡是要为同组

人员共享的配置项都从该分支获得。即各开发人员必须将私有工作空间中的开发成果归并（Merge）到该分支后才能进入下一个开发活动。所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的管理工作由系统集成员及相关指定人员负责。

l 公共（主干）分支

公共分支对应的是整个软件开发组织的公共空间。各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人员开放只读权限。该分支的管理工作由系统集成员负责。

上面定义的3类工作空间（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。 3．变更控制

对于大型的软件开发项目，无控制的变更将迅速导致混乱，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的的机制。本文所涉及的变更控制的对象主要指配置库中的各基线配置项。变更管理的一般流程是：

A) 由开发人员或系统集成员提出变更需求；

B) 由SCCB（软件变更控制委员会）审核并决定是否批

准；

C) 配置管理员根据SCCB的决定临时开放相应的权限，并备案；

D) 系统集成员执行相应的变更。

在这里，将要涉及的变更控制分为两类：一类是基线的变更控制，另一类是软件版本的变更控制。 l 基线的变更控制

基线的变更是指在一个软件版本的开发周期内对基线配置项的变更，主要包括基线的应用和更新等活动。

基线变更所涉及的操作主要包括基线标签的定义和标签的使用。基线标签属于严格受控的配置项，它的命名必须严格按照相关的命名规范来进行。基线在建立时，按照角色职责的分工，须经SCCB同意并以正式的将该基线的标识和作用范围通知系统集成员，由后者负责执行；基线一旦划定，由该基线控制的各配置项的历史版本均处于锁定或严格受控状态，任何对基线位置的变更请求都必须按变更控制流程，提交SCCB批准，然后由系统集成员执行。

l 软件版本的变更

软件版本的命名规范应事先制定，并按照开发计划予以发布使用。在软件版本的演进过程中既需要从以前的版本中继承，又需要相对的独立性。所以在对于一个子版本（例如某特定用户的定制版本）就需要对一系列配置项从统一的开

发起始基线所确定的版本上建立新的分支，然后在此分支上开发新的版本。因此在这样的变更控制流程中，受控的对象还应包括特定的分支类型，以及工作视图的选取规则，同时配置管理员将在这一过程中担负更多的操作职责。

上述几点是笔者在从事软件配置管理过程中的一些心得体会，在此抛砖引玉，供大家参考。本文来自《PMT评论》总第23期

篇二：软件项目管理总结

软件项目管理过程的简单总结

学院：计算机学院

班级：软件

学号：

姓名：雷莉莎 11 1060611014033

做任何事情都需要管理，好的管理出好的效益，开发软件项目也不例外。随着信息系统工程、络工程、软件工程的发展，项目管理和软件工程的交汇越来越多，从而使“软件项目管理”发展起来，一个项目的成功与否，关键一点就是，看项目管理是否得当。所以，项目管理是项目的核心部分，是项目的灵魂。软件项目管理的概述

所谓项目，就是在特定条件下，具有特定目标的一次性任务，是在一定时间内，满足一系列特定目标的多项相关工作的总称．项目具有一次性、独特性、目标的确定性、组织

的临时性和开放性以及成果的不可挽回性等基本属性。

而软件项目管理是为了使软件项目能够按照预定的成本，进度、质量顺利完成，而对人员，产品，过程和项目进行分析和管理的活动。根本目的是为了让软件项目尤其是大型项目的整个软件生命周期（从分析，设计，编码到测试，维护全过程）都能在管理者的控制之下，以预定成本按期，按质完成软件交付用户使用。

软件项目的管理过程详解

在软件项目开发管理过程中，不仅要努力实现项目的范围、时间、成本和质量等目标，还必须协调整个项目过程，以满足项目参与者及其他利益相关者的需要和期望。随着软件规模和所涉及的领域不断扩大，软件项目的管理越来越困难。纵观所有失败的软件项目，基本原因是不能管理其软件过程，在无纪律、混乱的项目状态下，组织不可能从较好的方法和工具中获益。严谨的软件过程控制与管理不仅可以在每个阶段回顾和纠正项目的偏差，识别软件项目的风险甚至果断中止项目，而且可以将人才流动所带来的不利影响减少到最小。要进行有效的过程控制，必须明确软件项目管理流程。

下图即为软件项目管理流程：

接下来详细介绍项目管理过程的步骤包括：

项目立项——启动——规划——执行和控制——收尾

阶段

1.软件项目立项包含5个环节：发起、评估、申请、审核、立项。

立项流程图

2. 项目的启动就是确定项目的目标范围，它主要包括开发和被开发双方的合同（或是协议），软件要完成的主要功能以及这些功能的量化范围，项目开发的阶段周期等。

PMBOK中明确指明项目启动阶段主要的工作是制定项目章程和识别项目干系人。结合软件项目的特点，成功的软件项目启动包括以下三个方面的工作：

1）制定项目章程

项目章程的主要内容：项目的名称和授权日期，项目目的或批准项目的原因，可测量的项目目标和相关的成功标准，项目总体要求和概述性的描述，项目的主要风险，总体里程碑进度计划，总体预算，项目审批要求，委派的项目经理及其职责和联系方式，项目干系人尤其是发起人或其他批准项目章程的人员的姓名和职责以及他们的签名，有时包括他们对项目的承诺。

2）识别项目干系人

干系人分析对项目的成功至关重要，一般通过三个步骤进行干系人的分析，首先是识别可能的干系人，然后进行他们的影响力分析，最后管理干系人期望。

3）项目启动会议

项目启动会议的成功与否对整个项目的影响非常大。好的开始是成功的一半，如果第一次会议中能够表现出公司的专业性，树立起良好的形象，对日后的项目协调、工作安排会有良好的推动作用；如果在第一次会议中显得比较被动，不够专业，会让项目的协助方对项目产生疑问，对日后项目的实验收都会产生负面影响。

3.项目的规划为项目的运作提供可靠的实施基础。在整个项目中，项目规划是指项目的估算，风险的分析，进度的规划，人员的选择与配置，产品质量的规划等。然而，在项目管理的过程中，计划的编制是整个项目规划中最为复杂的阶段。在计划编制的过程中，我们还可看到后面各阶段的输出文件。所以说它是指导项目的进程发展。规划建立软件项目的预算，提供一个控制项目成本的尺度，也为将来的评估提供参考，它是项目进度安排的依据。最后，形成的项目计划书将作为跟踪控制的依据。

项目规划工作涉及软件项目团队管理、软件项目估算、风险管理、质量管理、配置管理、进度管理。

团队管理：团队就是有两个或两个以上、相互依赖的、能相互负责的、具有共同的目的和方向的、愿意为共同的目标而努力的有互补技能的成员组成的群体，并且具有三个特征：目标、人、领导者。

团队的成长过程：形成期、震荡期、正规\规范期、表现\执行期、收尾期。软件项目团队角色分类：软件项目经理，系统分析人员，系统设计人员，开发人员，测试人员，软件配置管理人员，软件质量保证人员。

项目估算：软件项目估算的内容主要包括软件工作产品的规模估算、工作量估算、成本估算和进度估算。如图所示：需要进行估算的几个阶段：

·可行性研究·需求说明·系统设计·系统实现·系统运行

软件项目估算步骤：

1）确定软件项目范围

2）确定完成软件开发所需的资源

3）估算工作量

4）估算成本

软件项目估算的常见方法: 代码行法、功能点法、自下而上法、类比法、专家判断法、参数估算法、简单估算法等。

风险管理：软件风险是软件项目与生俱来的，会阻碍目标的实现，所以在软件开发中需要风险管理。所谓风险管理就是为了管理项目中的风险而应用过

程、方法和工具的一种实践，它提供一种良好的环境来作出以下决策：连续的评估项目中存在什么样的风险。

确定哪些风险是需要重点考虑的。

对重点考虑的风险采取积极的措施来应对。

简单归纳软件风险管理工作就是在风险成为影响软件项目成功的问题之前，识别并着手处理风险的过程。风险管理是对不确定性和变化的一种应对方式。

风险识别的过程：

质量管理：软件质量是项目管理的三个目标之一，且成本和时间这两个目标都只要以质量为基础的。软件项目管理的好坏直接关系到最终产品能否通过验收、项目能否顺利结束。质量是软件产品和软件组织的生命线，而软件质量管理就是稳定这条生命线的标尺。

软件质量管理的各过程如下：

1)规划质量。识别项目及其产品的质量要求和标准，并书面描述项目将如何达到这些要求和标准的过程。

2）实施质量保证。审计质量要求和质量控制测量的结果，确保采用合理的质量标准和操作性定义的过程。

3）实施质量控制。监测并记录执行质量活动的结果，从而评估绩效并建议必要更改过程。

结合软件开发项目的特殊性，软件项目质量管理的主要内容包括编制软件项目的质量计划、软件质量保证和软件质量控制三个方面。

质量计划是质量管理的第一过程域，它主要结合各个公司的质量方针、产品描述以及质量标准和规则，通过效益、

成本分析和流程设计等工具制定出实施方案，其内容全面反映用户的需求，为质量小组成员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保障提供坚实的基础。质量保证则是贯穿整个项目全生命周期的有计划和由系统的活动，经常性的针对整个项目质量计划的执行情况进行评估、检查、改进等工作，向管理者、顾客或其他方提供信任，确保项目质量与计划保持一致。质量控制是对阶段性的成果进行检测、验证，为质量保证提供参考依据，他是一个PDCA（计划Plan—执行Do—检查Check—纠正Act）循环过程。

配置管理：软件项目配置管理的目的在于：

1）记录软件产品的演化过程

2）确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置

3）最终保证软件产品的完整性、一致性、追溯性、可控性

配置管理的过程：

篇三：做配置管理你需要那些知识？我的几年工作总结做配置管理你需要那些知识？我的几年工作总结。

做配置管理你需要那些知识？

我在做配置管理以前做过两年的测试，期间做过两家公

司的iso 9000的内审员，然后老板觉得我比较有耐心，所以赶鸭子上架，和前任学习拉一周，我就是配置管理拉，然后不知不觉，已经6年拉，总结一下，看看会需要些什么呢？

1、软件公司的开发流程，对软件工程一定要熟悉，尤其是开发模型，你不能保证公司的所有项目使用一个模型。比如：瀑布、迭代或者极限编程。只有熟悉这些开发模型，你才能参与到公司的流程制定中去。

2、熟悉一些标准，比如：iso 9000和cmmi。一个公司想要发展大，想要稳定，就一定会有一套稳定的流程。而熟悉标准，会更有利于你理解和说服你的同事。记得以前一个同事说过这样一句话，一个公司想要长大，那一定必须是一头小象而不能是一只大蚂蚁。而一个做有流程，愿意将公司的事情流程化的公司才能保证不因人成事，才能长大。

3、沟通能力。配置管理员的工作就是沟通协助需求、开发及测试人员工作。而一个新的项目的建立意味这大家都是新人，来自不同的行业不同的公司，公司文化不同，做事的方法也不同，你只有有好的沟通能力，才能说服项目经理支持你的工作，才只能说服开发测试人员按你要求的流程工作。

4、编程能力。想做好配置管理，你就不得不编写一些配置脚本，以方便开发测试人员，同时减少自己的工作量。

5、数据库知识。一般来说配置管理员，同时要管理BUG

跟踪或需求管理的系统，那免不了老板会让你提供一些统计数据，所以数据库知识也是必不可少的。

6、系统知识。多说公司的配置管理员还要负责开发测试环境的维护，那么有系统知识，无疑可以减少你求助的机会。

现在说说我做过什么？

一、上海项目的时候，只是负责系统的配置管理，包括代码编译，上线，这个系统比较大，但是还好，我是从别人手上接手的，所以还在顺序。

二、集团项目的的时候，我同时维护9个省的测试上线环境。

由于用户一直是用unix系统，所以顺便学会拉shell ，学会来在ibm，hp，sun的小型机上安装配置软件。

尤其是bes521的安装，简直是无言啊？宝蓝从总部派人过来，现场安装，配置、测试，美国总部修改bug，然后打补丁，终于，我写了一本安装手册，两年后公司同事还在用。安装ibm的websphere的时候，我发现需要打操作系统补丁，于是比较傻瓜的我，安装拉最新版的补丁，要命的是这个websphere比较变态，尽然只能用它指定版本，所以到现在我都恨websphere啊。要说最大的收获，就是在压力下面，我做事情很负责，我的努力让公司项目经理面对甲方也很硬气。

三、做公司的openboss系统。这个系统对我的锻炼很大，工作如下：

1、写cvs脚本，保证代码能在提交的时候,同时建立开发和构建分支，同时不能是分支之上建立分支。

2、和一个没有任何配置管理经验的开发团队扯皮，扯开发流程，扯目录结构，扯Makefile模板，扯代码命名规范，然后想办法让他们执行。

这个系统很大，到今天，已经有11个移动，3个通，3个电信在使用。分出来的系统现在也有15个拉，仅仅营业和账务两个系统，unix后台就有500多个动态库，当时扯皮，现在受益。

3、和总工办一起搞unix主机下的编译选项，由于用户的环境复杂，所以要求做到，代码写出来后，可以跨cpu，跨操作系统、跨中间件、跨数据库。所以这个过程让我对unix 下的编译器熟悉起来，不然无法做到。让我自豪的是到现在，开发人员只要修改Makefile模板很少的地方，就可以跨平台编译拉。

4、编写自动编译脚本。通过我们开发的自动编译系统，开发人员只要在浏览器中提交编译单就可以自动编译拉。而如果开始的时候，如果没有将目录规划好，我想自动编译就是无源之水。这个系统我们web部分用jsp，unix用tcl/tk 脚本。现在已经集成到QCS的源码管理中，还在改进，还在

使用。

四、公司的QCS系统（质量控制系统）。

这是一个配置管理系统，通过rsh将CVS和QCS结合在一起，用jsp和oracle的存储过程开发，其中包括：需求管理、功能点管理、任务管理、源码管理、bug管理、工程故障管理、接口管理、数据库变更管理、版本管理、发布管理、回退管理等模块的系统。

五、参加公司的EPG小组，并且以配置管理员的身份参与评审。

公司两年前已经通过CMMI 5的认证。我加入公司的公司只是通过拉CMM 2级。后来由于甲方的要求，公司开始CMMI 的认证。这中间有大量的文档要写。尤其是配置管理员，在几乎所有的过程中，都要参与评审，所以准备工作做拉好久。到 CMMI 5级的时候，就要提供大量的统计数据来说明持续改进的结果，所以对QCS就需要不少地方做改动，来收集数据。还好公司一直注意这块，我们的各种脚本，模板，都是尽量的优化以满足开发测试人员的需要。所以后来的评审中基本没有费什么事就过拉。

在这个项目中，让我对配置管理中的很多概念理解很深。尤其是在评审的时候，将自己平时做的工作用CMMI的语言讲解，感觉的确是锻炼人。

这中间的很多事情，我的感谢我的师傅，虽然他比我年

龄还小，而且也没有带我很久，但是很多问题都是和他讨论中加深理解的，不管是从技术上，还是为人都让我学之不尽啊。

要做好配置管理，我觉得有几个概念一定要理解清楚：

1、基线。

2、配置项。

3、变更。

4、版本。

5、标签或tag。这个是理解它的作用。

6、工作区及工作区隔离。

转载请注明源自/,请保留版权. 本贴地址：http:///tid=16353

要做好配置管理，一定要耐心、细心、恒心。

冰冻三尺非一日之寒。

希望以上内容能给新入行的同行一点帮助。

本文来自CSDN博客，转载请标明出处：http:///nuoyazhizhou/archive/XX/12/28/

篇四：软件项目管理小结2篇

软件项目管理已经到了学期的最后，我们seed小组的软件项目也已完工，这一个学期真的是获益匪浅！礼平老师曾经说我既可以走技术路线也可以走管理路线，一切都看我自己。真的很是佩服老师的看人眼光，很犀利。我知道，现

在的我不是没有能力去做好，只是自己没有去做，一直在殿外徘徊，不肯付出努力向前迈进。从大一到现在，我的专业技术一直都是我的短板，理由么，很简单，就是因为自己懒，不肯花时间去做。从以前不知道自己想做什么，到现在明确目标，可以说，软件项目管理课程给了我很多灵感，让我从自己纷乱的思绪中看清楚了自己最想要的东西。一直自己很喜欢管理，我会花费很多时间在这上面，从大一到现在一直都是，一直没有改变过。在技术上，我总是给自己找借口，总是偷懒，但我现在明确了一点，没有技术，就没有管理！脱离技术的管理是不可能的，也是不现实的。在这个行业里，技术是一切的基本，想作工程师也好，想作管理者也好，技术都是起步的根基。而我这次所经历的项目更让我明确了这一点。在这个小项目里，虽然我们两个星期就开发完成了这个软件，并交付使用，但是问题还是很多的。在这么一个小项目里，由于需求、设计、代码、文档产生的问题，每一个看似容易，却都需要实实在在的经验在里面，都需要对业务的熟悉，有语言功底作根基。在这个项目里，我负责软件配置管理工作，在文档的整理过程中，我仔细看了他们的需求分析，概要设计，数据库设计，模块设计等文档，也参与了风险分析文档的编写，承担了用户手册和项目成本估算的编写。在这个过程中，我明确了技术的实在意义，明确了技术对我的指导作用，同时也明确了自己的学习道路应该怎么走