为什么定义很重要
开发环境包含团队构建和部署软件密集型系统所需的一切(软件是必不可少且必不可少的元素)。 那么,为什么对开发环境具有一致的定义很重要? 简而言之,许多组织都希望缩短产品上市时间,降低成本并提高质量,而所有这些业务目标都直接受到用于生产这些系统的环境质量的影响。 拥有一致,全面的开发环境定义可以确保在计划改善当前环境的计划,定义环境的需求,定义环境的架构,评估环境,确保适当的计划时,不会忽略任何事情。更改环境时的投资回报率等。 开发环境定义是所有这些任务的关键输入。
将开发环境置于上下文中
在查看构成开发环境的特定元素之前,先了解该环境在整体方案中的位置确实有帮助。
在图1中,您看到了一个卓越中心,该中心负责创建和维护开发环境。 此环境用于开发项目,这些开发项目又创建和维护软件密集型系统(或某些其他与软件相关的可交付成果,例如组件或服务)。 这种简单的可视化有助于阐明现有的任何卓越中心的角色(包括其团队成员的角色,流程和关键可交付成果:开发环境)与使用该开发环境的项目( 及其角色,流程)之间的区别以及可交付成果)。
图1.从开发项目中区分卓越中心
开发环境的要素
对于IBM Rational软件专家来说,开发环境包括这六个元素,每个元素如图2所示,并在以下各节中进行了详细描述:
- 方法
- 工具类
- 使能
- 组织
- 基础设施
- 采用
图2.开发环境的元素
您可能对成功开发项目的关键要素“人员,过程和技术”很熟悉。 但是,出于本文的目的,此模型过于简单。 尽管如此,图2中显示的元素还是建立在该模型上的:
- 人们以能力和组织为代表。
- 过程等于方法 。
- 技术以工具和基础架构为代表。
采用是一个新的(也是非常重要的)元素,其重点是在组织,业务部门或开发项目中引入开发环境。
方法
任何开发环境的关键要素都是从业人员正式或非正式地遵循的方法。 这些是与方法相关的关键元素:
- 核心方法元素,例如角色,工作产品,任务和流程
- 补充方法元素,例如标准,指南,清单,模板和示例
- 例如在将方法作为公司Intranet上的网站部署时可能考虑的方法部署拓扑。 在此示例中,需要使用Web服务器来托管内容,并且工作站必须安装适当的Web浏览器并连接到Web服务器。
工具类
开发工具可自动执行所遵循方法的各个方面。 例如,您可能使用一种工具来存储和管理开发项目上的需求,或者使用一种工具来可视化地对体系结构和设计进行建模,或者使用工具来测试您的软件,等等。
这些是与工具相关的关键元素:
- 开发工具及其集成
- 开发工具配置和安装脚本
- 开发工具部署拓扑,它考虑了客户端和服务器端所需的软件和硬件,以及任何相关的目标平台和仿真器(例如,当您为实时或嵌入式设备进行开发时)
使能
使从业人员能够使用(开发和指导)使用开发环境有助于成功采用。 因此,可以应用的培训和指导材料的定义和创建是开发环境的方面。 成熟的组织还特别注意其员工的专业化以及与外部专业组织的配合。
这些是与启用相关的关键元素:
- 培训课程和课程。 这涵盖了各种各样的培训需求,从培训有经验的从业人员到精益求精到开发环境,一直到针对担任新角色的从业人员的综合培训课程。
- 指导材料。 这些都是在指导经验不足的同事进行项目时由个人应用的。
- 启用部署拓扑。 例如,当通过基于Web的培训提供启用时,必须考虑部署拓扑。 同样,需要Web服务器来托管启用材料和配备Web浏览器的工作站。 部署拓扑还可能指定交付课堂培训所需的位置和房间。
组织
开发环境的另一个考虑因素是确保有适当的组织来定义,部署和管理它。 这可能包括开发环境的某些方面的专家(例如方法专家,工具专家,培训师和指导者),管理和支持环境的人员,在公司服务台上具有适当技能的人员以及适当的实践社区。
这些是与组织相关的关键要素:
- 定义开发环境中的组织角色和单位
- 指示这些组织单位位置的组织部署拓扑
基础设施
开发环境从硬件和软件角度考虑基础结构。 先前在讨论方法,工具,实现和组织时已经暗示了这一点。 但是,有以下三个理由将基础结构独立地视为关键要素:
- 首先是合并。 例如,通过查看整个开发环境的基础结构需求,您可能会发现只需要一个Web服务器即可支持基于Web的方法内容和基于Web的培训。
- 第二是确保适当考虑支持开发环境的任何其他硬件和软件,例如操作系统软件,数据库管理系统或板级控件以及测试工具(如果要进行实时或实时开发)。嵌入式设备。
- 第三是卓越中心可能需要基础结构来支持开发环境的测试和开发,然后才能在任何生产基础结构上使用它来支持业务项目。
这些是与基础架构相关的关键元素:
- 位置,节点和连接性
- 软件(例如操作系统,数据库管理系统,板级控件和测试工具)。
采用
除了已经列出的要素之外,关注组织,业务部门或开发项目中环境的采用也很重要。
这些是与采用有关的关键要素:
- 收养计划。 该计划定义了采用环境时通常执行的任务,例如购买任何硬件和软件。
- 推动组织变革的技术。 将需要这些来将开发环境引入并嵌入到受影响组织区域的日常工作中。
- 环境指标的定义。 这些度量标准用于评估环境的有效性。
解决方案上下文
解决方案上下文 (开发环境是所考虑的解决方案)也很重要。 上下文代表对开发环境的要求,可以从功能 , 质量和约束方面考虑。
- 功能代表开发环境要提供的软件工程实践或学科。 实现这些要求会使您考虑前面提到的所有元素。 例如,如图3所示,需求管理学科将受到以下支持:
- 需求管理方法
- 需求管理工具
- 需求管理方面的培训和指导
- 知道需求管理解决方案的服务台人员
- 支持需求管理相关元素的硬件和软件
- 在项目上适当采用需求管理准则
图3.所需的功能涉及开发环境的所有元素
这种想法可以应用于开发环境中的其他功能,例如体系结构或质量管理。 它也可以应用于特定的实践,例如迭代开发(在软件开发和交付的敏捷方法的核心),这也需要您考虑所有要素。
- 质量代表开发环境应展现的属性。 这也需要考虑开发环境的所有要素。 例如,可以通过以下方式适应可伸缩性质量(例如,支持不同数量的并发用户的能力):
- 可以定制以适合项目规模的方法
- 可以配置为支持可配置方法的工具
- 针对不同规模项目的适当机制和培训水平
- 提供团队成员适当技能水平以支持预期数量的开发项目的组织
- 可以扩展以支持预期的并发用户数量的基础架构
- 采用适当的环境机制。
- 开发环境应适应的约束还需要考虑开发环境的所有要素。 例如,需要从现有环境进行迁移可能导致这些操作
- 从现有方法中获取实践并将其合并到新方法中
- 将工作产品从不推荐使用的工具集中迁移到另一个(或需要与将保留的现有工具集成)
- 提供承认当前理解并适当定制的支持
- 提供了人员保证平稳过渡从原样状态到待状态。
- 指定最大程度地重用现有基础结构的基础结构(例如,尽可能重用现有的硬件和软件许可证)
- 适当的采用机制确认要执行的迁移
当然,当组织考虑对其现有开发环境进行更改时,另一个重要的约束条件就是投资回报率(ROI)。 为了使这样的计划成功,它必须明确地产生与该计划的业务案例相符的积极成果。 开发环境的每个区域都会在成本和收益方面影响ROI。
尽管未在图2中显示,但功能,质量和约束通常与已定义的任何业务环境(例如业务目标)保持一致。 从这个意义上讲,解决方案上下文还包含业务考虑因素。 当显示开发环境如何直接或间接地有助于实现业务目标时,这一点尤其重要。
定义,部署,管理
在定义开发环境的各种元素时,考虑到环境生命周期的以下元素(如图4所示)非常有用,因为除了解决方案上下文之外,它们每个都具有影响定义的特定问题:
- 环境的定义
- 部署环境
- 环境管理
图4.开发环境的生命周期
在研究这些领域之前,有必要解释一下为什么将这些不同的领域以图4的周期链接在一起。该图承认有效的更改(在这种情况下,是对开发环境的改进)通常是通过一系列渐进式更改而不是而不是大爆炸式的改变(进化,而不是公转),其中每个增量代表一个循环。 但是,按照定义,增量执行的更改会更改下一个增量的上下文(例如,从业人员现在可能已经提高了技能,可以使用新的硬件,可以使用新的工具等等)–因此显示出周期性。
在以下各节中,将对开发环境的每个元素以及解决方案定义,解决方案部署和解决方案管理进行综合考虑。
定义
较早的讨论集中在定义开发环境时要考虑的关键要素。 虽然为了完整起见,这里不重述该讨论,但表1中再现了所定义的各个项目。
还应注意,该定义通常在组织级别考虑,并且可能需要本地实例化以解决特定业务单元或项目在部署时的需求。 这在下面的部分中得到反映。
表1.定义注意事项
元件 | 描述 |
---|---|
方法 | 角色,工作产品,任务,流程 标准,准则,清单等 方法部署拓扑 |
工具类 | 开发工具和集成 开发工具配置和安装脚本 开发工具部署拓扑 |
使能 | 培训课程和课程 指导材料 启用部署拓扑 |
组织 | 组织角色和单位 组织部署拓扑 |
基础设施 | 位置,节点和连通性 配套软件(如操作系统) |
采用 | 收养计划 推动组织变革的技术 环境指标 |
部署
表2显示了开发环境的部署针对每个元素引入了特定的关注点。
表2.部署注意事项
元件 | 描述 |
---|---|
方法 | 定义本地配置 部署方法 |
工具类 | 执行本地配置 安装工具 迁移本地数据 |
使能 | 执行本地配置 部署支持材料 培训从业人员 |
组织 | 定义本地配置 改组 |
基础设施 | 定义本地基础架构 供应位置,节点,连接性 提供支持软件 |
采用 | 定义本地收养计划 验证环境 |
与方法有关的关键要素:
- 定义本地配置。 将方法部署到业务部门或开发项目时,可能需要一些本地配置以反映业务部门,开发项目或系统的特定特征(例如,通过提供适当级别的仪式 )。
- 部署方法。 这确保该方法可供从业人员使用。
关键工具相关元素:
- 执行本地配置。 应用任何本地工具配置来自动执行本地方法配置。
- 安装工具。 使安装的工具(及其集成)可供从业人员使用。
- 迁移本地数据。 例如,可能有必要将数据从现有工具集迁移到更新的工具集。
与关键实现相关的元素:
- 执行本地配置。 根据需要调整,完善或更新培训材料。 例如,您可以修改启用材料以适应为该业务部门或开发项目定义的过程。
- 部署使能材料。 确保从业人员可以使用启用材料,包括访问任何基于Web的培训。
- 培训从业人员。 对从业人员进行培训,并收集有关培训的反馈。
与组织相关的关键要素:
- 定义本地配置。 可能需要提供专家来支持特定业务部门或开发项目的特定需求。
- 改组。 组织人员和资源以支持开发环境。
与基础架构相关的关键要素:
- 定义本地基础结构。 定义特定业务部门或开发项目所需的基础结构。
- 供应位置,节点和连接性。 使所需的任何硬件可用(包括为实时或嵌入式设备开发的任何目标平台和仿真器)。
- 提供支持软件。 安装任何支持开发环境的软件(例如数据库管理系统或测试工具)。
与采用相关的关键要素:
- 定义本地采用计划。 完善采用计划,以反映业务部门或开发项目的特定需求。
- 验证环境。 测试已部署的环境,以确保其在提供所需功能,满足规定的质量以及在定义的限制内运行方面满足定义的要求。
管理
如表3所示,部署后对开发环境的管理还引入了对每个元素的特定关注。
表3.管理注意事项
元件 | 描述 |
---|---|
方法 | 收集方法反馈 |
工具类 | 备份,存档或还原数据 收集工具反馈 |
使能 | 导师 收集有关启用的反馈 |
组织 | 收集有关组织的反馈 |
基础设施 | 根据需要配置或淘汰基础架构 收集有关基础架构的反馈 |
采用 | 衡量环境效益 收集关于采用的反馈 |
与方法有关的关键要素:
- 收集有关方法的反馈。 管理开发环境的一个关键方面是不断改进。 因此,收集有关每个元素的反馈是遍及所有元素的主题。 通常通过使用例如问卷调查来主观地收集反馈。
关键工具相关元素:
- 备份,存档或还原数据。 确保适当地管理从业者创建的工作产品,并应用“良好内务管理”做法。
- 收集有关工具的反馈。 收集有关工具功能和性能的反馈(正面和负面)。
与关键实现相关的元素:
- 导师从业者。 为项目分配导师,以确保从业人员知道如何使用环境。
- 收集关于支持的反馈,从而收集有关任何培训或指导的反馈。
与组织相关的关键要素:
- 收集有关组织的反馈。 从业人员会就使用开发环境所提供的支持(例如帮助台支持的质量)提供反馈。
与基础架构相关的关键要素:
- 根据需要配置或淘汰基础结构。 随着项目的开始和结束,开发环境需要相应地调整大小,以最佳地支持在任何给定时间使用该环境的从业人员数量。
- 收集有关基础架构的反馈,包括硬件和支持软件。
与采用相关的关键要素:
- 衡量环境有效性。 这是成功采用的关键方面。 例如,您可以向从业人员提供一份调查表,并请他们评估他们在采用新做法方面的有效性。
- 收集关于采用的反馈。 收集了有关采用方法的反馈。
相互依存
最后,请记住,开发环境的各个要素并不像本文所暗示的那样独立。 图5显示了图2的另一种表示形式,它说明每个元素与所有其他元素都有关系。
图5.元素之间的相互依赖性
以下是一些元素之间依赖关系的示例:
- 该方法(方法)参考了可用的培训课程(启用)。
- 工具(工具)使任务(方法)自动化。
- 定义管理角色(组织)以支持工具(工具)。
- 供应服务器(基础结构)以承载工具集(工具)。
- 采用定义的方法(方法)对实践的采用(采用)进行评估。
摘要
本文是同一作者Peter Eeles的文章, 该文章由The Rational Edge在2008年出版: 开发环境架构师的兴起 。 这里的各节详细介绍了构成开发环境的关键要素,并指出了在定义,部署和管理这种环境时的不同关注点。 这提供了一个简单的框架,可用于确保在计划旨在改善当前环境的计划,定义对环境的要求,定义体系结构,评估环境等等时,考虑所有这些方面。
翻译自: https://www.ibm.com/developerworks/rational/library/define-scope-development-environment/index.html