软件配置管理工作总结

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

软件配置管理工作总结

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

软件配置管理实施体会

陈越,fashi@ 随着软件产业的崛起,软件工程技术正吸引着越来越多关注的目光。作为软件工程的一个重要的领域,软件配置管理( Software Configuration Management )也日益受到

人们的重视。在这里,笔者并不打算对软件配置管理的细节进行讨论,几乎任何一本关于软件工程的教材中都有专门的章节对此进行介绍,而是想从一个实践者的角度来阐述关于软件配置管理的一些想法。

一.软件配置管理的目的对于任何一个软件组织(企业)来说,开发出满足用户需求的、高质量的软件产品是其追求的目标。而要实现这一目标的关键是建立起一个稳定、可控、可重用的软件流程

( Software Process )。因为某一软件产品的成败可能维系于关键技术的突破和创新;但对于软件组织而言,要想永葆竞争优势并不断取得成功,那就必须不断地改进它的软件流程。要进行软件流程改进( Software Process Improvement ) 就需要有明确的、量化的对现状的分析和对未来的预期,这些数据来源于对软件过程的度量,而进行度量的前提和基础就是软件配置管理。

与一般制造业相类似,软件流程就像是一条流水线,在它的各个环节上都会有“零部件”产生,它们就是我们所熟悉的程序、相关文档以及数据。这些正是软件配置管理的对象一一(软件)配置项。它

们不仅是大量人力物力投入的结晶,更是开发经验的积累,是软件组

织最宝贵的财富。软件配置管理贯穿于软件开发活动的始终,覆盖了开发活动的各个环节,它的重要作用之一就是要全面的管理保存各个配置项,监控各配置项的状态,并向项目经理及相关的人员报告,从而实现对软件过程的控制。

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

的问题都能尽量得以

避免

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

二.工具的选择古语有云:“工欲善其事,必先利其器。”软

件配置管理是一项十分繁琐的工作,同时又和整个软件的开发活动紧

密地联系在一起,所以在实际工作中更需要有得力的工具辅助。目前常用的配置管理工具主要有MS SourceSafe 、Rational ClearCase 等,这些工具各有所长,因而只有根据项目

的预算和开发组织的些实际情况出发来选择,正所谓“好用就好” 。在这里,笔者提出一些个人的看法供大家参考。

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

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

置库里提供多视角的观察手段,在

逻辑上按照不同的角色分工来组织信息的选取规则和显示方式,从而能根据需要,在开发人员间灵活的进行分工合作。由于我们把配置管理工作立足于软件过程的改进,那么我们所选用的工具最好能具有一定的过程控制的能力,能利用它按照企业本身的开发流程来灵活的建立相应的电子流,并在此过程中记录用于过程度量的相关数据,整合软件过程管理的各个环节,以便于客观的发现问题,高效的解决问题。

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

软件配置管理过程指导说明书(超级实用)

软件配置管理过程指导说明书

目录 1 前言 (2) 1.1 目的 (2) 1.2 适用范围 (2) 1.3 术语名词解释 (2) 2 角色和职责说明 (3) 3 输入 (4) 4 入口准则 (4) 5 配置管理实施 (4) 5.1 配置库结构 (4) 5.1.1 配置库 (4) 5.1.2 配置管理库系统 (6) 5.2 配置管理流程 (6) 5.2.1 配置管理流程图 (6) 5.2.2 配置变更流程图 (7) 5.3 配置标识 (8) 5.3.1 配置库划分 (8) 5.3.2 配置库结构 (8) 5.3.3 配置项命名 (11) 5.3.4 版本编号规范 (11) 5.4 配置管理活动 (12) 5.4.1 制定配置管理计划 (12) 5.4.2 建立配置库 (12) 5.4.3 建立配置项 (12) 5.4.4 基线建立及发布过程 (12) 5.4.5 配置变更 (13) 5.4.6 配置审计 (15) 5.4.7 备份 (16) 6 输出 (16) 7 出口准则 (16) 8 本过程裁剪规定 (16)

1 前言 1.1 目的 用于描述配置管理作用和过程,规范配置管理的实施过程、活动和操作。 1.2 适用范围 适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3 术语名词解释 CCB:Configuration Control Board,配置管理委员会,每个项目组需要建立项目级的CCB作为变更控制权威。CCB由质量工程师、项目经理、测试经理、配置管理员构成,有时也可以包括客户代表、上级质量部门主管。CCB组长可以是质量工程师或质量部领导,但不能是项目经理。 软件配置项:是指软件工程过程中所生产或使用的任何元素,或者是纳入软件产品的元素。它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等,包括:项目文档,源代码,执行程序,相关设备及资料。 软件配置管理:对软件配置项的管理称为软件配置管理。软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。 软件工作产品:由定义、维护和使用一个软件过程所产生的任何人工制品,包括过程描述、计划、规程、计算机程序和相关文档,无论是否打算将它们交给客户或最终用户。 软件产品:可交付给客户或最终用户的软件工作产品的子集称作软件产品 基线:基线,是开发过程中标识出的里程碑所交付的一个或多个配置项,也即指一个(或一组)配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征:(1)已经过正式的评审和批准;(2)作为项目发展和产品升级的基础。(3)基线变更必须经过CCB审批。 变更控制:对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。 版本发布:指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。即交付给客户的一个包括可执行程序和文档的发布基线称为发布(release)。 配置审计:可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性,主要考查软件受控库的结构、内容及其它相关信息,以验证基线和描述它的文档的一致性;功能审计审查配置项内容的正确性与一致性,主要考核配置项在实现功能上的一致性,功能审计主要通过评审和测试报告体现。 物理审计的内容包括: ? 确认配置项标识的正确性; ? 确认已受控配置项的更改是受到控制的; ? 验证配置库内容与相应记录之间的一致性; ? 验证配置管理活动与相应记录之间的一致性; ? 验证配置管理工作是否符合适用的标准和规程; ? 验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括: ? 验证当前基线所含配置项对前一基线所含配置项的追溯性; ? 确认当前基线所含配置项均正确反映了项目需求; ? 评估基线的完整性; ? 验证当前基线和各基线间所含配置项的一致性; 验证配置库内容的完备性和正确性等。

16软件配置管理报告

份号:001 密级: XXXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX公司 XXXX年XX月XX日

辑要页

文档修改记录

目次 1 范围 (1) 1.1标识 (1) 1.2系统概述 (1) 1.3文档概述 (1) 2 引用文挡 (1) 3 软件配置管理情况综述 (1) 4 软件配置管理基本信息 (1) 5 专业组划分及权限分配 (1) 6 配置项记录 (1) 7 变更记录 (2) 8 基线记录 (2) 9 入库记录 (2) 10 出库记录 (2) 11 审核记录 (2) 12 备份记录 (2) 13 测量 (2) 14 主释 (2)

1 范围 1.1 标识 本条应描述本文档所适用的系统和软件的完整标识,适用时,包括其标识号、名称、缩略名、版本号和发布号。 1.2 系统概述 本条应概述本文档所适用的系统和软件的用途。它还应描述系统与软件的一般特性;概述系统开发、运行和维护的历史;标识项目的需方、用户、开发方和保障机构等;标识当前和计划的运行现场;列出其他有关文档。 1.3 文档概述 本条应概括本文档的用途和内容,并描述与其使用有关的保密性考虑。 2 引用文挡 本章应列出引用文档的编号、标题、编写单位、修订版及日期,还应标识不能通过正常采购活动得到的文档的来源。 3 软件配置管理情况综述 本章应描述软件配置管理活动进展,与软件配置管理计划的偏差;软件配置管理活动与规程是否相符;对不符合项所采取的措施;完成软件配置管理工作的工作量等。 4 软件配置管理基本信息 本章应概述软件配置管理的基本信息,包括项目负责人、各级软件配置管理机构组成人员和负责人、软件配置管理所用的资源(如计算机、软件和工具)等。 5 专业组划分及权限分配 本章应列出项目专业组的划分、各专业组的成员以及各成员的权限分配,如专业组可分为项目负责人、开发组、测试组、质量保证组、配置管理组等,权限可分为读出、增加、替换、删除等。 6 配置项记录 本章所列出项目的所有配置项,包括配置项名称、配置项最后发布日期、配置项控制力度(控制力度可分为基线管理、非基线管理(受到管理和控制))、配置项版本变更历史、配置项变更累计次数等内容。

软件开发项目配置管理工具的选择

软件开发项目配置管理工具的选择 通过软件配置管理,将对软件系统中的多重版本实施系统的管理;全面记载系统开发的历史过程,包括为什么修改,谁作了修改,修改了什么;管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制,完整、明确地记载开发过程中的历史变更,形成规范化的文档,不仅使日后的维护和升级得到保证,而且更重要的是,这还会保护宝贵的代码资源,积累软件财富,提高软件重用率,加快投资回报…… 每一个软件项目,无论是工程类项目,还是产品类项目,都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中,将生成各种各样不同的工件,包括文档、源程序、可执行代码、支持库。更可怕的是,频繁出现的变更是不可避免的,因此面向如此庞大且不断变动的信息集,如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题,最早的开发人员尝试过的解决办法是通过手工来实现: 1)文档:每次修改时都另存为一个新的文件,然后通过文件名进行区分,例如"XXX 软件需求说明书V1.0,XXX软件需求说明书V1.1,XXX 软件需求说明书V2.0.",并且在文件中注明每次版本变化的内容; 2) 源代码:每次要修改时就将整个工程目录复制一份,将原来的文件夹进行改名,例如"XX 项目V1.0、XX 项目1.01、.",然后在新的目录中进行修改; 但是这种方法,不仅十分繁琐,容易出错,而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时,还是会造成很大的混乱。很显然,这样简陋的方法是无法应对这一问题的。后来,有人尝试从制造工业领域引入了"配置管理"这一概念,通过不懈的研究与实践,最终形成了一套管理办法和活动原则,这也就是软件配置管理。 通过软件配置管理,将对软件系统中的多重版本实施系统的管理;全面记载系统开发的历史过程,包括为什么修改,谁作了修改,修改了什么;管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制,完整、明确地记载开发过程中的历史变更,形成规范化的文档,不仅使日后的维护和升级得到保证,而且更重要的是,这还会保护宝贵的代码资源,积累软件财富,提高软件重用率,加快投资回报。 常见的配置管理工具 正如前面所述,由于软件配置管理过程十分繁杂,管理对象错综复杂,如果是采用人工的办法不仅费时费力,还容易出错,产生大量的废品。因此,引入一些自动化工具是十分有裨益的,这也是做好配置管理的必要条件。 正是因为如此,市场上出现了大量的自动化配置管理工具,这些工具的实现原理与基本机制

软件配置管理流程

配置管理流程规定 (Ver1.0) 拟制:___________________ 审核:___________________ 签发:___________________

目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)

1.配置管理流程 1.1概述 规范配置管理活动,确保配置项正确地唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图

1.3软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 1.4软件设计阶段 参加设计阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计,配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后,建立设计基线。 1.5制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 1.6配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限 项目经理: 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划,并按相关规定贯彻执行; 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求; 5)提出管理管理的建议和要求。 配置管理员 1)编制配置管理计划; 2)执行配置项管理; 3)执行版本控制和变更控制方案; 4)编制配置状态报告; 5)配置库的建立和权限分配; 6)配置管理工具的日常管理与维护; 7)配置库的日常操作和维护 开发人员

软件配置管理报告

份号:001密级: XXXXXXX项目 软件配置管理报告 XXXX-RPB-R01.00 XXXXXXXX 公司 XXXX 年XX月XX日

辑要页

摘要: 主题词:

文档修改记录

1范围............................................................................................... 1.1标识.......................................................................................... 1.2系统概述...................................................................................... 1.3文档概述......................................................................... 1........... 2引用文挡........................................................................................... 3软件配置管理情况综述............................................................................. 4软件配置管理基本信息............................................................................. 5专业组划分及权限分酉己.......................................................................... 6配置项记录......................................................................................... 7变更记录........................................................................................... 8基线记录........................................................................................... 9入库记录...........................................................................................

软件项目配置管理系统计划清单指导应用清单

中国核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注:如无受控文件标识(蓝色印章)则为非有效版本,以受控文件规定为准。 此文件属中国核电集团所有,未经许可,不得以任何方式外传。

修改记录页

目录 (一)基本信息 (4) (二)角色与职责 (4) (三)配置管理资源 (5) (四)权限分配 (5) (五)配置项计划 (6) (六)配置库基线 (7) (七)配置库备份计划 (8) (八)配置库状态报告 (8) (九)配置审核 (9) (十)审批意见 (9)

配置管理计划(一)基本信息 项目名称: 项目代号: 立项时间: 预计主要项目阶段有: 配置项目命名规则依据: (二)角色与职责

(三)配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理,并提供更新、检索和历史版本的恢复。 提示: (1)配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。 (2)配置管理员根据所采用的配置管理软件,确定计算机资源(考虑存、外存、CPU等)。 预计建库申请日期: 预计建库日期: 预计工作库需空间: (四)权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域的设置相同。 若个人要求另行设置的,由项目组配置管理员负责汇总后,提交给高级配置管理员调整设置。

(五)配置项计划 填写上面表格过程中,需要对照成果物列表逐项填写。

SCMS软件配置管理过程

C M M文件软件配置管理过程 XXXXXXXXXXXX (版权所有,翻版必究)

文档变更请求(DCR)

文档变更记录

目录 1 概述 (1) 1.1 目的 (1) 1.2 范围 (1) 1.3 术语与定义 (1) 1.4 参考文档 (1) 1.5 引用文档 (2) 2 过程目标 (2) 3 过程定义 (2) 3.1 责任人 (2) 3.2 输入 (3) 3.3 入口准则 (3) 3.4 过程活动 (3) 3.5 出口准则 (6) 3.6 输出 (6) 附录 A :软件配置项/产品包标识 (8) A.1 文档的编号 (8) A.2 程序的名称 (9) A.3 软件产品包的标识 (9) A.4 系统、数据库、开发与支持软件工具的编号 (9) 附录 B :配置项状态报告 (10) B.1 系统软件、数据库、开发与支持软件工具列表 (10) B.2 软件基线/配置项状态报告 (10) B.3 软件基线软件基线变更报告 (10) 附录 C :软件配置管理测量报告 (11)

1概述 1.1目的 软件配置管理(简写为SCM)是维护项目软件整个生命周期产品完整性的重要活动,本文档明确规定了公司软件配置管理活动的目标和过程定义,为公司软件配置管理提供所遵循的过程、程序和指导方针。 1.2范围 本文档适用于管理公司所有软件项目在各阶段标识的软件配置。软件配置管理的大部分活动用“软件配置管理工具”实现。 1.3术语与定义 1.3.1软件工作产品:作为定义、维护或应用软件过程的一部分所生成的任何人工制品,包括过程描述、 计划、规程、计算机程序和相关文档,这些可能交付也可能不交付给顾客或最终用户。 1.3.2软件基线:软件配置项经软件验证、确认、评审和认定后,形成了软件基线,也就成了该阶段的一 个基准。下一个阶段只能在这个基准上进行开发活动。 1.3.3软件配置项:是指一个软件产品在软件生存周期各个阶段所产生或应用的各种形式(机器可读或人 工可读)和各种版本的文档、程序及其数据。 1.3.4SCCB:软件配置管理委员会(Software Configuration Control Board)(关于责任,参见“责任 人”)。 1.3.5SCM:软件配置管理(Software Configuration Management) 包括了标识软件工作产品、控制对 软件工作产品的更改、和维护在整个软件生存周期中的软件工作产品的完整性和可跟踪性。 1.4参考文档 1.4.1Mark C. Paulk,Bill Curtis,Mary Beth Chrissis,Charles V. Weber,Capability Maturity Model for Software (Version 1.1) 1.4.2Roger S. Pressman,Software Engineering –A Practitioner’s Approach (Fourth Edition) 1.4.3《计算机软件配置管理计划规范》GB/T 12505-90

35配置管理办法

配置管理办法 文件名称:配置管理管理办法 文件编号:ZHWH-CM-01-2017 文件类别:技术管理 编制部门:北京中航鼎成科技有限公司质量管理部 版本号: A 文件密级:秘密 受控标识:受控 拟制/日期:黄妙然 2017年09月27日 审核/日期:刘晔 2017年10月15日 会签: 批准/日期:杨成 2017年11月1日

修订页

目录 第1章目的和范围 (1) 第2章角色和职责 (1) 第3章定义和术语 (2) 第4章配置库管理及规划 (2) 第5章配置管理流程图及活动说明 (2) 5.1 研发配置管理流程图及活动说明 (2) 第6章度量数据收集 (6) 第7章相关文件和记录 (6)

北京中航鼎成科技有限公司配置管理管理办法 第1章目的和范围 为规范北京中航鼎成科技有限公司在项目生命周期过程中的配置管理活动,确保在项目的整个生命周期中建立和维护项目产品的完整性、正确性、可追溯性和一致性,保证项目过程中配置管理相关工作满足公司质量体系要求,特制定北京中航鼎成科技有限公司配置管理规范。 本文档适用于北京中航鼎成科技有限公司所有项目的配置管理活动。 第2章角色和职责

注1:“配置变更控制”参见《TDCS/CTC综合维护平台产品变更实施细则》,本文不再说明,配置项拟审批原则参见《北京中航鼎成科技有限公司配置项清单》。 第3章定义和术语 (1)基线:BaseLine,就是经过正式评审和认可的工作产品,它是以后进一步开发的基础。基线分为过程基线和交付基线。 (2)配置项:配置是指在项目生命周期各个阶段所产生的各种形式和各种版本的文档、程序及其数据的集合,该集合中的每一个元素称为该配置中的一个配置项。配置项分为基线配置项和非基线配置项。(3)基线配置项:一般组成产品元素的配置项均要定义成基线配置项,如产品需求、设计文件、源代码、测试文件等均要定义成基线配置项,基线发布后所有的变更都要严格按照《北京中航鼎成科技有限公司产品变更实施细则》执行。 (4)非基线配置项:一般非产品组成元素的配置项可以定义为非基线配置项,如项目计划、评审类等。 非本项目控制的工作产品,但为了共享和最新版本的获取,该类元素作为非基线配置项也纳入配置管理库,如外部文件、标准、参考文件、会议纪要、工作报告、过程记录等。 第4章配置库管理及规划 配置库管理及规划如下: 1)研发项目(含工程项目的定制开发):按照产品线进行规划管理; 2)工程项目:按项目管理、工程实施过程两大块进行规划管理; 第5章配置管理流程图及活动说明 5.1 研发配置管理流程图及活动说明 5.1.1研发配置管理流程图

【项目管理知识】从项目管理角度看软件配置管理

从项目管理角度看软件配置管理 项目的目地是为了创造一项产品或服务,因此,产品本身的生产工艺必然会成为项目管理过程的核心内容。无论在哪一种软件工程方法中,软件配置管理都是一项不可或缺的重要管理内容,特别是对于服务企业内部的信息技术部门来说,从产品生命周期出发,同时支持服务产品和软件产品,同时负责开发与运行,其管理复杂度很高,要想理顺各项工作的内部关系、理清各项工作之间的配合关系,都离不开配置管理这个基本手段,它是许多管理工作的“落地”部分。其实,配置管理并不是一个时髦的概念,在许多传统行业(例如制造业)中早已有之,软件行业只是在软件工程方法中继续延用了这一概念,它是一流软件开发企业所必备的基础设施。 在项目管理中,配置管理是一种重要的管理手段。在PMI的PMBOK中对于配置管理系统是这样描述的: 由此可见,配置管理是一个非常宽泛的概念,项目中只要是需要进行管理的任何特性,都可以纳入配置管理。配置管理不只是操作层面的问题,更是管理理念、管理方法的问题,是一个系统。 项目范围管理需要配置管理来落实 在项目范围管理中,需要识别和控制项目的交付成果,要描述交付物应有的各种特性。这些交付物及其特性,就是配置管理中的配置项。从项目管理的角度,WBS只需要分解到可管理(Manageable)的程度,而配置管理则要求分解到终可操作的程度,管理的粒度更为精细。因此,良好的配置管理机制,是项目范围管理得到终落实的保证。 在许多软件开发项目中,项目范围管理涉及三个方面:业务需求、技术结构、投产服务。编写哪些程序模块,实现哪些功能,部署到哪些地点,这其实

都是项目范围管理所要关注的内容,在配置管理中对应了产品的物理属性和功能属性以及服务的属性,都可以通过配置管理来识别、记录和跟踪。只有做好软件配置管理,才能真正把项目的范围管理做实。 业务需求决定了软件产品的功能特性,对软件产品的配置管理,首先就是对业务需求的管理。在业务需求中,要求软件产品所提供的各种功能和特性,包括界面风格、操作方式、处理流程、业务规则、数据逻辑等,也都是软件产品的配置项,这种对业务需求的分解、管理的过程,就是对业务需求中的配置项的管理过程。当项目中业务需求发生变更时,其实就是对这些配置项的变更管理。因此,在软件工程过程中,配置管理是需求管理的基本手段,通过科学、严谨的配置管理方法,对业务需求进行识别、分解、跟踪、控制,直接决定了对业务需求的管理能力。许多公司目前在需求管理方面还处于粗放型的管理,虽然基本能够满足项目管理的需要,但对于软件工程过程来说,管理粒度还比较粗,而且缺乏明确的配置项的定义,缺少有效的跟踪控制手段,还需要更精细的管理。 技术结构是软件产品的物理属性,软件产品的配置管理,也是对软件内部技术结构的管理。从技术方案到软件产品、再到产品内部结构,这也是项目范围不断分解、细化的过程。为了实现业务需求、满足产品外部特征的要求,软件产品应如何设计其内部结构,划分内部模块、定义模块接口、确定有多少个程序等等,产品分解到后,每一个程序都作为一个单独的配置项进行管理,在开发过程中对于程序的修改都纳入配置管理,跟踪程序变化过程。这种对软件产品从技术角度的不断分解和定义,就是基于技术结构的配置项管理,是与软件结构设计相对应的,配置项的划分是否合理,使用起来是否灵活、方便,哪些可以成为公共组件(Component),其实反映的都是软件设计的思想。在有的软件企业中,配置管理不只是程序员的操作工具,它已经成为工程技术管理的

软件配置管理流程

软件配置管理流程

目录 1.配置管理流程 (3) 1.1 概述 (3) 1.2 总体流程图 (3) 1.3 软件需求分析阶段 (4) 1.4 软件设计阶段 (4) 1.5 制定配置管理计划 (4) 1.6 配置库管理 (4) 1.6.1 相关人员分配权限 (4) 1.6.2 配置项 (5) 1.7 版本控制 (6) 1.8 变更控制 (6) 1.9 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9)

1.配置管理流程 概述 规范配置管理活动,明确配置项正确的唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 总体流程图

软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 软件设计阶段 参加涉及阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计,配置时应说明系统设计的版本于需求分析报告版本的对应关系。设计书评审通过后,建立设计基线。 制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 相关人员分配权限 项目经理: 1)与(有关负责人员)协商确定项目起始基线; 2)接受配置管理计划,并按相关规定贯彻执行; 3)接受配置控制委员会的报告; 4)提出配置管理计划的修改要求; 5)提出管理的建议和要求。 配置管理员 1)编制配置管理计划; 2)执行配置项管理; 3)执行版本控制和变更控制方案; 4)编制配置状态报告; 5)配置库的建立和权限分配; 6)配置管理工具的日常管理与维护; 7)配置库的日常操作和维护; 开发人员 1)根据确定的配置管理计划和相关规定,提交配置项

软件配置管理实验报告-SVN

软件过程管理 实验报告 (2011/ 2012 学年第二学期) 实验报告 指导教师 实验名称软件配置管理-SVN的安装配 置和使用 实验类型验证实验学时 2 实验时间一、实验目的和要求 掌握开源软件配置工具SVN的安装配置和使用。 二、实验环境(实验设备) PC机,V isual SVN Server ,Tortoise SVN

三、实验原理及内容 实验内容:1.安装SVN服务器端软件Visual SVN Server及配置。 2.安装SVN客户端软件Tortoise SVN及配置。 实验步骤: 1.安装服务器端Visual SVN Server 2.安装客户端Tortoise CVS 3.配置SVN服务器的用户,用户组和权限 4.客户端机器上,新建一个工作目录,执行检出操作。 5.修改版本库 6.SVN分支与合并 实验报告

四、实验小结(包括问题和解决方法、心得体会、意见与建议等) svn(subversion)是近年来崛起的版本管理工具,是cvs的接班人。目前,绝大多数开源软件都使用svn作为代码版本管理软件。 SVN采用virtual copy(虚拟拷贝)的方式创建分支.创建后展现给客户端的是独立的库路径,而实际上和主版本共用同样的数据,哪怕是创建多个分支.因此,完全不用担心创建多个分支会增加磁盘的占用空间,而且,其创建效率也是非常高的,官方的说法是constant time(恒定时间),无论你的库有多大,其创建分支的时间基本上是恒定的。 SubV ersion官方建议SVN库根目录应包括Trunk和Branches,这是两个最基本的目录.其实其目录结构可以是任意的.一般Trunk存放主版本,Branches存放众多的分支版本.如下图所示EAS100C的SVN目录结构.因此可以把EditionG3和EditionContracts放在Branches目录. 如何创建分支 TortoiseSVN是官方SVN客户端,以性能好,对Subversion支持全面而被广泛使用.(Tortoise,海龟,无明确寓意). 有多种方式可创建分支. 方式一 第一种方式是采用浏览模式,这种方式简单,快捷,会以当前trunk的最新修订本创建分支,无其他可选项.见完整图示: (1)右键,选择Repo-browser

软件配置管理计划示例

软件配置管理计划示例 作者:赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1.1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款,以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求,能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统(其中包括为本项目研制或选用的各种支持软件)时,都应该执行本计划中的有关规定,但可以根据各自的情况对本计划作适当的剪裁,以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1.2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1.3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理

2.1 机构 在本软件系统整个开发期间,必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导,由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成,由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导,在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求,制订必要的规程和规定,以确保完全遵守本计划规定的所有要求。 2.2 任务 在软件工程化生产的各个阶段中,与本阶段的阶段产品有关的全部信息在软件开发库存放,与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中,开发者和开发小组长有权对本阶段的阶段产品作必要的修改;但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时,就必须通过项目的配置管理小组办理正规的审批手续。因此,软件开发库属开发这个阶段产品的开发者管理,而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后,应该送入软件产品库,如欲对其修改,必须经软件配置管理小组研究同意,然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续,将在第条中详细规定。 2.3 职责 在软件配置管理小组中,各类人员要互相配合、分工协作,共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下: A.组长是总体组代表,他对有关软件配置管理的各项工作全面负责,特别要对更改建议的审批和评审负责; B.软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范; C.项目的专职配置管理人员检查在作配置更改时的质量保证措施; D.各子系统的配置管理人员具体负责实施各自的配置管理工作,并参与各子系统的功能配置检查和物理配置检查;

it运维年终工作总结

it运维年终工作总结 作为整个企业的IT“管家”,首先应该对管理的资产情况了然于胸。比如说: 现在的IT规模是怎样的?网络链路总长是多少?网络设备和服务器的数量、类型各是什么?都是什么品牌的?还有每个服务器上运行的数据库、中间件的类型和数量等等,这些情况都应该一个不漏、有条理地梳理清楚。 搞清楚“有什么”的问题以后,还应该做个比较,目前的资产情况和历年相比有什么变化,是增加还是减少了,这些变动都体现在哪里?这些数据整理出来,一张清晰的“资产图”便被轻松地“绘制”出来了 二、业务构成及分析 一个企业里,最重要的应该就是业务系统的稳定运行和增效。所以IT运维管理员的总结里,必然不能缺少对业务系统保障情况的描述。 首先也应该勾勒出“业务”的大体形象:目前我们所有的业务系统有哪些?哪些是核心的业务,它们在解决何种问题,为用户提供了哪些服务?这些业务又运行在哪些服务器上,它们的运行状态如何…?这样我们先直观地把“业务系统”介绍给大家。 接下来我们可以深入地去剖析一下这些业务的运行状况,比如:我们的业务系统一年中平均每月主干链路的总流量达到了多少?将这些业务流量排名,前几位的是哪些?这些高流量的业务有多少人次在

访问?这些业务的平均无故障运行时间是多少?根据其设计,这些业务的可用性指标达到多少?是远未达到使用预设,差一些到满负荷,还是已经超负荷…等等。还有“变化”的视角是应该一直具备的,还需要与往年比,哪些业务是新增的,这些新增业务的使用情况如何,是用得较多还是较少? 三、事件处理情况 对一年中所做的事件处理情况进行汇总。你是否能说清楚IT部门这一年处理的事件数量有多少?这些事件分类有哪些?哪些是重大事件?这一年里产生过哪些重大的事件?这些重大事件对整个IT系统的影响是什么?是否针对此进行过全面的分析,并给到过改进的意见?采取了哪些措施保障了核心业务的SLA?这些数据也有助于对全年的运维工作进行了解。 四、未来工作开展建议 一份年终总结,除了要说清楚这一年发生的事儿,还应该能对下一年乃至未来几年的工作开展提供客观依据。并且作为一个合格的IT运维管理员,眼界应该更宽一些,除了着眼于本职工作,也应该不断地关注业界的新技术、新趋势,并去分析这些新技术对本企业的IT规划是否会产生影响,可能产生的影响又是什么?结合之前对业务使用情况的统计和分析,你就可以为决策者提供出一些更有意义的信息和建议:未来企业上马一些什么样的IT业务能为企业可持续发展带来先机,哪些IT系统需要改进以满足未来不断增长的需要等等。

校务通管理系统软件项目配置管理计划案例

软件项目配置管理计划案例 本案例选自《软件项目管理案例教程》(韩万江,机械工业出版社)一书,项目案例为《校务通管理系统》,该项目的配置管理计划如下: 1. 引言 包括目的、缩写词和参考资料,具体内容略。 2.组织及职责 配置管理的角色和职责见表1。 表1:配置管理角色职责表 3.配置管理环境 由于本项目属于中小型项目,工期也不很长,而且项目组人员对Visual SourceSafe也比较熟悉,所以采用Visual SourceSafe作为配置管理工具。 3.1配置库目录结构

3.2用户及权限 4.配置管理活动 4.1 配置项标志 4.1.1 命名规范 本项目配置项命名规范由5个字段组成,从左到右依次为:公司、项目、类型、编号和版本号,如图1所示。这些字段用一横线(-)分隔。

图1:配置项命名规范 4.1.2 主要配置项 QTD-School –RM –SRS-v1.0 公司:3个字符 项目:最长10个字符 类型:最长5个字符 编号:最长8位数字/字符 版本号:V m.n

4.1.3 项目基线 在Visual SourceSafe中基线由LABLE标志,字母必须为大写。基线管理由项目执行负责人确认、SCCB授权,由配置管理员执行。 表5 4.1.4 配置项的版本管理 配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支:主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。 这四类工作空间(分支)由项目执行负责人统一管理,根据各开发阶段的实际情况定制相应的版本选取规则,来保证开发活动的正常运作。在变更发生时,应及时做好基线的推进。 对配置项的版本管理在不同分支具有不同的策略: (1)主干分支 系统默认自动建立的物理分支——主干分支(/main),基线均以LABLE方式出现在主干分支上。 (2)私有分支 如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不与管理,如个别私有空间上的版本树过于冗余,将对其冗余版本进行限制。 (3)小组分支 如果出现小组共同开发一配置项,该分支可视为项目组内部分组的私有空间,存放代码开发过程中的版本分支,由项目组内部控制。

软件配置管理规范流程

1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动,确保配置项正确地唯一标识并且易于存取,保证基线配置项的更改受控,明确基线状态,在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围 本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动,针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法,本文件以CVS(并行版本系统)配置管理工具为例,规定公司的配置管理办法,使用其他工具时也可对应本文件的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理(Software Configuration Management,SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项(Configuration Item,CI) 凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的。 每个配置项的主要属性有:名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里,确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线(Baseline) 在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”。每一

软件项目-配置管理总结-模板

XXX项目 配置管理总结模板 版本:V1.0 XXXX年XX月

1配置管理工作总结 (1) 1.1配置项按计划入库情况 (1) 1.2配置项变更情况 (1) 1.3配置管理工作统计 (1) 2经验教训 (2) 3好的实践 (2) 4对配置管理改进的建议 (2) 5模板补充说明 (2) 5.1关于字体 (2) 5.2关于页眉页脚 (2) 5.3关于图、表 (3)

1 配置管理工作总结 [介绍项目中的配置管理情况,与配置管理计划对比,进行总结,包括进行了什么培训、进行了什么审计、发现问题的情况、问题处理的情况,配置管理的工作量,工具支持、指导情况] 1.1 配置项按计划入库情况 表1-1 1.2 配置项变更情况 表1-2 1.3 配置管理工作统计 [包括进行了什么审计、进行了什么变更等]

[介绍在项目的配置管理中遇到了一些什么问题,并介绍如何解决] 3 好的实践 1、产生较好执行效果的过程或活动;好的方式、方法和技巧,尽可能具体,便于在公 司或其它项目组推广;好的经验 2、列出配置管理推荐出来的项目优秀范例或方法的清单 4 对配置管理改进的建议 [列出对配置管理的改进意见和建议] 5 模板补充说明 5.1 关于字体 ●封面题名项目计划一号黑体 ●大标题 1 项目目标黑体二号 ●一级节标题 1.1质量目标黑体三号 ●二级节标题 1.1.1过程质量黑体四号 ●三级节及以下标题 1.1.1.1测试过程质量黑体小四号 ●正文测试过程质量要求宋体小四号 ●表及表题表1-1 黑体五号 ●英文和数字字体采取Arial 5.2 关于页眉页脚 ●封面:没有页眉页脚; ●版本及目录:页眉为文档名称;页角中的页码采取罗马数字,从Ⅰ开始; ●正文:页眉与版本及目录一致,为文档名称;页码编号采取阿拉伯数字,从1开始。

软件配置管理规范流程模板

软件配置管理规范 流程 1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件

的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再

相关文档
最新文档