軟體觀點 － 從軟體工程到業務工程

文章目錄

• 業務工程
• 業務工程實踐

軟 件工程

　　軟件工程是一門研究用工程化方法構建和維護有效、實用的和高品質的軟體的學科。它涉及到程式設計語言、資料庫、軟體開發工具、系統平台、標準、設計模式等方面。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/ ]