为什么定义很重要

一个开发环境包含了一个团队构建和部署软件系统（在这里软件特别重要，不可或缺的元素）所需要的一切条件。那么拥有开发环境的稳定定义为什么很重要呢？简单来说，许多公司想要降低实用时间，降低成本，并改进质量，而所有这些业务目标都直接受到了用于生成这些系统所需要环境质量的影响。对开发环境拥有一个稳定的综合定义，可以确保在规划一次迭代时没有忽略什么事，迭代期间要改进并发的环境，为环境定义需求，定义环境的结构，评价环境，确保更改环境时有适当的投入产出比，等等。开发环境定义对所有这些任务来说都是一个关键性的收入。

将开发环境置于背景之中

在查看组成开发环境的特定元素之前，首先理解该环境的具体内容十分有用。

在图 1 之中，您看到了一个 培训基地，它对创建及维护开发环境负责，因此反过来又对创建和维护软件系统负责（或者其他一些与软件相关的可交付项目，例如构件或者服务）。这种简单的可视性有助于弄清培训基地角色之间的差异性（包括其团队成员的角色，进程，以及关键可交付项目：一个开发环境），以及 使用 开发环境（及 它们的 角色，进程，以及可交付项目）的项目。

回页首

开发环境的元素

对于 IBM Rational 软件专家来说，一个开发环境由以下的六个元素组成，每个如图 2 所示，并在接下来的部分之中进行了详细的介绍：

• 方法
• 工具
• 启动
• 公司
• 基础
• 采用

您可能对“人员、进程，以及技术”很熟悉，它们是成功开发项目的关键成分。但是，对于本文的写作目的来说，该模型过于简单了。尽管如此，如图 2 所示的元素构建在该模型之上：

• 人员 由 启动与公司 代表。
• 进程 等同于 方法。
• 技术 由 工具与基础 代表。

采用是一种新的（并且非常重要）元素，该元素关注于一个公司，业务单元，或者开发项目之内开发环境的引入。

方法

开发环境的一个关键性元素就是接下来的方法，正式的或者非正式的，由执行人员使用。有几个关键的与方法相关的元素：

• 核心方法元素，例如角色，工作产品，任务及进程
• 补充性的方法元素，例如标准，指南，检查列表，模板，以及范例
• 方法部署拓扑可能会得到考虑，例如，方法作为公司内部网上的网站部署时，就是这样。在这里的范例之中，您可能需要一个网络服务器来安装内容，而工作台上必须安装适当的网络浏览器，并连接到网络服务器。

工具

开发工具将接下来方法的一些方面实现了自动化。例如，您可能使用一个工具，来存储和管理开发项目之上的需求，或者使用工具来可视化建模您的结构与设计，或者使用工具来测试软件，等等。

下面是关键的与工具相关的元素：

• 开发工具及其集成
• 开发工具配置以及安装脚本
• 开发工具部署拓扑，考虑需要的软件及硬件，包括客户端以及服务器端的，以及相关的目标平台和模拟器（例如开发实时设备或者嵌入设备时）

启动

使用开发环境从业人员（培训和监视）的启动对成功采用有着重要的意义。因此，可以应用的培训及指导材料的定义和创建操作，就是开发环境的一方面。成熟的公司还特别关注员工的专业性，以及与外部专业性公司的合作。

有一些关键性的启动相关的元素：

• 培训课程及安排。这涉及到了各种类型的培训需要，从改进之中的培训经验从业人员，到开发环境，所有这些都组成了扮演一个新角色从业人员的综合性培训课程。
• 指导材料。在培训欠缺经验的同事时，私人会使用这些指导材料。
• 启动部署拓扑结构。考虑部署拓扑结构是明智的选择，例如，通过基于网络培训来提供启动时，就是这样。您需要一个网络服务器来安装带有网络浏览器的启动材料和工作台。部署拓扑结构可能还指定了交付课堂培训所需要的位置和教室。

公司

开发环境的另一个考虑是确保适当的公司对定义，部署，和管理它做好了准备。这可能包括了开发环境特定领域的专家（例如方法专家，工具专家，培训员和指导人员），管理和支持环境的人员，拥有公司支持经验的人员，以及实践交流人员技能的人员。

下面是关键的公司相关的元素：

• 作为开发环境一部分的公司角色和单元的定义
• 指示公司单元位置的公司部署拓扑结构

基础

一个开发环境考虑了硬件和软件方面的基础。在讨论方法，工具，启动以及公司时，前文已经提到了这一点。但是，将基础当做关键性的元素，有三个原因：

1. 首先是稳定性。例如，通过将开发环境的基础需要看做一个整体，您可能发现了您只需要一个网络服务器，以支持基于网络的方法内容，以及基于网络的培训。
2. 第二个是确保适当考虑了支持开发环境的其他硬件和软件，例如操作系统软件，数据库管理软件，一个数据库管理系统，或者广阔层次上的控件，如果您在开发实时设备或者嵌入式设备，那么还有测试的使用。
3. 第三个是产品基础支持业务项目之前，一个培训基地可能需要基础来支持开发环境的开发与测试。

下面是关键的与基础相关的元素：

• 位置，节点，以及连接性
• 软件（例如操作系统，数据库管理系统，广阔层次的控件，以及测试使用）。

采用

除了已经列出的元素，关注一个公司，一个业务单元，或者一个开发项目之内环境的采用，同样也会非常重要。

下面是关键的与采用相关的元素：

• 采用计划。该计划定义了采用元素时一般执行的任务，例如硬件和软件的获取。
• 驱动公司更改的技术。您可以需要它来进行介绍，并将开发环境嵌入到受影响公司区域的日常工作之中。
• 环境工具的定义。使用工具来评价环境的有效性。

方案背景

同样相关的是 方案背景（这里开发环境是考虑的方案）。背景代表了对开发环境的需求，并且可以当做 功能，质量， 以及 限制性因素。

• 功能 代表了开发环境所提供的软件工程实践或者规则。实现这样的需求，会让您考虑以前提到的所有元素。例如，如图 3 所示，一个需求管理规则由以下项目支持：
  • 需求管理方法
  • 需求管理工具
  • 培训和指导需求管理
  • 知道需求管理方案的服务台员工
  • 支持需求与管理相关元素的硬件和软件
  • 需求管理规则的适当采用

这种想法可以适用成为开发环境部分的其他功能，例如结构或者质量管理。它还可以适用于特定的实践，例如迭代开发（软件开发与交付敏捷方法的中心），它还需要您去考虑所有的元素。

• 质量 代表了开发环境应该展示的属性。它又需要考虑开发环境的所有元素。例如，可评测性质量（例如，支持并发用户数量变化的能力）可能会以以下的方式进行适应：
  • 定制一个方法来适应项目的规模
  • 您可以配置工具来支持一个可配置的方法
  • 对不同规模的项目有适当的机理以及培训层次
  • 向团队成员提供适当层次技巧的公司，以支持预期数量的开发项目
  • 可以评价的基础以支持并发用户的预期数量
  • 适应环境适当的机理
• 开发环境应该适应的 限制因素 还需要考虑开发环境的所有元素。例如，从已存在环境进行转移可能会导致以下的操作
• 从已存在的方法采用实践，并以新的方式来集成它们
• 将工作产品从一个工具集转移到另一个工具集（或者需要与已存在的工具集成起来）
• 提供当前的理解并得到适当的定制
• 提供人员以确保从 现状 状态向 将来 状态的平滑过度。
• 指定一个基础，以将已存在基础的再使用实现最大化（例如在可能时再使用已存在硬件和软件）
• 确认执行转移操作的适当采用机理

当公司在考虑对其已存在开发环境的更改时，另一个重要的限制因素，当然是投资的回报率（ROI）。对于这样一个成功的动机，它必须能够清晰地交付积极的结果以及动机的业务案例。每一领域的开发环境都会影响到成本与收益方面的 ROI。

尽管在图 2 之中没有显示出来，功能性，质量，和限制性因素一般与被定义的业务背景在一起，例如业务目标。在这种情况之下，方案背景还包含了业务方面的考虑。在显示开发环境是如何帮助实现业务目标时，不管是直接的还是非直接的，这一点非常重要。

回页首

定义，部署，管理

在定义开发环境的不同元素时，考虑环境生命周期以下的元素已被证明是有用的（如图 4 所示），因为除了方案背景之外，他们还关注影响定义的特定内容：

• 环境的定义
• 环境的部署
• 环境的管理

在查看这些区域之前，应该解释一下为什么这些不同的区域与图 4 之中的 循环 联系起来。该图显示了有效的更改（在这种情况之下，对开发环境的改进）通常是由一系列的更改，而不是 大爆炸 方法实现的，以更改（发展，不是巨变）在哪里发展代表通过循环。但是，发展之中实施的更改，更改了下一个发展过程的背景（例如，从业人员现在可能拥有改进的技巧，新的硬件可能可以使用了，新的工具可能已经实用化了，等等）- 因此循环的本质就显露出来。

接下来的部分，讨论了开发环境的每一个元素，以及方案定义，方案部署以及方案管理。

定义

在 定义 一个开发环境时，早期的讨论关注关键的元素。在这里不会重新进行讨论，出于完整性的考虑，在表 1 之中重新列出了定义的各种项目。

人们还注意到一般在公司层次上考虑定义，可能需要 本地实例 以处理部署时特定义务单元或者项目的需要。这将反映在下面的部分之中。

部署

开发环境的部署会介绍与每个元素相关的特定关注点，表 2 所示。

关键 与方法相关的 元素：

• 定义本地配置。在对业务单元或者开发项目部署方法时，可能需要一些本地配置，以反映业务单元，开发项目，或者系统的特定特征（例如，通过提供适当的 仪式层次 ）。
• 部署方法。这可以确保从业人员可以使用该方法。

关键 与工具相关的 元素：

• 执行本地配置操作。应用本地工具配置以适应本地方法配置。
• 安装工具。让执行人员可以使用安装的工具（及它们的集成）。
• 转移本地数据。例如，可能您需要将数据从已存在的工具集转移至更新的工具集。

关键 激活相关的 元素：

• 执行本地配置。尽可能地适应，改进或者更新培训材料。例如，您可以定制启动材料，以适应业务单元或者开发项目定义的进程。
• 部署启动材料。确保从事人员可以使用启动材料，包括对任意基于网络培训的访问。
• 培训执行人员。执行人员会得到培训，并对收集的培训进行反馈。

关键的 公司相关的 元素：

• 定义本地配置。可能需要提供专家，以支持特定业务单元或者开发项目的特定需要。
• 认知。组织人员和资源以支持开发环境。

关键 与基础相关的 元素：

• 定义本地基础。定义特定业务单元或者开发项目所需要的基础。
• 规定位置，节点，以及连接性。提供需要的硬件（在开发实时或者嵌入设备时包括目标平台和模拟器）。
• 规定支持软件。安装支持开发环境的软件（例如数据库管理系统或者测试工具）。

关键 采用相关的 元素：

• 定义本地采用计划。定义采用计划，以反映业务单元或者开发项目的特定需要。
• 确认环境。测试部署的环境，以确保它满足了定义的需求，该需求涉及到提供需要的功能，满足提出的质量要求，以及定义限制因素内的功能。

管理

如表 3 所示，部署之后开发环境的管理还会介绍关于每个元素的特定关注点。

关键 方法相关的 元素：

• 收集关于方法的反馈信息。管理开发环境的关键性方面是持续性的改进。因此，收集关于每个元素的反馈信息，就是确定所有元素的主题。反馈一般是使用调查问卷来获得的。

关键 工具相关的 元素：

• 备份，档案，或者存储数据。确保执业人员创建的工作产品都得到了适当的管理，而“良好家务活动”实践得到了应用。
• 收集关于工具的反馈。收集关于工具功能及性能的反馈（积极的和消极的）。

关键 启动相关的 元素：

• 指导从业人员。向项目分配指导人员，以确保该从业人员知道怎样使用环境。
• 收集关于启动的反馈信息，因此也收集关于培训或者指导的信息。

关键 与公司相关的 元素：

• 收集关于公司的反馈信息。从事人员给出了使用开发环境所提供支持的反馈信息（例如累积桌面支持的质量）。

关键 基础相关的 元素：

• 需要规定或者弃用基础。随着项目的开始以及结束，开发环境需要有根据地调整行为，以最佳支持给定时间内使用环境的从业人员的数量。
• 收集关于基础的反馈，包括硬件和支持性软件。

关键的 采用相关的 元素：

• 评价环境的有效性。这是成功采用的关键方面。例如，您可以向从事人员提供一个调查问卷，以让他们评价采用新实践方式时的效率。
• 收集关于采用的回馈。关于采用方法的反馈得到了收集。

回页首

联系

最后，记住开发环境之中各种元素并不像本文中所表达的那样独立。图 2 另一个代表如图 5 所示，它演示了每个元素与所有其他的元素都有关系。

下面是元素之间联系的一些范例：

• 方法（方法）引用可用的培训课程（启动）。
• 工具（工具）将任务实现自动化（方法）。
• 定义管理员角色（公司）以支持工具（工具）。
• 提供服务器（基础）以安装工具集（工具）。
• 使用定义的方法（方法）来采用实践（采用）。

回页首

总结

本文是由相同的作者，Peter Eeles 写作，发表在 2008 年的 Rational Edge 上的文章：开发环境架构师的兴起的更新。这一部分详细介绍了组成开发环境的关键性元素，并指出了在定义，部署，和管理环境时不同的关注点。本文提供了一个简单的框架，以确保在计划一个动机，从而改进当前的环境，定义环境上的需求，定义结构，评价环境时所需要考虑的所有方面都得到了考虑。

参考资料

学习

• 早期的、较简单的文章如下：Peter Eeles 所作的 开发环境架构师的兴起（Rational Edge，2008 年）。
  
  
• 访问 developerWorks 上的 Rational 专区，了解有关 Rational 软件交付平台产品的技术资源和最佳实践。
  
  
• 时刻关注 developerWorks 技术事件和 Web 广播，包括各种 IBM 产品和 IT 行业主题。
  • 参见 developerWorksLive! 技术讲座，快速了解 IBM 产品和工具，以及 IT 行业趋势。
  • 观看 developerWorks 演示中心，从初学者的产品安装和配置演示，到面向有经验开发人员的高级功能。
  
  
• 改善您的技能。查看 Rational 培训和认证 目录，其包含了许多广泛议题的课程类型。您可以在任何地方，任何时间学习它们，许多“启动”课程是免费的。
  
  

获得产品和技术

• 获得 IBM WebSphere UDDI 注册中心预览版 FAQ，或查看 Rational 软件的 试用和演示 页面。
  
  
• 按照最适合您的方式IBM 产品评估试用版软件：下载进行试用，可以在线进行，在云环境中使用，或者在 IBM SOA 人员沙箱 中花一些时间了解如何有效实施面向服务架构。
  
  

讨论

• 加入 Rational 软件讨论区，询问相关问题，并加入讨论。
  
  
• 通过 撰写一篇 developerWorks Rational 文章 共享您的知识，并帮助那些使用 Rational 软件的人员。您将获得全球范围展示，RSS 企业联合组织，署名和建立，以及 developerWorks Rational web 网站专业编辑和出版的益处。查找 如何编写一篇好的 developerWorks ，以及如何进行。从查找 如何编写一篇好的 developerWorks Rational 文章 开始。
  
  
• 跟随 Facebook 和 Twitter (@ibmrational) 上的 Rational 软件，并添加您的注释和请求。
  
  
• 您可以加入 Rational 讨论区，cafés 和 wikis，询问并回答问题，增加您的专业技能。
  
  
• 通过加入 developerWorks 中文社区，与其他人员联系，分享您的兴趣爱好，并响应 开发人员驱动的博客。
  
  

关于作者

Peter Eeles 是全球 IBM Rational 组织的一名首席 IT 架构师和 IT 主架构师，帮助组织改进软件开发能力。经常结合以架构为中心的活动，例如面向服务架构（SOA）或策略重用。Peter 是“软件架构过程”（2009 年），“使用 Rational 统一过程构建 J2EE 应用程序”（2002 年），以及“构建业务对象”（1998 年）的合作者。他的联系方式是 peter.eeles@uk.ibm.com。

为本文评分

评论

回页首

内容

• 为什么定义很重要
• 开发环境的元素
• 定义，部署，管理
• 联系
• 总结
• 参考资料
• 关于作者
• 评论