今天大部份軟件工程項目失敗的主要原因是我們采用40年前的軟件開發(fā)模式， 30年前的計算機(jī)應(yīng)用思維。從業(yè)人員采用過時的方法，落后的思維，所以大部份項目未能為業(yè)主帶來預(yù)期的效益，滿足業(yè)主的要求。

　　40年前計算機(jī)開始進(jìn)入商業(yè)用途之初期，沒有任何開發(fā)體系可以應(yīng)用，所以從業(yè)人員在表格上整理邏輯，編寫程序，測試及對程序進(jìn)行Debugging，然后移交，今天從業(yè)人員在腦中開展系統(tǒng)的邏輯，進(jìn)行程序編寫，過去的Debug變成今天的Fix（修改），成為邊想，邊做，邊改的三邊模式來進(jìn)行軟件開發(fā)。30年前軟件的主要應(yīng)用目的是運營自動化，提升企業(yè)部門的執(zhí)行效率，今天大部份從業(yè)人員還是以自動化為軟件開發(fā)的主要目標(biāo)。軟件工程失敗的主要原因不是技術(shù)應(yīng)用的問題，是從業(yè)人員未能把握客戶思維，交付客戶期盼的交付物，導(dǎo)致項目在開發(fā)過程中不斷修改和返工，為項目帶來延誤和超支。

　　往往我們把客戶的期盼當(dāng)作系統(tǒng)的功能需求，這是一個錯誤的觀念。要知道客戶的期盼（我們口中所說的客戶需求）是要做什么，這是客戶投資的最終目標(biāo)。但系統(tǒng)或功能需求卻是該如何做，是技術(shù)應(yīng)用的手段。知道“要做什么”，才知道“該如何做”。我們未能把握客戶的期盼（要做什么），如何能夠提供高效的技術(shù)手段來達(dá)到目的呢！所謂“條條大道通羅馬”，只要知道了目標(biāo)，我們有很多選擇采用不同的手段來達(dá)到。過去的問題在于我們把目標(biāo)當(dāng)成手段來處理，一步一摸索，在過程中不斷開路搭橋，縱然最終能夠抵達(dá)目的地，但這種執(zhí)行模式能不浪費時間，精力和金錢嗎！

　　今天的軟件工程的終極要求與過去數(shù)十年軟件工程的終極要求有很大的差異。過去自動化時代的軟件工程主要是技術(shù)的應(yīng)用，提升運營效率，以技術(shù)的應(yīng)用方法為項目的最終目標(biāo)。今天的信息化軟件工程必須考慮和提供業(yè)主希望獲得的投資價值，著重于科技如何能夠帶出相對的投資價值和運營效益為目的。可惜我們還是利用過去數(shù)十年前的技術(shù)開發(fā)思維和應(yīng)用方法來進(jìn)行項目交付，未能有效地面對項目屬性和交付目的的轉(zhuǎn)變做出相應(yīng)的調(diào)整。讓項目中大部份的工作量停留在編程，測試，修改和返工上。我們采用過時的方法，落后的思維來面對今天軟件工程的挑戰(zhàn)，如何能夠在軟件工程方面帶出創(chuàng)新，引領(lǐng)未來呢？

　　計算機(jī)是邏輯學(xué)

　　“四步創(chuàng)新軟件開發(fā)”的要旨在于擺脫過去軟件工程對需求的重視。從邏輯的思維去實現(xiàn)最終目標(biāo)。軟件工程項目多基于規(guī)范性的邏輯應(yīng)用，任何軟件工程項目的最終交付都必須包含兩個部分，一個是業(yè)務(wù)邏輯（即業(yè)務(wù)應(yīng)用流程）、另一個是系統(tǒng)邏輯（即程序執(zhí)行流程）。業(yè)務(wù)邏輯是任何系統(tǒng)在最終實際的業(yè)務(wù)層面所體現(xiàn)出的邏輯，就是“要做什么”；而系統(tǒng)邏輯是指系統(tǒng)為了滿足業(yè)務(wù)上的能力而在系統(tǒng)層面所體現(xiàn)出的邏輯，就是“該如何做”。無論是業(yè)務(wù)邏輯還是系統(tǒng)邏輯，它們存在的目的都是為了交付最終的價值或達(dá)到項目的目標(biāo)。所以在沒有明確相關(guān)的業(yè)務(wù)邏輯和系統(tǒng)邏輯時，要想建立出交付價值的相關(guān)邏輯是十分復(fù)雜的。一般來說，業(yè)務(wù)邏輯是范圍所處的層面，而系統(tǒng)邏輯是功能需求所處的層面。

　　為了明確主要的構(gòu)思，我們不以軟件工程項目為例來帶出相關(guān)的構(gòu)思，而是以其它工程項目為例來說明這些構(gòu)思。這樣做是為了讓讀者可以擺脫軟件工程中的原有思維，以一個新的角度來看待軟件項目。不知大家是否還記得，在1.2中所提到的“工匠與專家”的故事，這里我們將會以一個內(nèi)部裝潢設(shè)計專家的角度來說明如何利用一個新的房間為例，帶出四部開發(fā)方法的主要構(gòu)思。

　　假設(shè)我們要利用一個空房間，使用的目的可能是作為辦公室、會議室、書房或者其他的用途。那么在決定了這個最終目的后，便需要決定房間中所需的家具和布置，房間可以是空房間、也可以是有些家具的房間。

　　所以，在知道最終用途后，我們（扮演了裝潢設(shè)計師）才會明確有哪些家具，這些家具便是交付物的定義。也許我們明確知道需要一張桌子，不管是從家具店購買、還是找工匠打做，我們一定要依據(jù)最終交付物定義來思考。更明確的說，知道一張桌子使用的最終目的，是用來放置計算機(jī)、放置一個咖啡器、用來書寫、或者是用來開會還是裝飾，更甚者是可以放置計算機(jī)、可以辦公、可以放置一個咖啡器的辦公桌。其中一樣或多樣都可以是說明需要一張桌子的最終目的。這是我們在理解了這些最終目的后在價值層面思考后獲得的最終交付物說明，這些最終目的構(gòu)成了說明交付物的依據(jù)。而思考的方法就是PCDM。

　　最終的目的已經(jīng)構(gòu)成最終交付物的主要構(gòu)思，加上應(yīng)用的地域和環(huán)境，將會直接影響最終交付物的外觀和大小。例如，試想我們?yōu)橐粋€僅有15平米的辦公室，進(jìn)行裝修布局?？蛻裘鞔_指出了，在該辦公室中可以有3個經(jīng)理辦公、同時可以滿足某一經(jīng)理愛喝咖啡的習(xí)慣、還需滿足另外一個經(jīng)理需要經(jīng)常與其他員工在辦公室見面和會談的工作要求。那么，這些目的和應(yīng)用的環(huán)境（15平米）將會影響到交付物（辦公桌子和椅子）的外觀。

　　有了需要一張桌子的最終目的和建立的交付物定義，接下來我們要考慮的便是這件交付物的外觀（Appearance），是圓的、方的、長方形的、橢圓形的、折合型的，需要抽屜的，需要附加柜的（如放置咖啡器），桌腿是三叉腳的、四角的，是需要兩邊豎立或交叉對立支撐的（如需要經(jīng)常面見員工）。這些外觀的設(shè)計直接影響交付物的外表。另外，考慮外觀的時候需要考慮拜訪的應(yīng)用環(huán)境（如15平米），桌子是放在中央還是角落、或是平常依附角落用的時候放到中央。這些也會影響交付物的外觀。該階段我們可以稱為交付物的外觀階段，如一張桌子到底是什么樣的。

　　當(dāng)明確了最終目的和外觀后，最后進(jìn)入建造或采購過程的時候才考慮所采用的組合技術(shù)和材料，包括桌子的組合是透過釘子、螺絲結(jié)合或是焊接。這些技術(shù)的應(yīng)用將會影響交付物的質(zhì)量和投資成本。而不同的技術(shù)仍然可以打造同樣的結(jié)果，如釘子組合或螺絲結(jié)合（當(dāng)然是木螺絲）都可以組合不同的交付組件。該階段也被稱為建造階段（Construct），而該階段的成功歸功于前期交付物和交付物的外觀獲得客戶的認(rèn)可，這樣在建造過程中將會把客戶的需求變更降到最低，甚至消失。

　　當(dāng)然，我們需要把交付物（如桌子）與實際的應(yīng)用環(huán)境（如15平米的經(jīng)理辦公室）相結(jié)合，看看是否能夠演繹出預(yù)期的最終目的，如是否滿足了某一經(jīng)理及需要擺置電腦又需要擺置咖啡器的目的。該階段稱為演繹（Demonstrate）階段，它可以讓交付物與環(huán)境結(jié)合成一個完整的驗收過程。環(huán)境包括應(yīng)用的部門、人員、培訓(xùn)、硬件配置等。

　　四步創(chuàng)新軟件開發(fā)

　　四步開發(fā)方法的主要構(gòu)思是：在我們失去了業(yè)務(wù)操作流程的時候，我們可以從項目的價值或目標(biāo)來考慮和確定出項目的交付物定義；同時我們可以利用這些交付物定義來建立每個交付組件所對應(yīng)的業(yè)務(wù)操作流程，通過業(yè)務(wù)操作流程帶出每個交付組件的數(shù)據(jù)定義和界面定義；最終，根據(jù)這些數(shù)據(jù)定義和業(yè)務(wù)操作流程我們可以將構(gòu)建交付物的任務(wù)劃分為多個子任務(wù)來完成；當(dāng)我們將所有的交付組件建造完后，可以將實際構(gòu)建成的交付組件應(yīng)用到客戶所需的業(yè)務(wù)之中，帶出在項目初期確立的目標(biāo)或價值。










　　四步軟件開發(fā)方法共分為四個階段，它們分別是：

　　1)    第一階段稱為目的階段，它開始于項目贊助人給出項目說明，結(jié)束于交付物定義。在該階段中，我們通過使用PCDM構(gòu)建出項目的交付物定義和最終目的。該階段需要相關(guān)受益人的確認(rèn)，包括項目贊助人和項目干系人。

　　2)    第二階段稱為外觀階段，它開始于交付物定義，結(jié)束于交付物的外觀建立完成。該階段的產(chǎn)物包括，業(yè)務(wù)流程定義、數(shù)據(jù)定義、界面定義；同時數(shù)據(jù)定義和界面定義構(gòu)成交付物的外觀。這里需要使用的方法是系統(tǒng)操作規(guī)范（SOP）。該階段需要項目贊助人認(rèn)可和確認(rèn)交付物的業(yè)務(wù)流程。 [NextPage]

　　3)    第三階段稱為構(gòu)建階段，它開始于數(shù)據(jù)定義和界面定義，結(jié)束于最終解決方案的生成；這里解決方案是指實際的、有相關(guān)技術(shù)方案構(gòu)成的最終交付的系統(tǒng)。這里最終的解決系統(tǒng)需要項目贊助人的測試和確認(rèn)。該階段的主要任務(wù)是編程和測試，同時我們不準(zhǔn)備強(qiáng)制任何方法和技術(shù)標(biāo)準(zhǔn)，這里可以自由地選擇適當(dāng)?shù)募夹g(shù)標(biāo)準(zhǔn)來構(gòu)建最終的解決方案。

　　4)    第四階段稱為演示階段，該階段將最終的解決方案放置到相應(yīng)的環(huán)境中進(jìn)行組合，來產(chǎn)生最終的效益。這里我們需要明確每個解決方案的環(huán)境組合，包括系統(tǒng)配置、用戶培訓(xùn)、用戶測試。

　　四步創(chuàng)新軟件開發(fā)的生命周期包括四個主要階段：目的階段，外觀階段，構(gòu)建階段，和最后的演示階段。與傳統(tǒng)的軟件開發(fā)模式相比較，四步創(chuàng)新軟件開發(fā)的每一個階段都可以培養(yǎng)有關(guān)的專業(yè)人員，目的階段可以培養(yǎng)優(yōu)秀的業(yè)務(wù)和系統(tǒng)分析人員，外觀階段可以培養(yǎng)業(yè)務(wù)流程改做和軟件設(shè)計人才，構(gòu)建階段讓技術(shù)人員盡情發(fā)揮本身的技術(shù)知識和應(yīng)用能力，演示階段培養(yǎng)優(yōu)秀的綜合性軟件工業(yè)人才。這些都是我們目前大部份企業(yè)所希望做到但沒有辦法做到的最終成果。

　　第一步：目標(biāo)階段

　　任何項目在起動的第一時間必須明確項目的范圍，才能夠控制開發(fā)過程中的范圍變動。在今天的信息化時代，要為未來的運營模式成立前建立工程的范圍是相當(dāng)困難的任務(wù)，我們過去采取逃避的方式，不去嘗試建立項目范圍，把精力虛耗在把握客戶需求（業(yè)務(wù)邏輯）上，同時把客戶需求作為功能需求（系統(tǒng)邏輯）來處理，所以我們一直沒有一套高效的辦法為客戶構(gòu)建所需的系統(tǒng)，滿足客戶投資的最終目的。

　　我設(shè)計的項目組件分拆發(fā)（Project Component Decombbbbbbbb bbbbbb, PCDM）是一套建立信息化系統(tǒng)工程范圍的手段（詳情請參閱“項目組件分拆法PCDM”一文），可以在相對較短的時間聯(lián)同業(yè)主即主要項目干系人共同分析項目的最終交付需求，從交付需求中整理出業(yè)務(wù)邏輯和系統(tǒng)邏輯。

　　第二步：外觀階段
　　也許這個階段以“內(nèi)觀”代替外觀比較貼切，但實際上這個階段的工作保護(hù)兩個主要目的，一是讓客戶認(rèn)同未來交付的成果，二是建立系統(tǒng)的規(guī)格。

　　外觀階段主要是對未來需要交付的系統(tǒng)執(zhí)行操作規(guī)劃（System Operation Planning, SOP）,建立未來的業(yè)務(wù)邏輯和系統(tǒng)邏輯，同時依據(jù)業(yè)務(wù)邏輯建立系統(tǒng)的數(shù)據(jù)流，利用系統(tǒng)邏輯建立用戶界面。讓客戶認(rèn)同未來系統(tǒng)的操作流程，明確過程中的各種界面設(shè)計和內(nèi)容，構(gòu)建了工程核心的業(yè)務(wù)邏輯和創(chuàng)建了系統(tǒng)的核心價值，減低開發(fā)過程中的返工需求。這個階段的主要交付包括未來的業(yè)務(wù)定義，數(shù)據(jù)定義和界面定義三部分。

　　交付組件為什么可以明確業(yè)務(wù)流程

　　PCDM的交付組件是如何限定每個組件內(nèi)的業(yè)務(wù)流程或業(yè)務(wù)邏輯呢！這是因為：

　　1)    每個交付組件都是在獨立的價值層面上來進(jìn)行定義的，它們僅僅圍繞價值的交付來進(jìn)行建立相關(guān)的交付組件。每個組件最多說明到通過做什么來生成價值，而不涉及業(yè)務(wù)邏輯和系統(tǒng)邏輯。

　　2)    每個交付組件都會明確從那些方面來生成相應(yīng)的結(jié)果或效果，這樣可以在獨立的價值層面上從不同方面來確保最終的系統(tǒng)可以交付所期盼的價值。而如何做和做什么是交付價值的邏輯與系統(tǒng)和業(yè)務(wù)邏輯相互分離。

　　3)    這樣每個組件通過價值層面的邏輯來指出通過哪些相關(guān)的工作內(nèi)容來交付價值，同時這些工作內(nèi)容是價值層面的描述。當(dāng)我們?yōu)槊總€交付組件建立相關(guān)的業(yè)務(wù)流程時，我們根據(jù)業(yè)務(wù)環(huán)境所選擇的業(yè)務(wù)邏輯在價值層面上的映射必須與交付組件的內(nèi)容一致，使得業(yè)務(wù)邏輯可以完全符合價值層面的要求來交付相關(guān)的價值，否則我們很難控制每個價值的交付過程或業(yè)務(wù)流程。

　　四步開發(fā)方法在PCDM交付物定義的引導(dǎo)下，使得我們構(gòu)建項目的業(yè)務(wù)操作流程的時間和精力將會被縮短、質(zhì)量將會被提高。

　　交付組件與業(yè)務(wù)模塊

　　交付組件就是一種業(yè)務(wù)模塊，所以它可以獲得所有業(yè)務(wù)模塊的優(yōu)點。但是，它與業(yè)務(wù)模塊還是有一些本質(zhì)區(qū)別的。

　　1)    交付組件是在價值層面對交付組件進(jìn)行描述，與具體的業(yè)務(wù)流程或業(yè)務(wù)邏輯基本分離，不受到具體的業(yè)務(wù)流程影響。

　　2)    交付組件可以是交付物定義的組件，同時也可以是由方案所直接轉(zhuǎn)變而成的交付成果或組件。同時每個交付組件可以包含一個或多個業(yè)務(wù)模塊。

　　3)    交付組件主要是針對價值而言的，么個交付組件都通過它自身所描述的工作內(nèi)容來對交付價值，或通過不同方面的效果或成果使得最終的某一交付物可以生成最終價值的描述。而業(yè)務(wù)模塊主要是為了業(yè)務(wù)層面的維護(hù)、復(fù)用和解耦，在一個項目中業(yè)務(wù)模塊可能很難明確的在價值層面被描述出來。這是因為它所貢獻(xiàn)的效果可能針對的是另一個價值。

　　4)    交付組件是通過PCDM方法來確立的。而業(yè)務(wù)模塊基本上是根據(jù)在交付組件內(nèi)的業(yè)務(wù)邏輯進(jìn)行的解耦獲得的，它更加利于復(fù)用其它價值層面。

　　5)    交付組件是與效益或價值同時擴(kuò)充和維護(hù)的，而業(yè)務(wù)模塊是被包含在交付組件內(nèi)變更的。
　　6)    交付組件可以說成是價值層面的邏輯，而業(yè)務(wù)模塊是業(yè)務(wù)層面的邏輯。

　　業(yè)務(wù)定義

　　業(yè)務(wù)定義中所指明的系統(tǒng)模塊是從業(yè)務(wù)角度來看待的，是PCDM的交付物定義中所包括的內(nèi)容，它與具體的技術(shù)使用無關(guān)；如API的調(diào)用序列。而且它也不是編程語言中所指的模塊，如像JAVA中提供的包或組件等。同時它也不完全等價于PCDM中所建立的交付組件；一個交付組件可以是一個業(yè)務(wù)模塊，同時也可以是一個和多個業(yè)務(wù)模塊的組合。在進(jìn)行業(yè)務(wù)層面的系統(tǒng)模塊說明前，我們還是明確一下業(yè)務(wù)流程在開發(fā)體系中的一些本質(zhì)作用，這樣我們就可以較為清楚地理解業(yè)務(wù)層面的系統(tǒng)模塊這一概念。

　　回顧在PCDM中所描述的案例，我們的最終交付物在下圖中描述有關(guān)的業(yè)務(wù)模塊（交付組件）和數(shù)據(jù)組合（數(shù)據(jù)組）。 



　　每個交付組件可以是一種業(yè)務(wù)模塊，它指明了該模塊內(nèi)應(yīng)當(dāng)完成那些任務(wù)來帶出客戶期盼的價值。但是交付組件并不是從業(yè)務(wù)層面思考獲得的，而是從價值層面構(gòu)成的定義；而這個定義卻指明了業(yè)務(wù)層面應(yīng)當(dāng)完成的任務(wù)。可能一個交付組件要包括一個或多個業(yè)務(wù)模塊的組合（這依賴于定義業(yè)務(wù)模塊的方法）。實際上每個業(yè)務(wù)模塊仍然可以明確地存在于價值層面上，對于任何不同項目價值層面可能會有所不同，會出現(xiàn)一個交付組件包含多個業(yè)務(wù)模塊的現(xiàn)象。由于業(yè)務(wù)模塊的本身特性和價值層面描述具有同一性的交付組件，使得我們構(gòu)建的業(yè)務(wù)流程必然對應(yīng)了相關(guān)的系統(tǒng)接口或組合。所以在制定操作流程時，我們?nèi)匀恍枰紤]到價值層面，即每個業(yè)務(wù)點不是單純從客戶使用角度建立，更應(yīng)當(dāng)將從業(yè)務(wù)角度來考慮每個業(yè)務(wù)點中如何來貢獻(xiàn)出項目的價值。[NextPage] 

　　由于每個業(yè)務(wù)點的制定都考慮到了價值的貢獻(xiàn)，所以一個或多個業(yè)務(wù)點的輸入和輸出所構(gòu)成的業(yè)務(wù)模塊與實際的系統(tǒng)接口調(diào)用組合都是用來產(chǎn)生相應(yīng)價值的，它們之間構(gòu)成了明確的對應(yīng)關(guān)系。

　　交付物定義明確指明了每個業(yè)務(wù)流程上的工作內(nèi)容，使得交付物所對應(yīng)的目標(biāo)可以細(xì)化到業(yè)務(wù)層面，這樣我們可以知道流程中的業(yè)務(wù)邏輯與項目價值的對應(yīng)關(guān)系。這就是我們建立業(yè)務(wù)流程的主要目的：通過交付物定義來明確在交付物內(nèi)的業(yè)務(wù)邏輯與價值之間的對應(yīng)關(guān)系，可以幫助我們分離不同價值的業(yè)務(wù)邏輯，從而使得該交付組件或所對應(yīng)的業(yè)務(wù)模塊具有高內(nèi)聚低耦合性。同時這些業(yè)務(wù)模塊可以由相應(yīng)的系統(tǒng)接口構(gòu)成，而且這些系統(tǒng)接口的定義和實現(xiàn)完全可以依照不同的技術(shù)標(biāo)準(zhǔn)來制定。而這些業(yè)務(wù)模塊要么是交付組件，要么一同構(gòu)成了交付組件。

　　由于業(yè)務(wù)模塊的特性，使得業(yè)務(wù)邏輯和系統(tǒng)邏輯相互分離，同時確保它們是一致的。這樣對于每個業(yè)務(wù)流程所帶出的相關(guān)數(shù)據(jù)，我們可以通過業(yè)務(wù)模塊來制定出明確數(shù)據(jù)定義，這些數(shù)據(jù)定義將會成為我們構(gòu)建系統(tǒng)模塊（或接口）和系統(tǒng)架構(gòu)的基礎(chǔ)。

　　我們可以通過“業(yè)務(wù)操作流程、數(shù)據(jù)定義、界面定義”來代替“需求調(diào)研、需求分析和系統(tǒng)設(shè)計”。雖然，我們還需詳細(xì)的論述數(shù)據(jù)定義后才可以下該結(jié)論，但是在這里我們基本上明確了交付物可以通過系統(tǒng)操作流程帶出的輸入和輸出制定出數(shù)據(jù)定義，這些數(shù)據(jù)定義構(gòu)成了制定系統(tǒng)模塊的基礎(chǔ)。

　　業(yè)務(wù)定義：操作流程

　　為了使得業(yè)務(wù)操作流程的制定能夠明確的表明，我們需要制定一些基本的限定：
    ·每個業(yè)務(wù)操作流程必須指明一個開始點和完結(jié)點。
    ·每個開始點和完結(jié)點，以時間、地點或時間的狀態(tài)作為標(biāo)注。
    ·每個操作流程都會擁有一個或多個業(yè)務(wù)點。
    ·每個業(yè)務(wù)點必須有明確的輸入或輸出，或者是二者兼有。
    ·每個業(yè)務(wù)點必須從業(yè)務(wù)層面指明一個活動或操作，且只有一個。
    ·每個業(yè)務(wù)點的輸入和輸出的數(shù)據(jù)屬于業(yè)務(wù)層面的數(shù)據(jù)，但不一定不設(shè)計技術(shù)的信息。例如，記錄客戶信息中的客戶號，有可能是一個技術(shù)信息，但是它是在業(yè)務(wù)層面的表達(dá)，所以不會涉及到技術(shù)的具體運用，如不會指明該客戶號可能是一個哈希編碼等等。
    ·每個操作流程必須有明確的目標(biāo)，同時這些目標(biāo)要么是交付的價值，也就是對于交付組件所對應(yīng)的價值在價值層面做出相關(guān)貢獻(xiàn)。
    ·每個業(yè)務(wù)點必須是自包含的、限定的，否則任何軟件也無法實現(xiàn)一個非限定性的業(yè)務(wù)流程，即該業(yè)務(wù)流程是“不可計算的”。 
  












 
　　有了業(yè)務(wù)操作流程的精確定義，我們就可以為每個交付物的外觀做出精確定義。

　　數(shù)據(jù)定義

　　對于系統(tǒng)操作流程中的每個輸入或輸出，都會成為我們制定數(shù)據(jù)定義的基礎(chǔ)。這些輸入和輸出會構(gòu)成相關(guān)業(yè)務(wù)模塊和系統(tǒng)接口的基礎(chǔ)。

　　在建立初步系統(tǒng)邏輯和業(yè)務(wù)邏輯抽，我們可以劃分出業(yè)務(wù)模塊，實際上一個交付組件（或方案所對應(yīng)的組件）就是一個很好的業(yè)務(wù)模塊。但是，由于不同價值層面的原因，在某一層面的交付組件有可能包含了明確的另外層面的多個交付組件。所以，我們需要將交付組件劃分為更加明確的業(yè)務(wù)模塊，而劃分的規(guī)則就是在業(yè)務(wù)層面的高內(nèi)聚和低耦合；即根據(jù)每個業(yè)務(wù)模塊所對應(yīng)的業(yè)務(wù)流程的輸入和輸出制定業(yè)務(wù)模塊。

　　根據(jù)輸入和輸出建立該業(yè)務(wù)模塊的數(shù)據(jù)定義，最終需要整合所有的數(shù)據(jù)定義成為系統(tǒng)的數(shù)據(jù)架構(gòu)或數(shù)據(jù)定義。一般來說會有兩種方法，面向過程和面向?qū)ο?。面向過程可以分別建立業(yè)務(wù)模塊和數(shù)據(jù)架構(gòu)，而面向?qū)ο笮枰煌㈩I(lǐng)域模型（業(yè)務(wù)層面的類模型）和動態(tài)模型（對象狀態(tài)轉(zhuǎn)移圖），同時領(lǐng)域模型一般來講是數(shù)據(jù)架構(gòu)，而非業(yè)務(wù)模塊；因為，如果以對象來標(biāo)志業(yè)務(wù)模塊的話，可能很難明確該模塊所對應(yīng)的業(yè)務(wù)目標(biāo)，那么這種模塊會喪失業(yè)務(wù)內(nèi)聚性。另外，需要說明的是數(shù)據(jù)架構(gòu)可以根據(jù)要使用的技術(shù)標(biāo)準(zhǔn)直接建立到系統(tǒng)層面，也可以僅僅建立業(yè)務(wù)層面的數(shù)據(jù)架構(gòu)，這完全依賴于我們使用的技術(shù)標(biāo)準(zhǔn)。

　　最終我們需要利用數(shù)據(jù)架構(gòu)建立業(yè)務(wù)模塊的架構(gòu)，以使得業(yè)務(wù)模塊的架構(gòu)可以與最終的包含在每個模塊內(nèi)系統(tǒng)模塊或接口的架構(gòu)相互對稱。數(shù)據(jù)定義模型包含了業(yè)務(wù)模塊、數(shù)據(jù)架構(gòu)和業(yè)務(wù)模塊的總體架構(gòu)。而業(yè)務(wù)模塊的總體架構(gòu)僅僅是通過完善交付組件之間的關(guān)聯(lián)（數(shù)據(jù)耦合）來完成的。

　　界面定義


　　業(yè)務(wù)流程與交付物外觀”代替“需求與設(shè)計?？赡芗?xì)心的讀者會問，怎么在四步方法中沒有需求和設(shè)計這兩個活動了呢？是的，在構(gòu)建四步開發(fā)方法時確實將這兩個活動從四步方法中移除了，我們是通過“業(yè)務(wù)流程與交付物外觀”來代替“需求與設(shè)計”的。通過交付組件我們可以明確指出工作內(nèi)容，同時可以使得業(yè)務(wù)邏輯和系統(tǒng)邏輯在交付組件上相互對應(yīng)（或業(yè)務(wù)模塊），這里的交付組件可以是交付物定義，也可以是方案所對應(yīng)的一個個單一的組件。 [NextPage]

　　1)    我們可以獨立地建立該交付組件的業(yè)務(wù)邏輯，這將帶出明確的數(shù)據(jù)定義，同時也會帶出相關(guān)的業(yè)務(wù)模塊（如果交付組件內(nèi)還可以分解出更明確的業(yè)務(wù)模塊）。

　　2)    由于業(yè)務(wù)模塊和交付組件的原因，我們可以等價地利用交付組件或業(yè)務(wù)模塊來建立出系統(tǒng)在業(yè)務(wù)層面所對應(yīng)的架構(gòu)；同時每個組件內(nèi)都可以對應(yīng)明確的系統(tǒng)接口或模塊。

　　3)    最終我們可以利用業(yè)務(wù)模塊的架構(gòu)來等價地建立出系統(tǒng)的架構(gòu)，同時并不影響每個模塊內(nèi)系統(tǒng)邏輯的制定。

　　對于功能需求，我們利用業(yè)務(wù)模塊將其屏蔽和限定在一個個的交付組件或業(yè)務(wù)模塊內(nèi)，使得我們根本不需要從系統(tǒng)角度來建立在項目初期根本就不存在的需求。實際上，客戶一直不知道他自己的需求（功能需求），否則客戶為什么在70%的失敗率下還是要依靠我們來建立功能需求呢！

　　第三步：構(gòu)建階段

　　構(gòu)建階段的設(shè)立是為了使得技術(shù)人員可以更加自由地發(fā)揮他們的技術(shù)特長，從而構(gòu)建的交付物不僅可以帶出價值，而且是高質(zhì)量、易維護(hù)應(yīng)用軟件。我們不準(zhǔn)備詳細(xì)的討論每個技術(shù)規(guī)范和強(qiáng)制約束該使用那些技術(shù)規(guī)范，因為我們既不想加入到曠日已久的技術(shù)大戰(zhàn)中，也不想再為“名詞百出”的IT界增加新的辭藻。

　　技術(shù)標(biāo)準(zhǔn)選擇

　　技術(shù)標(biāo)準(zhǔn)的選擇是跟客戶是無關(guān)的，而且大部份客戶也不太理會?？蛻舻闹饕康氖且蕾嚰夹g(shù)人員的專長來為他搭建所需的應(yīng)用系統(tǒng)，所以技術(shù)的應(yīng)用完全可以由開分人員來進(jìn)行選擇。但是需要一個系統(tǒng)架構(gòu)師來確認(rèn)這個項目的統(tǒng)一技術(shù)標(biāo)準(zhǔn)，否則交付物將會因為技術(shù)標(biāo)準(zhǔn)的錯誤選擇而失敗。

　　這里我們僅僅說明交付物和操作流程是如何隔離不同技術(shù)方案的。這是因為：
    
　　·對于與交付物對應(yīng)的系統(tǒng)操作流程反映了出了業(yè)務(wù)的邏輯，同時我們有從業(yè)務(wù)角度建立出了業(yè)務(wù)的模塊，使得每個業(yè)務(wù)模塊之間的耦合度降到最低。
    
　　·由于業(yè)務(wù)模塊（數(shù)據(jù)定義的一部分）不依賴于具體技術(shù)的實現(xiàn)，所以我們可以非常自由地為每個業(yè)務(wù)模塊賦予不同的技術(shù)方案，只要它們之間是相互一致的。
    
　　·由于業(yè)務(wù)模塊隔離了系統(tǒng)邏輯，使得每個業(yè)務(wù)模塊的邏輯不會受到系統(tǒng)邏輯的變更影響，所以被包含在不同業(yè)務(wù)模塊的技術(shù)方案之間不會被相互影響；對于整個系統(tǒng)架構(gòu)而言，即使添加或拆除一個業(yè)務(wù)模塊，也僅僅是增加和取消系統(tǒng)接口的調(diào)用，使得整個系統(tǒng)便于維護(hù)。
    
　　·我們在定義了統(tǒng)一的技術(shù)標(biāo)準(zhǔn)規(guī)范后，獨立地定義每個業(yè)務(wù)模塊的系統(tǒng)接口調(diào)用和實現(xiàn)。

　　這里可以引入的技術(shù)標(biāo)準(zhǔn)可以包括如SOA、UML、BPEL等。同時也可以使用一些較早的技術(shù)標(biāo)準(zhǔn)，如面向過程的編程等等。因為所有的軟件項目都不可能完全以一個技術(shù)標(biāo)準(zhǔn)來實現(xiàn)，如嵌入式系統(tǒng)完全可以涉及到更加接近底層的匯編語言。
　　接口定義

　　在統(tǒng)一了技術(shù)標(biāo)準(zhǔn)規(guī)范后便需要獨立地定義每個接口的實現(xiàn)方法。接口定義不同于模塊的建立，如面向?qū)ο笾械囊粋€對象可以是一個模塊，而么個對象中的方法是一個接口。接口說明了在某一模塊中引入另一個模塊的目的和作用，也就是規(guī)定了模塊之間的耦合。

　　系統(tǒng)中的每個接口，是依據(jù)業(yè)務(wù)模塊和數(shù)據(jù)關(guān)系表來建立的。每個業(yè)務(wù)模塊說明了系統(tǒng)接口是如何被相互調(diào)用而組成業(yè)務(wù)模塊的。如“顯示報名信息”是一個業(yè)務(wù)模塊的話，從對象角度可能需要定義出兩個對象，“Booking”和“Booking Layout”兩個對象來分別完成“維護(hù)報名信息”和“報名信息屏幕布局”兩個任務(wù)。注意，在該案例中我們沒有說明具體的API是如何調(diào)用的。

　　所以，這里我們需要進(jìn)一步強(qiáng)調(diào)業(yè)務(wù)模塊的制定不要設(shè)計任何技術(shù)的信息，甚至定義某個對象的接口，不要忘記一個對象的接口有可能涉及系統(tǒng)的邏輯，而是的我們在選擇技術(shù)標(biāo)準(zhǔn)時進(jìn)入一個兩難的境地。

　　編寫測試

　　在選擇每個系統(tǒng)模塊或接口的實現(xiàn)方法前，最好根據(jù)技術(shù)標(biāo)準(zhǔn)和業(yè)務(wù)模塊的定義制定出系統(tǒng)模塊的測試文檔和整個系統(tǒng)的測試文檔。這對于任何技術(shù)標(biāo)準(zhǔn)都是需要的，這樣我們不僅可以有根據(jù)的檢驗每個接口的實現(xiàn)，同時我們可以根據(jù)則是文檔的制定讓程序員更加明確每個程序?qū)崿F(xiàn)的約束。

　　編程規(guī)范制定

　　無論哪種技術(shù)標(biāo)準(zhǔn)都會議自身的角度來強(qiáng)調(diào)編程的規(guī)范，試圖從公眾的角度加以限定幾乎是不可能的。所以，這里我們僅僅說明編程中必須注意的事項，而與具體的技術(shù)規(guī)范無關(guān)。

　　1.    使用一致的和有意義的變量名；這幾乎是所有糾錯性維護(hù)的根源。才將任務(wù)試圖根據(jù)業(yè)務(wù)模塊或交付組件來分給不同的技術(shù)小組時，一定要制定一致的變量名和數(shù)據(jù)庫的調(diào)用規(guī)范；如不要試圖對同一個數(shù)據(jù)庫中的表使用多個索引。

　　2.    代碼注釋規(guī)范。如果問維護(hù)中最大的難點是什么，無疑是對代碼的理解，即使對于面向?qū)ο蟮某绦蚨?，在沒有代碼時試圖讀懂程序也會是一個噩夢。

　　3.    使用參數(shù)。實際上，程序中數(shù)據(jù)大部分以變量形式出現(xiàn)，否則我們不必在這如此費神。這里的參數(shù)是指將一個常量也綁定到某一變量中來。至于是否有相關(guān)的語言可以幫助我們實現(xiàn)，我想現(xiàn)在不用我們指出，即使不太精通編程的非專業(yè)人員都會指出一兩種來。

　　4.    代買編排版式需要統(tǒng)一，這會大大增加可讀性?，F(xiàn)在有大量的CASE工具來幫助我們實現(xiàn)。

　　5.    不要將嵌套的IF語句超過3個，雖然這不是必須的規(guī)定，但是它已經(jīng)在業(yè)界獲得一致的認(rèn)可。

　　6.    對于任何API而言，在小組試圖開發(fā)前需要明確相關(guān)API至少是在程序中使用的API的正確調(diào)用順序。好像這點并不需要強(qiáng)調(diào)，只要你登錄UCLA的網(wǎng)站，你就可以找到關(guān)于API構(gòu)成BUG的相關(guān)數(shù)據(jù)挖掘的解決方案，那時你會知道這種錯誤的出現(xiàn)不僅是致命的，而且是十分普遍的。

　　最后我們沒有明確指明如何進(jìn)行測試的原因是不同技術(shù)規(guī)范有不同的測試需求和技巧。
　　第四步：演示階段

　　在演示階段主要是通過將交付物與具體的應(yīng)用環(huán)境相結(jié)合來帶出客戶所期盼的價值，從而使得項目可以得到驗收。演示階段主要有三個過程：

　　1)    系統(tǒng)配置：即安裝報告，明確指明系統(tǒng)的環(huán)境參數(shù)如何設(shè)置（如MySQL的安裝信息），指明如何配置相關(guān)的系統(tǒng)參數(shù)（如設(shè)置路徑變量等）。這部分也可以有系統(tǒng)維護(hù)人員來協(xié)助客戶一同完成。

　　2)    用戶培訓(xùn)：由于新的系統(tǒng)的引入，我們還需要按照系統(tǒng)操作規(guī)范和交付系統(tǒng)的特征來撰寫培訓(xùn)計劃和流程，以使得客戶可以明確如何使用和操控系統(tǒng)。

　　3)    用戶測試：當(dāng)然最終需要客戶按照項目交付物定義和操作流程來驗收整個系統(tǒng)是否可以帶出我們在項目初期所一同建立的價值。這部分的測試文檔有客戶自己制定。

　　四步創(chuàng)新軟件開發(fā)的作用

　　任何開發(fā)方法都有其相應(yīng)的作用，四步創(chuàng)新軟件開發(fā)方法也不例外；它的作用是：

　　1)    可以有效的隔離業(yè)務(wù)邏輯和系統(tǒng)邏輯，使得他們可以單獨的處理；充分發(fā)揮了技術(shù)人員的技術(shù)特長。

　　2)    具有高度的可維護(hù)性，使得我們可以根據(jù)客戶提出的維護(hù)需求，僅僅修改和擴(kuò)充相關(guān)的交付組件而已，不會影響其他組件的內(nèi)部結(jié)構(gòu)。

　　3)    業(yè)務(wù)與技術(shù)可以單獨地變更；也就是技術(shù)的變更不會影響業(yè)務(wù)的邏輯。

　　4)    可以有效的融合其他技術(shù)標(biāo)準(zhǔn)，使得四步創(chuàng)新軟件開發(fā)方法應(yīng)用更加廣泛。

　　在構(gòu)建程序上，賦予了構(gòu)建過程的靈活性，使得程序員可以僅僅考慮給予他們的任務(wù)；這樣，加大了程序員的工作效率；最終將會減少開發(fā)的時間、減少資源的運用。

　　實際上，上述的論述過程也反映了自動化時代項目制定功能需求的一面，但不是全部。因為自動化時代僅僅描述了功能需求，但是還需要系統(tǒng)架構(gòu)來劃分模塊來完成所有的功能需求。該過程更加適應(yīng)于信息化時代；這也是為什么引入業(yè)務(wù)模塊的一個根本的原因。雖然，該論述沒有引入數(shù)據(jù)流與業(yè)務(wù)流的精確一一對應(yīng)關(guān)系，但是它足以說明系統(tǒng)與業(yè)務(wù)存在著某種對應(yīng)關(guān)系，使得我們可以從業(yè)務(wù)角度靈活地部署整個系統(tǒng)。

　　下次我會把最后如何有效地對四步創(chuàng)新軟件開發(fā)項目進(jìn)行項目管理的方法與大家分享，

作者：黃紹良教授 　研究員王柏亮