使用一个以用户为中心的协作模式开发应用程序

IBMdW 发布于 2012/01/18 17:38
阅读 412
收藏 1
Lindsay Smith, 首席架构师, Aviarc
简介: 移动设备计算被许多 IT 专业人士视为是云计算的一个完美补充,它实际上是一个以用户为中心的功能。如果将一个以用户为中心的模式应用到云应用程序的开发和部署中,会发生什么呢? 它也支持将密集的社会协作加入到设计和构建阶段且允许您在一个完全虚拟的空间中执行结果?作者将详细介绍这种系统并通过现实示例来展示它。

IT 领域最显著的变化之一是一种称为 IT 消费化 的现象的出现。日常生活中个人计算设备的激增和应用程序的崛起从根本上改变了技术期望。

用户期望:

  • 软件符合他们的思考方式。
  • 变化很快。
  • 能够促成、共享和应对软件的行为方式。

这一新的软件标准源于智能手机和平板电脑等消费设备的快速创新,以及由 Internet 实现的丰富的软件产品的激增。

尽管出现软件认知方式的这一革新,企业 IT 为业务用户提供、开发和支持软件的方式至今保持不变。前期很长,变化缓慢,且用户很少对新软件计划有巨大投入。虽然这一方法在过去 30 多年成功地构建了全球一些大公司依赖的基础架构,但是新的互连世界需要新的战略。

当关注用户和快速响应的能力成为一个组织内促进创新的最重要的手段时,一个新时代就开始了。对这种用户引领的创新提供强大支持的一个组织将能够快速适应市场条件、提高现有流程的效率,且与其竞争对手区别开来。

用户是强大的新思想的最宝贵来源之一;如果 IT 没有办法利用这一创造力,这些用户会毫不犹豫地另投别处。

新开发流程、新工具和新思维早就应该满足这一需求。本文描述如何在这些新条件下重新设想开发流程,并提供一个实际系统作为实现这些变化的一个示例。

首先,我们定义一些术语。

这对于 IT 专业人士意味着什么?

对于开发人员、管理员、系统设计人员和规划人员,我要首先定义一些有助于理解以用户为中心的、协作的、虚拟的云应用程序开发方法的短语:

  • 移动计算应用程序开发。
  • 以用户为中心与以数据为中心的应用程序开发之间的区别。
  • 协作与传统应用程序开发之间的区别。
  • 虚拟开发和部署运作如何?

移动计算应用程序开发

对于本文来说,移动计算 是指从任何位置访问应用程序和其他软件服务的能力。这一位置可以是任何可访问 Internet 的机器上的浏览器或智能手机或平板电脑等移动设备。

关键领会概念是,在对用户访问位置没有任何假设的情况下开发应用程序。

以用户为中心与以数据为中心的应用程序开发

以用户为中心的应用程序开发将用户体验看作是主要关注。这包括应用程序的可视性质、程序流程、用户与应用程序的交互方式以及响应方式。用户要同时体验用户界面和程序流程。一个重要方面在于,不必通过数据结构来实现这一体验。

有一类开发人员能够最有效地进行这一以用户为中心的开发。他们喜欢用户参与和反馈周期且靠以实际问题解决方案满足和取悦实际客户而茁壮成长。

相比之下,以数据为中心的应用程序开发将数据模式看作是第一要务。数据库模式或其他模式成为首要关注,且应用程序行为从数据检索和修改方面加以描述。数据一致性、访问控制和服务定义是一个应用程序以数据为中心的视图的一些关键方面。实施工作还可能包括冗余架构和事务设计。

应用程序开发的这一方面可得到这样一类开发人员的最有效处理:他们在企业 IT 领域内拥有雄厚的技术技能,能够架构容错的事务系统和这些系统进行互操作所依赖的机制。

一个自适应组织能够迅速发展以迎接重要的挑战与机遇,这是应用程序必须独立发展的两个方面。可以有多个以用户为中心的应用程序只利用一个以数据为中心的系 统而向用户或用户社区提供完全不同的体验。还可以有一个以用户为中心的应用程序利用多个以数据为中心的系统,比如通过共享服务访问组织范围内的数据。

以用户为中心的系统战略不仅向用户提供他们在个人和社会计算体验上要求的质量和多功能性,而且极大地增强了以数据为中心的制度,策略和实践的有效性(有效的利用促进有效的维护)。

协作与传统应用程序开发

传统应用程序开发遵循规范-实施周期:在开发之前记录、审查并批准需求。需求可以采用书面文件、绘图或流程图的形式,且开发流程寻求将这些需求转化成运作的工件。

社会协作应用程序开发可尽早地让许多用户参与到应用程序的设计中。应用程序的起源始终在于业务创新:社会协作应用程序开发提供工具来促进业务创新,这一创新完美地融入到应用程序开发中,从而自动实现这一不错的创意。

转向社会协作随之而来的最大的思维变化是,需要从标准的 “创意和需求” 引出流程(通过在文档中完成)转向一个元数据驱动的架构。这个架构需要远离泄露,且需要无限制地创建任何东西。如果一切顺利的话,这个元数据结构就可以完 全符合要求的功能和应用程序的体验部分(其中工程细节是开发周期的重点)。这支持业务人员通常赞成的原则:“工程方面易于界定但难于落实;体验方面难于界 定,但相对易于落实。”

这里并非使用单一资源维护一个中央需求文档。一个新应用程序的思想、启示和可视化常常在用户之间得到共享,以供直接输入、反馈、修改或进一步的创意。在发展粗略的创意时,团队会以抽象而又复杂的方式进行思考:交换彼此的概念以提出、测试和发展思维。

一个高效的团队思维过程在早期阶段既不是线性的也不是过于结构化的。因此在社会协作应用程序开发中,一切在早期阶段也都可见、直观且可持续访问。它寻求提供体验创新到应用程序成形的能力作为确定其需求最重要步骤,并且提供实时修改和改进应用程序的能力。

虚拟开发和部署

虚拟应用程序开发描述按需创建虚拟开发环境的能力。当需要开发功能时,可以配置一个虚拟开发系统并在数秒内使其联机,以提供记录创意和构建应用程序的功能。

由于这些应用程序是在虚拟平台上创建和开发的,可以随意在平台之间移动它们。可以将通过可行性或 ROI 测试的应用程序部署到一个更公开的平台,以进行进一步的审查和开发工作。

这是由云实现的,不过它在传统环境中也可用。

以用户为中心的开发环境的愿景

在一个以用户为中心的应用程序开发中,用户的创意和输入是应用程序设计最重要的部分:因此开发环境必须提供记录创意的方法。

该环境的云性质是指,它在任何浏览器可访问的地方都可用。当要捕获一个创意时,用户只需将环境载入其浏览器,然后开始捕获内容。

由于这些创意变得精炼起来,它们会开始描述实现了它们的应用程序的具体性质,比如它会包含的界面或流程。因此,一个以用户为中心的开发环境会允许用户将其创意直接变成可执行的应用程序,遵循它们描述的结构。

一个真正以用户为中心的开发流程不会将创意转录为文档以供其他系统实现,而是会创建描述的应用程序并同时将应用程序项目与之相关的创意和需求连接。这让用户即刻就能看到已传播的思想的影响;反馈回路瞬间完成,使在评估实现的应用程序时能更快提炼和改进创意。

如果一个开发环境真正是以用户为中心的,那么它无需任何以数据为中心的组件即可构建和体验应用程序。这需要应用程序架构发生转变,从而意味着可以充分实现 用户体验而无需数据系统存在。相反地,会将样例或生成的数据用于提供体验。当前的垂直架构在分隔表示与持久性时,并没有真正地将体验描述与数据描述分离 开,因为表示层仍然与底层数据模型相连。云和 Web 允许您从这些大部分垂直架构转向完全水平的架构,这样,不仅可以获得自适应性,而且可以大大减少不必要的复杂性。

创建自适应软件的优势

该方法产生多重效益:

  • 对于用户来说,变化会很迅速,因为不需要传播到数据存储。这让用户的创意和期望不受约束。
  • 这也意味着,当完成体验后,就应该对需要以数据为中心的组件服务的消费者有了一个非常成熟、生动和充分发挥作用的体现。有一个地方的需求是系统的完整动态演示,而不是需求与原型之间的循环(在该循环中,两者都在不断更新以反映另一个)。

展望未来,必然没有一个应用程序用于一组用户;但是会基于一个常见的以数据为中心的层上构建多个以用户为中心的应用程序,其中每个应用程序专门服务于一组专注于定制体验的用户(让他们更高效)。

这将是一小步进步;使移动、个人计算成为 “这种应用” 的普遍现象也提供了相同的体验和动力,您可利用这种应用随时满足每个需求。用户可开发一系列专门特定于其角色和首选工作方式的应用。

但是这一切需要使用一种先进的软件开发范式才能实现,这种范式要具有比目前所能想象的更高水平的生产力和灵活性。是吗?

自适应软件创建的三个关键阶段

我了解到自适应软件创建的三个关键阶段:

  1. 思考:创意和需求的起源。
  2. 链接:将概念与可以实现组件的较大的团队连接起来。
  3. 构造:通过构建工件的工作使一切都变成现实。

思考:创意和业务需求的起源;完成范围划定工作

思考阶段是概念的一部分;这是企业收集和组合创意的阶段。关键在于,捕获阶段允许用户以不受约束的方式进行社会协作,不管有无 IT 专业人士的帮助,但是通常会分配一个团队指定的分析师。当分析师逐渐从调解人和讨论仲裁人的角色转向前线角色时,该阶段结束,以确保有足够的细节用于划定 构想阶段的范围。然后创建一个范围文档来将业务案例组合在一起,供下一个阶段使用。

链接:充实并链接团队构思的解决方案,有极少的工程设计,无转化或删除

当经过用户(仍在密切和互动地参与)大致上同意后,该阶段结束。项目通常还要开展工程保证审查工作。

链接阶段主要由分析师与重要用户的密切合作下完成。它对思考阶段进行扩展,直至每个环节都得到充实,以让业务令人满意。这意味着,它是 “凭体验” 完成的,尽管实际工程可能看起来仅描述实施起来之后系统如何运作;事实上,与用户体验相关的工作逻辑完整,并构成最终应用程序的主体。

当构建以用户为中心的应用程序时,这是一个重要概念。此时,项目已经过精心构思、测试和理解。

在整个这些构想阶段,用户社区应当能够持续情景化地进行交互,并且对不断演变的现有应用程序进行注释和重新定义,持续贯彻社会协作计算的高体会原则。在以下情况下该阶段结束:

  • 业务已随意遍历整个系统,并确认这是否是它想要构建的。
  • 已完成工程保证审查,以识别任何工程问题(比如性能)。当工程审查识别出会影响体验的问题时,会让用户了解这些并为其提供选择。
  • 当项目涉及到现有企业资产时,那么这也是为该业务提供备用解决方案的时候。关键区别在于,工程能够提供其最佳的折衷该当以及其建议解决方案的商业利益(通常是时间和成本),而不会说一些无法做到的事情。

构造:通过构建和组装工件让一切成功实现

该阶段通过验收完全运作的、部署就绪的、以用户为中心的应用程序来完成。

该阶段需要完成软件开发工作,构建所描述的和到本阶段为止在虚拟环境中运行的组件。当然,使用的工具均是专门为利用有关以用户为中心的社会协作流程的一切而设计的,可以快速而经济地填补复杂逻辑的任何差距,并促进与现有的以数据为中心的应用程序的集成。

应用程序的现有主体使这一阶段极其简单,当然,用户社区可以随意查看和试运行即将完成的项目。

在本阶段结束之时,用户应当看不出与概念结束时所看到的有任何区别。

协作开发环境的愿景

社会协作开发环境使得新思路和开发更易于在不同利益相关者和技术贡献者之间共享。从捕获创意和结构那一刻开始,云应用程序开发环境的直观、可视、基于浏览器的性质均可允许任何许可权限的用户访问、评估和促成这些创意。

当执行应用程序成形后,充许任何人对其进行访问和体验,并提供一种即时手段来获取用户对该应用程序的认可和反馈。一个真正的社会协作云环境不需要部署应用程序来提供测试反馈,它会一直处于可用状态,并且能够不断得到更新。

甚至应用程序的技术方面都得益于协作式的云性质。所有应用程序开发工具都可以通过云予以访问,因此技术资源从任何区域和时区都可以提供帮助,而不太可能出 现误解情况或在转化过程中丢失的风险。将应用程序开发的一部分分配给远程资源,执行技术审查,具有吸引力的远程协助,这一切都归因于环境的云性质。

拥有一个共同的应用程序开发环境非常有助于远程协作和支持。开发人员、主题专家、业务和行业专家能够随时随地工作,让团队跨州进行协作。

虚拟开发环境的愿景

开发人员花费在处理偶然复杂性的时间远远超过以用来处理有待解决业务问题的复杂性的时间。一个先进的虚拟开发环境要负责处理偶然的复杂性,而让开发人员专注于正在实施的创意。这样可极大地加快了创造价值的进程,提供给开发人员更令人满意的工作并降低项目风险。

单纯的云应用程序开发要求在本地浏览器上运行所有工具和支持;这不同于历史的方法:工具安装在桌面上,而应用程序部署到云中。

这里与基于浏览器的工具的重要区别在于,协作和问题解决得到简化,因为不必在每个设备上正确地配置工具,且环境没有在活动中,从而在解决让环境和配置正确匹配的相关问题所需的时间内消除影响生产力的问题。

通过从平台上得到应用程序,现在可以随意在任何提供商之间移动完整的环境(不管是在内部还是外部),同时仍然维持一个一致的开发环境。

环境的虚拟性是指可以随意创建、移动和扩展它。为了应对新客户或新应用程序,必须在较短的时间内配置完一个环境,以让 IT 具有高度的响应能力。由于可以轻松移动这些环境中的应用程序,我们可以添加、删除和聚合虚拟系统,而无需更改虚拟系统上运行的应用程序。这就履行了云计算 的实用承诺,但不是在上层、最得益的层。

下一代开发系统

将这三个愿景结合起来,就为我们提供了下一代软件开发原则和系统的一个全景。这个系统旨在更好地服务于用户需求、利用创造力,并促进社会协作。这些系统会弥补业务与 IT 之间、用户与数据之间、现代个人、移动和社会计算与企业计算之间的差距。

一个云环境的所有方面在这里都适用。任何环境(包括开发、测试或生产)都可以立即得到配置、从任何地方加以访问、随需求的增加予以扩展,且可应用 “即用即付” 成本模式。环境可以在一个内部环境或外部环境中。可以在无任何修改的情况下在环境之间迁移应用程序。

应用程序平台是以用户为中心的,这意味着它迎合用户的思考方式。用户的创意成为新应用程序的构想中的一等公民。在需要任何以数据为中心的组件之前,环境首先侧重于应用程序对用户的表现方式。构想的应用程序行为元素可以被自动转换为一个运作的应用程序,以获得即时反馈。

其社会协作性质意味着任何人都可以随时审查或促成创意或运行中的应用程序,包括专家、团队成员和远程专家。可以在运行过程中修改应用程序,这样一来,无需 一个构建/发布周期就可以吸收反馈。应用程序开发环境是基于浏览器的,允许开发人员从多个位置进行协作,如有需要,一天内要进行多次反复协作。

实际示例

现在我想向您介绍一个真实的系统,展示如何实现以用户为中心的协作式虚拟云应用程序开发的目标:Aviarc 和 Aviarc DrawingBoard。我要讨论系统如何在之前介绍的思考/链接/构造模式内工作。首先,我要介绍我用于说明的案例研究。

Aviarc 案例研究:Property Brokers 营销应用

背景:Property Brokers 是一个大型省级房地产组织,在新西兰中部占据主导地位。它在 28 个地区提供全面的房地产服务。其服务组合包括农场、出租物业、小区住宅、迎合顾客生活品味的地产,和商业/工业投资与企业不动产。

挑战:Property Brokers 有一个老化的信息系统支持房地产活动的各个方面。这一集中式的庞大应用程序系统远远不能满足公司的信息需求。其流程是手动的,且需要多次重复的数据录入步 骤。公司因系统滞后而导致的大量非增值文书工作,一直受到外地代理的抱怨。在看到一个竞争对手推出的智能 iPad 应用程序之后,Property Brokers 意识到其系统可能不再具有吸引力,甚至可能因其竞争对手的 “炒作” 而失去好的销售代理。

方向:Property Brokers 评估了各种解决方案选项,选择了 Aviarc 和 Aviarc DrawingBoard 作为解决方案。该公司了解到 Aviarc 的价值在于能够设计一个以用户为中心的 Web 解决方案,该解决方案将重点放在用户体验需求上。该公司的任务是在较短的时间内完成构想,以展示产品并从所有销售代理那里获得补进。

在思考阶段捕获创意

DrawingBoard 和 Aviarc 架构改变了当前软件范式的基本原理;它们帮助管理复杂性并推进创新型思维。

第一步是从业务和用户友好的全景角度捕获整个构想阶段演化的创意。讨论始于广泛抽象的概念,该概念逐渐变得更有条理。

对于 Property Brokers,Aviarc DrawingBoard 用于捕获利益相关者和用户的创意。图 1 显示初步思考后的 DrawingBoard。


图 1. 初步思考的结果
初步思考的结果

由于 DrawingBoard 是基于 Web 的,用户可以在正式会议室和论坛的范围之外审查和促成思考和共享。此阶段始于用户创建初始的 Aviarc DrawingBoard;同事间的社会协作确保 Aviarc DrawingBoard 捕获最广泛的需求。每个用户可以使用最适合他们的技能、方法和技术;例如,集思广益或组件业务建模。没有必要学习新的复杂工具或处理阻碍创新的刚性流程。 在一些阶段,业务用户可能要邀请 IT 专业人士或某种形式的顾问来进行协助或调解,进而帮助业务用户充实其思维。

用户能够开展一个或多个研讨会或仅仅在 Web 上通过 Aviarc DrawingBoard 工作。这一阶段的输出被一些人看作等同于敏捷的特性驱动的方法,但是 Aviarc DrawingBoard 允许业务用户更多地反复参与,不受线性流程或技术要求的约束。这个流程可由企业执行任意长的时间,直至他们确定已经准备好转向流程的第二部分。

打个比方,有一个项目是要建房,在该阶段您需要定义房间号码和类型、灯具的总体质量、楼层数,等等。这些都可以在 Aviarc DrawingBoard 内捕获到。创意可视地呈现为便笺,就像使用便条一样简单;如果出于某种原因用户认为这有助于思考过程,那么可以将这些连在一起。可以通过激增和骤减便笺组 来轻松处理规模和复杂性。

Aviarc DrawingBoard 还用于将有关计划进展的重要消息传达给管理层和其他利益相关者,甚至是在地球另一端的项目经理。DrawingBoard 还提供项目计划和进展更新。图 2 显示用于阐明有关项目进展的重要消息以及获取用户组反馈的仪表板。


图 2. 用于项目管理的初始仪表板
用于项目管理的初始仪表板

有关素材可通过专门的元素作为思考过程的一部分附加到 Aviarc DrawingBoard:便笺、文档、视频、音频、人、型材、角色、实时网站、素描、其他 Aviarc DrawingBoards,等等。对于可以从视觉和功能上纳入设计的元素的类型基本没有任何限制;可以创作并添加新元素到调色板。可以添加其他元素,比 如聊天室、表决数据库和提醒有关变更的表,来使上述素材具有交互特征。

添加并连接元素所在的 “桌面” 可以由描绘思维工具的任何 JPG 图片替代,比方说一个 SWOT 网格、泳道或 CBM 布局。通过这种方式,几乎任何咨询或思维工具都可用于捕获和组织思维,而无需学习新技术。

另外,Aviarc DrawingBoard 上发生的任何事情可以在特定时间点捕获到,因此在项目生命周期的任何时间,对思维和设计的每一次添加或变更都可以归结到精确设计的情景中。这样一来,就可以调整好范围、正直、思维的演变,且永不丢失。

在链接阶段组织创意

在该阶段,可以选定一个深思熟虑并且双方一致同意的范围(传统上是通过一个签署的工作说明书)。通常对于设置完成项目其余阶段所需的固定成本很实用。然而,稍后想要但在本阶段不包含在内的功能可以通过权衡或双方商定的范围变更来添加。

捕获到思维之后,业务分析师使用 DrawingBoard 来阐明分析的结果。流程图、业务事实的抽象、应用程序主题设计、应用程序组件等分析输出都提炼在 DrawingBoard 中。图 3 显示分析阶段的一个输出。


图 3. 分析过程流程图和草图
分析过程流程图和草图

顾名思义,该阶段通常引入业务分析师或其他专门资源到项目中,促进和调解业务用户发展 Aviarc DrawingBoard 的持续社会协作。在分析进行过程中,体验化设计工作开始。对于 iPad 应用程序,体验化需求不同于正常的基于 PC 的浏览器体验。范围内涵盖的所有项目都被扩展,以便用户完全理解将通过 “体验” 构造的一切内容。

这是一个高度重复且可追溯的阶段,其中支持工具允许各种社会协作交互发生。一些示例包括:

  • 使用交互式的上下文应用技术(比如 Aviarc Pins)来澄清细节和注释演化的应用程序的各个方面。
  • 使用允许用户阐明各种事情的基于 Aviarc DrawingBoard 的用户工具,比如绘图工具,来修改外观。
  • 使用在线 Aviarc DrawingBoards、会议或研讨会来探究更大的领域或澄清事情。同样,这由用户在 Aviarc DrawingBoard 上以交互方式商定同意捕获/记录且确认。

构想阶段可能是围绕应用程序的性能和其他非可视化(或体验化)需求捕获需求的一个机会。这些需求也可以使用 Aviarc DrawingBoard 进行捕获/记录。

在构想阶段,起推动作用的分析师将能够获取 Aviarc Marketplace 中现有工件;当他还创建工件接口时,这些工件就被选择性地加载到 Marketplace,这样就可以共享或与他人共同创建潜在工件。

在构想阶段,可通过避免结构(或工程)方面来提高速度和效率。换言之,房子看上去真实,但还不真实,因此一些东西改变起来就很简单快捷。房子(应用程序)仅可视地(或凭体验)构建,因此可以创建新的房间。

界面是在此阶段设计的,此过程中用户可以利用 Aviarc 内一个用户友好的简化版的演播室设备。其他用户可以注释、固定便笺到界面,并就界面设计展开社会协作。

所有实体都由用户开发,用户添加任何相关数据或约束这些实体,比如预期数据类型的示例或用例。由此,Aviarc 能够推导出大部分的应用程序逻辑并在悄悄将应用程序流程和逻辑拼在一起时进行自我测试,推断哪些元素会成功地协同工作以及应用程序流程如何。参见图 4。


图 4. 使用 DrawingBoard 的界面和业务逻辑以及模拟数据
使用 DrawingBoard 的界面和业务逻辑以及模拟数据

当每个元素、连接、界面和逻辑元素都成功完成并连接起来时,应用程序开始活跃起来;它的外观和行为开始变得与生产应用程序完全一样。实际上可以看到 Aviarc 可扩展的 XML 代码在 Aviarc DrawingBoard 的背景下自动变化和发展。参见图 5。


图 5. 营销活动调度界面
营销活动调度界面

通过 Aviarc DrawingBoard 使用社会协作,此刻没有转化、解译或创建传统的二维规范。完成和捕获的一切事物都成为 Aviarc 应用程序不可分割的一部分;用户社区仍然积极参与,与当下不断演化的项目进行交互。

在本阶段后期,进行工程保证很有用,可以确保虚拟示例中的一切都得到构建,而没有隐藏含义。在有些情况下,工程保证需要改变用户已经构思且 “体验” 的东西。

在虚拟现实示例中,假设工程无法运行厨房管道;它必须想出一些解决方法,并将其提交给客户供其验收。

现在该是时候让 Aviarc 自动组装项目了:这是一个自动化过程,可根据需要加以重复。该过程组装在思考和链接构思阶段创建和运行的所有可自动组装的可扩展 XML。这通常发生在整个项目有 40% 到 80% 可供部署时(取决于项目类型)。

可以在一个地方由一个人使用一个自动组装软件密钥进行自动组装。该任务的完成表示:

  • 构想阶段结束,不过用户与应用程序的可视和上下文交互会继续。
  • 转入一个更受认可的领域,即由技能娴熟的团队成员编写应用程序的其余元素。

迄今为止的体验表明,组织应当期望构想过程(思考和链接)通过最佳实践敏捷工具、技术和实践工作者,在大约一周的时间内完成之前需要一个月完成的工作。

在构造阶段构造应用程序

在构造阶段,在构想期间指定的没有被自动组装的任何元素(这包括任何工程保证过程需要的变更)都已完成。在构想阶段创建的应用程序 XML 将所有(要构造的)组件绑定在一起以完成应用程序。换言之,应用程序的外观和行为现在总是和构想期间所体验的一样。

使用 Aviarc 开发平台,实践工作者可以快速构造任何剩余的复杂逻辑和数据处理元素。Aviarc DrawingBoard 对这些元素的精确设计和构造提供非常具体的指导。

运作的应用程序还提供一个清晰的上下文来容纳这些手动构造的元素。开发人员可以为了产品用途的适用性随时测试这些元素,而且它们也要与应用程序其余部分一 致。通常这些元素已经存在于 Aviarc Marketplace、标准的元素库中,或者您甚至可以重用本区域先前工作中的元素。

当您确实需要手动开发一个逻辑元素时,DrawingBoard 可以使这个过程变得简单而快捷。

本阶段所做的工作非常适合外包给专家,仍然能够让您的团队与外部程序员高效合作。

部署新 Aviarc 应用程序的最后一步是,用户接受根据先期构思所构造的东西。最好的测试:用户应该在预期(在早期的模拟阶段所体验的)和实际结果之间没发现任何区别。

结束语

最近,云计算本身被视为一个新兴技术(如果不是再现技术的话)。如今出现这样的一个问题:如何使用运用云环境等尖端技术的一个以用户为中心的协作式虚拟方法,如何承诺改变(如果不是彻底变革)完成应用程序开发的方式。

在一个竞争日益激烈的应用程序市场中,开发时间成为一个重要方面。这一时间不仅包括应用程序的逻辑基础、程序编码,而且包含应用程序的用户交互行为。您不 仅需要减少正确编码所需的时间和精力,而且得构造用户想要的应用程序,且从一开始就要预想正确。围绕编程的代码重用和模块化已经出现一段时间了;使用我提 出的以用户为中心的协作式虚拟方法,您还可以减少生产用户需要的应用程序所需的时间和精力。

云的结构是进行这一切的完美环境。

在我提出的环境中,用户社区能够随意直观、可视化地就概念和设计过程的每一个方面以及实际运行的应用程序彼此交互(虽然您想做出界定)。我看到过用户在意识到他们对参数所做的变更出现在虚拟应用程序时所产生的自我怀疑。

该方法的一些效果是什么?一小部分预期不到效果开始显现:

  • 更多持怀疑态度的人开始相信 IT 有能力通过非常合适的体验和成果来满足业务用户迅速变化的迫切需要。
  • 通过与以数据为中心的系统的紧密集成,我们看到有更多人更充分地利用这些传统系统,以及 SOA、ESB 和逐渐进入新的以用户为中心的系统中的其他最佳实践。

下面是我对以用户为中心的开发系统的未来的预见:

  • 通过某种自动组装实现应用程序完成率的稳步增长,不断交付快速上市的应用程序(并使组织越来越具有自适应性和创新性)。
  • 社会协作开发体验连同工具的快速发展;用户和 IT 专业人员的更加 “游戏化” 或直观的参与。
  • 构建大量有销路的 IP。

最后,我想我们会从云计算技术中获得比目前为止看到的更巨大的获益。最终内部技术堆栈和工具与云技术堆栈和工具之间的界限会变得模糊起来,因为开发成为一个协作式行业。

文章出处:IBM developerWorks

加载中
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部