XX项目平台配置管理计划.docx

1、XX项目平台配置管理计划XX项目平台配置管理计划文件修改控制文件状态：文件标识：XX项目平台配置管理计划V意见稿当前版本：V1.0 正式发布作 者： 正在修改完成日期：2015.05XX公司2015年5月版本号修改描述作者修改日期审核人审核日期V1.0新建:2015.02V2.0修改2015.05第 1 章 引言 . 31.1.目的 . 31.2.术语定义 . 31.3.参考资料 . 3第 2 章 软件配置 . 42.1. 软件配置环境 . 42.1.1服务器软件环境 . 42.1.2硬件环境 . 42.1.3配置管理客户端 . 42.2. 软件配置项 . 42.2.1受控配置库 . 42.2

2、.2非受控配置目录 . 52.3.配置管理员 . 5第 3 章 软件配置管理计划 . 43.1 建立示例配置库 . 43.2配置标识管理 . 43.3配置库控制 . 53.3.1 权限控制 . 53.3.2配置库的控制 . 53.3.3建立软件库 . 53.3.4软件配置更改 . 53.4配置的检查和评审 . 63.5配置库的备份 . 73.6配置管理计划的修订 . 73.7配置管理计划附属文档 . 8第 4 章 里程碑 . 9附录 1 文档命名规定 11、受控配置库文件命名规则 . 12、非受控配置库文件命名规则 . 13、提交文档文件命名规则 . 2附录 2 帐号及权限管理 3附录 3 配

3、置库使用规定 4第 1章 引言1.1.目的本文档目的在于对 XX 项目进行软件配置管理，提高软件质量，降低软件开发成本。本文档内容主要参考研发中心相关的制度文档，并在这基础上整理成适合本项目的软件 配置管理，为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。1.2.术语定义软件配置管理：简称 SCM( Software Configuration Management 的缩写)，是在项目开 发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以 及风险水平。软件的规模越大，配置管理就显得越重要。基线： (BaseLine) 是项目储存库中每个工件版本在特定时

4、期的一个“快照” 。它提供一 个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初 始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。配置管理员：项目组中负责配置管理工作的角色，该角色可以兼职。在某一开发阶段通 过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效 版本以及审批人签字。配置标识：( Configuration Identification )对软件项目在开发过程中的资源进行标识， 以便识。配置检查：( Configuration Audit )对软件配置管理过程中的行动进行检查。1.3.参考资料暂无第

5、2章软件配置2.1.软件配置环境2.1.1服务器软件环境软件名称作用Windows 10、Windows Server2013操作系统TortoiseSVN配置管理软件在整个项目过程或产品生命周期中 ，选择SVN作为配置管理工具。2.1.2硬件环境名称规格说明网络局域网服务器PC服务器名称：FileServer4G内存为SVN保留500G独立使用空间客户机普通PC机项目组成员各自的计算机2.1.3配置管理客户端项目组成员在各自的计算机安装 SVN客户端，项目组成员以分配的帐号访问配置服务器和登录配置管理系统，根据配置管理员设定的用户权限进项配置管理活动。2.2.软件配置项在本项目的实施过程中，

6、将配置库分为受控配置库和非受控配置库两种。2.2.1受控配置库11个受控配置目录,在本项目开发实施的整个过程中，根据不同阶段的配置管理划分只有配置管理员拥有增加和修改的权限，其它用户只有只读的权限。初始配置库的根目录中包项目的配置文件清单，该文档包括本项目开发过程中应该提交 的文档的清单，在实际开发过程中，根据实际情况，可以在清单中酌情修改、增加和删除需 要提交的文档。具体内容参见本文 3.3的“配置文件清单的维护”。2.2.2非受控配置目录在本项目开发过程中，设立了非受控配置目录。设立非受控配置目录的目的是为了统一 管理和存放开发过程中产生的临时文档和过程性文档，没有格式及命名上的严格要求，

7、使项 目组成员在思考、设计时不受太多的限制和约束，能够更有效地发挥个人能力，符合以人为 本的原则。在项目初期，设立了以下三个目录:目录名称用途及说明个人工作区用于保存项目成员自己编写的文档，每个项目成员都有自己独立的工作目录小组工作区用于保存小组成员写作编写的文档，每个小组都有自己独立的工作目录文档提交区作为非受控配置库和受控配置库之间的缓冲，用于提交已 经定稿的文档和代码，在评审通过后，再由配置管理员取 出并提交到受控配置库中在根据项目开发过程中，根据实际需要，可以酌情增加非受控配置目录。2.3.配置管理员在本软件项目开发过程中，项目组设立配置管理员，专业（或兼职）负责软件项目开发 过程中的

8、软件配置管理工作，保证在项目开发过程中的一些变更管理及文档管理的完整性， 顺利地实施项目开发进度。配置管理员负责制定配置管理计划，检查项目组成员是否正确使用配置库，并督促项目 开发计划的实施。配置管理员还需配合研发中心产品管理部进行项目的配置评审。评审结束，相关文档的 批准人电子签名由批准人签写或经批准人授权配置管理员填写，然后由配置管理员负责签入 配置库；同时，由配置管理员收集配置项审批相关的 email文档并签入配置库。第 3章 软件配置管理计划关于配置库的日常使用的规定参见附件 3配置库使用规定 。3.1建立示例配置库配置管理员在制定完计划后，根据公司建议的配置库建立符合本项目的配置管理

9、库。配 置库建立在SVN上，目录结构可按照示例配置库提供的目录。对于本项目来说，需要划分多 个子系统，因此要在确定子系统的划分后，在不同阶段下分 建立各子系统的配置目录。配置管理库建立完毕后，可根据配置管理库的人员计划在 SVN上建立相应的用户及权限， 并将这些用户分发给指定的开发人员或用户。 具体的帐号及权限管理参见附录 2 帐号及权 限管理配置管理员应保管好配置管理工具的管理员权限，项目组中使用配置管理库的成员应该 及时更改自己在配置管理工具的缺省设置密码。3.2配置标识管理1文档 根据配置管理计划和配置库中的文档清单，配置管理员要检查需要提交的文档是否都按 时提交，文档数目是否符合，文档

10、的标识、命名以及版本等是否符合程序规定。关于文档的 命名请参见附件 1 文档命名规定 。2程序 所有属于该项目的程序、分程序、模块和程序单元，都要按照由项目组和配置管理员制 订的软件系统的命名约定的规定来标识。要求所有模块的源代码都需记录模块编号，且模块编号在整个系统中是唯一的。模块编 号在系统设计完成之后，由项目组和配置管理员共同根据系统设计进行编制。3基线 所有属于本项目及其各子系统的各类基线，首先要按照计划书、软件需求规格说明书、 软件项目详细分析设计说明书的规定确定其技术内容，在整个软件项目开发过程中定义以下 两类基线：文档基线：本项目的文档基线的定义以里程碑的定义为准，将到达各阶段的

11、里程碑时的 文档作为基线，具体里程碑的定义参见第 4 节“里程碑” 。产品基线：产品基线包 两个，一个是系统上线时，一个是系统经过客户验证测试时，基 线包含所有程序代码和文档。配置管理员负责在项目开发的每一个里程碑处、每一个阶段性的版本发布时负责为整个 配置库设立书签，划定配置管理基线，并以文档的方式记录下这些书签的定义。3.3配置库控制3.3.1权限控制配置管理员根据附录 2帐号及权限管理设置和调整项目组成员对配置项的权限。3.3.2配置库的控制在项目开发和实施的整个过程中，配置管理员应根据配置管理计划及管理规则对配置库 对应进行管理和控制。配置管理员负责检查项目组成员使用配置库是否正确。包

12、括是否及时 签入最新版本、是否添加了注释、是否及时更改配置状态，是否存在项目组成员修改了不属 于自己负责的配置项，项目组成员是否完成了自己负责的配置项的检入，测试版本的构造是 否从配置库中取出等。3.3.3建立软件库在项目的各个开发阶段， 应建立起各阶段各子系统的软件开发库 （软件开发工作区） ，同 时建立起想对应的有关该系统及其子系统的软件受控库。在每个阶段结束或里程碑，需让各 子系统提交相关的产品并送入软件受控库，由配置管理员统一管理，以后再有对产品的变更 需求，应按照正常的变更程序来控制并检查相关的变更文档。当全部开发工作结束，需建立 起软件产品库，将所有可交付的产品都送入软件产品库。3

13、.3.4软件配置更改软件配置的更改管理适用于全部项目的所有文档和代码，其中包括整个项目的各个运行 软件，也包括为项目专门开发的支持软件。对该项目各个子系统及其专用支持软件的基线及其集成系统的任何修改， 必须得到项目负责人的批准并在本项目软件质量管理专员处备案才能进行配置更改。更改完成后的文档和代码等， 需得到项目负责人认可， 提交给配置管理员后， 由配置管理员签入受控配置库。受控配置库中的文档，在文档中需要有修改记录部分，包括修改人、修改日期、修改内 容等项，每次对于受控配置库中文档的修改，必须填写这些项。配置文件清单的维护由配置管理员维护。项目初期，配置管理员与项目组成员一起对开发过程中可能

14、产生的文档的进行预计，并 在配置文件清单中列出这些文档及其大致的计划提交时间。在实际开发过程中， 文档提交可能会产生一些变化， 如新增某些文档、 原计划的一些文档不再单独产生、文档计划提交日期的变更等，项目组应该及时通知配置管理员，由配置管 理员及时更改配置文件清单中的相应项。3.4配置的检查和评审配置的检查和评审可通过研发中心配置管理制度的审核内容来进行检查。相关的审核内容如下表：审核分类审核内容检查情况发布审核发布文档是否清楚地定义发布的范围， 包括应被纳入的更改请求？所有已知缺陷/毛病（bug）是否已文档化？是否有适当的文档，它标识重建该发布所需的环境（编译器版本、OS 版本、pilat

15、i on flags ，等等）？是否有适当的文档，它说明构成该发布的成分及成分的版本？发布的所有项是否彼此同步（在时间上一致）？是否采用正确存储库中的正确成分的正确版本生成发布？存储库/配 置项审核存储库是否按SCM计划定义？项是否已经进入正确的库？是否按SCM计划中规定的命名约定项命名 ？是否按照SCM计划，规定项的版本号？是否按照SCM计划中规定的事件已经将所有项入库？例如：测试 完成、客户的评审意见已采纳？项是否有所要求的文档以识 项、版本和更改历史？更改实施审是否全部所要求的更改请求均已结束？核是否更改请求标识出全部拟更改的项？更改请求中所标识的全部要更改的项均已更改， 被QC和在所要

16、求的QC后入库？是否可能在项的任何两个版本中间区分更改？项的文档是否足够，能向后追踪更改到相应的更改请求？是否有恰当方法能回到以前的版本？审核的其他 方面是否对库作了恰当的备份 ？是否已测试过从备份中恢复 ？在群组成员的工作目录中是否有任何 经许可的成分？是否有恰当的保密/批准手续以保证只有经授权的群组成员才能进 行入库/出库？配置管理员应配合研发中心产品管理部定期对项目进行配置管理的审核。 在审核过程中,提供所需要的配置管理计划及相关资料，在项目开发结束后，需提交所有关于项目的软件配置库。3.5配置库的备份在项目开发实施过程的各个阶段，配置管理员应定期做好软件配置库的备份，以防造成 劳动成果

17、的丢失而给整个项目及公司带来的严重损失。备份可按照公司的要求定期（按周或月）进行。在每个阶段或里程碑处在做完基线工作 后应进行备份。备份文件应存放在不同的地方。3.6配置管理计划的修订初始的配置管理计划在项目开始的初期进行制定，由于此时只能大致确定整个开发过程 中的一些活动及其会产生的文档，在实际开发过程中，可能会与此有些差异，因此，配置管 理计划也需要根据开发过程的实际情况，及时进行修订，使之能够有效地对本项目的配置管 理活动进行指导。在一般情况下，进行配置管理计划修订的时机选在到达各个阶段的里程碑时。如果在一 个阶段的实施过程中，配置管理计划不能适应实际过程的变更，则由配置管理员与项目管理

18、 人员一起根据实际情况修订配置管理计划。3.7配置管理计划附属文档配置文件清单：记录项目开发过程中应该产生的一些文档、 描述及其提交计划等内容,是执行配置管理及检查的重要依据。该文档在项目开始的初期建立，确定开发过程中需要提交的大部分文档，并在项目开发过程中根据实际情况稍做更新。模块清单：模块清单记录了系统各个子系统、程序模块的名称并分 进行项目内的唯一编号，是所有模块的源代码需记录模块编号的依据。 模块清单在系统设计完成之后，由项目组和配置管理员共同根据系统设计进行编制。文档命名规定：参见附录1文档命名规定帐号及权限管理：参见附录2帐号及权限管理配置库日常使用规定参见附录3配置库日常使用规定

19、第4章里程碑本项目主要划分以下几个里程碑:里程碑特点1.需求分析已确立系统（或所有已确定子系统）的需求分析全部完成 已形成相应的需求分析说明书及其它附属文档；需求分析说明书已通过公司评审或与客户一致认为需求分析阶段已结束，可以进入设计阶段；2.概要设计完成系统（或所有已确定子系统）的概要设计全部完成 已形成相应的概要设计说明书及其它附属文档 ；概要设计说明书已通过公司评审或与客户一致认为概要设计阶段已结束，可以进入详细设计阶段 ；3.详细设计完成系统（或所有已确定子系统）的详细设计全部完成 已形成相应的详细设计说明书及其它附属文档详细设计说明书已通过公司评审或与客户一致认为详细设计阶段已结束，

20、可以进入编码阶段 ；4.编码完成系统（或所有已确定子系统）的编码全部完成 系统所有程序已经经过调试并确定可以运行 ；已通过公司评审或与客户一致认为编码阶段已结束，可 以进入系统测试阶段 ；5.测试计划完成测试需求已经确定并完成； 已形成相应的测试计划说明书及其它附属文档 ；6.测试设计完成测试用例已经覆盖所有测试需求 已形成相应的测试用例说明书及其它附属文档 ；7.系统测试完成系统测试完成，所发现的所有缺陷已得到妥善处理 符合系统测试退出条件 已完成测试分析报告 ；8.项目结束上线成功 ；已得到客户的确认并通过验收测试 项目已结束。与客户一致认为该附录1文档命名规定本命名规定主要是针对文档的，

21、不包括源代码文件和最终程序的命名规则。 本规定主要以下三个方面的命名规则：受控配置库文件命名规则非受控配置库文件命名规则提交文档文件命名规则1、受控配置库文件命名规则受控配置库中的配置项文档（不含源代码和最终工作产品）名称应该按照如下格式命名: 项目名称+资料名称+撰写或修改日期项说明项目名称XX项目资料名称软件开发计划需求规格说明书概要设计用户手册撰写或修改日期第一次撰写完成日期或修改完成日期例如：2015年3月15日定稿的需求规格说明书。2、非受控配置库文件命名规则只要求提交时不致出错,非受控配置库主要用于存放项目成员工作时产生的临时文档等, 对命名规则没有其它限制，由项目成员根据自己习惯

22、对文档命名。3、提交文档文件命名规则同受控配置库的文件命名规则。项目成员提交文档到文档提交区前，应该按照受控配置库的文件命名规则对文档命名， 然后才提交道文档提交区中。附录 2 帐号及权限管理一、 帐号管理1、 配置管理服务器帐号在配置管理服务器( FileServer )上为项目组的每个项目成员都建立帐号； 根据项目过程中的人员调配状况适时增加和删除帐号；初始口令与用户名一致； 每个项目成员访问配置管理服务器时，都应该用自己的帐号；2、 配置管理库帐号在SVN上为项目组的每个项目成员都建立帐号； 根据项目过程中的人员调配状况适时增加和删除帐号； 初始口令与用户名一致； 每个项目成员第一次登录

23、配置库时应该修改自己的用户口令；每个项目成员应该使用自己的帐号登录 SVN； 项目成员如果遗忘帐号口令，应即时通知配置管理员重新分配该帐号的口令；二、 权限管理 权限管理分为两大部分的权限管理： 受控配置库的权限管理 非受控配置库的权限管理1、 受控配置库 配置管理员对受控配置库拥有所有权限； 项目组其他成员对受控配置库拥有只读权限； 非项目组成员 经允许对整个配置库没有任何权限；2、 非受控配置库 非受控配置库主要包 以下三个目录： 个人工作区小组工作区文档提交区附录 3 配置库使用规定1.项目组成员编写的与本项目有关文档、程序代码等，应该保存在配置库中；2.文档在编写过程中， 保存在配置库

24、的非受控目录中， 其中个人文档和代码保存在 “个 人工作区”的项目成员本人的目录下，小组文档保存在“小组工作区”的所属小组目录下；3.每周第一个工作日开始， 项目成员从非受控配置库中签出要编写、 修改的文档或代 码到本人的计算机，进行编写、修改工作；4.每周最后一个工作日结束时，项目成员必须将签出的文档保存后签入到配置库中；5.文档和代码要提交到受控配置库中时， 必须先提交给配置管理员， 由配置管理员提 交到受控配置库中；6.当文档或代码通过评审或得到项目管理人员及客户的一致认为可以提交时， 提交到 “文档提交区”的目录中；7.文档提交前应该按照附录 1文档命名规定 中的规定进行命名， 文档编码应该符 合附录 2 文档编码规范中的规定；8.项目组成员未经项目组允许不得更改他人的文档和代码；9.任何文档、代码等，不能以压缩文件的方式签入配置库中；10.每次评审结束， 相关文档的批准人电子签名由批准人签写或经批准人授权配置管理 员填写，然后由配置管理员负责签入配置库。11.如果需要对受控配置库中的文档、 代码进行变更， 需得到项目负责人批准方能从受 控配置库中取出更改；12.更改完成后的文档， 需得到项目负责人认可， 提交给配置管理员后， 由配置管理员 签入受控配置库。