软件配置模板

目的（Purpose）为了建立和维护软件项目中所有产品的完整性，该文件描述了用于软件配置管理SoftwareConfigurationManagement（SCM）的过程。目标（Objective）通过有计划的软件配置管理活动，使软件工作产品经过标识、受到控制并具有可用性。任何对软件工作产品的更改都是受控的，并确保相关小组和个人能及时了解软件基线的状态和内容。范围（Scope）受控于配置管理下的工作产品，包括交付给客户的软件产品，以及生成软件产品所需要的或由软件产品标识的有关项。准备/前提/条件（Input）软件配置控制委员会（SCCB）：负责评价、认可或否定有关基线更改建议并确保确认的更改得以执行。具体活动包括，授权标识与建立软件基线，阐述项目负责人和所有受软件基线变更影响的小组的权益。高层SCCB包括BUM和高层经理。项目SCCB包括项目经理和产品经理。每个软件产品都有一个软件配置管理（SCM）小组负责协调和实施产品的软件配置活动。SQA定期对SCM小组的活动进行监察与审核，以验证SCM小组的活动是否按照相应的规程进行。规程/任务/活动（Procedure）制定SCM计划MakingSCMPlan在项目的初期需要制定《SCM计划》SCMPlan.dot，并且始终与项目保持一致。在项目计划（ProjectPlan.dot）的软件配置管理一章中，需要指明该项目对应的SCM计划文档。项目经理或由项目经理指定的SCM小组成员制定SCM计划，并提交该项目的SCCB进行审批。SCM计划的主要内容包括：确定该项目的SCM小组以及SCCB的成员名单。需要管理的工作产品和项目使用工具，以及管理它们的目录结构设置。项目的工作产品包括项目文档、源代码、源代码所生产出的EXE、OCX、DLL等所有生成文件。目录结构设置可参考《SCM路径设置规程》（SCMPathSetupProcedure.doc）。SCM的日常工作及安排等，如各种备份的计划。SCM活动的进度计划做为项目计划的一部分，由项目经理在项目进度表中统一制定计划并进行跟踪。SCM活动的跟踪TrackingSCMActivities项目经理在项目的状态会议中询问SCM的实施情况，记录SCM活动的实际进度，并与SCM计划进行比较，必要时对SCM计划进行调整。SCM小组每两周制作《SCM状态报告》SCMStatusReport.xlt，并提供给项目SCCB。如果项目的周期不是两周的整数倍或者小于两周时，《SCM状态报告》的制作周期为每两周加上项目结束。版本控制VersionControl对于所有项目文档和源代码，在项目开发过程中都使用SourceSafe进行配置管理，即为配置项。源代码所生产出的EXE、OCX、DLL等产品则存放在固定服务器的固定路径进行保存。SCM小组需要按照SCM计划，为每个项目在SourceSafe上建立相应的目录并设置权限，以供存放和管理项目文档和源代码。SourceSafe的使用方法参见《R&D员工手册》R&DHandbook.doc中的“配置管理工具的使用”。SCM小组使用SCM工具（SCMTools.exe）每周检查文档和源代码的Check-out状态。项目文档的版本控制VersionControlforDocuments与软件产品相关的所有项目文档，如需求文档、设计文档以及测试文档等，存放在\\Filesvr\DocVSS\或\\CIPFilesrv\Documents的SourceSafe中该项目的指定目录下。当一份文档完成后，需要提交项目经理和SCM人员（可以email及附件的形式），经项目经理审核通过或签字，并经过SCM人员对该文档的命名和编号进行审核无误后，由作者将其放入SourceSafe的规定目录进行管理。如果需要对放入SourceSafe的文档进行修改，修改者将文档CheckOut，采用修改时将文档CheckIn，取消修改时UndoCheckOut。软件产品的文档除存放在SourceSafe进行管理外，还需在固定服务器的固定路径保留一份副本，供不使用SourceSafe的相关人员查询。SCM小组需每周从SourceSafe中取得最新版本更新固定服务器的固定路径中的副本。源代码及生成文件的版本控制VersionControlforSourceCode&BuildFiles软件产品的源代码文件，存放在\\Filesvr\VSS或\\CIPFilesrv\SourceCode的SourceSafe中指定的目录下。程序员及编译人员需为每个项目在本机设置工作目录。程序员在本机进行编码，将新增的源代码文件加入到SourceSafe中进行管理。先”GetLatestVersion”获取最新版本代码，使本地机的代码同步。然后将要修改的源代码文件Checkout。采用更改时Checkin，取消更改时选择UndoCheckout。当程序员源代码编写完成，并通过单元测试和集成测试后，提交《编译申请表》进行编译和系统测试。有关源代码提交编译的规程请参见《编译控制规程》CompileControlProcedure.doc。QE对生成文件进行测试，发现问题或BUG，在QAManager中新增缺陷记录，并将该条记录状态变为确认修改状态，指定修改人对源代码进行修改。有关缺陷管理的处理流程参见《缺陷管理规程》DefectsManagementProcedure.doc。历史记录以及恢复以前版本History&RollbackSCM小组需每周将SourceSafe中的所有项目文档和所有源代码进行备份(*.ssa备份到指定备份服务器中)。此外，SCM小组需每周将正在开发或维护中的源代码刻录光盘备份，然后提交给SeniorManager。对于受控于SourceSafe配置管理下的工作产品，如文档或源代码，都应保留历史更改记录，并且能恢复以前的版本。可以使用SourceSafe本身自带功能“ShowHistory”来显示该配置项的历史更改记录，并且使用“ShowHistory”中“Rollback”功能来恢复以前的版本。对于存放在固定路径下进行管理的配置项，如由源代码所生成的EXE、OCX、DLL，可以通过《编译列表》（模板为CompileList.xlt）文档来显示该配置项的历史更改记录，而通过恢复源代码的以前版本来重新生成EXE、OCX、DLL即可恢复该配置的以前版本。基线管理和变更控制BaselineManagement&ChangeControl基线的建立BaselineEstablishment基线Baseline：已经通过正式评审和批准的规格说明或工作产品，可以将其作为进一步开发的基础，并且只有通过正式的变更控制规程才可以被更改。在软件开发过程中，建立基线的步骤如下：1.由项目SCCB批准纳入基线的内容，授权SCM建立基线。2.SCM人员在建立基线以前，必须检查：是否还有被Check-out的文件。3.将SourceSafe中纳入基线的目录打上基线的标签(Label)，标签名称为”Baseline_ZZ_YYYYMMDD”,其中包含里程碑缩写ZZ和基线建立的日期YYYYMMDD。需求完成时，将”Requirements”目录标签为“Baseline_RQ_YYYYMMDD“，即需求文档纳入基线。概要设计完成时，将“Design&System”目录标签为“Baseline_SA_YYYYMMDD“，即概要设计文档纳入基线。系统测试完成时，将源代码目录标签为“Baseline_ST_YYYYMMDD“，即所有源代码纳入基线；并且将公共代码和核心代码的目录设为只读权限。4.使用”GetLatestVersion”从SourceSafe中，取得该项目的所有配置项内容项目文档和源代码。5.使用SCM工具（SCMTools.exe）生成《配置项内容列表》，提交项目SCCB。对于XP极限项目，只要在批准产品发布时，一次性生成软件基线库即可。基线库的建立BaselineLibraryEstablishment基线库BaselineLibrary：当产品发布新版本时建立的，包括所有的工作产品（项目文档、源代码、生成文件），并且只允许新建，不允许再变更。建立软件基线库的步骤如下：1.经项目SCCB审核，批准产品发布。2.项目经理在状态会议上授权SCM生成软件产品的基线库。3.SCM人员在建立基线库以前，必须通过下列检查：是否还有被Check-out的文件是否还有审批通过的变更请求没有关闭（SCMManager）Baseline服务器可用磁盘空间的大小，是否能在将来一段时间内继续正常工作4.将SourceSafe中该项目的项目文档目录Document和源代码目录SourceCode分别打上基线的标签(Label)，标签名称为”Baseline_BL_YYYYMMDD”.5.使用”GetLatestVersion”从SourceSafe中获取该项目最新版本的所有项目文档Document和源代码SourceCode，以及存放在固定服务器上的该产品的安装盘文件Setup，共同组成软件基线库内容，并复制到该产品在网络路径的Baseline目录中。6.使用SCM工具（SCMTools.exe）生成《软件基线库内容列表》。变更控制ChangeControl纳入基线以前的工作产品，可以通过SourceSafe日常的Check-in和Check-out进行更改。而纳入基线以后的工作产品，必须遵循下列变更控制规程：1.申请人先通过QAManager的”SCMManager”提交该变更请求，记录变更源类型、和变更的内容。状态为“请求变更”。2.由PM或PM指定的项目小组成员分析变更的影响，包括变更影响的工作产品、带来的风险、以及对工作量和进度的影响。影响的工作产品可能有项目计划、需求文档、概要设计文档、详细设计文档、源代码和程序、测试计划和测试案例、以及用户文档，影响还包括需要回测的范围。3.对影响小的变更，由PM直接进行审批；对影响大的变更，需要通过项目SCCB的审批。项目SCCB无法决定的变更，则提交高层SCCB决定。下列情况称为影响大的变更：变更的影响面比较大，如会影响系统的框架，或者所影响的相关模块比较多；或者变更会影响对客户的承诺；或者变更会带来很大的风险。4.审批通过后，PM对影响的工作产品指定相应的修改人，并指定变更的审核负责人。状态为“请求通过”。如果“请求不通过”，则该变更请求结束。5.修改人对相关工作产品进行修改。对文档进行修改后，需在修改历史表格中注明修改人、修改时间以及修改原因。工作产品修改完成后，”Checkin”回SourceSafe，”Checkin”的备注Comment中记录该变更的变更号SCMNumber；同时通知审核负责人开始审核。6.审核负责人对修改的工作产品逐个进行审核，并记录审核是否通过的状态。如果审核未通过，则返回修改者继续修改。直到所有影响的工作产品全部修改通过，关闭该变更请求。如果对原文件修改过大，必要时可以重新组织工作产品的评审。基线维护（审核及验证）BaselineMaintenance（Audit&Verification）SCM小组每两周对已纳入基线的内容进行审核，以验证基线内容的完备性以及准确性。基线审核的规程如下：1.使用”GetLatestVersion”从SourceSafe中取得所有配置项的最新内容，使用SCM工具（SCMTools.exe）重新生成一份最新的《配置项内容列表》。2.使用SCM工具的基线审核功能，将这一次和与上一次的《配置项内容列表》进行对比，得到《基线审核差异列表》（即新增、修改和删除的内容列表）。3.使用使用”SCMManager”的Report功能，将在该期间内所发生的SCM变更记录生成报告。4.SCM根据在该期间内所发生的SCM变更记录，从《基线审核差异列表》分析并找出不合法的基线变更差异。5.SCM人员根据以上报告的分析结果填写《SCM状态报告》，并与《基线审核差异列表》和SCM变更记录报告一起提交项目SCC