搜索
酒店管理系统卷号卷内编号密级分类:专题计划使用者:项目经理、配置变更控制经理、集成员、项目组成员配置管理计划Version1.0项目承担部门：配置管理部门撰写人（签名）：完成日期：2010/7/18本文档使用部门：□主管领导■项目组□客户（市场）□维护人员□用户评审负责人（签名）：评审日期：文档信息标题:配置管理计划作者:创建日期:2010/7/18上次更新日期:2010/7/18版本:Version1.0部门名称:swjtu-Java-02修订文档历史记录日期版本说明作者2010/7/18Version1.0创建文档2010/7/22Version1.1修改文档目录1.简介41.1目的41.2范围41.3定义、首字母缩写词和缩略语41.4参考资料442.软件配置管理42.1组织、职责和接口42.2工具、环境和基础设施43.配置管理活动63.1配置标识63.1.1标识方法63.1.2项目基线63.2配置和变更控制83.2.1变更请求的处理和审批83.2.2变更控制委员会(CCB)103.3配置状态统计113.3.1项目介质存储和发布进程113.3.2报告和审计114.里程碑115.培训和资源126.分包商和厂商软件控制错误!未定义书签。配置管理计划1.简介项目CM计划说明在产品生命周期中将执行的所有与CM相关的活动。它详细说明了活动时间表、分配的职责以及必需的资源（包括人员、工具和计算机设备）。1.1目的CM计划的目的在于，定义或参考那些描述要在软件产品开发中执行配置和变更控制管理(CM)方式的步骤和活动。1.2范围本规范规定了在制订软件配置管理计划时应该遵循的统一的基本要求。本规范适用于软件特别是重要软件的配置管理计划的制订工作。对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。1.3定义、首字母缩写词和缩略语CCB-configurationcontrolboard变更（或配置）控制委员会CI-configurationitem配置项CM-configurationmanagement配置管理Baseline：基线。PCA：物理审计，在配置管理系统中建立基线的工件是否为“正确”版本。FCA：功能审计，是核实软件配置项的实际性能是否符合它的需求。CMP-configurationmanagementplan配置管理计划CR-changerequest变更请求SCM-softwareconfigurationmanagement软件配置管理任意角色–项目中所有角色1.4参考资料《RationalUnifiedProcess2000》《SDPPlan》《DevelopCase》2.软件配置管理2.1组织、职责和接口角色相关人员职责接口CCB该委员会监督变更流程，由开发人员和用户的代表组成。与任意角色：任意角色提出变更请求，需提交给CCB，对变更请求进行处理后，将结果通知给提出者。配置经理配置经理负责为产品开发团队提供全面的配置管理(CM)基础设施和环境。CM的作用是支持产品开发行为，使开发人员和集成员有适当工作区来构建和测试其工件，并且使所有工件均可根据需要包含在部署单元中。配置经理还必须确保CM环境有利于进行产品复审、更改和缺陷跟踪等活动。配置经理还负责撰写CM计划并汇报基于“变更请求”的进度统计信息。发布基线与项目经理：CM计划需要参照SDP计划，而且SDP又参照CM计划。SCM经理每周/每阶段都要提供系统的配置状态报告给项目经理。与集成员：CM经理创建配置管理库，而集成员创建集成工作区。集成员创建基线和提升基线，由SCM经理管理基线。与部署经理：SCM经理创建部署单元，需要部署计划。与架构设计师：SCM经理创建CM环境，需要实施模型。与任意角色：任意角色创建开发工作区，需要配置库。与系统管理员：创建CM环境时，需要系统管理员提供硬件和网络基础设施。与组织SCM管理员：在每一阶段基线完成后提交基线工件。与评审协调员：接收评审协调员提交的评审结果工件和评审表。与SQA人员：配合SQA人员活动。任意角色项目组所有成员任何角色均可以“检入”和“检出”任何与产品相关的工件，以便在配置控制系统中进行维护。此外，任意角色都可以提交变更请求，并且对它们所拥有的变更请求进行更新。2.2工具、环境和基础设施1.工具类型使用时期工具原因配置管理产品开发全程SvnSvn简单，功能强大。2.CM环境和基础设施1）产品数据量的预期大小：我们期望本项目至少有150个文件，50M的磁盘空间。2）产品团队的分配：角色成员名单角色说明PM项目经理SA需求分析师SE设计分析师TE测试工程师CM配置管理员PPQA产品和质量保证服务器和客户机的实际位置：1台。2G内存、160G硬盘。Win7。服务器位置在C2-6,客户端在C2-1.3.4.5.7.8.9.103.配置管理活动3.1配置标识3.1.1标识方法最终的工件的命名方式是大写字母+缩写+编号+名称例：HMS-CM-101-配置管理计划相应的工件的中间版本命名方式是以对应的阶段大写字母缩写加类别大写缩写加版本编号命名发布标志为产品缩写加版本号,阶段发布为阶段号加版本号3.1.2工件存储目录及分类项目开发过程产生的工件由相应的负责人及时上传至SVN服务器，由配置管理员统一管理。SVN服务器文件存放目录分类如下图3.1.3文件上传管理所有模块负责人必须与每日工作结束之前上传当日工作内容上传至SVN服务器。所有上传工件必须符合标识方法中的命名方式。3.1.3项目基线基线名称基线标识产出时机计划基线JH-01计划阶段结束需求基线XQ-01需求分析阶段结束设计基线SJ-02设计阶段结束产品基线CP-03实现部署阶段结束基线创建非代码类基线：由配置经理根据《开发案例》创建代码类基线：由集成员根据产品架构文档创建3.2配置和变更控制3.2.1变更请求的处理和审批软件配置的变更管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。变更请求表单是一个正式提交的工件，用于在整个项目的生命周期内跟踪所有的请求（包括新特性、扩展请求、缺陷、变更的需求等）与相关的状态信息。所有变更历史记录，包括所有状态变更及变更的日期和原因，都将随CR一起保存。进行多次复审和结束项目时都可使用此信息。变更过程中的活动活动角色内容提交变更请求提交者项目的任何涉众均可提交变更请求(CR)。通过将变更请求状态设置为已提交，变更请求被记录到变更请求追踪系统中（例如ClearQuest）并放置到CCB复审队列中。复审变更请求CCB此活动的作用是复审已提交的变更请求。在CCB复审会议中对变更请求的内容进行初始复审，以确定它是否为有效请求。如果是，则基于小组所确定的优先级、时间表、资源、努力程度、风险、严重性以及其他任何相关的标准，判定该变更是在当前发布版的范围之内还是范围之外。确认重复或拒绝CCB代表如果怀疑某个变更请求为重复的请求或已拒绝的无效请求（例如，由于操作符错误、无法重现、工作方式等），将指定一个CCB代表来确认重复或已拒绝的变更请求。如果需要的话，该代表还从提交者处收集更多信息。更新变更请求提交者如果评估变更请求时需要更多的信息（详细信息），或者如果变更请求在流程中的某个时刻遭到拒绝（例如，被确认为是重复、已拒绝等），那么将通知提交者，并用新信息更新变更请求。然后将已更新的变更请求重新提交给CCB复审队列，以考虑新的数据。分配工作与安排工作时间项目经理一旦变更请求被置为已打开，项目经理就将根据请求的类型（例如，扩展请求、缺陷、文档变更、测试缺陷等）把工作分配给合适的角色，并对项目时间表做必要的更新。进行变更指定的角色指定的角色执行在流程的有关部分中指定的活动集（例如，需求、分析设计、实施、制作用户支持材料、设计测试等），以进行所请求的变更。这些活动将包括常规开发流程中所述的所有常规复审活动和单元测试活动。然后，变更请求将标记为已解决。核实测试工作版本中的变更测试员指定的角色（分析员、开发人员、测试员、技术文档编写员等）解决变更后，变更将放置在要分配给测试员的测试队列中，并在产品工作版本中加以核实。核实发布工作版本中的变更系统集成员已确定的变更一旦在产品的测试工作版本中得到了核实，就将变更请求放置在发布队列中，以便在产品的发布工作版本予以核实、生成发布版本说明等，然后关闭该变更请求。3.2.1.1变更过程中的变更请求状态状态定义已提交出现此状态的原因为：1)提交新的变更请求；2)更新现有的变更请求；或3)考虑在新的发布周期中使用已推迟的变更请求。变更请求放置在CCB复审队列中。本操作的结果不会指定拥有者。已推迟变更请确定为有效，但对于当前发布版来说属于“超出范围”。处于已推迟状态的变更请求将得以保留，并在以后的发布版中被重新考虑并加以使用。可以指定一个目标发布版，以表明可以提交变更请求（以重新进入CCB复审队列）的时间范围。重复处于此状态的变更请求被视作对已提交的另一个变更请求的重复。变更请求可由CCB复审管理员或被指定解决它的角色置于该状态中。将变更请求置于重复状态中时，将（在ClearQuest的“附件”选项卡上）记录它所重复的那个变更请求的编号。在提交变更请求之前，提交者应首先查询变更请求数据库，看是否已有与之相重复的变更请求。这将省去复审流程中的若干步骤，从而节省大量的时间。应将重复变更请求的提交者添加到原始变更请求的通知列表中，以便以后将有关解决事宜通知他们。已拒绝CCB复审会议或指定的角色确定此状态中的变更请求为无效请求，或者需要提交者提供更为详细的信息。如果已经指定（提出）变更请求，则它将从解决队列中删除并重新复审。这将由CCB所指定的权威来予以确认。除非有必要，否则提交者无需进行任何操作。在此情况下变更请求状态将变为详细信息。考虑到可能会有新的信息，在CCB复审会议中将重新复审该变更请求。如果变更请求确认为无效，将被CCB关闭并且通知提交者。详细信息数据不足以确认已拒绝或重复的变更请求是否有效。拥有者自动变成提交者，将通知提交者提供更多数据。已打开对于当前发布版来说，处于此状态的变更请求已被确定为属于“范围之内”，并且亟待解决。它已定于在即将来临的目标里程碑之前得以解决。它被确定在“指定队列”中。与会者是提出变更请求并将其放入解决队列中的唯一权威。如果发现优先级为第二或更高的变更请求，应立即通知QE经理或开发经理。此时，他们可以决定召开紧急CCB复审会议，或立即打开变更请求以将其放入解决队列中。已指定然后由项目经理负责已打开的变更请求，他应根据变更请求的类型分配工作；如果需要,还应更新时间表。已解决表示该变更请求已解决完毕，现在可以进行核实了。如果提交者是QE部门的成员，则拥有者将自动变成执行提交的QE成员。否则，拥有者将变成QE经理，以重新进行人工分配。测试已失败在测试工作版本或发布工作版本中进行测试时失败的变更请求将置于此状态中。拥有者自动变成解决变更请求的角色。已核实处于此状态的变更请求已经在测试工作版本中得到了核实，并且可以进行发布了。已关闭变更请求不再引人注意。这是可以指定给变更请求的最后一个状态。只有CCB复审管理员有权关闭变更请求。变更请求被关闭后，提交者将收到一份有关对变更请求的最终处理结果的电子邮件通知。在下列情况中可能关闭变更请求：1)其已核实的解决结果在发布工作版本中得到确认之后；2)其拒绝状态得到确认时；或3)被确认为对现有变更请求的重复。在后一种情况中，会将重复变更请求通知给提交者，并将提交者添加到该变更请求中，以便以后通知他们（详情请参见状态“拒绝”和“重复”的定义）。如果提交者希望对关闭变更请求有异议，则必须更新变更请求并且重新将其提交供CCB复审。变更过程的变更请求状态(状态图)：3.2.1.2保存变更历史记录如果工件为Word文档，则在文档的修订文档历史记录。如果工件为其他工件，必须在相应的记录中保存变更历史纪录。3.2.1.3变更请求中受影响配置项的变更在变更请求中受影响配置项需要变更时，首先由CCB协调员通知受影响配置项的变