SP30209软件项目配置管理计划.ppt

基线配置项——可能包括所有的设计文档和源程序等 非基线配置项——可能包括项目的各类计划和报告等。 注意：基线是一个或者多个配置项的集合，因此它的形成往往需要一定的过程。 内容和状态已经通过技术的复审，并在生存期的某一阶段被接受了。 * 关于配置项复审 目标是验证配置项被接受之前的正确性和完整性 一旦配置项经过复审，并正式成为一个初始基线，那么该基线就可以作为项目生存期下面开发活动的起始点。 * 基线的图示（1）总体情况 * 图9.4基线图示（转向） 图9.4基线图示 基线1 基线2 基线3 基线4 思考：怎样得到基线4? 基线的图示（2）：细节情况 * 《如何规划一个UCM工程》/developerworks/cn/rational/r-sunzq/ 基线的图示（3）产品情况——对基线图示（2）的解释 * 请问：这里的配置项是依据什么确定的？ 基线的表格描述——也是对基线图示（2）的解释 * 建立基线的好处 好处：控制配置项不得随意改动，同时又不过分阻止合理的变化。 对于已成为基线的配置项，虽然可以修改，但必须接照一个特殊的、正式的过程进行评估，确认每一处修改。 相反，对于未成为基线的配置项，可以进行非正式修改。 * 基线不是不让变化！ 变化意味着两个连续的版本之间的不同（如从配置项中添加和去掉的线和图）。 不能简单地认为变化就是改变。这里的关键词是“不同”。 基线是否可以改变，要看变化本身的特征 通常，修复一个系统错误或添加一个功能到系统上，要求对几个配置项做变化——形成变化集。 如果两个变化集不重叠（即，如果它们用于不同的且无关的配置项集合时），它们能够以任意的顺序应用到同样的基线上，这为选择配置的开发者提供了更多的灵活性。 * 怎样做到这一点？ 有变化才有产品的发布 * 9.2.3 配置控制委员会 配置控制委员会（Software configuration Control Board，SCCB） 可以是一个人也可以是一个小组，基本是由项目经理及其相关人员组成。 SCCB承担变更控制的所有责任，具体责任如下： 评估变更。 批准变更申请。 在生存期内规范变更申请流程。 对变更进行反馈。 与项目管理层沟通。? * * 9.3.1 配置项标识跟踪 配置项应该被唯一标识，同时应该定义软件配置项的表达约定。 通常，一个配置项与其他的配置项存在一定的关系，跟踪配置项之间的关系是很重要的。 图9-6是需求规格配置项和系统测试用例配置项的跟踪关系。 * * 9.3.2 配置管理环境的建立 配置管理环境——配置管理库，简称配置库。 是用于更好地进行软件配置管理的系统环境。 配置库存储内容——所有配置项的集合和配置项修改状态记录的集合 配置项（SCI）相应版本 修改请求、变化记录等内容 只要没有新的版本，配置库中的文件是不会变的(禁止修改) 任何更改都被视为创建了一个新版本的文件 * 9.3.3 基线变更管理 变更应受到控制，这种变更要经SCCB授权，按照程序进行控制并记录修改的过程。 变更管理也就是对配置的控制——防止开发人员对软件的随意变更，需要在管理上实施复审和批准过程。 * 推荐的阅读材料：微软的配置管理与变更管理 /china/technet/itsolutions/msit/valuecard/chgconfigmgmt.mspx 9.3.4 配置审核 配置管理活动审核 用于确保项目组成员的所有配置管理活动，遵循已批准的软件配置管理方针和规程，如检入/检出的频度、产品版本升级原则等 基线审核 保证基线化软件工作产品的完整性和一致性，其目的是保证基线的配置项（SCI）正确地构造并正确地实现，并且满足其功能要求 * 小知识：检入/检出（签入/签出） 这是代码或文档源文件的版本管理术语 签出——使用户在编辑文件的同时可以将其锁定，从而防止其他人不慎覆盖或编辑它。只有签出文档的用户可以编辑该文档。 签入——解除对编辑功能的锁定，使其他用户可以查看更新的文件或签出该文件。 参考：使用 Rational ClearCase 检出和检入配置项 /~car/programming/rup/toolment/clearcase/tm_cico.htm 基线的完整性和一致性 基线的完整性——覆盖面问题 基线库是否包括所有计划纳入的配置项，基线库中配置项自身的内容是否完整。 对于代码，要根据代码清单检查是否所有源文件都已存在于基线库中。 编译所有的源文件，检查是否可产生最终产品。 基线的一致性——检查点问题 需求与设计以及设计与代码的一致性如何？ 在有变更发生时，所有受影响的部分是否都做了相应的变更？ 审核发现的不符合项要进行记录，并跟踪直到解决。 * 9.3.6 配置管理的其他作用 9.3.