配置管理原理与实践 (2008 年度畅销榜NO.1897 )

软件配置管理是软件质量改进的核心环节。它贯穿于整个软件生命周期，为软件改进提供了一套解决办法与活动原则。本书阐明了完善的软件工程配置管理策略应该包含的元素，以及它所带来的好处，还描述了如何把配置管理策略应用到实践中。\r\n\r\n 全书分为5部分，共26章和3个附录，其主题：配置管理基本概念；配置管理基本原则；配置管理数据的选择和应用；配置管理活动中涉及到的不同角色及其任务；在不同的环境中应用配置管理；在各种大小规模的项目中，针对安全性要求严格的系统、复合系统、多平台系统和多变体系统实施配置管理，管理多地点开发、提供跨组织的功能；集成不同的配置管理工具；基于CMMI来改进配置管理过程。\r\n\r\n 本书对试图提高生产效率、增强市场竞争力的软件企业及意欲在软件配置管理领域有所作为的读者来说，无疑是不可多得的一本好书。本书可作为大专院校相关专业的教辅材料和培训教材，也可供计算机软件开发人员和用户阅读。\r\n
\r\n

前言 \r\n\r\n 介绍 \r\n\r\n 第1部分 什么是配置管理? \r\n\r\n 第1章 本书对配置管理的定义 \r\n\r\n 1. 1 配置管理活动 \r\n\r\n 1. 2 标识 \r\n\r\n 1. 3 存储 \r\n\r\n 1. 4 变更控制 \r\n\r\n 1. 5 状态报告 \r\n\r\n 1. 6 伪朋友：版本控制与基线 \r\n\r\n 第2章 成熟度模型的配置管理 \r\n\r\n 2. 1 CMM版本1. 1 \r\n\r\n 2. 2 CMMI \r\n\r\n 2. 3 ISO 15504(SPICE)与BOOTSTRAP 3. 2 \r\n\r\n 第3章 配置管理的国际标准 \r\n\r\n 3. 1 相关标准的概述 \r\n\r\n 3. 2 BS6488. DOD和IEEE \r\n\r\n 3. 3 ESA PSS-05-09 \r\n\r\n 3. 4 GAMP \r\n\r\n 3. 5 ISO 9001：1994. ISO 9000-3和ISO 9001：2000 \r\n\r\n 第4章 从事配置管理的组织 \r\n\r\n 4. 1 研究所与公司 \r\n\r\n 4. 2 项目 \r\n\r\n 第5章 确定配置管理的任务范围 \r\n\r\n 5. 1 希望等级--成本／收益分析 \r\n\r\n 5. 2 举例 \r\n\r\n 5. 3 效益计算 \r\n\r\n 5. 4 确定在范围方面的陷阱 \r\n\r\n 5. 5 怎样对待被排斥在外的内容 \r\n\r\n \r\n\r\n 第2部分 配置管理数据 \r\n\r\n 第6章 什么可以置于配置管理之下 \r\n\r\n 6. 1 物理对象或者电子对象 \r\n\r\n 6. 2 从产品角度看对象类型 \r\n\r\n 6. 3 从项目角度看对象类型 \r\n\r\n 6. 4 从跨组织角度看对象类型 \r\n\r\n 6. 5 配置管理下的交付产品 \r\n\r\n 6. 6 已计划事件(例如, 里程碑)的交付产品 \r\n\r\n 第7章 对配置项需要了解什么 \r\n\r\n 7. 1 配置项的元数据概述 \r\n\r\n 7. 2 惟一标识的元数据 \r\n\r\n 7. 3 授权的元数据 \r\n\r\n 7. 4 表示和其他配置项间关系的元数据 \r\n\r\n 7. 5 分发的元数据 \r\n\r\n 第8章 配置项必须记录什么内容 \r\n\r\n 8. 1 配置项批准 \r\n\r\n 8. 2 发布请求 \r\n\r\n 8. 3 事件记录 \r\n\r\n 8. 4 变更请求 \r\n\r\n 第9章 可由配置项得到什么信息 \r\n\r\n 9. 1 实例 \r\n\r\n 9. 2 配置管理作为度量标准的提供者 \r\n\r\n \r\n\r\n 第3部分 配置管理中的角色 \r\n\r\n 第10章 人与配置管理 \r\n\r\n 10. 1 配置管理作为一种职业 \r\n\r\n 10. 2 管理配置是每个人的工作 \r\n\r\n 10. 3 理解团队角色 \r\n\r\n 第11章 配置管理角色 \r\n\r\n 11. 1 配置控制委员会 \r\n\r\n 11. 2 库管理员 \r\n\r\n 11. 3 配置管理负责人 \r\n\r\n 第12章 组织角色 \r\n\r\n 12. 1 管理层 \r\n\r\n 12. 2 资产负责人 \r\n\r\n 12. 3 操作负责人 \r\n\r\n 12. 4 过程管理负责人 \r\n\r\n 12. 5 环境与工具负责人 \r\n\r\n 12. 6 支持与帮助 \r\n\r\n 第13章 与项目有关的角色 \r\n\r\n 13. 1 分析人员 \r\n\r\n 13. 2 设计人员 \r\n\r\n 13. 3 程序员 \r\n\r\n 13. 4 集成人员 \r\n\r\n 13. 5 测试人员 \r\n\r\n 13. 6 项目经理 \r\n\r\n 13. 7 质量负责人 \r\n\r\n 13. 8 客户合同负责人 \r\n\r\n 13. 9 分包商合同负责人 \r\n\r\n 第14章 外部角色 \r\n\r\n 14. 1 客户 \r\n\r\n 14. 2 分包商 \r\n\r\n \r\n\r\n 第4部分 配置管理实践 \r\n\r\n 第15章 通用的原则 \r\n\r\n 15. 1 里程碑 \r\n\r\n 15. 2 文档处理 \r\n\r\n 15. 3 紧急变更 \r\n\r\n 第16章 开发活动中的配置管理 \r\n\r\n 16. 1 文档记录活动(规格说明和设计) \r\n\r\n 16. 2 编码 \r\n\r\n 16. 3 集成 \r\n\r\n 16. 4 测试 \r\n\r\n 16. 5 操作使用 \r\n\r\n 16. 6 维护 \r\n\r\n 第17章 项目支持功能的配置管理 \r\n\r\n 17. 1 项目管理 \r\n\r\n 17. 2 配置管理 \r\n\r\n 17. 3 质量保证 \r\n\r\n 17. 4 分包商管理 \r\n\r\n 第18章 不同开发模型中的配置管理 \r\n\r\n 18. 1 敏捷开发 \r\n\r\n 18. 2 频繁联编技术 \r\n\r\n 18. 3 集成产品开发 \r\n\r\n 18. 4 迭代开发 \r\n\r\n 18. 5 顺序开发 \r\n\r\n 第19章 针对不同产品类型的配置管理 \r\n\r\n 19. 1 复合系统 \r\n\r\n 19. 2 多平台 \r\n\r\n 19. 3 多变体 \r\n\r\n 19. 4 安全性要求严格的产品 \r\n\r\n 19. 5 产品的规模(大型和小型) \r\n\r\n 19. 6 Web应用 \r\n\r\n 第20章 特殊环境下的配置管理 \r\n\r\n 20. 1 多地点开发 \r\n\r\n 20. 2 多个项目关系人 \r\n\r\n 20. 3 并行开发 \r\n\r\n 20. 4 工具支持 \r\n\r\n 第21章 跨组织功能的配置管理 \r\n\r\n 21. 1 公司基础设施 \r\n\r\n 21. 2 跨组织的对象 \r\n\r\n 21. 3 外部重用组件开发 \r\n\r\n 21. 4 内部资产开发(生产线方法) \r\n\r\n 21. 5 包括过程管理的质量体系 \r\n\r\n \r\n\r\n 第5部分 配置管理的改进 \r\n\r\n 第22章 开始配置管理--达到能力成熟度等级1 \r\n\r\n 22. 1 从零开始 \r\n\r\n 22. 2 走向配置管理的第一步 \r\n\r\n 22. 3 执行配置管理的经验 \r\n\r\n 第23 计划配置管理--达到能力成熟度等级2 \r\n\r\n 23. 1 通用的计划建议 \r\n\r\n 23. 2 配置管理计划的内容表 \r\n\r\n 23. 3 配置管理计划：介绍 \r\n\r\n 23. 4 配置管理计划：管理以及与环境的关系 \r\n\r\n 23. 5 配置管理计划：活动 \r\n\r\n 23. 6 配置管理计划：时间进度安排 \r\n\r\n 23. 7 配置管理计划：工具. 技术和方法 \r\n\r\n 第24章 配置管理的过程--达到能力成熟度等级3 \r\n\r\n 24. 1 通用过程 \r\n\r\n 24. 2 配置管理过程--概览 \r\n\r\n 24. 3 配置管理过程--模型实例第25章 继续改进配置管理--达到能力成熟度等级4和等级5 \r\n\r\n 25. 1 通用的软件过程改进建议 \r\n\r\n 25. 2 控制配置管理性能的度量标准 \r\n\r\n 25. 3 控制和改进的度量标准分析 \r\n\r\n 第26章 配置管理的工具支持 \r\n\r\n 26. 1 配置管理工具的分类 \r\n\r\n 26. 2 组织的考虑因素 \r\n\r\n 26. 3 配置管理工具的选择 \r\n\r\n 26. 4 对配置管理工具的需求 \r\n\r\n 26. 5 对工具供应商的需求 \r\n\r\n 26. 6 配置管理工具的定制 \r\n\r\n 附录A 配置管理过程模型：一个软件代码的实例 \r\n\r\n 附录B 配置管理过程模型：一个跟踪实例 \r\n\r\n 附录C 敏捷SCM \r\n\r\n 术语表 \r\n\r\n 参考文献 \r\n
\r\n

序1

解决配置管理的问题可以 大大减少返工的代价, 更可以大大减少程序员们的烦恼. 我曾经很幸运地在一家公司工作过, 该公司在自己的专有系统中配置管理工作做得非常出色. 然而, 当他们开始在开放系统上开发软件时, 配置管理实践就不那么容易了. 那些根深蒂固的习惯. 已经融入自我意识中而无需再进行任何考虑的东西, 突然变成了不能预料. 没法在新系统中思考的东西, 这使我们又陷入了麻烦之中. 我们必须重新学习那些自以为已经掌握的东西, 而倒回去从头开始学习是那么困难. 此时, 本书对概念. 定义. 角色和责任的阐述将帮助我们走出困境.

对那些所在公司从未建立有关配置管理的正确原则的读者来说, 尤其是对有过下列可怕经历的读者来说, 本书将对他们有所帮助：

找不到软件："我知道我已经写好了, 但是不知道把它放在哪儿了. "

丢失链接："原来还是好好的, 但是现在它指向的代码已经不见了. "

相互覆盖代码：开发人员对相同的代码做了不同的修改, 互相覆盖.

无法返回：新的修改比原来的更差, 但是没有"撤销"按钮.

无法重拾：落下一份没有页码的文档, 或者落下两份没有标题的文档, 哪份是哪份呢?

谁是第一个版本?接着是谁?客户报告了错误, 但不知道他们使用的是哪个版本, 因此不知道要给他们哪个补丁.

"但是我知道我已经修改过了!"

--客户打电话说："出问题了. "

--程序员解决了这个问题, 但是忘了进行变更登记.

--在没有将修正包含在内的情况下联编软件(没人审计此基线).

--把未做修改的软件交付给客户.

--客户打电话说："仍然有问题. "

--程序员说："但是我已经改过了!"

配置管理是软件过程改进的基石. (毕竟, 如果你连自己的属下都无法管理, 又怎能知道他们已经有了提高?)在"CMM Implementation Guide"(能力成熟度模型实施指南)中, 我写道："软件业中的很多人已涉足软件过程改进领域, 并且走出了自己的路, 但是可能很多人还没有涉及更困难的方面, 即相互学习, 并在交叉文化的影响下改变自我. 如果我们不分享各自的经验和技术, 就不能出现这种局面. 我把自己的经验和技术拿出来与大家共享, 并不是要别人采用我的方法, 而是打开一扇门, 让整个行业和全世界的同僚们相互学习. 可能我不是第一个打开这扇门的人, 而且也希望我不是最后一个为之努力的人. 来与我们共舞吧!"

横跨地球, 9个时区之外的地方, Anne Mette Jonassen Hass已经应邀而来, 并带来了一份精彩的礼物. 她把自己成功的配置管理经验和技术拿出来与大家分享, 与此同时, 还有几种可能的解决方案, 读者可以采用这些方案, 并将其融入自己的工作中. 她还给出了丰富的参考资料, 提供了进一步学习的各种信息. 我很高兴看到这份礼物, 它定会影响我们的行业与世界.

--Kim Caputo

于加利福尼亚州Mission Viejo序2

软件配置管理和自动回归测试工具是敏捷项目成功的两个最关键的开发工具. 在过去的10年中, 不断有人对我说, 对特别要求敏捷和由计划驱动的项目来说, 版本控制与配置管理系统是最需要安装的工具. 别的工具无法与其相提并论. (编辑器和编译器是本应该有的工具, 所以没有提到. )习惯于使用版本控制与配置管理系统的团队会对不使用此系统的项目予以拒绝.

很多团队发现, 一旦有令人满意的配置管理系统供其使用, 那么他们就可以做对项目更重要的事情, 而不仅仅是协调其检入：他们开始试验间隔越来越短的联编. (这时候自动回归测试工具变得重要起来. )

有些团队每半小时运行一次全自动联编, 同时还运行单元集和系统回归测试, 在Web页面上发布测试结果, 并以电子邮件的方式向错误代码的作者邮寄未通过的测试结果!这些团队的成员要报告在速度. 敏捷性. 质量和个人舒适度方面的提高.

有一家公司甚至还做了这样的试验：通过持续联编系统来同步在印度和在美国的编辑工作. 他们说, 这有助于这两个跨越9个时区的团队相互之间保持同步.

因此你可以很惊讶地看到, 有多少团队试图在没有配置管理系统的情况下工作. 而且, 有关配置管理方面的信息非常难找, 让人沮丧.

在此书中, Anne Mette Jonassen Hass设法捕捉此课题的中心以及各种不同环境所需的变体--极少有人做到了这一点. 如你们所了解的那样, 她知道有些组织内部官僚主义严重, 而有些公司则相反, 有些组织不注重形式, 而有些公司则形式化严重--他们都需要配置管理, 以使其集体工作顺利地进行. 她从几个方面来讨论这个主题：工作产品. 涉及的工作角色. 组织问题. 工具以及形式和官僚化的各种级别. 此外, Steve Berczuk和BradAppleton还在附录中描述了怎样在敏捷项目中使用这些术语与实践方法.

一直以来, 我都觉得这是个让人畏惧的课题, 因此, 很高兴看到有人很好地阐述了这个问题, 并且其内容也很容易消化. 我是永远也写不出这样的书来的, 很高兴Anne MetteJonassen Hass为我们写出来了.

--Alistair Cockburn

于犹他州盐湖城

我的软件专家生涯

我酷爱两个专业领域--实际上是3个领域：测试. 配置管理与过程改进.

刚投身这个领域的时候, 我是一个全能型的开发人员--做少许需求收集工作. 少许分析工作. 大量编码与重编码工作, 以及一些测试工作--那是20多年前的事. 在最初的这些岁月中, 我一直钟爱测试--使我的工作成果可以在计算机上运行, 计算机准确并且令人信服地告诉我哪里错了. 我喜欢这种方式, 这使我可以做出修改, 并且享受特权：这个错误只有我和计算机知道.

随着经验的增加和团队的成长, 同时问题也变多了. 我不能很肯定, 可以做出自己希望的东西来, 也不能肯定方方面面都已测试过. 有时候还会出现错误!

后来, 我得到一份工作, 在一个为欧洲航空局开发软件的公司中负责系统和验收测试. 在接下来的12年职业生涯中, 我第一次听到了"配置管理"这个词. 我根本不知道这是什么东西, 但是, 当我花费一个又一个小时来弄懂它, 和负责质量保证的人员讨论它, 并部分地将其应用到日常工作中时, 我渐渐地明白, 我拥有了一个多么好的工具.

有史以来第一次, 我可以把测试用例上溯到需求. 我可以随时知道测试规格说明中涵盖了多少需求, 还有多少没有完成. 我再也不会由于为尚未实现的需求生成测试用例而沮丧了. 每当忘记为什么返工时, 我可以找到测试规格说明的前一个版本, 看看为什么要修改. 我喜欢这样!

最近7年, 我的身份是顾问, 我要花费大量时间为很多公司进行各类测试任务分配. 我从中学到的一点是, 客户要求的和他实际上真正想的. 他需要的东西(你想给他的东西)以及你能给他的东西是不同的.

他们经常交给测试顾问一个系统, 让其测试, 而不给出完成专业测试应有的条件. 需求可能是各种各样的, 从没有需求, 到具有写得非常出色的需求, 而大多数情况下是前者. 即使有需求, 也多数是过时的. 这部分是需求规格说明问题, 部分是配置管理问题.

要根据测试的时间和人员来要求测试资源. 这些资源通常很稀少. 这是项目管理问题.

当测试顾问计划并进行测试时, 他们不仅需要概述要测试的内容, 而且还需要概述测试进度. 已经发现了什么错误, 以及错误修正状态. 这些是配置管理问题.

对顾问来说, 尽力交付给客户真正需要的东西的确具有诱惑力. 但是, 这个方法有其局限性与缺点. 真正的美妙之处是在需要和可能之间取得平衡. 作为顾问, 要记住的一点是：要正确地遵照标准执行. 因此, 当分配测试任务时, 我都尽力遵照配置管理标准--希望客户能了解配置管理是什么, 并可能寻求在这个方面获得帮助.

我的另一部分时间花费在评估使用BOOTSTRAP成熟度模型和方法的公司上. 和相关的能力成熟度模型(CMM, Capability Maturity Model)相似, 这个模型也包含了配置管理. 作为进行过40多场评估的评估员, 当我问及怎样进行配置管理时, 我无数次看到了茫然的眼神. 如果我详尽地阐述并询问产品之间的跟踪情况. 错误报告的生成情况, 或者配置管理原则的其他细节问题时, 他们仍然面无表情.

而另一方面, 人们很愿意谈论他们所经历过的问题, 导致出现这些问题的原因是未能控制正在被实现与被测试的工作, 未能控制已经出现的错误, 未能控制哪些错误已经得到了改正, 而哪些还没有得到改正.

虽然对坚实的开发工作而言, 配置管理是其中的一个基本原则(在CMM中, 它是第2级的一个关键过程), 但是很多人在他们职业生涯的大部分时间内, 对配置管理是什么. 怎样使日常工作更轻松等方面, 从来就没有任何想法, 就如同我以前所经历的那样. 因此, 我不断强调配置管理的重要性, 并经常建议那些开始结构化过程改进的公司将其当作第一原则.

此书的写作

Datateknisk Forum是一个丹麦组织, 大约有70家软件开发公司加入了这一协会, 该组织1999年邀请我写一本关于配置管理的书. 这是向各成员调查需要关于哪个专题的书之后

所作出的决定. 这次调查反馈回来的一些意见与需求是：

在开发过程中, 你们具体怎样进行配置管理?

你们怎样有区别地处理不同的工作产品(像文档和代码)?

你们怎样集成不同的配置管理工具?

你们怎样进行多地点开发?

你们怎样进行与面向对象开发(基于组件的开发)有关的配置管理?

我之所以从事这项工作, 是因为在我的经历中, 配置管理有非常重要的价值, 而不是因为我觉得自己掌握了很多配置管理方面的理论. 现在, 我知道的东西更多了, 我希望我能传递出一些我对配置管理的理解. 知识和在我写作此书时所获得的评价. 如果读者试着按照我讲述的一些原则去做, 我希望他们能够体验到我曾经体验过的热情.

本书建立在理论与经验相结合的基础之上--同时还建立在态度与意见的基础之上. 书中包含大量实例. 忠告和建议, 虽然这些实例. 忠告和建议并非真理, 但基本上是经验的总结--正面的经验和反面的经验.

当我得知此书包含在敏捷系列(Agile Series)中时, 我对敏捷开发还几乎一无所知. 但是在学习敏捷开发的价值与原则时, 我发现这些年来, 我已经在实践中用到了很多. 敏捷开发是极好的想法, 它成功的基石之一就是配置管理, 因此很高兴能够为该系列奉上我最喜欢的一条原则.

对从事敏捷开发的人来说, 本书可能厚了点, 但是, 我认为, 在知道还有什么没有做的情况下, 有意地抛弃某些形式和细节活动, 比因为无知而没有去做这些事情更好. 因此, 从事敏捷开发的人员和其他读者, 请阅读和选择你所需要的!

本书的目的

本书并不是为配置管理领域的新手而写. 不过, 它首先介绍基本原理, 建立对所使用概念的基本了解. 本书的主要部分将讨论在实施配置管理的过程中遇到的更高级的话题. 本书总的目的包括以下两个方面：

使从事配置管理的人员感到恐惧!本书使读者了解这门学科的复杂性与综合性.

配置管理并不容易. 如果你认为它很容易, 那么你就不能以专业的方式来解决配置管理的问题.

减轻配置管理人员的恐惧!本书将阐述对该学科原则的基本理解. 这些原则的相互关系及用途. 配置管理并不难. 你所要做的就是开始做. 如果你理解了这一点,

那么规定和计划会更容易, 因此能够达到目的并变得可管理.

在这里, 我们假设读者已经了解软件开发的其他一些原则, 例如, 计划. 设计. 测试和质量保证等.

致 谢

本书的创作得到了很多人的帮助, 我无法逐一列出. 首先, 要感谢Datateknisk Forum的成员与管理委员会, 以及我的经理Jorn Johansen先生和Ole Andersen先生, 感谢他们信任这个想法并在内容方面提出意见.

还要感谢我的同事们(尤其是Elisabeth Broe Christensen女士和Robert Olesen先生). 兰德大学的Lars Bendix先生, 还有一个相当重要的人--我丈夫Finn. 感谢他们给了我很多相当好的建议与想法, 感谢他们在我写作过程中表现出的兴趣和耐心. 我丈夫对事情的荒谬看法有时候确实很令人恼火, 但总是具有启发性--感谢你, Finn, 谢谢你始终如一的支持.

感谢出版商和本书的编辑Ross Venables先生, 感谢他们在从我最初的想法, 到最后完成全书手稿的过程中自始至终的热情与鼓励.

最后值得一提的是, 非常感谢我一直以来的朋友Pernille Lemvig Fog先生和我父亲Briger Jonassen先生, 感谢他们帮着把本书翻译成读者可以理解的英文.