3.5、配置和变更管理支持迭代式的基于基线的开发

    迭代式开发意味着每个后继迭代，都以前一个迭代为基础，不断地进化和完善系统，直至完成最终产品。历史上有一段时期，为了强调这一点，RUP曾特意宣传“迭代和增量开发”。

    建立并管理基线(baseline)，为迭代式开发提供了有力支持。基线的要点有二：一是要通过评审，二是要受配置和变更管理控制。IEEE对于基线的完整定义是：已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变。

    配置和变更管理完成建立并管理基线的任务。置于配置和变更管理之下的工件，称为配置项(configuration item)——因此下图把配置项建模为工件的子类。而基线就是有多个配置项组成的瞬时快照——因为受配置和变更管理控制是基线的必要条件。

    上面讨论了“工件-配置项-基线”这些静态概念，下面再讨论一下相关动态概念。任何工件，都有可能发生变更;正如并不是所有工件都是配置项一样，变更也不一定都受控，比如，用于讨论的临时设计就不必受控。只有配置项的变更，才是需要受配置和变更管理控制的。到底哪些工件应当受控，是根据实践情况决定的，应当在规范性和灵活性之间权衡考虑。

    3.6、发布是什么，发布不是什么

    发布(release)是软件产品的一个稳定的、可执行的版本，它包括了发布说明、用户手册等相关工件。

    单纯的文档或者不能执行的软件版本，并不是发布。

    发布是某个迭代周期的成果，但是并非每个迭代周期都用发布。

    图中表达得很明白，发布是特殊的基线。这意味着发布不是单一的工件，而是工件集;而且发布的工件都应当置于配置管理的控制之下，这是因为你必须标识和跟踪这些工件，开发团队或者用户的很多活动都和它们相关。

    4、总结

    UML已经广泛用于软件开发活动，可视化表达使得理解和解决问题变得容易。本文是UML的另一个应用，它被用来明确概念之间的关系，希望对大家有所启发。

    参考文献：

    [1] Gary Pollice等著，宋锐等译. 小型团队软件开发：以RUP为中心的方法. 中国电力出版社，2004

    [2] Per Kroll等著，徐正生等译. Rational统一过程：实践者指南. 中国电力出版社，2004