软件工程第十七章软件配置管理技朮分析.ppt

版本控制 很多版本控制系统都可以建立变更集——构造软件特定版本所需要的所有变更(针对某些基线配置)的集合。 可以为一个应用程序或系统标识很多已命名的变更集。这样就使软件工程师能够通过指定必须应用到基线配置的变更集来构造软件的一个版本。 在过去几十年中，对于版本控制已经提出了很多不同的自动化方法，这些方法的主要区别在于构造系统特定版本和变体属性时的复杂程度以及构造过程的机制。 变更控制 对于大型的软件工程项目，不受控制的变更会迅速导致混乱。对于这种大型项目，变更控制应该将人为制定的规程与自动工具结合起来。变更控制过程如图17-5所示，提交一个变更请求之后，要对其进行多个方面的评估：技术指标、潜在的副作用、对其他配置对象和系统功能的整体影响，以及变更的预计成本。评估的结果形成变更报告，由变更控制授权人使用。对每个被批准的变更，需要建立工程变更工单ECO，ECO描述了将要进行的变更、必须要考虑的约束以及评审和审核的标准。 变更控制过程 图17-5 变更控制过程 变更控制 可以将要进行变更的对象放到一个目录中，该目录只能由实施变更的软件工程师单独控制。完成变更之后，版本控制系统可以更新原始文件。或者，可以将要进行变更的对象从项目数据库中“检出(check out)，进行变更，并应用适当的SQA活动，然后，再将对象检入(check in)到数据库，并应用适当的版本控制机制构建该软件的下一个版本。 变更控制 以上版本控制机制与变更控制过程集成在一起，实现了变更管理的两个主要元素——访问控制和同步控制。访问控制负责管理哪个软件工程师有权限去访问和修改某个特定的配置对象；同步控制协助保证两个不同的人员完成的并行变更不会被相互覆盖。 变更控制 在SCI成为基线之前，只需要进行非正式的变更控制。还在讨论之中的配置对象(SCI)的开发者可以进行任何变更，只要项目和技术需求证明这些变更是适当的。一旦配置对象经过正式技术评审并被批准，它就成为基线。一旦SCI成为基线，就可以实现项目级变更控制了。这时，若要进行变更，开发者必须得到项目管理者的批准，如果该变更影响到其他SCI，则必须得到CCA的批准。在某些情况下，无需生成正式的变更请求、变更报告和ECO，但是，必须对每个变更进行评估，并对所有的变更进行跟踪和评审。 配置审核 标识、版本控制和变更控制帮助软件开发者维持秩序，否则情况可能将是混乱和不断变化的。然而，即使最优秀的控制机制也只能在ECO建立之后才可以跟踪变更。如何保证变更的实现是正确的呢？可从两个方面入手：(1)技术评审；(2)软件配置审核。 技术评审关注的是配置对象在修改后的技术正确性。评审者要评估SCI，以确定它与其他SCI是否一致，是否有遗漏，或是否具有潜在的副作用。除了那些非常微不足道的变更之外，应该对所有变更进行技术评审。 配置审核 作为技术评审的补充，软件配置审核针对在评审期间通常不被考虑的特征对配置对象进行评估。软件配置审核要解决以下问题：1.在ECO中指定的变更已经完成了吗？引起任何额外的修改了吗？2.是否已经进行了技术评审来评估技术正确性？3.是否遵循了软件过程，是否正确地应用了软件工程标准？4.在SCI中“显著标明”所做的变更了吗？是否说明了变更日期和变更者？配置对象的属性反映出该变更了吗？5.是否遵循了SCM规程中标注变更、记录变更和报告变更的规程？6.是否已经正确地更新了所有相关的SCI？ 状态报告 配置状态报告（有时称为状态账目）是一项SCI任务，它解答下列问题：(1)发生了什么事？(2)是谁做的？(3)是什么时候发生的？(4)会影响到其他哪些事情? 每当赋予SCI新的标识或更改其标识时，就会产生一个CSR条目；每当CCA批准一个变更时，就会产生一个CSR条目；每当进行配置审核时，其结果要作为CSR任务的一部分提出报告。CSR的结果可以放置到一个联机数据库中或Web站点上，以便软件开发者或维护人员可以按照关键词分类来访问变更信息。此外，定期生成的CSR报告使管理者和开发人员可以评估重要的变更。 小结 作业 P316 4 10 软件工程 第17章 软件配置管理 主要内容 软件配置管理概述 SCM中心存储库 SCM过程 小结 软件配置管理 软件配置管理（SCM），也称为变更管理，是一组管理变更的活动。它通过下面的方式来管理变更：识别可能发生变更的工作产品，建立这些工作产品之间的关系，制定管理这些工作产品的不同版本的机制，控制所施加的变更，审核和报告所发生的变更。 参与软件过程的每个人在某种程度上都参与变更管理，但是有时候也设专人来管理SCM过程。 软件配置管理 如果不控制变更，将被变更所控制。一个未受控制的变更流可以很容易地将一个运行良好的软件项目带入混乱。结果会影响软件质量并且会推迟软件交付。为此