《XX项目平台配置管理计划.docx》由会员分享，可在线阅读，更多相关《XX项目平台配置管理计划.docx（19页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、精品word 可编辑资料 - - - - - - - - - - - - -XX项目平台配置治理方案文件修改掌握文件状态： 看法稿 正式发布 正在修改文件标识：XX项目平台配置治理方案当前版本：V1.0作者：完成日期：2021.05XX 公司2021 年 5 月第 1 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案版本号修改描述作者修改日期审核人审核日期V1.0新建2021.02V2.0修改2021.05第 2 页，共 19 页 - - - - - - - - - -精品word 可
2、编辑资料 XX 项目- - - - - - - - - - - - -平台配置治理方案目录第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非受控配置目录.52.3.配置治理员 .5第3 章软件配置治理方案.43.1建立示例配置库.43.2配置标识治理.43.3配置库掌握 .53.3.1权限掌握 .53.3.2配置库的掌握.53.3.3建立软件库 .53.3.4软件配置更换.53.
3、4配置的检查和评审.63.5配置库的备份.73.6配置治理方案的修订.73.7配置治理方案附属文档.8第4 章里程碑 .9附录 1 文档命名规定11、受控配置库文件命名规章1I第 3 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案2、非受控配置库文件命名规章13、提交文档文件命名规章2附录 2 帐号及权限治理3附录 3 配置库使用规定5II第 4 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX
4、项目平台配置治理方案第1章引言1.1 .目的本文档目的在于对XX 项目进行软件配置治理，提高软件质量，降低软件开发成本；本文档内容主要参考研发中心相关的制度文档，并在这基础上整理成适合本项目的软件配置治理，为项目经理、配置治理员及相关人员供应日常的配置治理操作步骤；1.2 .术语定义软件配置治理：简称SCM（ Software Configuration Management的缩写），是在项目开发中，标识、掌握和治理软件变更的一种治理；配置治理的使用取决于项目规模和复杂性以及风险水平；软件的规模越大，配置治理就显得越重要；基线： (BaseLine) 是项目储存库中每个工件版本在特定时期的一个
5、“快照 ”；它供应一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准；建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线；配置治理员：项目组中负责配置治理工作的角色，该角色可以兼职；在某一开发阶段通过评审或某一质量检查点通过审核后，配置治理员负责统一添加或修改相关文档的最新有效版本以及审批人签字；配置标识：（ Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识；配置检查：（ Configuration Audit ）对软件配置治理过程中的行动进行检查；1.3 .参考资料暂无3第 5 页，共 1
6、9 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案第2章软件配置2.1 .软件配置环境2.1.1 服务器软件环境软件名称作用Windows 10、Windows Server2021操作系统TortoiseSVN配置治理软件在整个项目过程或产品生命周期中,挑选SVN作为配置治理工具；2.1.2 硬件环境名称规格说明网络局域网服务器PC 服务器名称： File Server4G 内存为 SVN保留 500G 独立使用空间客户机普 通 PC 机项目组成员各自的运算机2.1.3 配置治理客户端项目组成员
7、在各自的运算机安装SVN客户端，项目组成员以安排的帐号拜访配置服务器和登录配置治理系统，依据配置治理员设定的用户权限进项配置治理活动；2.2 .软件配置项在本项目的实施过程中，将配置库分为受控配置库和非受控配置库两种；2.2.1 受控配置库在本项目开发实施的整个过程中，依据不同阶段的配置治理划分11 个受控配置目录，只有配置治理员拥有增加和修改的权限，其它用户只有只读的权限；4第 6 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案初始配置库的根目录中包项目的配置文件清单，该文档包括本
8、项目开发过程中应当提交的文档的清单，在实际开发过程中，依据实际情形，可以在清单中酌情修改、增加和删除需要提交的文档；具体内容参见本文 3.3 的“配置文件清单的保护 ”；2.2.2 非受控配置目录在本项目开发过程中，设立了非受控配置目录；设立非受控配置目录的目的是为了统一治理和存放开发过程中产生的暂时文档和过程性文档，没有格式及命名上的严格要求，使项目组成员在摸索、设计时不受太多的限制和约束，能够更有效地发挥个人才能，符合以人为本的原就；在项目初期，设立了以下三个目录： 目录名称用途及说明个人工作区用于储存项目成员自己编写的文档，每个项目成员都有自己独立的工作目录小组工作区用于储存小组成员写作
9、编写的文档，每个小组都有自己独立的工作目录文档提交区作为非受控配置库和受控配置库之间的缓冲，用于提交已经定稿的文档和代码，在评审通过后，再由配置治理员取出并提交到受控配置库中在依据项目开发过程中，依据实际需要，可以酌情增加非受控配置目录；2.3 .配置治理员在本软件项目开发过程中，项目组设立配置治理员，专业（或兼职）负责软件项目开发过程中的软件配置治理工作，保证在项目开发过程中的一些变更治理及文档治理的完整性， 顺当地实施项目开发进度；配置治理员负责制定配置治理方案，检查项目组成员是否正确使用配置库，并督促项目开发方案的实施；配置治理员仍需协作研发中心产品治理部进行项目的配置评审；评审终止，相
10、关文档的批准人电子签名由批准人签写或经批准人授权配置治理员填写，然后由配置治理员负责签入配置库；同时，由配置治理员收集配置项审批相关的 email 文档并签入配置库；5第 7 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案第3章软件配置治理方案关于配置库的日常使用的规定参见附件3配置库使用规定 ；3.1 建立示例配置库配置治理员在制定完方案后，依据公司建议的配置库建立符合本项目的配置治理库；配 置库建立在SVN 上，目录结构可依据示例配置库供应的目录；对于本项目来说，需要划分多个子系
11、统，因此要在确定子系统的划分后，在不同阶段下分建立各子系统的配置目录；配置治理库建立完毕后，可依据配置治理库的人员方案在SVN 上建立相应的用户及权 限，并将这些用户分发给指定的开发人员或用户；具体的帐号及权限治理参见附录2 帐号及权限治理配置治理员应保管好配置治理工具的治理员权限，项目组中使用配置治理库的成员应当准时更换自己在配置治理工具的缺省设置密码；3.2 配置标识治理1文档依据配置治理方案和配置库中的文档清单，配置治理员要检查需要提交的文档是否都按时提交，文档数目是否符合，文档的标识、命名以及版本等是否符合程序规定；关于文档的命名请参见附件 1 文档命名规定 ；2程序全部属于该项目的程
12、序、分程序、模块和程序单元，都要依据由项目组和配置治理员制订的软件系统的命名商定的规定来标识；要求全部模块的源代码都需记录模块编号，且模块编号在整个系统中是唯独的；模块编号在系统设计完成之后，由项目组和配置治理员共同依据系统设计进行编制；3基线全部属于本项目及其各子系统的各类基线，第一要依据方案书、软件需求规格说明书、软件项目具体分析设计说明书的规定确定其技术内容，在整个软件项目开发过程中定义以下两类基线：4第 8 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案文档基线：本项目的文档
13、基线的定义以里程碑的定义为准，将到达各阶段的里程碑时的文档作为基线，具体里程碑的定义参见第4 节“里程碑 ”；产品基线：产品基线包两个，一个是系统上线时，一个是系统经过客户验证测试时，基线包含全部程序代码和文档；配置治理员负责在项目开发的每一个里程碑处、每一个阶段性的版本发布时负责为整个配置库设立书签，划定配置治理基线，并以文档的方式记录下这些书签的定义；3.3 配置库掌握3.3.1 权限掌握配置治理员依据附录2帐号及权限治理设置和调整项目组成员对配置项的权限；3.3.2 配置库的掌握在项目开发和实施的整个过程中，配置治理员应依据配置治理方案及治理规章对配置库对应进行治理和掌握；配置治理员负责
14、检查项目组成员使用配置库是否正确；包括是否准时签入最新版本、是否添加了注释、是否准时更换配置状态，是否存在项目组成员修改了不属于自己负责的配置项，项目组成员是否完成了自己负责的配置项的检入，测试版本的构造是否从配置库中取出等；3.3.3 建立软件库在项目的各个开发阶段，应建立起各阶段各子系统的软件开发库（软件开发工作区） ，同时建立起想对应的有关该系统及其子系统的软件受控库；在每个阶段终止或里程碑，需让各子系统提交相关的产品并送入软件受控库，由配置治理员统一治理，以后再有对产品的变更需求，应依据正常的变更程序来掌握并检查相关的变更文档；当全部开发工作终止，需建立起软件产品库，将全部可交付的产品
15、都送入软件产品库；3.3.4 软件配置更换软件配置的更换治理适用于全部项目的全部文档和代码，其中包括整个项目的各个运行软件，也包括为项目特地开发的支持软件；5第 9 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案对该项目各个子系统及其专用支持软件的基线及其集成系统的任何修改，必需得到项目负责人的批准并在本项目软件质量治理专员处备案才能进行配置更换；更换完成后的文档和代码等，需得到项目负责人认可，提交给配置治理员后，由配置治理员签入受控配置库；受控配置库中的文档，在文档中需要有修改记录
16、部分，包括修改人、修改日期、修改内容等项，每次对于受控配置库中文档的修改，必需填写这些项；配置文件清单的保护由配置治理员保护；项目初期，配置治理员与项目组成员一起对开发过程中可能产生的文档的进行估计，并在配置文件清单中列出这些文档及其大致的方案提交时间；在实际开发过程中，文档提交可能会产生一些变化，如新增某些文档、原方案的一些文档不再单独产生、文档方案提交日期的变更等，项目组应当准时通知配置治理员，由配置管理员准时更换配置文件清单中的相应项；3.4 配置的检查和评审配置的检查和评审可通过研发中心配置治理制度的审核内容来进行检查；相关的审核内容如下表：审核分类审核内容检查情形发布审核发布文档是否
17、清晰地定义发布的范畴，包括应被纳入的更换恳求？全部已知缺陷 /毛病 (bug)是否已文档化？是否有适当的文档，它标识重建该发布所需的环境（编译器版本、OS 版本、 compilation flags ，等等）？是否有适当的文档，它说明构成该发布的成分及成分的版本？发布的全部项是否彼此同步（在时间上一样）？储备库 /配置项审核是否接受正确储备库中的正确成分的正确版本生成发布？储备库是否按SCM 方案定义？项是否已经进入正确的库？是否按SCM 方案中规定的命名商定项命名.是否依据SCM 方案，规定项的版本号？是否依据SCM 方案中规定的大事已经将全部项入库？例如：测试完成、客户的评审看法已接受？项
18、是否有所要求的文档以识项、版本和更换历史？更换实施审是否全部所要求的更换恳求均已终止？6第 10 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案核是否更换恳求标识出全部拟更换的项？更换恳求中所标识的全部要更换的项均已更换，被QC 和在所要求的QC 后入库？是否可能在项的任何两个版本中间区分更换？项的文档是否足够，能向后追踪更换到相应的更换恳求？审核的其他方面是否有恰当方法能回到以前的版本？是否对库作了恰当的备份.是否已测试过从备份中复原.在群组成员的工作目录中是否有任何经许可的成分？
19、是否有恰当的保密/批准手续以保证只有经授权的群组成员才能进行入库 /出库？配置治理员应协作研发中心产品治理部定期对项目进行配置治理的审核；在审核过程中，供应所需要的配置治理方案及相关资料，在项目开发终止后，需提交全部关于项目的软件配置库；3.5 配置库的备份在项目开发实施过程的各个阶段，配置治理员应定期做好软件配置库的备份，以防造成劳动成果的丢失而给整个项目及公司带来的严峻缺失；备份可依据公司的要求定期（按周或月）进行；在每个阶段或里程碑处在做完基线工作后应进行备份；备份文件应存放在不同的地方；3.6 配置治理方案的修订初始的配置治理方案在项目开头的初期进行制定，由于此时只能大致确定整个开发过
20、程中的一些活动及其会产生的文档，在实际开发过程中，可能会与此有些差异，因此，配置治理方案也需要依据开发过程的实际情形，准时进行修订，使之能够有效地对本项目的配置治理活动进行指导；在一般情形下，进行配置治理方案修订的时机选在到达各个阶段的里程碑时；假如在一个阶段的实施过程中，配置治理方案不能适应实际过程的变更，就由配置治理员与项目治理人员一起依据实际情形修订配置治理方案；7第 11 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案3.7 配置治理方案附属文档配置文件清单 ：记录项目开发过
21、程中应当产生的一些文档、描述及其提交方案等内容，是执行配置治理及检查的重要依据；该文档在项目开头的初期建立，确定开发过程中需要提交的大部分文档，并在项目开发过程中依据实际情形稍做更新；模块清单 ：模块清单记录了系统各个子系统、程序模块的名称并分进行项目内的唯独编号，是全部模块的源代码需记录模块编号的依据；模块清单在系统设计完成之后，由项目组和配置治理员共同依据系统设计进行编制；文档命名规定 ：参见附录1 文档命名规定帐号及权限治理 ：参见附录2 帐号及权限治理配置库日常使用规定参见附录3 配置库日常使用规定8第 12 页，共 19 页 - - - - - - - - - -精品word 可编辑
22、资料 - - - - - - - - - - - - -XX 项目平台配置治理方案第4章里程碑本项目主要划分以下几个里程碑： 里程碑特点1. 需求分析已确立系统（或全部已确定子系统）的需求分析全部完成已形成相应的需求分析说明书及其它附属文档；需求分析说明书已通过公司评审或与客户一样认为需求分析阶段已终止，可以进入设计阶段；2. 概要设计完成系统（或全部已确定子系统）的概要设计全部完成已形成相应的概要设计说明书及其它附属文档；概要设计说明书已通过公司评审或与客户一样认为概要设计阶段已终止，可以进入具体设计阶段；3. 具体设计完成系统（或全部已确定子系统）的具体设计全部完成已形成相应的具体设计说明
23、书及其它附属文档具体设计说明书已通过公司评审或与客户一样认为具体设计阶段已终止，可以进入编码阶段；4. 编码完成系统（或全部已确定子系统）的编码全部完成系统全部程序已经经过调试并确定可以运行；已通过公司评审或与客户一样认为编码阶段已终止，可以进入系统测试阶段；5. 测试方案完成测试需求已经确定并完成；已形成相应的测试方案说明书及其它附属文档；6. 测试设计完成测试用例已经掩盖全部测试需求已形成相应的测试用例说明书及其它附属文档；7. 系统测试完成系统测试完成， 所发觉的全部缺陷已得到妥当处理符合系统测试退出条件已完成测试分析报告；9第 13 页，共 19 页 - - - - - - - - -
24、 -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案8. 项目终止上线胜利；已得到客户的确认并通过验收测试与客户一样认为该项目已终止；10第 14 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案附录1文档命名规定本命名规定主要是针对文档的，不包括源代码文件和最终程序的命名规章；本规定主要以下三个方面的命名规章：受控配置库文件命名规章 非受控配置库文件命名规章提交文档文件命名规章1、受控配置库文件命名规章受控配置库中的配置项文档（不
25、含源代码和最终工作产品）名称应当依据如下格式命名：项目名称+资料名称+ 撰写或修改日期项说明项目名称XX 项目资料名称软件开发方案需求规格说明书概要设计用户手册撰写或修改日期第一次撰写完成日期或修改完成日期例如：20 15 年 3月 15日定稿的需求规格说明书；2、非受控配置库文件命名规章非受控配置库主要用于存放项目成员工作时产生的暂时文档等，只要求提交时不致出错，对命名规章没有其它限制，由项目成员依据自己习惯对文档命名；1第 15 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案3、
26、提交文档文件命名规章同受控配置库的文件命名规章；项目成员提交文档到文档提交区前，应当依据受控配置库的文件命名规章对文档命名，然后才提交道文档提交区中；2第 16 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案附录2帐号及权限治理一、帐号治理1、配置治理服务器帐号在配置治理服务器（FileServer）上为项目组的每个项目成员都建立帐号； 依据项目过程中的人员调配状况适时增加和删除帐号；初始口令与用户名一样；每个项目成员拜访配置治理服务器时，都应当用自己的帐号；2、配置治理库帐号在 S
27、VN 上为项目组的每个项目成员都建立帐号；依据项目过程中的人员调配状况适时增加和删除帐号；初始口令与用户名一样；每个项目成员第一次登录配置库时应当修改自己的用户口令；每个项目成员应当使用自己的帐号登录SVN；项目成员假如遗忘帐号口令，应即时通知配置治理员重新安排该帐号的口令；二、权限治理权限治理分为两大部分的权限治理：受控配置库的权限治理非受控配置库的权限治理1、受控配置库配置治理员对受控配置库拥有全部权限；项目组其他成员对受控配置库拥有只读权限；非项目组成员经答应对整个配置库没有任何权限；2、非受控配置库非受控配置库主要包以下三个目录：.个人工作区3第 17 页，共 19 页 - - - -
28、 - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案.小组工作区.文档提交区4第 18 页，共 19 页 - - - - - - - - - -精品word 可编辑资料 - - - - - - - - - - - - -XX 项目平台配置治理方案附录3配置库使用规定1. 项目组成员编写的与本项目有关文档、程序代码等，应当储存在配置库中；2. 文档在编写过程中， 储存在配置库的非受控目录中，其中个人文档和代码储存在“个人工作区 ”的项目成员本人的目录下，小组文档储存在“小组工作区 ”的所属小组目录下；3. 每周第一个工作日
29、开头，项目成员从非受控配置库中签出要编写、修改的文档或代码到本人的运算机，进行编写、修改工作；4. 每周最终一个工作日终止时，项目成员必需将签出的文档储存后签入到配置库中；5. 文档和代码要提交到受控配置库中时，必需先提交给配置治理员，由配置治理员提交到受控配置库中；6. 当文档或代码通过评审或得到项目治理人员及客户的一样认为可以提交时，提交到 “文档提交区 ”的目录中；7. 文档提交前应当依据附录1文档命名规定中的规定进行命名，文档编码应当符合附录2文档编码规范中的规定；8. 项目组成员未经项目组答应不得更换他人的文档和代码；9. 任何文档、代码等，不能以压缩文件的方式签入配置库中；10. 每次评审终止， 相关文档的批准人电子签名由批准人签写或经批准人授权配置治理员填写，然后由配置治理员负责签入配置库；11. 假如需要对受控配置库中的文档、代码进行变更， 需得到项目负责人批准方能从受控配置库中取出更换；12. 更换完成后的文档，需得到项目负责人认可，提交给配置治理员后，由配置治理员签入受控配置库；5第 19 页，共 19 页 - - - - - - - - - -