软件配置管理工作总结.docx

1、软件配置管理工作总结软件配置管理工作总结篇一：软件配置管理实施体会软件配置管理实施体会陈越， fashi 随着软件产业的崛起，软件工程技术正吸引着越来越 多关注的目光。作为软件工程的一个重要的领域，软件配置 管理( Software Configuration Management )也日益受到人们的重视。在这里，笔者并不打算对软件配置管理的细节 进行讨论，几乎任何一本关于软件工程的教材中都有专门的 章节对此进行介绍，而是想从一个实践者的角度来阐述关于 软件配置管理的一些想法。一 软件配置管理的目的 对于任何一个软件组织(企业)来说，开发出满足用户 需求的、高质量的软件产品是其追求的目标。而要

2、实现这一 目标的关键是建立起一个稳定、可控、可重用的软件流程 ( Software Process )。因为某一软件产品的成败可能维系 于关键技术的突破和创新；但对于软件组织而言，要想永葆 竞争优势并不断取得成功，那就必须不断地改进它的软件流 程。要进行软件流程改进 ( Software Process Improvement ) 就需要有明确的、量化的对现状的分析和对未来的预期，这 些数据来源于对软件过程的度量，而进行度量的前提和基础 就是软件配置管理。与一般制造业相类似，软件流程就像是一条流水线，在 它的各个环节上都会有“零部件”产生，它们就是我们所熟 悉的程序、相关文档以及数据。这些正是

3、软件配置管理的对 象一一（软件）配置项。它们不仅是大量人力物力投入的结 晶，更是开发经验的积累，是软件组织最宝贵的财富。软件 配置管理贯穿于软件开发活动的始终，覆盖了开发活动的各 个环节，它的重要作用之一就是要全面的管理保存各个配置 项，监控各配置项的状态， 并向项目经理及相关的人员报告， 从而实现对软件过程的控制。那么我们对这些配置项进行管理只是为了保存这些信 息吗？众所周知，人员的高流动性和知识和技术的快速更新 是软件业的重要特点。应对这样的特点我们只有努力地把开 发人员个人的成功经验转化为团队的以及整个组织的经验。 在这样的一个转化过程中，软件配置管理也起着极其重要的 作用。因为对于一个

4、大型的软件企业来说，它的配置库有如 一个巨大的图书馆，随着产品版本的不断演进，越来越多的 配置项会充斥其间，以至于没有任何一个人能了解其中的全 部内容。当我们需要在开发组织内部迅速的共享以往的成果 时，配置管理就能发挥作用了。它就像常见的图书编目法那 样，帮助图书管理员（配置管理员）迅速的找出所需的资料 （配置项），而不必彻底了解其中的确切内容。这样工作效 率大为提高，很多常见的容易引起混乱的问题都能尽量得以避免所以，我们在从事软件配置管理工作时应以整个软件流 程的改进为目标，为软件项目管理和软件工程的其它领域打 好基础，以便于稳步推进整个软件组织的能力成熟度。二 工具的选择 古语有云：“工欲

5、善其事，必先利其器。 ”软件配置管理 是一项十分繁琐的工作，同时又和整个软件的开发活动紧密 地联系在一起，所以在实际工作中更需要有得力的工具辅助。 目前常用的配置管理工具主要有 MS SourceSafe 、 Rational ClearCase 等，这些工具各有所长，因而只有根据项目的预算和开发组织的些实际情况出发来选择，正所谓 “好用就好” 。在这里，笔者提出一些个人的看法供大家参 考。首先，配置管理工具应该提供完善的版本管理的功能。 在该工具的所管理的配置库中，所有的配置项都应清晰、完 整的得到保存，相应的操作纪录完备，使得开发组织中的任 何人员都能迅速的了解任一配置项的演进过程，并快捷

6、的找 到所需的资源。其次，配置管理工具应具备一定的工作空间的管理功能。 正如前文指出的那样，一个软件企业往往有多个项目同时进 行着开发，为了最大程度的利用组织的经验、共享成果，我 们有必要在一个共同的配置库里提供多视角的观察手段，在逻辑上按照不同的角色分工来组织信息的选取规则和显示 方式，从而能根据需要， 在开发人员间灵活的进行分工合作。 由于我们把配置管理工作立足于软件过程的改进，那么 我们所选用的工具最好能具有一定的过程控制的能力，能利 用它按照企业本身的开发流程来灵活的建立相应的电子流， 并在此过程中记录用于过程度量的相关数据，整合软件过程 管理的各个环节， 以便于客观的发现问题， 高效

7、的解决问题。另外，我们选取得工具一定要操作简便，不能给开发人 员增加过多的负担，因为过多的形式化的约束往往带来人们 的反感，使得大家不约而同的选择规避的措施，其结果只能 是事倍功半，甚至和我们的目标南辕北辙。三 实现的策略 笔者所在的软件组织从事的通信软件的研发，我们把配 置管理作为推进软件过程改进的一个很重要的工作领域。我 们明确定义了配置管理相关的角色、工作职责和工作流程， 通过一段时间的努力，已经取得了明显的效果。 1 配置 库的设置决定配置库的结构是配置管理活动的重要基础。一般常 用的是两种组织形式：按配置项类型分类建库和按任务建库。按配置项的类型分类建库的方式经常为一些咨询服务 公司

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

9、 在实际的开发活动中系统中，为了让每个开发人员和各 个开发团队能更好的分工合作，同时又互不干扰，我们基本 上为每个配置项从建立开始就划分成 3 个不同的分支，让它 们分别对应 3 类工作空间。l 私有分支 私有分支对应的是开发人员的私有开发空间。开发人员 根据任务分工获得对相应配置项的操作许可之后，他即在自 己的私有开发分支上工作，他的所有工作成果体现为在该配 置项的私有分支上的版本的推进，除该开发人员外，其他人 员均无权操作该私有空间中的元素。l 集成分支 集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得。即各开发人员必须将私 有工作空间中的开发成果归并（ Me

10、rge）到该分支后才能进入下一个开发活动。所有涉及多人协调的开发工作（如集成 测试等）都必须工作在这一空间中。该开发团队拥有对该集 成分支的读写权限，而其他成员只有只读权限。该分支的管 理工作由系统集成员及相关指定人员负责。l 公共（主干）分支 公共分支对应的是整个软件开发组织的公共空间。各个 开发小组在现阶段的任务完成后，将可以发布的版本归并到 该分支上，将来需要查阅相关资料时，以该分支上的版本为 准。该分支对组织内的全体软件人员开放只读权限。该分支 的管理工作由系统集成员负责。上面定义的 3 类工作空间（分支）由配置管理员统一管 理，根据各开发阶段的实际情况定制相应的版本选取规则， 来保证

11、开发活动的正常运作。在变更发生时，应及时做好基 线的推进。 3 变更控制对于大型的软件开发项目，无控制的变更将迅速导致混 乱，变更控制就是通过结合人的规程和自动化工具，以提供 一个变化控制的的机制。本文所涉及的变更控制的对象主要 指配置库中的各基线配置项。变更管理的一般流程是：A） 由开发人员或系统集成员提出变更需求；B） 由SCCB（软件变更控制委员会）审核并决定是否批准；C） 配置管理员根据 SCCB的决定临时开放相应的权限， 并备案；D） 系统集成员执行相应的变更。 在这里，将要涉及的变更控制分为两类：一类是基线的变更控制，另一类是软件版本的变更控制。 l 基线的变更 控制基线的变更是指

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

13、既需要从以前的版本中 继承，又需要相对的独立性。所以在对于一个子版本（例如 某特定用户的定制版本）就需要对一系列配置项从统一的开 发起始基线所确定的版本上建立新的分支，然后在此分支上 开发新的版本。因此在这样的变更控制流程中，受控的对象 还应包括特定的分支类型，以及工作视图的选取规则，同时 配置管理员将在这一过程中担负更多的操作职责。上述几点是笔者在从事软件配置管理过程中的一些心 得体会，在此抛砖引玉，供大家参考。 本文来自 PMT 评 论总第 23 期篇二：软件项目管理总结软件项目管理过程的简单总结学院：计算机学院班级：软件学号：姓名：雷莉莎 11 1060611014033 做任何事情都需

14、要管理，好的管理出好的效益，开发软 件项目也不例外。随着信息系统工程、络工程、软件工程的 发展，项目管理和软件工程的交汇越来越多，从而使“软件 项目管理”发展起来， 一个项目的成功与否， 关键一点就是， 看项目管理是否得当。所以，项目管理是项目的核心部分， 是项目的灵魂。 软件项目管理的概述所谓项目，就是在特定条件下，具有特定目标的一次性 任务，是在一定时间内，满足一系列特定目标的多项相关工 作的总称项目具有一次性、独特性、目标的确定性、组织的临时性和开放性以及成果的不可挽回性等基本属性。而软件项目管理是为了使软件项目能够按照预定的成 本，进度、质量顺利完成，而对人员，产品，过程和项目进 行分

15、析和管理的活动。根本目的是为了让软件项目尤其是大 型项目的整个软件生命周期（从分析，设计，编码到测试， 维护全过程）都能在管理者的控制之下，以预定成本按期， 按质完成软件交付用户使用。软件项目的管理过程详解在软件项目开发管理过程中，不仅要努力实现项目的范 围、时间、成本和质量等目标，还必须协调整个项目过程， 以满足项目参与者及其他利益相关者的需要和期望。随着软 件规模和所涉及的领域不断扩大，软件项目的管理越来越困 难。纵观所有失败的软件项目，基本原因是不能管理其软件 过程，在无纪律、混乱的项目状态下，组织不可能从较好的 方法和工具中获益。严谨的软件过程控制与管理不仅可以在 每个阶段回顾和纠正项

16、目的偏差，识别软件项目的风险甚至 果断中止项目，而且可以将人才流动所带来的不利影响减少 到最小。要进行有效的过程控制，必须明确软件项目管理流 程。下图即为软件项目管理流程：接下来详细介绍项目管理过程的步骤包括：项目立项一一启动一一规划一一执行和控制一一收尾阶段1. 软件项目立项包含 5 个环节：发起、评估、申请、审 核、立项。立项流程图2. 项目的启动就是确定项目的目标范围，它主要包括 开发和被开发双方的合同（或是协议） ，软件要完成的主要 功能以及这些功能的量化范围，项目开发的阶段周期等。PMBOK中明确指明项目启动阶段主要的工作是制定项目章程和识别项目干系人。结合软件项目的特点，成功的软件

17、 项目启动包括以下三个方面的工作：1） 制定项目章程项目章程的主要内容：项目的名称和授权日期，项目目 的或批准项目的原因，可测量的项目目标和相关的成功标准， 项目总体要求和概述性的描述，项目的主要风险，总体里程 碑进度计划，总体预算，项目审批要求，委派的项目经理及 其职责和联系方式，项目干系人尤其是发起人或其他批准项 目章程的人员的姓名和职责以及他们的签名，有时包括他们 对项目的承诺。2） 识别项目干系人干系人分析对项目的成功至关重要，一般通过三个步骤 进行干系人的分析，首先是识别可能的干系人，然后进行他 们的影响力分析，最后管理干系人期望。3）项目启动会议项目启动会议的成功与否对整个项目的影

18、响非常大。好 的开始是成功的一半，如果第一次会议中能够表现出公司的 专业性，树立起良好的形象，对日后的项目协调、工作安排 会有良好的推动作用；如果在第一次会议中显得比较被动，不够专业，会让项目的协助方对项目产生疑问，对日后 项目的实验收都会产生负面影响。3. 项目的规划为项目的运作提供可靠的实施基础。在整 个项目中，项目规划是指项目的估算，风险的分析，进度的 规划，人员的选择与配置，产品质量的规划等。然而，在项 目管理的过程中，计划的编制是整个项目规划中最为复杂的 阶段。在计划编制的过程中，我们还可看到后面各阶段的输 出文件。所以说它是指导项目的进程发展。规划建立软件项 目的预算，提供一个控制

19、项目成本的尺度，也为将来的评估 提供参考，它是项目进度安排的依据。最后，形成的项目计 划书将作为跟踪控制的依据。项目规划工作涉及软件项目团队管理、软件项目估算、 风险管理、质量管理、配置管理、进度管理。团队管理：团队就是有两个或两个以上、相互依赖的、 能相互负责的、具有共同的目的和方向的、愿意为共同的目 标而努力的有互补技能的成员组成的群体，并且具有三个特 征：目标、人、领导者。团队的成长过程：形成期、震荡期、正规 规范期、表 现 执行期、收尾期。 软件项目团队角色分类：软件项目经 理，系统分析人员，系统设计人员，开发人员，测试人员， 软件配置管理人员，软件质量保证人员。项目估算：软件项目估算

20、的内容主要包括软件工作产品 的规模估算、 工作量估算、 成本估算和进度估算。 如图所示： 需要进行估算的几个阶段：可行性研究需求说明系统设计系统实现系统运行软件项目估算步骤：1）确定软件项目范围2） 确定完成软件开发所需的资源3） 估算工作量4）估算成本软件项目估算的常见方法 : 代码行法、功能点法、自下 而上法、 类比法、 专家判断法、 参数估算法、 简单估算法等。风险管理：软件风险是软件项目与生俱来的，会阻碍目 标的实现，所以在软件开发中需要风险管理。所谓风险管理 就是为了管理项目中的风险而应用过程、方法和工具的一种实践，它提供一种良好的环境来 作出以下决策：连续的评估项目中存在什么样的风

21、险。确定哪些风险是需要重点考虑的。对重点考虑的风险采取积极的措施来应对。简单归纳软件风险管理工作就是在风险成为影响软件 项目成功的问题之前，识别并着手处理风险的过程。风险管 理是对不确定性和变化的一种应对方式。风险识别的过程：质量管理：软件质量是项目管理的三个目标之一，且成 本和时间这两个目标都只要以质量为基础的。软件项目管理 的好坏直接关系到最终产品能否通过验收、项目能否顺利结 束。质量是软件产品和软件组织的生命线，而软件质量管理 就是稳定这条生命线的标尺。软件质量管理的各过程如下：1） 规划质量。识别项目及其产品的质量要求和标准，并 书面描述项目将如何达到这些要求和标准的过程。2）实施质量

22、保证。审计质量要求和质量控制测量的结 果，确保采用合理的质量标准和操作性定义的过程。3）实施质量控制。监测并记录执行质量活动的结果， 从而评估绩效并建议必要更改过程。结合软件开发项目的特殊性，软件项目质量管理的主要 内容包括编制软件项目的质量计划、软件质量保证和软件质 量控制三个方面。质量计划是质量管理的第一过程域，它主要结合各个公 司的质量方针、产品描述以及质量标准和规则，通过效益、 成本分析和流程设计等工具制定出实施方案，其内容全面反 映用户的需求，为质量小组成员有效工作提供了指南，为项 目小组成员以及项目相关人员了解在项目进行中如何实施 质量保证和控制提供依据，为确保项目质量得到保障提供

23、坚 实的基础。质量保证则是贯穿整个项目全生命周期的有计划 和由系统的活动，经常性的针对整个项目质量计划的执行情 况进行评估、检查、改进等工作，向管理者、顾客或其他方 提供信任，确保项目质量与计划保持一致。质量控制是对阶 段性的成果进行检测、验证，为质量保证提供参考依据，他 是一个PDCA（计戈【J Plan 执行 Do检查 Check纠正 Act） 循环过程。配置管理：软件项目配置管理的目的在于：1）记录软件产品的演化过程2） 确保软件开发者在软件生命周期中的各个阶段都能 得到精确的产品配置3） 最终保证软件产品的完整性、一致性、追溯性、可控性配置管理的过程： 篇三：做配置管理你需要那些知识？

24、我的几年工作总结 做配置管理你需要那些知识？我的几年工作总结。 做配置管理你需要那些知识？ 我在做配置管理以前做过两年的测试，期间做过两家公 司的 iso 9000 的内审员，然后老板觉得我比较有耐心，所 以赶鸭子上架，和前任学习拉一周，我就是配置管理拉，然 后不知不觉， 已经 6年拉，总结一下，看看会需要些什么呢？1、软件公司的开发流程，对软件工程一定要熟悉，尤 其是开发模型，你不能保证公司的所有项目使用一个模型。 比如：瀑布、迭代或者极限编程。只有熟悉这些开发模型， 你才能参与到公司的流程制定中去。2、 熟悉一些标准，比如：iso 9000和cmm。一个公司 想要发展大，想要稳定，就一定会

25、有一套稳定的流程。而熟 悉标准，会更有利于你理解和说服你的同事。记得以前一个 同事说过这样一句话，一个公司想要长大，那一定必须是一 头小象而不能是一只大蚂蚁。而一个做有流程，愿意将公司 的事情流程化的公司才能保证不因人成事，才能长大。3、 沟通能力。配置管理员的工作就是沟通协助需求、 开发及测试人员工作。而一个新的项目的建立意味这大家都 是新人，来自不同的行业不同的公司，公司文化不同，做事 的方法也不同，你只有有好的沟通能力，才能说服项目经理 支持你的工作，才只能说服开发测试人员按你要求的流程工 作。4、编程能力。想做好配置管理，你就不得不编写一些 配置脚本，以方便开发测试人员，同时减少自己的

26、工作量。5、数据库知识。一般来说配置管理员，同时要管理 BUG 跟踪或需求管理的系统，那免不了老板会让你提供一些统计 数据，所以数据库知识也是必不可少的。6、系统知识。多说公司的配置管理员还要负责开发测 试环境的维护，那么有系统知识，无疑可以减少你求助的机 会。现在说说我做过什么？一、上海项目的时候，只是负责系统的配置管理，包括 代码编译，上线，这个系统比较大，但是还好，我是从别人 手上接手的，所以还在顺序。二、集团项目的的时候，我同时维护 9 个省的测试上线 环境。由于用户一直是用 unix 系统，所以顺便学会拉 shell ， 学会来在 ibm ， hp， sun 的小型机上安装配置软件。

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

28、交的时候 , 同时建立开 发和构建分支，同时不能是分支之上建立分支。2、和一个没有任何配置管理经验的开发团队扯皮，扯 开发流程，扯目录结构，扯 Makefile 模板，扯代码命名规 范，然后想办法让他们执行。这个系统很大，到今天，已经有 11 个移动， 3 个通， 3 个电信在使用。分出来的系统现在也有 15 个拉，仅仅营业 和账务两个系统， unix 后台就有 500 多个动态库，当时扯皮， 现在受益。3、和总工办一起搞 unix 主机下的编译选项，由于用户 的环境复杂，所以要求做到，代码写出来后，可以跨 cpu ，跨操作系统、 跨中间件、 跨数据库。所以这个过程让我对 unix 下的编译器

29、熟悉起来， 不然无法做到。 让我自豪的是到现在， 开发人员只要修改 Makefile 模板很少的地方，就可以跨平 台编译拉。4、编写自动编译脚本。 通过我们开发的自动编译系统， 开发人员只要在浏览器中提交编译单就可以自动编译拉。而 如果开始的时候，如果没有将目录规划好，我想自动编译就 是无源之水。 这个系统我们 web 部分用 jsp ，unix 用 tcl/tk 脚本。现在已经集成到 QCS勺源码管理中，还在改进，还在使用。四、 公司的QCS系统（质量控制系统）。这是一个配置管理系统，通过 rsh将CVS和 QCS结合在 一起，用 jsp 和 oracle 的存储过程开发，其中包括：需求 管

30、理、功能点管理、任务管理、源码管理、 bug 管理、工程 故障管理、接口管理、数据库变更管理、版本管理、发布管 理、回退管理等模块的系统。五、 参加公司的EPG小组，并且以配置管理员的身份参 与评审。公司两年前已经通过 CMMI 5 的认证。我加入公司的公 司只是通过拉 CMM2 级。后来由于甲方的要求， 公司开始 CMMI 的认证。这中间有大量的文档要写。尤其是配置管理员，在 几乎所有的过程中， 都要参与评审， 所以准备工作做拉好久。 到 CMMI 5 级的时候，就要提供大量的统计数据来说明持续 改进的结果，所以对 QCS就需要不少地方做改动，来收集数 据。还好公司一直注意这块，我们的各种脚

31、本，模板，都是 尽量的优化以满足开发测试人员的需要。所以后来的评审中 基本没有费什么事就过拉。在这个项目中，让我对配置管理中的很多概念理解很深。 尤其是在评审的时候，将自己平时做的工作用 CMMI的语言讲解，感觉的确是锻炼人。这中间的很多事情，我的感谢我的师傅，虽然他比我年 龄还小，而且也没有带我很久，但是很多问题都是和他讨论 中加深理解的，不管是从技术上，还是为人都让我学之不尽 啊。要做好配置管理，我觉得有几个概念一定要理解清楚： 1、基线。2、配置项。3、变更。4、版本。5、标签或 tag 。这个是理解它的作用。6、工作区及工作区隔离。转 载 请 注 明 源 自 /, 请 保 留 版 权

32、. 本 贴 地 址 ： http:/tid=16353要做好配置管理，一定要耐心、细心、恒心。 冰冻三尺非一日之寒。 希望以上内容能给新入行的同行一点帮助。本 文 来 自 CSDN 博 客 ， 转 载 请 标 明 出 处 ： http:/nuoyazhizhou/archive/XX/12/28/ 篇四：软件项目管理小结 2 篇 软件项目管理已经到了学期的最后，我们 seed 小组的 软件项目也已完工，这一个学期真的是获益匪浅！礼平老师 曾经说我既可以走技术路线也可以走管理路线，一切都看我 自己。真的很是佩服老师的看人眼光，很犀利。我知道，现在的我不是没有能力去做好，只是自己没有去做，一直在殿 外徘徊，不肯付出努力向前迈进。从大一到现在，我的专业 技术一直都是我的短板，理由么，很简单，就是因为自己懒， 不肯花时间去做。从以前不知道自己想做什么，到现在明确 目标，可以说，软件项目管理课程给了我很多灵感，让我