统一过程最佳实践细化阶段

　　内容简介目录本书重点介绍了与统一过程的细化阶段相关的最佳实践。通过对诸如代码走查、配置管理、变更控制和软件组织架构建模等最佳实践的介绍说明了实现软件过程的细节。本书可以作为软件项目管理人员、软件开发工程师、过程工程师、系统工程师等专业人员的指导用书，也可作为高等院校计算机及相关专业学生的参考书。前言 Software Development杂志（www. sdmagazine. com）以及它的前身Computer Language曾经发表过大量关于如何成功开发软件的文章. 曾经以及还在为该杂志写作的很多作者都是令人印象深刻的：Steve McConnell. Ed Yourdon. Larry Constantine. Steve McCarthy. Clemens Szypers-ki. Peter Coad以及KarlWiegers等. 这些信息产业的著名专家已经通过这本令人尊敬的杂志同我们分享了他们的智慧成果. 后来， 更多的组织开始逐步将更多的精力投入到提高软件过程上. 这部分是因为千年虫（Y2K）的灾难， 大约80％～90％的大规模软件项目的失败， 和与日俱增的对于遵循成熟软件过程是决定一个软件项目成功与否的关键的认识. 从20世纪90年代中期以来， Rational公司就开始收购和合并别的软件公司， 这样做的结果是， 将这些工具所支持的过程合并到单个开发过程中， 即所谓的统一过程. 是不是有可能将整个软件过程自动化呢？即使可以将其完全自动化， Rational有一个完整的工具集吗？我不太确定. 幸运的是， 还有其他的人也在致力于定义软件过程：OPEN联盟的OPEN过程就是其中之一， 我自己的面向对象软件过程（OOSP）的过程模式也是一个：所以我们对于怎么去做这样的工作还是有些其他的观点. 这些其他的观点能够用于驱动一个更加健壮的统一过程， 并且为准确反映你的组织的真实需求的统一过程产生一个增强的生命周期. 我相信在Software Development多年积累起来的智慧成果能够用来充实统一过程， 并且能够统一业界的最佳实践. 正因为如此， 我们出版了这套丛书. 遵循一个经过证实的. 成熟的过程是软件专家成功的关键. 为什么软件过程这么重要？我们后面就会讨论这个问题. 假如你想建造一座房子， 并且让两个建筑商来竞标. 第一个告诉你通过使用新的建造技术， 他能在两周内为你建造一座房子， 如果他第二天就开始建造的话， 这座房子将仅仅花费100000美元. 这个建筑商有一些顶级的木匠和管道工， 并且在过去已经使用这种技术建造过一个花园洋房， 并且他们也愿意日夜加班工作保证按时完成. 第二个建筑商告诉你他需要跟你讨论你希望建成什么样的房子， 当他一旦清楚你的需求后， 将在一周内将你的需求做出一个草图， 然后你可以审查并且反馈给她你的意见. 这个初始阶段将耗费你10000美元， 而一旦你决定了想要建造的样式后， 他会把详细计划和剩余工作的费用安排综合起来. 你对哪个建筑商更加放心呢？想立刻开始建造的那个还是想先了解你对建造样式需求， 做出模型， 做出计划然后再建造的那个呢？显然， 第二个建筑商有更大的机会做出满足你实际需求的房子. 现在设想你正在构建软件：这是一项比建房子复杂程度高出几个数量级， 并且常常是更加昂贵的工作：并且再一次假设你有两个承包商， 而且他们使用上面两种方式. 你对哪个更加放心呢？我希望答案仍然是第二个：一个明智的过程. 不幸的是， 实践证明绝大多数的时间内， 组织往往会选择第一个承包商所使用的方法. 当然， 实践也说明我们有大约85％的失败率， 你认为两种现象有关联吗？我想是. 细化阶段 细化阶段是4个阶段的第2个. 这4个阶段包括：初始阶段. 细化阶段. 构造阶段. 交付和产品化阶段. 在细化阶段， 软件的发布贯穿了它的整个生命周期. 这个阶段有几个目标： ·为系统产生一个经过证实的. 架构的基准. ·让需求模型发展到"80％的完成点". ·为构造阶段开发一个粗粒度的项目计划. ·确保关键的工具. 过程. 标准和指南已经为构造阶段准备好. ·了解并消除项目中风险级别高的问题. 本书介绍了一组由业界专家所撰写的文章， 这些文章讲述了最佳实践的前沿知识. 本书的一个目标， 并且也是这套书的总的目标， 是为统一过程技术提供可选的. 经过证实的方法. 本书的另一个目标则是填补统一过程的漏洞：坦白地说， 没有任何过程可以真正称为"完整"的. 统一过程是开发过程而不是软件过程， 因此， 正因为它所选择的范围， 它必然会略过一些软件专业方面的重要概念. 但幸运的是， Software Development中的作者们都使用了更为广阔的视角来看待过程. 关于这套书 本套书由四本书组成：分别为初始阶段. 细化阶段. 构造阶段以及移交阶段和产品化阶段. 每本书都自成体系， 但通过整个系列才能够完整了解软件过程. 由于每本书中的文章都不重复， 你会发现每一本书都很有价值. 有时候， 可能其中一本书中讲述的比较薄弱的过程工作流在其他几本书中讲述得更为详尽. 例如， 关于初始阶段的书中包括了大量项目计划和评估的内容：这也是开始一个项目时最关键的内容：而在其他几本书中这方面的讨论就比较少. 另外， 在着手编著这套系列丛书时， 我发现要比最初想像得难许多. 我所碰到的问题在于， 好的资料很多， 但本系列丛书却只有有限的容量. 所以大家可以发现本系列书中的文章都是精华中的精华. 关于我本人 作为Computer Language以及后来的Software Development杂志多年来忠实的读者， 我从1995年开始为它撰写文章， 并在1997年成为对象技术专栏的作家. 我在20世纪80年代初期开始软件开发的工作， 曾经使用Fortran以及Basic语言来编写代码， 在80年代中期使用过Turing. C. Prolog以及Lisp. 在80年代后期， 我意识到有比编程生命周期更为长久的工作， 所以我开始重新学习用户界面设计. 数据建模. 过程建模以及测试的技术， 那时我用COBOL和第四代语言在IBM主机上编程. 当我从结构挝程技术中醒悟过来后， 在1990年我发现了对象， 并很快地一头扎入Smalltalk开发中， 接着是C++开发， 最后又重新回到Smalltalk. 在几个机构中担任指导者以及架构师后， 我决定将这些经历以及我所获取的技术结合， 并在多伦多大学获得了一份助教的工作， 在90年代中期开始从事职业培训工作. 不久之后， 我就意识到下面两件事情， 首先， 尽管我很喜欢教授培训课程（我到今天仍不曾间断）， 但我并不希望做一个全职授课者. 其次， 更重要的是， 我学习到如何使用简单易懂的方式来交流复杂的概念， 例如怎样开发面向对象软件. 基于这样的经验， 我最初的两本书诞生了：《The Obiect Primer》（Cambridge University Press， 1995）以及《Building Obiect Applications That Work》（Cambridge University Press， 1997／1998）：这两本书从开发者的角度讲述了对象技术的基础知识. 紧接着， 我在《Process Pat-terns》（Cambridge University Press， 1998）一书中继续讲述了面向对象软件过程， 并在另一本书《More Process Patterns》（Cambridge University Press， 1999）中提供给读者我在加拿大某个一流的对象技术咨询公司所获得的宝贵经验. 从那时开始， 我帮助过多家机构（无论大小， 成立时间长短， 所属行业）来提高他们的内部软件过程. 我近期的著作包括本系列丛书以及另一本书：《The Elements of Java Style》（Cambridge University Press， 2000）. 我想， 我已经发现了属于我自己的体系结构.序言 信息技术行业最不为人知的事就是那些大型的. 关键性的项目有80％～90％最终都遭遇失败. 对于从事软件开发工作超过15年， 并在3年前刚刚成为编辑的我来说， 对此深有体会. 当我刚刚开始成为Software Development杂志的技术编辑时， Scott Ambler开始在"Thinking Ob-jectively"专栏中发表文章. 他使用日常用语来写作， 这使得普通的开发者都能够阅读. 在诸如过程模式. 有效使用UML以及将对象映射到关系型数据库中等前沿技术领域， Scott堪称专家. 现在Scott开始将他的热情和兴趣投入到如何将大多数软件项目从高失败率的深渊中解救出来. 软件过程涉及如何标准化开发团队的工作并促进在业界长期共识的最佳实践， 例如代码走查. 配置管理. 变更控制以及架构建模. 拥有过程模式开发背景的Scott， 正处于一个对当前的面向对象的软件过程（例如Rational统一过程， 即RUP. OPEN联盟所提供的OPEN过程以及面向对象软件过程， 即OOSP）可以提供一致而有重点的评价的理想位置. 尽管OOSP（详见Scott的（ProcessPatterns》和《MoreProcessPatterns》）为过程模式提供了更好的内在支持， 但Scott认识到：尽管面临挑战， 统一过程是市场领导者， 而且还将继续下去. 正如Scott所说的（"增强统一过程"， Software Development， 1999年10月）， "统一过程不是完美的：没有任何软件过程是完美的：但是， 如果我们想要在软件领域成功， 它是我们需要投入工作的一个领域. "这个系列书籍从OPEN过程和OOSP里抽取了资料来充实目前还单薄的统一过程. 在我看来， 一个充实的统一过程是处理这一尴尬问题的最好的方式之一， 同时Scott就是分析解决这种问题的优秀教师. RogerSmith SQftware Development杂志技术编辑第1章导论 1. 1统一过程 1. 2 超越统一过程 1. 2. 1 能力成熟度模型 1. 2. 2 OPEN过程 1. 2. 3 过程模式 1. 3 增强的统一过程生命周期 1. 4 细化阶段的目标 1， 5 细化阶段通常如何进行 1. 5. 1 项目管理工作流 1. 5. 2 业务建模工作流 1. 5. 3 需求工作流 1. 5. 4 基础管理工作流 1. 5. 5 分析和设计工作流 1. 5. 6 实现工作流 1. 5. 7 部署工作流 1. 5. 8 测试工作流 1. 5. 9 配置和变更管理工作流 1. 5. 10 环境工作流 1. 6 本书的组织形式 第2章 项目管理工作流最佳实践 2. 1 多团队开发管理 2. 2 人员管理 2. 3 招募新人和团队定义过程管理 2. 4 培训和教育工作管理 2. 5 文章 2. 5. 1 全球团队管理 2. 5. 2 协作管理 2. 5. 3 实现功能特征团队 2. 5. 4 技术面试的技巧 2. 5. 5 持续不断地进步 2. 5. 6 面向对象的培训 第3章 业务建模工作流的最佳实践 3. 1 从业务建模到业务流程重组 3. 2 公共的建模表示法 3. 3 文章 3. 3. 1 本质言说 3. 3. 2 业务规则的逻辑 3. 3. 3 为什么要使用UML 3. 3. 4 实用的UML：将UML加入到项目中的诀窍 第4章需求工作流的最佳实践 4. 1 用例及其他 4. 2 用户界面原型制作 4. 3 需求的重要性 4. 4 文章 4. 4. 1 工程化面向对象的需求 4. 4. 2 撰写高质量需求 4. 4. 3 用例的各种用途 4. 4. 4 从用户角度进行原型制作 4. 4. 5 打破屏障 第5章 基础管理工作流的最佳实践 5. 1 企业需求和架构建模 5. 2 与遗留应用的集成：EAI 5. 3 文章 5. 3. 1 面向对象架构建模：第一部分 5. 3. 2 面向对象架构建模：第二部分 5. 3. 3 混合方法 5. 3. 4 变更架构 5. 3. 5 彻底进行企业应用集成 5. 3. 6 掌握消息代理 5. 3. 7 构建企业架构 第6章 分析和设计工作流最佳实践 6. 1 以架构为中心的建模实践 6. 2 分离关注的对象 6. 3 分布式架构 6. 4 构件和基于框架的架构 6. 5 遗留软件的复用架构 6. 6 接口设计与设计模式 6. 7 文章 6. 7. 1 回复：架构 6. 7. 2 分布式对象设计 6. 7. 3 构件和对象共同体 6. 7. 4 建立遗留链接 6. 7. 5 Java接口设计 6. 7. 6 模式简介 第7章 测试工作流的最佳实践 7. 1 概述 7. 2 文章 7. 2. 1 对象测试模式 7. 2. 2 客户／服务器系统的基于场景的测试 7. 2. 3 快速开发高质量的软件 第8章 结束语 附录A 参考文献 附录B 作者索引作译者简介 Scott W. Ambler是软件开发方法年轻一代的领军人物之一， 在理论和实践上的造诣都很深厚. 作为一位高级咨询师， 他一直积极参与全球各种大型软件开发和过程改进项目. 同时， 他还是一位视野广阔的方法学者， 是《Software Development》杂志的专栏作家， 撰写了多部颇受推崇的著作， 其中包括《The Object Primer》. 《Agile Modeling》.《The Elements of UML Style》等.

　　ScottW.AmblerScottW.Ambler是敏捷建模方法学的创建者和思想领导者，是软件开发方法年轻一代的领军人物之一，在理论和实践上的造诣都很深厚。作为一位高级咨询师，他一直积极参与全球各种大型软件开发和过程改进项目。他是RoninInternational公司的高级顾问，该公司是专门提供软件过程指导、敏捷建模（AgileModeling）及基于对象／组件的软件架构建设和开发等方面服务的软件公司。同时，他还是一位视野广阔的方法学者，是《SoftwareDevelopment》杂志的专栏作家，撰写了多部颇受推崇的著作，其中包括《TheObjectPrimer》、《AgileModeling》、《TheElementsofUMLStyle》、《MoreProcessPatterns》等。>>更多作品

 第1章  导论
 1. 1  统一过程
 1. 2 超越统一过程
 1. 2. 1 能力成熟度模型
 1. 2. 2 OPEN过程
 1. 2. 3 过程模式
 1. 3 增强的统一过程生命周期
 1. 4 细化阶段的目标
 1, 5 细化阶段通常如何进行
 1. 5. 1 项目管理工作流
 1. 5. 2 业务建模工作流
 1. 5. 3 需求工作流
 1. 5. 4 基础管理工作流
 1. 5. 5 分析和设计工作流
 1. 5. 6 实现工作流
 1. 5. 7 部署工作流
 1. 5. 8 测试工作流
 1. 5. 9 配置和变更管理工作流
 1. 5. 10 环境工作流
 1. 6 本书的组织形式
 第2章 项目管理工作流最佳实践
 2. 1 多团队开发管理
 2. 2 人员管理
 2. 3 招募新人和团队定义过程管理
 2. 4 培训和教育工作管理
 2. 5 文章
 2. 5. 1 全球团队管理
 2. 5. 2 协作管理
 2. 5. 3 实现功能特征团队
 2. 5. 4 技术面试的技巧
 2. 5. 5 持续不断地进步
 2. 5. 6 面向对象的培训
 第3章 业务建模工作流的最佳实践
 3. 1 从业务建模到业务流程重组
 3. 2 公共的建模表示法
 3. 3 文章
 3. 3. 1 本质言说
 3. 3. 2 业务规则的逻辑
 3. 3. 3 为什么要使用UML
 3. 3. 4 实用的UML：将UML加入到项目中的诀窍
 第4章  需求工作流的最佳实践
 4. 1 用例及其他
 4. 2 用户界面原型制作
 4. 3 需求的重要性
 4. 4 文章
 4. 4. 1 工程化面向对象的需求
 4. 4. 2 撰写高质量需求
 4. 4. 3 用例的各种用途
 4. 4. 4 从用户角度进行原型制作
 4. 4. 5 打破屏障
 第5章 基础管理工作流的最佳实践
 5. 1 企业需求和架构建模
 5. 2 与遗留应用的集成：EAI
 5. 3 文章
 5. 3. 1 面向对象架构建模：第一部分
 5. 3. 2 面向对象架构建模：第二部分
 5. 3. 3 混合方法
 5. 3. 4 变更架构
 5. 3. 5 彻底进行企业应用集成
 5. 3. 6 掌握消息代理
 5. 3. 7 构建企业架构
 第6章 分析和设计工作流最佳实践
 6. 1 以架构为中心的建模实践
 6. 2 分离关注的对象
 6. 3 分布式架构
 6. 4 构件和基于框架的架构
 6. 5 遗留软件的复用架构
 6. 6 接口设计与设计模式
 6. 7 文章
 6. 7. 1 回复：架构
 6. 7. 2 分布式对象设计
 6. 7. 3 构件和对象共同体
 6. 7. 4 建立遗留链接
 6. 7. 5 Java接口设计
 6. 7. 6 模式简介
 第7章 测试工作流的最佳实践
 7. 1 概述
 7. 2 文章
 7. 2. 1 对象测试模式
 7. 2. 2 客户／服务器系统的基于场景的测试
 7. 2. 3 快速开发高质量的软件
 第8章 结束语
 附录A 参考文献
 附录B 作者索引
</font>