SVN软件配置管理汇.ppt

软件版本升级管理： 每次登入时，在服务器上都会生成新的版本。 任何版本都可以随时检出编辑，同一应用的不同版本可以像树枝一样向上增长。 加锁功能： 目的是在文件更新时保护文件，避免不同用户更改同一文件时发生冲突。 某一文件一旦被登入，锁即被解除，该文件可被其它用户使用。 在更新一个文件之前锁定它，避免变更没有锁定的项目源文件。 在文件登入和检出时，需要注意登入和检出的使用: 当需要修改某个小缺陷时，应只检出完成工作必需的最少文件； 需要对文件变更时，应登入它并加锁，保留对每个变更的记录； 应避免长时间地锁定文件。如果需要长时间工作于某个文件，最好能创建一个分支，并在分支上做工作。 如果需要做较大的变更，可有两种选择： a.将需要的所有文件检出并加锁，然后正常处理； b.为需要修改的所有分支创建分支，把变更与主干“脱机”，然后把结果合并回去。 变更控制 软件生存期内全部的软件配置是软件产品的真正代表，必须使其保持精确。 软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息。 变更控制包括建立控制点和建立报告与审查制度。 变更控制 过程 在此过程中，首先用户提交书面的变更请求，详细申明变更的理由、变更方案、变更的影响范围等。 然后由变更控制机构确定控制变更的机制、评价其技术价值、潜在的副作用、对其它配置对象和系统功能的综合影响以及项目的开销、并把评价的结果以变更报告的形式提交给变更控制负责人（最终决定变更状态和优先权的某个人或小组）。 对每个批准了的变更产生一个工程变更顺序（ECO），描述进行的变更、必须考虑的约束、评审和审计的准则等。 要做变更的对象从项目数据库中检出（check out），对其做出变更，并实施适当的质量保证活动。然后再把对象登入（check in）到数据库中并使用适当的版本控制机制建立软件的下一版本。 软件变更有两类不同情况： 为改正小错误需要的变更。它是必须进行的，通常不需要从管理角度对这类变更进行审查和批准。但是，如果发现错误的阶段在造成错误的阶段的后面，例如在实现阶段发现了设计错误，则必须遵照标准的变更控制过程，把这个变更正式记入文档，把所有受这个变更影响的文档都做相应的修改。 为了增加或者删掉某些功能、或者为了改变完成某个功能的方法而需要的变更。这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和它对软件系统其它部分的影响。 如果变更的代价比较小且对软件系统其它部分没有影响，或影响很小，通常应批准这个变更。 如果变更的代价比较高，或者影响比较大，则必须权衡利弊，以决定是否进行这种变更。 如果同意这种变更，需要进一步确定由谁来支付变更所需要的费用。如果是用户要求的变更，则用户应支付这笔费用；否则，必须完成某种成本／效益分析，以确定是否值得做这种变更。 这种变更报告和审查制度，对变更控制来说起了一个安全保证作用。 在一个SCI成为基线之前，可以对所有合理的项目和技术申请进行非正式的变更； 一旦某个SCI经过正式的技术评审并得到批准，它就成了基线。以后如果需要对它变更，就必须得到项目负责人的批准，或者必须得到变更控制负责人的批准。 配置状态报告 为了清楚、及时地记载软件配置的变化，需要对开发的过程做出系统的记录，以反映开发活动的历史情况。这就是配置状态登录的任务。 登录主要根据变更控制小组会议的记录，并产生配置状态报告。 对于每一项变更，记录：发生了什么？为什么会发生？谁做的？什么时侯发生的？会有什么影响？ 配置状态报告信息流 每次新分配一个SCI，或更新一个已有SCI的标识，或一项变更申请被变更控制负责人批准，并给出了一个工程变更顺序时，在配置状态报告中就要增加一条变更记录条目。 一旦进行了配置审计，其结果也应该写入报告之中。 配置状态报告可以放在一个联机数据库中，以便软件开发人员或者软件维护人员可以对它进行查询或修改。此外在软件配置报告中新登录的变更应当及时通知给管理人员和软件工程师。 配置状态报告对于大型软件开发项目的成功起着至关重要的作用。避免了可能出现的不一致和冲突。 配置审计 软件的完整性，是指开发后期的软件产品能够正确地反映用户要求。 软件配置审计的目的就是要 证实整个软件生存期中各项产品在技术上和管理上的完整性。 确保所有文档的内容变动不超出当初确定的软件要求范围。使得软件配置具有良好的可跟踪性。 软件配置审计是软件变更控制人员掌握配置情况、进行审批的依据。 软件的变更控制机制通常只能跟踪到工程变更顺序产生为止。为确认变更是否正确完成? 一般可以用以下两种方法去审查： 正式技术评审 软件配置审计 正式的技术评审着重检查已完成修改的软件配置对象的技术正确性， 评审者评价SCI，