软件观点 － 从软件工程到业务工程
软件工程
软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。70年代初，自“软件工厂”这一概念提出以来，主要围绕软件过程以及软件复用，开展了有关软件生产技术和软件生产管理的研究与实践。其主要成果有：提出了应用广泛的面向对象语言以及相关的面向对象方法，大力开展了计算机辅助软件工程的研究与实践。尤其是近几年来，针对软件复用及软件生产，软件构件技术以及软件质量控制技术、质量保证技术得到了广泛的应用。
软件工程这一概念，主要是针对20世纪60年代“软件危机”而提出的。它首次出现在1968年NATO（北大西洋公约组织）会议上。自这一概念提出以来，围绕软件项目，开展了有关开发模型、方法以及支持工具的研究。其主要成果有：提出了瀑布模型，开发了一些结构化程序设计语言（例如PASCAL语言，Ada语言）、结构化方法等。并且围绕项目管理提出了费用估算、文档复审等方法和工具。综观60年代末至80年代初，其主要特征是，前期着重研究系统实现技术，后期开始强调开发管理和软件质量。
IT与业务融合bITa(Business and IT Alignment)
IT和业务本身具有较高的复杂性，而现在软件行业对这两者的处理也没有很好的融合在一起，这样两个复杂的东西加在一起变得更为复杂化了，导致从业务到实现角度来看软件也更为复杂化了。这个是一直存在的现象和问题，所以现在IT管理领域最热门的关键词之一就是bITa（Business and IT Alignment），也就是IT与业务融合问题。
IT界也不乏一些概念炒作，bITa在相当长一段时间里也是停留在概念炒作上。虽然引起了业界和媒体的关注和兴趣，但是并无法真正落实到具体的 产品和实践中去。SOA、WOA、REST、Web Services, 云计算这些对我们来说已经不是新鲜的词汇了，它们也经常出现在一些讨论bITa以及如何把业务融入开发内容中，但是这些更多的还只是围绕在方案域 （solution domain）概念上，而在问题域上讨论并不是很多。在没有技术时，方案域会更为重要，但在有这么多技术存在时，我们更多的应该先关注问题域，这也是进行 模型驱动开发需要进行的转变之一。
我虽然看过一些bITa的内容，但是在整理概念上还是非常模糊的，虽然理解还不深，但也希望能够记录下一些东西，感兴趣的可以一起讨论一下，以下我将从业务工程出发来谈如何更好的进行业务和IT的融合。
业务工程
软件工程是我们技术人员较为熟知的一个领域，它更多的关注于软件开发技术层面，它的提出也是为了更好的开发软件，它虽然很中有重要，但是仅单单从技术层面去看待开发是不够的，所以又有业务工程的概念提出。网上搜了一下，《Architecture and Engineering in Business Engineering》这篇进行了一些阐述，我觉得还不错，感兴趣可以看看。
软件开发有两种视角：业务功能或者构建软件视角。比如我们使用手机：
- 功能视角是从手机使用出发，我们不需要知道手机内部电路以及内部系统如何工作，但知道如何用它打电话，如何照相
- 构建视角是从手机工程师角度出发，知道如何制造和维修
在行业内，也有产品已经体现出这两个视角，以及如何结合起来的产品，如普元新推出的BPS6.1,如下图所示，主要解决流程的业务与技术一体化。
作为开发人员，我们以往更加习惯于从构建视角出发，描述一个应用应该如何工作。有时我们会画一些业务流程图，但是并不是一种规范的模型，连图例 也都不一致；有时通常首先是做了一些功能设计，但是也只是基础功能的设计，描述得并不精确，很多功能决策也就留给了开发人员。即使听到有些技术人员说模 型，但也更多的是低级别的模型，使用编程语言来描述，例如类图、活动图等UML图，我认为这种方式更贴现的应该说是基于模型开发（Model- based），而不能说是模型驱动（Model-Driven）开发，即使有这些类图，但更多时候也是设计时候画的，实现时也不会参考。
业务工程的主导思想是由业务来主导应用开发，取代如何（how）工作的模型，而使用精确和规范的模型来描述应用功能（what）。OpenExpressApp开发平台的应用模型更 多的也是从What入手。其实业务工程的思想并不是近期才出现的，OMG的MDA就是技术独立的一种模型描述方式，但是MDA发展并不是很好，因为它关注 于特定的从一些类图模型转换到代码的低级模型。而DSL关注的是特定领域模型，带来更大的定执性和灵活性，所以近期发展的也很不错，DSM有点类似的概 念，也是我比较喜欢的一种思路，还有MDE和SOBA等。业务工程更多的是关注如何自动的执行功能模型，而不是类似MDA专注于转换模型的过程，OpenExpressApp的类库会代码生成，但是模型会通过建模工具生成。
使用业务工程后，带来最大的变化就是由业务人员来主导构建应用方案，软件工程师会被转移到平台和工具的开发，而业务应用方案将由懂得业务并知道如何使用规范的模型建模的业务人员来进行构建。规范的模型在业务工程中需要强调出来，DDD中也有统一语言的概念，业务人员和IT人员在建模时也必须基于一个统一的规范来进行建模，如果没有统一的语言，模型也就很难自动执行了。下面这个漫画表达的就是沟通语言不一致带来的障碍:)
由于使用声明式的模型，业务人员可以更早的更多的加入开发流程，从而改善产品的质量。通过业务工程，应用软件也可以更快速的进行开发，也能更好的响应变化。
业务工程实践
业务驱动开发，这个很多人都知道，但是都觉得很难做，上面描述的业务工程也就是一种美好的向往而已。但是我觉得这绝不是向往，其实已经有很多人朝这个方向走了，我主导的OpenExpressApp开发平台也主要是这个方向，应用的也不错，roadmap只是时间问题，技术和思路上我觉得还是不错的。以下我说一下实践业务工程的几个重点，欢迎大家提出各自的见解。
方法支持
在《软件工厂方法》中说明了软件工厂的一些概念：
工具支持
DSL tools 和Model-Driven Software Factories。
- DSL工具用来定义领域模型语言，通过工具可以自定义DSL模型，如企业架构建模（EA）、界面建模（UI）、命令扩展（Command）、领域建模（Domain）、规则建模（Rule）、报表模型（Report）和工作流模型（Workflow）。
- 模型驱动软件工厂是一个完整的平台，可以用来构建产品，包含一系列的DSL模型，并且能够执行。OpenExpressApp框架就是软件工厂中的一部分。
应用支持
更多内容：
规模化产品开发方法－产品线工程 100222.pdf 开源信息系统开发平台之OpenExpressApp框架.pdf
欢迎转载，转载请注明：转载自周金根 [ http://zhoujg.cnblogs.com/ ]
