软件配置管理计划

1 / 29 软件配置管理计划 计划一：软件配置管理计划 1 引言 1 1 目的 本计划的目的在于对所开发的 CADCSC 软件规定各种必要的配置管理条款，以保证所交付的 CADCSC 软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后 的计划必须经总体组批准。 1 2 定义 2 / 29 本计 划中 用到 的一 些术 语的 定义按 GB/T11457 和GB/T12504。 1 3 参考资料 GB/T11457 软件工程术语 GB8566 计算机软件开发规范 GB8567 计算机软件产品开发文件编制指南 GB/T12504 计算机软件质量保证计划规范 GB/T12505 计算机软件配置管理计划规范 CADCSC 软件质量保证计划 2 管理 2 1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组3 / 29 负责配置管理工 作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规 定的所有要求。 2 2 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理4 / 29 小组管理。软件经过组装与系统测试后，应该送入软件产品库，如 欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2 3 职责 在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C项目的专职配置管理人员检查在作配置更改时的质量保 证措施； D各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查； 5 / 29 E用户代表负责反映用户对配置管理的要求，并协助检查各类人员对软件配置管理计划的执行情况； F项目专职的配置管理人员协助组长开展各项软件配置管理活动，负责审查所采用的配置管理工具、技术和方法，并负责汇总、维护和保存有关软件配置管理活动的各项记录。 2 4 接口控制 对各类接口进行严格、合理的控制，是软件配置管理中最重要的任务之一。整个软件项目及其各子系统都必须对进行严格的控制。在工程化软件系统中，主要的接口有如下五类： A用户界面：用户界面是指各子系统与设计人员、用户或维护人员之间的操作约定。同时还指实现这些操作约定的物理部件的功能与性能特性。 B系统内部接口：系统内部接口是指各子系统在集成为一个总的软件系统时的各种连接约定。 6 / 29 C标准程序接口：标准程序接口是指各应用子系统与标准子程序库（包括宿主计算机系统已有的库程序）之间的调用约定。 D设备接口：设备接口是指各子系统与各种设备（包括终端和其他各种输入 /输出设备）之间的连接约定。 E软件接口：软件接口是指各个子系统与宿主计算机上的系统软件以及与调用本软件的其它软件系统之间的连接约定。以上五类接口是一个软件系统各项配置的重要组成部分。对接口修改进行合理的控制，是软件配置管理的重要任务之一。这五类接口都涉及到 CADCSC 软件系统的全局，因此，当要求对这五类接口中的任一类接口进行修改时，都必须办理正规的审批手续，最后要经项目总体组批准。具体的审批程序将在本计划的第条中规定（可参阅表 1）。 表 1 两类修改的审批程序 步骤 A 类修改的审批程序 B 类修改的审批程序 1 发现问题，填写 软件问题报告单发现问题，填写软件问题报告单 7 / 29 2 项目组长评审项目组长评审 3 软件配置管理小组评审子系统配置管理人员评审 4 项目总体组批准子系统负责人批准 5 修改配置并填写软件修改报告单修改配置并填写软件修改报告单 6 项目组长评审项目组长评审 7 软件质量保证小组评审子系统质量保证人员评审 8 总体组批准项目的软件配置管理小组与子系统负责人共同批准并报项目总体组备索 2 5 软件配置管理计划的实现 在实现软件配置管理计划的过程中，要特别注意实现以下三个里程碑： 8 / 29 A建立软件配置管理小组：在项目总体组批准软件配置管理计划之后，立即成立软件配置管理小组； B建立各阶段的配置基线：随着 CADCSC 软件系统及其所属各子系统的任务书的评审和批准，建立起功能基线；随着总体组编写的 CADCSC 软件需求规格说明书的批准，建立起指派基线；随着 CADCSC 工程化软件系统的集成与系统测试的完成，建立起产品基线。 C建立软件库：在本项目所属的各个子系统的研制工作的开始，就建立起各个子系统的软件开发库，并在本项目配置管理小组的计算机上建立起有关该系统及其子系统的软件 受控库。以后在每个开发阶段的结束，建立各个子系统的新的开发库，同时把这个阶段的阶段产品送入总的软件受控库，并在各个子系统的计算机上建立软件受控库的副本。软件受控库必须以主软件受控库为准。当全部开发工作结束，在配置管理小组的计算机上建立起软件产品库，并在各子系统的计算机上建立软件产品库的副本。 2 6 适用的标准、条例和约定 除应奠定本计划第条中指出的参考资料以及本计划中的9 / 29 其他章条所作的各项规定外，还应该遵守如下标准、条例和约定： A软件开发库、软件受控库与软件产品库的操作规程与管理规程； B系统、子系统、模块和程序单元的命名约定； C文档和测试用例的命名和管理规程。 这引起命名约定、操作规程与管理规程应由 CADCSC 项目技术组负责制订，并应认真听取各子系统项目负责人的意见，最后报项目总体组审批。在执行过程中，如果发现某些条款需要修改，则必须办理正规的审批手续，最后要经项目总体组批准。具体的审批程序将在本计划的第条中规定。 3 软件配置管理活动 3 1 配置标识 3 1 1 文档 10 / 29 所有为本项目编制的文档，都要符合 GB8567 中的规定。CADCSC 软件系统 及其所属的各个子系统所编写的文档数目，可根据 GB8567 的规定作适当的剪裁。剪裁方案由技术组提出建议，报总体组批准。 3 1 2 程序 所有属于本项目的程序、分程序、模块和程序单元，都要按照由项目技术组制订，且经总体组批准的软件系统的命名约定的规定来标识。 3 1 3 各类基线 所有属于本项目及其各子系统的各类基线，首先要按照任务书、软件需求规格说明书的规定确定其技术内容，然后按照软件系统的上述命名约定的规定来标识。 3 2 配置控制 软件配置的更改管理适用于本项目的所有文档和 代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。配置控制的要点如下： 11 / 29 A修改批准权限；对本项目各个子系统及其专用支持软件的功能基线、指派基线、产品基线及其集成系统的任何修改（称为 A 类修改），都必须通过项目配置管理小组讨论，并必须经总体组批准；对本项目各个子系统及其专用支持软件的其他阶段产品的任何修改（称为 B 类修改），都必须通过本项目各个子系统的配置管理人员审查，并经项目的软件配置管理小组与各个子系统负责人的共同批准并报项目总体组备案。 B修改审批程序：上述两类修改的审批 程序如表 1。 C修改控制工具：修改控制工具是协助软件配置管理人员进行配置控制的有效手段。 3 3 配置状态审计 利用软件问题报告单和软件修改报告单对项目子系统及其支持软件的配置状态进行追踪。对软件问题报告单和软件修改报告单的追踪应由软件配置管理工具自动实现，用户可通过该软件系统对其进行查询。注：本计划在此处应给出软件问题报告单与软件修改报告单的具体格式，并作出必要的12 / 29 说明。鉴于本计划拟采用附录 B（参考件）中建议的格式，因而这两个报告单的格式及其说明可参阅附录 B。 3 4 配置的检查和评审 项目软件配置管理小组要对所有由第三方提供的软件进行物理配置检查；对本项目及其各个子系统的每一个新的释放进行功能配置检查和物理配置检查；对宿主计算机系统所提供的软件和硬件配置要每隔半年检查一次；在软件验收前要对宿主计算机系统、各个子系统及其专用支持软件的配置进行综合检查。 在软件开发周期各阶段的评审与检查工作中，要对该阶段所进行的配置管理工作进行必要的评审和检查。应该进行评审与检查的内容与次数，由 CADCSC 软件质量计划规定。配置修改的审批程序按本计划第条的规定处理（见表 1）。 4 工具、技 术和方法 在软件的开发过程中，与软件配置有关的工具有软件测试工具、软件配置管理工具、文档辅助生成工具与图形编辑工具等到三种。 13 / 29 A C 软件测试工具：它支持用 C 语言编写的模块的静态分析、结构测试与功能测试。主要功能为：协助测试人员判断程序结构与变量使用情况是否有错；给测试人员提供模块语句覆盖 C0 和分支覆盖率 C1 的值、并显示未覆盖语句和未覆盖分支的号码及其分支谓词，给出不同测试用例有效性的表格；同时提出功能测试的有效情况，并协助组织最终交付给用户的有效测试用例的集合。 B软件配置管理工具：它支 持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织；支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的涉及范围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理。 C文档辅助生成工具与图形编辑工具：它主要协助用户绘制描述程序流程与结构的 DFD 图与 SC 图、绘制描述软件功能（输入、输出关系）的曲线以及绘制描述系统特性的一些其他图形，同时还可生成若干与 CADCSC 软件文档编制大纲适应的文档模板。用户利用这个工具的正文与图形编辑功能以及上述辅助功能，可以比较方 便地产生清晰悦目的文档，也有利于对文档进行更改，这有助于提高文档的编制质14 / 29 量。 有关这些工具的详细需求可参阅这三项工具的需求规格说明书中的规定。 5 对供货单位的控制 CADCSC 项目所属的各个子系统开发组如果需要从软件销售单位购买、委托其他开发单位、从开发单位现存软件库选用或从项目委托单位或用户的现有连锁反应加中选用软件时，则在选用前应向 CADCSC 总体组报告，然后由 CADCSC 总体组组织 软件选用评审小组 进行评审、测试与检查，只有当演示成功、测试合格后才能批准使用。如果只选用其中部分内容 ，则按等待开发软件的处理过程办理，此时 CADCSC总体组不予预。在进行上述工作过程中，软件配置管理人员要进行下列工作： A项目的软件配置管理小组要参加对上述四类由间接供货单位提供的软件的物理配置检查；这些软件的功能配置检查由项目的软件质量保证小组负责。 B在这些软件送入软件受控库与其他软件成分进行组装15 / 29 之前，软件配置管理小组要对其存放媒体和配置标识进行认真的审查。 C由软件质量保证小组审查选用的上述四类软件，必须经过正式的验收手续，并由项目技术管理小组负责人批准，然后置于软件配置管理小 组的控制之下。 6 记录的惧维护和保存在本项目及其所属的各个子系统的研制与开发期间，要进行各种软件配置管理活动。准确记录、及时分析并妥善存放有关这些活动的记录，对这些软件的下沉运行与维护工作十分有利。在软件配置管理小组中，应有专人负责收集、汇总与保存这些记录。 A基础上组装系统、各个子系统、专用支持软件及选用软件的功能基线、指派基线与产品基线要送入软盘或磁带，至少必须一式两份且存放在两个不同的地点。这些记录应该每 6 个月拷贝一次，以免意外损伤与自然老化。 B上述这些软件的文档也应送入软盘或磁带，至 少必须工式两份且存放在两个不同的地点，并应有一份打印的硬拷贝。磁媒体应该每隔 6 个月拷贝一次，以免意外损伤与自然老化。 16 / 29 C软件产品的源程序、测试数据、测试报告及其他有关文档，除了按 A、 B 规定妥善存放外，要在项目结束后再保存 2 年，或在条件成熟时转交给这些软件产品的生产系统。 注：具体保存年限要根据项目的性质与开发单位的任务来确定，此处仅作为一个示例。 D上述这些软件的各项配置的个性状态、评审记录与修改历史，要作为这些软件的历史 记录来保存，目前可用打印硬拷贝一式两份存放，有条件时再转移到在线光学存储媒体中。 E鉴于处理版权或清理财务的需要，本软件系统的各项配置可能要求存放 57 年，但由于我国对这些问题尚无明确的规定，因此，有关本条款的具体规定待将来有必要与可能时再作修改与补充。 计划二：软件配置管理计划 预则立，不预则废 ，软件配置管理计划对于配置管理实施的重要性毋庸多言。大家想看看别人做的配置管理计划或17 / 29 者模板，无非是想学学别人的成功经验，避免自己走一些弯路。 但是我想，在这方面，更应该学习的应该是 计划软件配置管理实施的思路，毕竟，各个开发团队不同的地方太多了。下面是我观察和思考的一些成果，和大家分享。 像你的老板一样思考 作为一个配置管理实施的执行人员，你怎么样才能够保证这项活动的成功呢？ 说起来很简单、但是也是最重要的第一步，就是定义 成功 。 很多负责配置管理实施的人员都是技术人员出身，我经常能在他们身上观察到的一种现象就是：出于对技术的热爱，他们希望把软件配置管理学习、理解得很透彻，然后同样出于对技术的热情，希望能把所有在技术上很 诱人 的东西都实践起来。 我绝对 没有贬低这种热情的意思（事实上，我自己也经常18 / 29 被这种热情所导引）；但是，我们一定要小心地提防这种热情把我们引离了通向成功的方向。 为什么要实施软件配置管理？因为有效的配置管理可以帮助我们提高软件产品质量、提高开发团队工作效率。 什么是 成功 的配置管理实施？很简单，只要比较配置管理实施活动前后，软件产品的质量是不是得到了提高、开发团队是不是能够工作在一个有助于提高整体工作效率的配置管理平台上。 软件配置管理活动在整个开发活动中是一项支持性、保障性的工作，它本身并不直接为企业产出可以直接赢利的 工作成果；而配置管理每一项活动都需要消耗企业的人力资源，有些还需要购置专门的工具来支持活动的进行，这些都会导致企业生产成本的增加。 所以，在我们计划实施配置管理时要做哪些事情的时候，要小心地界定每一项活动，取舍的标准就是：从事这项活动是不是真正有助于我们实施活动的成功？它对于提高我们产品的质量有多大的帮助？能否帮助开发团队更高效率地工作？ 19 / 29 大多数情况下，你的老板花钱让你来做配置管理，并不是来让你学习配置管理或者研究配置管理，而是希望你的工作能帮助他改变些什么；他的投资成功与否，是用投资回报率（ ROI， return-on-investment）来衡量，而不是你对于配置管理技术研究的程度。 评估开发团队当前配置管理现状 计划配置管理实施的基础，是搞清楚开发团队当前配置管理的现状。知道自己现在站在哪里，才明白自己下一步要往哪里走。 对于配置管理现状的评估，可以自己进行，也可以引入外部专业咨询人员来完成评估活动 自己进行评估的话，可以参照 SW-CMM 中关于软件配置管理这个关键过程域的资料；也可以利用 PMT 编写的软件组织配置管理能力自我评估问题集，来完成自我评估的工作。 引 入外部专业咨询人员进行评估有两个好处，一是通常这样的咨询人员有比较丰富的配置管理实施经验，评估工作可20 / 29 以进行得更加细致，而且通常咨询人员会在评估结果的基础上提出实施的建议；二是引入外部人员，通常评估结果会比内部自我评估更客观。坏处是要花钱，而且如果该咨询人员与具体的配置管理工具厂商有利益关系的时候，也可能会出现评估过程受到这种利益关系影响的情形。 不管以何种方式进行，评估这个步骤的工作是一定要仔细进行的。有了评估的结果，才谈得上改进。做好这个工作，比到处去找一份配置管理计划的模板更有意义。 定义实 施的范围 对于没有正式实施过软件配置管理的开发团队来说，在配置管理方面存在的问题可能会比较多；经过评估，会找出来很多需要改进的点，那么，怎么样来计划改进的工作步骤呢？ 曾经有一位朋友向我展示他撰写的软件配置管理计划，从基本的版本控制、基线管理、变更管理，到软件构建的管理（ BuildManagement）、配置审核（ Auditing）、配置状态的报告，洋洋洒洒，什么都做在计划里了。他的团队以前没有太多配置管理的概念，因而也出现了很多一直困扰他的问21 / 29 题，在我向他介绍配置管理可以帮助他改善或解决这些问题以后他变成了一个配置管理技术的爱好者。我想他一定仔细研读了 RUP 配置管理工作流、 IEEE 软件配置管理标准之类的资料然后写出了这份计划。我对他的计划提了一个问题： 你觉得按照日程安排我们做得完这么多事情吗？ 这就是前边说过的，热爱技术的朋友最容易出现的情况，为技术而技术、为流程而流程；我记得一位朋友跟我说过一句非常有意义的话：流程改进应该是以结果为导向的（ ResultOriented）。配置管理的实施也是如此，应当在当前评估的基础上，抓住团队最头疼的几个问题，努力想办法解决这些问题。 大家都知道 管理学里有一个黄金法则： 80/20 法则。在这里我们也可以套用一下，想一想：我如何才能找出 20的问题，在当前这个阶段，这 20的问题给我的团队带来 80的困扰和痛苦，然后，我们集中 80的精力来解决这些问题。 一句话，不要企图一口吃个胖子。流程改进是一个持续的历程，一个阶段会有一个阶段改进的重点，抓住重点、做出成绩，才是有效的改进之道。 22 / 29 计划资源要素 俗话说，兵马未动，粮草先行。配置管理的实施需要消耗一定的资源，在这个方面一定要预先规划。 具体来说，配置管理实施主要需要两方面的资源要 素：一是人力资源，二是工具。下面分别论述。 人力方面，因为配置管理是一个贯穿整个软件生命周期的基础支持性活动，所以配置管理会涉及到团队中比较多的人员角色。比如，项目经理、配置管理员、开发人员、测试人员、集成人员、维护人员等。但是，工作在一个良好的配置管理平台上并不需要开发人员、测试人员等角色了解太多的配置管理知识，所以，配置管理实施的主要人力资源会是集中在配置管理员上。 配置管理员是一个比较奇妙的角色，对于一个实施了配置管理、建立了配置管理工作平台的团队来说，他是非常重要的，整个开发团队的工作成 果都在他的掌管之下，他负责管理和维护的配置管理系统如果出现问题的话，轻则影响团队其他成员的工作效率，重则可能出现丢失工作成果、发布错误版本等严重的后果。然而，由于传统不了解配置管理重要23 / 29 性的原因，在国内的开发团队中，通常大家都不愿意去做配置管理员。我遇到很多情况，都是项目经理找来找去，选出来一个不喜欢做开发工作的女孩，来担任配置管理员。 在国外一些比较成熟的开发组织中，配置管理员被称为CMO（ ConfigurationManagementOfficer），或者是配置经理；他们被称为是项目经理的左手。从这 两个称谓我们可以看出他们对于配置管理员的重视。在选拔配置管理员的时候，也有相当高的要求，比如，有一定的开发经验，对于系统（操作系统、网络、数据库等方面）比较熟悉，掌握一定的解决问题（ troubleshooting）的技巧，在个人性格上，要求比较稳重、细心。 在配置管理员这个资源配置方面，要注意后备资源（ Backup）的培养。在大家越来越重视配置管理的大环境下，经验丰富的配置管理员会成为抢手的人才；而配置管理员的离开可能会给团队的工作进度带来一定的影响，所以聪明的管理者会为自己留好备份。 选择什么 样的配置管理工具，一直是大家关注的热点问题。确实，与其他的一些软件工程活动不一样，配置管理工作更强调工具的支持；缺乏良好的配置管理工具的话，要做24 / 29 好配置管理的实施会非常困难。 具体来说，我想在配置管理工具的选型上，可以综合考虑下边的一些因素。 首先是经费。市场上现有的商业配置管理工具，大多价格不菲。到底是选用开放源代码的自由软件、还是采购商业软件，如果采购商业软件的话，选择哪个档次的软件，这些问题的答案，取决于你能从老板那儿拿到多少钱。 一般来说，如果经费充裕的话，采购商业的配置管理工具会让 实施过程更顺利一些，商业工具的操作界面通常更方便一些，与流行的集成开发环境（ IDE）通常也会有比较好的集成，实施过程中出现与工具相关的问题也可以找厂商解决。 如果经费有限的话呢，就不妨采用自由软件，如 CVS 之类的工具。其实无论在稳定性还是在功能方面， CVS 的口碑都非常好，我看到过很多组织成功地在 CVS 上完成配置管理的工作。如果你（或者你的配置管理员）不是一个依赖性很强的人，喜欢自己钻研、自己去寻找资料解决问题， CVS 会是一个不错的选择。 25 / 29 如果准备选择商业配置管理工具，就应当重点考虑下面几个因素。 一、工具的市场占有率。大家都选择的东西通常会是比较好的东西。而且市场占有率高也通常表明该企业经营状况会好一些，被人收购或者倒闭的可能性小一点。 二、工具本身的特性，如稳定性、易用性、安全性、扩展能力等。你应当在投资以前仔细地对工具进行试用和评估。这儿比较容易忽略的是工具的扩展能力（ Scalability），你现在可能只是在几个人、十几个人的团队中部署这个工具，但是以后可能会有几十个、几百个人要在依赖这个工具建立的平台上工作，到时候这个工具能不能提供这样的支持能力？如果到时候要换一个工具的话，你 一定会后悔今天的选择。 三、厂商支持能力。工具使用过程中一定会出现这样那样的问题，有些是因为你使用不当引起的，有些则是工具本身的毛病。这样的问题会影响到开发团队的工作进度，你一定希望能随时找到厂商的专业技术人员帮助你解决这些问题。 26 / 29 配置管理工具不是用一次两次的工具，因此，选择配置管理工具其实是选择和哪个厂商来建立一种长期的关系；如果你不信任或者干脆就是不喜欢这个厂商的技术代表，那么，不管他把他的东西吹得怎么个天花乱坠，还是赶紧让他走吧。 计划三：软件配置管理计划 通过分解“软件配 置管理计划”这八个字，并将其一层层演义，当演义结束的时候，你也就自然明白了什么叫“软件配置管理计划”。 首先讲软件 软件就是一些程序、数据、文档的集合，对应的是软件生命周期整个过程，如需求分析文档、概要设计文档、数据库设计文档、源代码、系统测试文档、安装手册等等。 同时，“软件”一词在这里又是广