四步創新軟件開發
今天大部份軟件工程項目失敗的主要原因是我們采用40年前的軟件開發模式， 30年前的計算機應用思維。從業人員采用過時的方法，落后的思維，所以大部份項目未能為業主帶來預期的效益，滿足業主的要求。
40年前計算機開始進入商業用途之初期，沒有任何開發體系可以應用，所以從業人員在表格上整理邏輯，編寫程序，測試及對程序進行Debugging，然后移交，今天從業人員在腦中開展系統的邏輯，進行程序編寫，過去的Debug變成今天的Fix（修改），成為邊想，邊做，邊改的三邊模式來進行軟件開發。30年前軟件的主要應用目的是運營自動化，提升企業部門的執行效率，今天大部份從業人員還是以自動化為軟件開發的主要目標。軟件工程失敗的主要原因不是技術應用的問題，是從業人員未能把握客戶思維，交付客戶期盼的交付物，導致項目在開發過程中不斷修改和返工，為項目帶來延誤和超支。
往往我們把客戶的期盼當作系統的功能需求，這是一個錯誤的觀念。要知道客戶的期盼（我們口中所說的客戶需求）是要做什么，這是客戶投資的最終目標。但系統或功能需求卻是該如何做，是技術應用的手段。知道“要做什么”，才知道“該如何做”。我們未能把握客戶的期盼（要做什么），如何能夠提供高效的技術手段來達到目的呢！所謂“條條大道通羅馬”，只要知道了目標，我們有很多選擇采用不同的手段來達到。過去的問題在于我們把目標當成手段來處理，一步一摸索，在過程中不斷開路搭橋，縱然最終能夠抵達目的地，但這種執行模式能不浪費時間，精力和金錢嗎！
今天的軟件工程的終極要求與過去數十年軟件工程的終極要求有很大的差異。過去自動化時代的軟件工程主要是技術的應用，提升運營效率，以技術的應用方法為項目的最終目標。今天的信息化軟件工程必須考慮和提供業主希望獲得的投資價值，著重于科技如何能夠帶出相對的投資價值和運營效益為目的。可惜我們還是利用過去數十年前的技術開發思維和應用方法來進行項目交付，未能有效地面對項目屬性和交付目的的轉變做出相應的調整。讓項目中大部份的工作量停留在編程，測試，修改和返工上。我們采用過時的方法，落后的思維來面對今天軟件工程的挑戰，如何能夠在軟件工程方面帶出創新，引領未來呢？
計算機是邏輯學
“四步創新軟件開發”的要旨在于擺脫過去軟件工程對需求的重視。從邏輯的思維去實現最終目標。軟件工程項目多基于規范性的邏輯應用，任何軟件工程項目的最終交付都必須包含兩個部分，一個是業務邏輯（即業務應用流程）、另一個是系統邏輯（即程序執行流程）。業務邏輯是任何系統在最終實際的業務層面所體現出的邏輯，就是“要做什么”；而系統邏輯是指系統為了滿足業務上的能力而在系統層面所體現出的邏輯，就是“該如何做”。無論是業務邏輯還是系統邏輯，它們存在的目的都是為了交付最終的價值或達到項目的目標。所以在沒有明確相關的業務邏輯和系統邏輯時，要想建立出交付價值的相關邏輯是十分復雜的。一般來說，業務邏輯是范圍所處的層面，而系統邏輯是功能需求所處的層面。
為了明確主要的構思，我們不以軟件工程項目為例來帶出相關的構思，而是以其它工程項目為例來說明這些構思。這樣做是為了讓讀者可以擺脫軟件工程中的原有思維，以一個新的角度來看待軟件項目。不知大家是否還記得，在1.2中所提到的“工匠與專家”的故事，這里我們將會以一個內部裝潢設計專家的角度來說明如何利用一個新的房間為例，帶出四部開發方法的主要構思。
假設我們要利用一個空房間，使用的目的可能是作為辦公室、會議室、書房或者其他的用途。那么在決定了這個最終目的后，便需要決定房間中所需的家具和布置，房間可以是空房間、也可以是有些家具的房間。
所以，在知道最終用途后，我們（扮演了裝潢設計師）才會明確有哪些家具，這些家具便是交付物的定義。也許我們明確知道需要一張桌子，不管是從家具店購買、還是找工匠打做，我們一定要依據最終交付物定義來思考。更明確的說，知道一張桌子使用的最終目的，是用來放置計算機、放置一個咖啡器、用來書寫、或者是用來開會還是裝飾，更甚者是可以放置計算機、可以辦公、可以放置一個咖啡器的辦公桌。其中一樣或多樣都可以是說明需要一張桌子的最終目的。這是我們在理解了這些最終目的后在價值層面思考后獲得的最終交付物說明，這些最終目的構成了說明交付物的依據。而思考的方法就是PCDM。
最終的目的已經構成最終交付物的主要構思，加上應用的地域和環境，將會直接影響最終交付物的外觀和大小。例如，試想我們為一個僅有15平米的辦公室，進行裝修布局。客戶明確指出了，在該辦公室中可以有3個經理辦公、同時可以滿足某一經理愛喝咖啡的習慣、還需滿足另外一個經理需要經常與其他員工在辦公室見面和會談的工作要求。那么，這些目的和應用的環境（15平米）將會影響到交付物（辦公桌子和椅子）的外觀。
有了需要一張桌子的最終目的和建立的交付物定義，接下來我們要考慮的便是這件交付物的外觀（Appearance），是圓的、方的、長方形的、橢圓形的、折合型的，需要抽屜的，需要附加柜的（如放置咖啡器），桌腿是三叉腳的、四角的，是需要兩邊豎立或交叉對立支撐的（如需要經常面見員工）。這些外觀的設計直接影響交付物的外表。另外，考慮外觀的時候需要考慮拜訪的應用環境（如15平米），桌子是放在中央還是角落、或是平常依附角落用的時候放到中央。這些也會影響交付物的外觀。該階段我們可以稱為交付物的外觀階段，如一張桌子到底是什么樣的。
當明確了最終目的和外觀后，最后進入建造或采購過程的時候才考慮所采用的組合技術和材料，包括桌子的組合是透過釘子、螺絲結合或是焊接。這些技術的應用將會影響交付物的質量和投資成本。而不同的技術仍然可以打造同樣的結果，如釘子組合或螺絲結合（當然是木螺絲）都可以組合不同的交付組件。該階段也被稱為建造階段（Construct），而該階段的成功歸功于前期交付物和交付物的外觀獲得客戶的認可，這樣在建造過程中將會把客戶的需求變更降到最低，甚至消失。
當然，我們需要把交付物（如桌子）與實際的應用環境（如15平米的經理辦公室）相結合，看看是否能夠演繹出預期的最終目的，如是否滿足了某一經理及需要擺置電腦又需要擺置咖啡器的目的。該階段稱為演繹（Demonstrate）階段，它可以讓交付物與環境結合成一個完整的驗收過程。環境包括應用的部門、人員、培訓、硬件配置等。
四步創新軟件開發
四步開發方法的主要構思是：在我們失去了業務操作流程的時候，我們可以從項目的價值或目標來考慮和確定出項目的交付物定義；同時我們可以利用這些交付物定義來建立每個交付組件所對應的業務操作流程，通過業務操作流程帶出每個交付組件的數據定義和界面定義；最終，根據這些數據定義和業務操作流程我們可以將構建交付物的任務劃分為多個子任務來完成；當我們將所有的交付組件建造完后，可以將實際構建成的交付組件應用到客戶所需的業務之中，帶出在項目初期確立的目標或價值。
四步軟件開發方法共分為四個階段，它們分別是：
1) 第一階段稱為目的階段，它開始于項目贊助人給出項目說明，結束于交付物定義。在該階段中，我們通過使用PCDM構建出項目的交付物定義和最終目的。該階段需要相關受益人的確認，包括項目贊助人和項目干系人。
2) 第二階段稱為外觀階段，它開始于交付物定義，結束于交付物的外觀建立完成。該階段的產物包括，業務流程定義、數據定義、界面定義；同時數據定義和界面定義構成交付物的外觀。這里需要使用的方法是系統操作規范（SOP）。該階段需要項目贊助人認可和確認交付物的業務流程。 [NextPage]
3) 第三階段稱為構建階段，它開始于數據定義和界面定義，結束于最終解決方案的生成；這里解決方案是指實際的、有相關技術方案構成的最終交付的系統。這里最終的解決系統需要項目贊助人的測試和確認。該階段的主要任務是編程和測試，同時我們不準備強制任何方法和技術標準，這里可以自由地選擇適當的技術標準來構建最終的解決方案。
4) 第四階段稱為演示階段，該階段將最終的解決方案放置到相應的環境中進行組合，來產生最終的效益。這里我們需要明確每個解決方案的環境組合，包括系統配置、用戶培訓、用戶測試。
四步創新軟件開發的生命周期包括四個主要階段：目的階段，外觀階段，構建階段，和最后的演示階段。與傳統的軟件開發模式相比較，四步創新軟件開發的每一個階段都可以培養有關的專業人員，目的階段可以培養優秀的業務和系統分析人員，外觀階段可以培養業務流程改做和軟件設計人才，構建階段讓技術人員盡情發揮本身的技術知識和應用能力，演示階段培養優秀的綜合性軟件工業人才。這些都是我們目前大部份企業所希望做到但沒有辦法做到的最終成果。
第一步：目標階段
任何項目在起動的第一時間必須明確項目的范圍，才能夠控制開發過程中的范圍變動。在今天的信息化時代，要為未來的運營模式成立前建立工程的范圍是相當困難的任務，我們過去采取逃避的方式，不去嘗試建立項目范圍，把精力虛耗在把握客戶需求（業務邏輯）上，同時把客戶需求作為功能需求（系統邏輯）來處理，所以我們一直沒有一套高效的辦法為客戶構建所需的系統，滿足客戶投資的最終目的。
我設計的項目組件分拆發（Project Component Decombbbbbbbb bbbbbb, PCDM）是一套建立信息化系統工程范圍的手段（詳情請參閱“項目組件分拆法PCDM”一文），可以在相對較短的時間聯同業主即主要項目干系人共同分析項目的最終交付需求，從交付需求中整理出業務邏輯和系統邏輯。
第二步：外觀階段
也許這個階段以“內觀”代替外觀比較貼切，但實際上這個階段的工作保護兩個主要目的，一是讓客戶認同未來交付的成果，二是建立系統的規格。
外觀階段主要是對未來需要交付的系統執行操作規劃（System Operation Planning, SOP）,建立未來的業務邏輯和系統邏輯，同時依據業務邏輯建立系統的數據流，利用系統邏輯建立用戶界面。讓客戶認同未來系統的操作流程，明確過程中的各種界面設計和內容，構建了工程核心的業務邏輯和創建了系統的核心價值，減低開發過程中的返工需求。這個階段的主要交付包括未來的業務定義，數據定義和界面定義三部分。
交付組件為什么可以明確業務流程
PCDM的交付組件是如何限定每個組件內的業務流程或業務邏輯呢！這是因為：
1) 每個交付組件都是在獨立的價值層面上來進行定義的，它們僅僅圍繞價值的交付來進行建立相關的交付組件。每個組件最多說明到通過做什么來生成價值，而不涉及業務邏輯和系統邏輯。
2) 每個交付組件都會明確從那些方面來生成相應的結果或效果，這樣可以在獨立的價值層面上從不同方面來確保最終的系統可以交付所期盼的價值。而如何做和做什么是交付價值的邏輯與系統和業務邏輯相互分離。
3) 這樣每個組件通過價值層面的邏輯來指出通過哪些相關的工作內容來交付價值，同時這些工作內容是價值層面的描述。當我們為每個交付組件建立相關的業務流程時，我們根據業務環境所選擇的業務邏輯在價值層面上的映射必須與交付組件的內容一致，使得業務邏輯可以完全符合價值層面的要求來交付相關的價值，否則我們很難控制每個價值的交付過程或業務流程。
四步開發方法在PCDM交付物定義的引導下，使得我們構建項目的業務操作流程的時間和精力將會被縮短、質量將會被提高。
交付組件與業務模塊
交付組件就是一種業務模塊，所以它可以獲得所有業務模塊的優點。但是，它與業務模塊還是有一些本質區別的。
1) 交付組件是在價值層面對交付組件進行描述，與具體的業務流程或業務邏輯基本分離，不受到具體的業務流程影響。
2) 交付組件可以是交付物定義的組件，同時也可以是由方案所直接轉變而成的交付成果或組件。同時每個交付組件可以包含一個或多個業務模塊。
3) 交付組件主要是針對價值而言的，么個交付組件都通過它自身所描述的工作內容來對交付價值，或通過不同方面的效果或成果使得最終的某一交付物可以生成最終價值的描述。而業務模塊主要是為了業務層面的維護、復用和解耦，在一個項目中業務模塊可能很難明確的在價值層面被描述出來。這是因為它所貢獻的效果可能針對的是另一個價值。
4) 交付組件是通過PCDM方法來確立的。而業務模塊基本上是根據在交付組件內的業務邏輯進行的解耦獲得的，它更加利于復用其它價值層面。
5) 交付組件是與效益或價值同時擴充和維護的，而業務模塊是被包含在交付組件內變更的。
6) 交付組件可以說成是價值層面的邏輯，而業務模塊是業務層面的邏輯。
業務定義
業務定義中所指明的系統模塊是從業務角度來看待的，是PCDM的交付物定義中所包括的內容，它與具體的技術使用無關；如API的調用序列。而且它也不是編程語言中所指的模塊，如像JAVA中提供的包或組件等。同時它也不完全等價于PCDM中所建立的交付組件；一個交付組件可以是一個業務模塊，同時也可以是一個和多個業務模塊的組合。在進行業務層面的系統模塊說明前，我們還是明確一下業務流程在開發體系中的一些本質作用，這樣我們就可以較為清楚地理解業務層面的系統模塊這一概念。
回顧在PCDM中所描述的案例，我們的最終交付物在下圖中描述有關的業務模塊（交付組件）和數據組合（數據組）。
每個交付組件可以是一種業務模塊，它指明了該模塊內應當完成那些任務來帶出客戶期盼的價值。但是交付組件并不是從業務層面思考獲得的，而是從價值層面構成的定義；而這個定義卻指明了業務層面應當完成的任務。可能一個交付組件要包括一個或多個業務模塊的組合（這依賴于定義業務模塊的方法）。實際上每個業務模塊仍然可以明確地存在于價值層面上，對于任何不同項目價值層面可能會有所不同，會出現一個交付組件包含多個業務模塊的現象。由于業務模塊的本身特性和價值層面描述具有同一性的交付組件，使得我們構建的業務流程必然對應了相關的系統接口或組合。所以在制定操作流程時，我們仍然需要考慮到價值層面，即每個業務點不是單純從客戶使用角度建立，更應當將從業務角度來考慮每個業務點中如何來貢獻出項目的價值。[NextPage]
由于每個業務點的制定都考慮到了價值的貢獻，所以一個或多個業務點的輸入和輸出所構成的業務模塊與實際的系統接口調用組合都是用來產生相應價值的，它們之間構成了明確的對應關系。
交付物定義明確指明了每個業務流程上的工作內容，使得交付物所對應的目標可以細化到業務層面，這樣我們可以知道流程中的業務邏輯與項目價值的對應關系。這就是我們建立業務流程的主要目的：通過交付物定義來明確在交付物內的業務邏輯與價值之間的對應關系，可以幫助我們分離不同價值的業務邏輯，從而使得該交付組件或所對應的業務模塊具有高內聚低耦合性。同時這些業務模塊可以由相應的系統接口構成，而且這些系統接口的定義和實現完全可以依照不同的技術標準來制定。而這些業務模塊要么是交付組件，要么一同構成了交付組件。
由于業務模塊的特性，使得業務邏輯和系統邏輯相互分離，同時確保它們是一致的。這樣對于每個業務流程所帶出的相關數據，我們可以通過業務模塊來制定出明確數據定義，這些數據定義將會成為我們構建系統模塊（或接口）和系統架構的基礎。
我們可以通過“業務操作流程、數據定義、界面定義”來代替“需求調研、需求分析和系統設計”。雖然，我們還需詳細的論述數據定義后才可以下該結論，但是在這里我們基本上明確了交付物可以通過系統操作流程帶出的輸入和輸出制定出數據定義，這些數據定義構成了制定系統模塊的基礎。
業務定義：操作流程
為了使得業務操作流程的制定能夠明確的表明，我們需要制定一些基本的限定：
·每個業務操作流程必須指明一個開始點和完結點。
·每個開始點和完結點，以時間、地點或時間的狀態作為標注。
·每個操作流程都會擁有一個或多個業務點。
·每個業務點必須有明確的輸入或輸出，或者是二者兼有。
·每個業務點必須從業務層面指明一個活動或操作，且只有一個。
·每個業務點的輸入和輸出的數據屬于業務層面的數據，但不一定不設計技術的信息。例如，記錄客戶信息中的客戶號，有可能是一個技術信息，但是它是在業務層面的表達，所以不會涉及到技術的具體運用，如不會指明該客戶號可能是一個哈希編碼等等。
·每個操作流程必須有明確的目標，同時這些目標要么是交付的價值，也就是對于交付組件所對應的價值在價值層面做出相關貢獻。
·每個業務點必須是自包含的、限定的，否則任何軟件也無法實現一個非限定性的業務流程，即該業務流程是“不可計算的”。
有了業務操作流程的精確定義，我們就可以為每個交付物的外觀做出精確定義。
數據定義
對于系統操作流程中的每個輸入或輸出，都會成為我們制定數據定義的基礎。這些輸入和輸出會構成相關業務模塊和系統接口的基礎。
在建立初步系統邏輯和業務邏輯抽，我們可以劃分出業務模塊，實際上一個交付組件（或方案所對應的組件）就是一個很好的業務模塊。但是，由于不同價值層面的原因，在某一層面的交付組件有可能包含了明確的另外層面的多個交付組件。所以，我們需要將交付組件劃分為更加明確的業務模塊，而劃分的規則就是在業務層面的高內聚和低耦合；即根據每個業務模塊所對應的業務流程的輸入和輸出制定業務模塊。
根據輸入和輸出建立該業務模塊的數據定義，最終需要整合所有的數據定義成為系統的數據架構或數據定義。一般來說會有兩種方法，面向過程和面向對象。面向過程可以分別建立業務模塊和數據架構，而面向對象需要一同建立領域模型（業務層面的類模型）和動態模型（對象狀態轉移圖），同時領域模型一般來講是數據架構，而非業務模塊；因為，如果以對象來標志業務模塊的話，可能很難明確該模塊所對應的業務目標，那么這種模塊會喪失業務內聚性。另外，需要說明的是數據架構可以根據要使用的技術標準直接建立到系統層面，也可以僅僅建立業務層面的數據架構，這完全依賴于我們使用的技術標準。
最終我們需要利用數據架構建立業務模塊的架構，以使得業務模塊的架構可以與最終的包含在每個模塊內系統模塊或接口的架構相互對稱。數據定義模型包含了業務模塊、數據架構和業務模塊的總體架構。而業務模塊的總體架構僅僅是通過完善交付組件之間的關聯（數據耦合）來完成的。
界面定義
業務流程與交付物外觀”代替“需求與設計。可能細心的讀者會問，怎么在四步方法中沒有需求和設計這兩個活動了呢？是的，在構建四步開發方法時確實將這兩個活動從四步方法中移除了，我們是通過“業務流程與交付物外觀”來代替“需求與設計”的。通過交付組件我們可以明確指出工作內容，同時可以使得業務邏輯和系統邏輯在交付組件上相互對應（或業務模塊），這里的交付組件可以是交付物定義，也可以是方案所對應的一個個單一的組件。 [NextPage]
1) 我們可以獨立地建立該交付組件的業務邏輯，這將帶出明確的數據定義，同時也會帶出相關的業務模塊（如果交付組件內還可以分解出更明確的業務模塊）。
2) 由于業務模塊和交付組件的原因，我們可以等價地利用交付組件或業務模塊來建立出系統在業務層面所對應的架構；同時每個組件內都可以對應明確的系統接口或模塊。
3) 最終我們可以利用業務模塊的架構來等價地建立出系統的架構，同時并不影響每個模塊內系統邏輯的制定。
對于功能需求，我們利用業務模塊將其屏蔽和限定在一個個的交付組件或業務模塊內，使得我們根本不需要從系統角度來建立在項目初期根本就不存在的需求。實際上，客戶一直不知道他自己的需求（功能需求），否則客戶為什么在70%的失敗率下還是要依靠我們來建立功能需求呢！
第三步：構建階段
構建階段的設立是為了使得技術人員可以更加自由地發揮他們的技術特長，從而構建的交付物不僅可以帶出價值，而且是高質量、易維護應用軟件。我們不準備詳細的討論每個技術規范和強制約束該使用那些技術規范，因為我們既不想加入到曠日已久的技術大戰中，也不想再為“名詞百出”的IT界增加新的辭藻。
技術標準選擇
技術標準的選擇是跟客戶是無關的，而且大部份客戶也不太理會。客戶的主要目的是依賴技術人員的專長來為他搭建所需的應用系統，所以技術的應用完全可以由開分人員來進行選擇。但是需要一個系統架構師來確認這個項目的統一技術標準，否則交付物將會因為技術標準的錯誤選擇而失敗。
這里我們僅僅說明交付物和操作流程是如何隔離不同技術方案的。這是因為：
·對于與交付物對應的系統操作流程反映了出了業務的邏輯，同時我們有從業務角度建立出了業務的模塊，使得每個業務模塊之間的耦合度降到最低。
·由于業務模塊（數據定義的一部分）不依賴于具體技術的實現，所以我們可以非常自由地為每個業務模塊賦予不同的技術方案，只要它們之間是相互一致的。
·由于業務模塊隔離了系統邏輯，使得每個業務模塊的邏輯不會受到系統邏輯的變更影響，所以被包含在不同業務模塊的技術方案之間不會被相互影響；對于整個系統架構而言，即使添加或拆除一個業務模塊，也僅僅是增加和取消系統接口的調用，使得整個系統便于維護。
·我們在定義了統一的技術標準規范后，獨立地定義每個業務模塊的系統接口調用和實現。
這里可以引入的技術標準可以包括如SOA、UML、BPEL等。同時也可以使用一些較早的技術標準，如面向過程的編程等等。因為所有的軟件項目都不可能完全以一個技術標準來實現，如嵌入式系統完全可以涉及到更加接近底層的匯編語言。
接口定義
在統一了技術標準規范后便需要獨立地定義每個接口的實現方法。接口定義不同于模塊的建立，如面向對象中的一個對象可以是一個模塊，而么個對象中的方法是一個接口。接口說明了在某一模塊中引入另一個模塊的目的和作用，也就是規定了模塊之間的耦合。
系統中的每個接口，是依據業務模塊和數據關系表來建立的。每個業務模塊說明了系統接口是如何被相互調用而組成業務模塊的。如“顯示報名信息”是一個業務模塊的話，從對象角度可能需要定義出兩個對象，“Booking”和“Booking Layout”兩個對象來分別完成“維護報名信息”和“報名信息屏幕布局”兩個任務。注意，在該案例中我們沒有說明具體的API是如何調用的。
所以，這里我們需要進一步強調業務模塊的制定不要設計任何技術的信息，甚至定義某個對象的接口，不要忘記一個對象的接口有可能涉及系統的邏輯，而是的我們在選擇技術標準時進入一個兩難的境地。
編寫測試
在選擇每個系統模塊或接口的實現方法前，最好根據技術標準和業務模塊的定義制定出系統模塊的測試文檔和整個系統的測試文檔。這對于任何技術標準都是需要的，這樣我們不僅可以有根據的檢驗每個接口的實現，同時我們可以根據則是文檔的制定讓程序員更加明確每個程序實現的約束。
編程規范制定
無論哪種技術標準都會議自身的角度來強調編程的規范，試圖從公眾的角度加以限定幾乎是不可能的。所以，這里我們僅僅說明編程中必須注意的事項，而與具體的技術規范無關。
1. 使用一致的和有意義的變量名；這幾乎是所有糾錯性維護的根源。才將任務試圖根據業務模塊或交付組件來分給不同的技術小組時，一定要制定一致的變量名和數據庫的調用規范；如不要試圖對同一個數據庫中的表使用多個索引。
2. 代碼注釋規范。如果問維護中最大的難點是什么，無疑是對代碼的理解，即使對于面向對象的程序而言，在沒有代碼時試圖讀懂程序也會是一個噩夢。
3. 使用參數。實際上，程序中數據大部分以變量形式出現，否則我們不必在這如此費神。這里的參數是指將一個常量也綁定到某一變量中來。至于是否有相關的語言可以幫助我們實現，我想現在不用我們指出，即使不太精通編程的非專業人員都會指出一兩種來。
4. 代買編排版式需要統一，這會大大增加可讀性。現在有大量的CASE工具來幫助我們實現。
5. 不要將嵌套的IF語句超過3個，雖然這不是必須的規定，但是它已經在業界獲得一致的認可。
6. 對于任何API而言，在小組試圖開發前需要明確相關API至少是在程序中使用的API的正確調用順序。好像這點并不需要強調，只要你登錄UCLA的網站，你就可以找到關于API構成BUG的相關數據挖掘的解決方案，那時你會知道這種錯誤的出現不僅是致命的，而且是十分普遍的。
最后我們沒有明確指明如何進行測試的原因是不同技術規范有不同的測試需求和技巧。
第四步：演示階段
在演示階段主要是通過將交付物與具體的應用環境相結合來帶出客戶所期盼的價值，從而使得項目可以得到驗收。演示階段主要有三個過程：
1) 系統配置：即安裝報告，明確指明系統的環境參數如何設置（如MySQL的安裝信息），指明如何配置相關的系統參數（如設置路徑變量等）。這部分也可以有系統維護人員來協助客戶一同完成。
2) 用戶培訓：由于新的系統的引入，我們還需要按照系統操作規范和交付系統的特征來撰寫培訓計劃和流程，以使得客戶可以明確如何使用和操控系統。
3) 用戶測試：當然最終需要客戶按照項目交付物定義和操作流程來驗收整個系統是否可以帶出我們在項目初期所一同建立的價值。這部分的測試文檔有客戶自己制定。
四步創新軟件開發的作用
任何開發方法都有其相應的作用，四步創新軟件開發方法也不例外；它的作用是：
1) 可以有效的隔離業務邏輯和系統邏輯，使得他們可以單獨的處理；充分發揮了技術人員的技術特長。
2) 具有高度的可維護性，使得我們可以根據客戶提出的維護需求，僅僅修改和擴充相關的交付組件而已，不會影響其他組件的內部結構。
3) 業務與技術可以單獨地變更；也就是技術的變更不會影響業務的邏輯。
4) 可以有效的融合其他技術標準，使得四步創新軟件開發方法應用更加廣泛。
在構建程序上，賦予了構建過程的靈活性，使得程序員可以僅僅考慮給予他們的任務；這樣，加大了程序員的工作效率；最終將會減少開發的時間、減少資源的運用。
實際上，上述的論述過程也反映了自動化時代項目制定功能需求的一面，但不是全部。因為自動化時代僅僅描述了功能需求，但是還需要系統架構來劃分模塊來完成所有的功能需求。該過程更加適應于信息化時代；這也是為什么引入業務模塊的一個根本的原因。雖然，該論述沒有引入數據流與業務流的精確一一對應關系，但是它足以說明系統與業務存在著某種對應關系，使得我們可以從業務角度靈活地部署整個系統。
下次我會把最后如何有效地對四步創新軟件開發項目進行項目管理的方法與大家分享，
作者：黃紹良教授 研究員王柏亮
40年前計算機開始進入商業用途之初期，沒有任何開發體系可以應用，所以從業人員在表格上整理邏輯，編寫程序，測試及對程序進行Debugging，然后移交，今天從業人員在腦中開展系統的邏輯，進行程序編寫，過去的Debug變成今天的Fix（修改），成為邊想，邊做，邊改的三邊模式來進行軟件開發。30年前軟件的主要應用目的是運營自動化，提升企業部門的執行效率，今天大部份從業人員還是以自動化為軟件開發的主要目標。軟件工程失敗的主要原因不是技術應用的問題，是從業人員未能把握客戶思維，交付客戶期盼的交付物，導致項目在開發過程中不斷修改和返工，為項目帶來延誤和超支。
往往我們把客戶的期盼當作系統的功能需求，這是一個錯誤的觀念。要知道客戶的期盼（我們口中所說的客戶需求）是要做什么，這是客戶投資的最終目標。但系統或功能需求卻是該如何做，是技術應用的手段。知道“要做什么”，才知道“該如何做”。我們未能把握客戶的期盼（要做什么），如何能夠提供高效的技術手段來達到目的呢！所謂“條條大道通羅馬”，只要知道了目標，我們有很多選擇采用不同的手段來達到。過去的問題在于我們把目標當成手段來處理，一步一摸索，在過程中不斷開路搭橋，縱然最終能夠抵達目的地，但這種執行模式能不浪費時間，精力和金錢嗎！
今天的軟件工程的終極要求與過去數十年軟件工程的終極要求有很大的差異。過去自動化時代的軟件工程主要是技術的應用，提升運營效率，以技術的應用方法為項目的最終目標。今天的信息化軟件工程必須考慮和提供業主希望獲得的投資價值，著重于科技如何能夠帶出相對的投資價值和運營效益為目的。可惜我們還是利用過去數十年前的技術開發思維和應用方法來進行項目交付，未能有效地面對項目屬性和交付目的的轉變做出相應的調整。讓項目中大部份的工作量停留在編程，測試，修改和返工上。我們采用過時的方法，落后的思維來面對今天軟件工程的挑戰，如何能夠在軟件工程方面帶出創新，引領未來呢？
計算機是邏輯學
“四步創新軟件開發”的要旨在于擺脫過去軟件工程對需求的重視。從邏輯的思維去實現最終目標。軟件工程項目多基于規范性的邏輯應用，任何軟件工程項目的最終交付都必須包含兩個部分，一個是業務邏輯（即業務應用流程）、另一個是系統邏輯（即程序執行流程）。業務邏輯是任何系統在最終實際的業務層面所體現出的邏輯，就是“要做什么”；而系統邏輯是指系統為了滿足業務上的能力而在系統層面所體現出的邏輯，就是“該如何做”。無論是業務邏輯還是系統邏輯，它們存在的目的都是為了交付最終的價值或達到項目的目標。所以在沒有明確相關的業務邏輯和系統邏輯時，要想建立出交付價值的相關邏輯是十分復雜的。一般來說，業務邏輯是范圍所處的層面，而系統邏輯是功能需求所處的層面。
為了明確主要的構思，我們不以軟件工程項目為例來帶出相關的構思，而是以其它工程項目為例來說明這些構思。這樣做是為了讓讀者可以擺脫軟件工程中的原有思維，以一個新的角度來看待軟件項目。不知大家是否還記得，在1.2中所提到的“工匠與專家”的故事，這里我們將會以一個內部裝潢設計專家的角度來說明如何利用一個新的房間為例，帶出四部開發方法的主要構思。
假設我們要利用一個空房間，使用的目的可能是作為辦公室、會議室、書房或者其他的用途。那么在決定了這個最終目的后，便需要決定房間中所需的家具和布置，房間可以是空房間、也可以是有些家具的房間。
所以，在知道最終用途后，我們（扮演了裝潢設計師）才會明確有哪些家具，這些家具便是交付物的定義。也許我們明確知道需要一張桌子，不管是從家具店購買、還是找工匠打做，我們一定要依據最終交付物定義來思考。更明確的說，知道一張桌子使用的最終目的，是用來放置計算機、放置一個咖啡器、用來書寫、或者是用來開會還是裝飾，更甚者是可以放置計算機、可以辦公、可以放置一個咖啡器的辦公桌。其中一樣或多樣都可以是說明需要一張桌子的最終目的。這是我們在理解了這些最終目的后在價值層面思考后獲得的最終交付物說明，這些最終目的構成了說明交付物的依據。而思考的方法就是PCDM。
最終的目的已經構成最終交付物的主要構思，加上應用的地域和環境，將會直接影響最終交付物的外觀和大小。例如，試想我們為一個僅有15平米的辦公室，進行裝修布局。客戶明確指出了，在該辦公室中可以有3個經理辦公、同時可以滿足某一經理愛喝咖啡的習慣、還需滿足另外一個經理需要經常與其他員工在辦公室見面和會談的工作要求。那么，這些目的和應用的環境（15平米）將會影響到交付物（辦公桌子和椅子）的外觀。
有了需要一張桌子的最終目的和建立的交付物定義，接下來我們要考慮的便是這件交付物的外觀（Appearance），是圓的、方的、長方形的、橢圓形的、折合型的，需要抽屜的，需要附加柜的（如放置咖啡器），桌腿是三叉腳的、四角的，是需要兩邊豎立或交叉對立支撐的（如需要經常面見員工）。這些外觀的設計直接影響交付物的外表。另外，考慮外觀的時候需要考慮拜訪的應用環境（如15平米），桌子是放在中央還是角落、或是平常依附角落用的時候放到中央。這些也會影響交付物的外觀。該階段我們可以稱為交付物的外觀階段，如一張桌子到底是什么樣的。
當明確了最終目的和外觀后，最后進入建造或采購過程的時候才考慮所采用的組合技術和材料，包括桌子的組合是透過釘子、螺絲結合或是焊接。這些技術的應用將會影響交付物的質量和投資成本。而不同的技術仍然可以打造同樣的結果，如釘子組合或螺絲結合（當然是木螺絲）都可以組合不同的交付組件。該階段也被稱為建造階段（Construct），而該階段的成功歸功于前期交付物和交付物的外觀獲得客戶的認可，這樣在建造過程中將會把客戶的需求變更降到最低，甚至消失。
當然，我們需要把交付物（如桌子）與實際的應用環境（如15平米的經理辦公室）相結合，看看是否能夠演繹出預期的最終目的，如是否滿足了某一經理及需要擺置電腦又需要擺置咖啡器的目的。該階段稱為演繹（Demonstrate）階段，它可以讓交付物與環境結合成一個完整的驗收過程。環境包括應用的部門、人員、培訓、硬件配置等。
四步創新軟件開發
四步開發方法的主要構思是：在我們失去了業務操作流程的時候，我們可以從項目的價值或目標來考慮和確定出項目的交付物定義；同時我們可以利用這些交付物定義來建立每個交付組件所對應的業務操作流程，通過業務操作流程帶出每個交付組件的數據定義和界面定義；最終，根據這些數據定義和業務操作流程我們可以將構建交付物的任務劃分為多個子任務來完成；當我們將所有的交付組件建造完后，可以將實際構建成的交付組件應用到客戶所需的業務之中，帶出在項目初期確立的目標或價值。
四步軟件開發方法共分為四個階段，它們分別是：
1) 第一階段稱為目的階段，它開始于項目贊助人給出項目說明，結束于交付物定義。在該階段中，我們通過使用PCDM構建出項目的交付物定義和最終目的。該階段需要相關受益人的確認，包括項目贊助人和項目干系人。
2) 第二階段稱為外觀階段，它開始于交付物定義，結束于交付物的外觀建立完成。該階段的產物包括，業務流程定義、數據定義、界面定義；同時數據定義和界面定義構成交付物的外觀。這里需要使用的方法是系統操作規范（SOP）。該階段需要項目贊助人認可和確認交付物的業務流程。 [NextPage]
3) 第三階段稱為構建階段，它開始于數據定義和界面定義，結束于最終解決方案的生成；這里解決方案是指實際的、有相關技術方案構成的最終交付的系統。這里最終的解決系統需要項目贊助人的測試和確認。該階段的主要任務是編程和測試，同時我們不準備強制任何方法和技術標準，這里可以自由地選擇適當的技術標準來構建最終的解決方案。
4) 第四階段稱為演示階段，該階段將最終的解決方案放置到相應的環境中進行組合，來產生最終的效益。這里我們需要明確每個解決方案的環境組合，包括系統配置、用戶培訓、用戶測試。
四步創新軟件開發的生命周期包括四個主要階段：目的階段，外觀階段，構建階段，和最后的演示階段。與傳統的軟件開發模式相比較，四步創新軟件開發的每一個階段都可以培養有關的專業人員，目的階段可以培養優秀的業務和系統分析人員，外觀階段可以培養業務流程改做和軟件設計人才，構建階段讓技術人員盡情發揮本身的技術知識和應用能力，演示階段培養優秀的綜合性軟件工業人才。這些都是我們目前大部份企業所希望做到但沒有辦法做到的最終成果。
第一步：目標階段
任何項目在起動的第一時間必須明確項目的范圍，才能夠控制開發過程中的范圍變動。在今天的信息化時代，要為未來的運營模式成立前建立工程的范圍是相當困難的任務，我們過去采取逃避的方式，不去嘗試建立項目范圍，把精力虛耗在把握客戶需求（業務邏輯）上，同時把客戶需求作為功能需求（系統邏輯）來處理，所以我們一直沒有一套高效的辦法為客戶構建所需的系統，滿足客戶投資的最終目的。
我設計的項目組件分拆發（Project Component Decombbbbbbbb bbbbbb, PCDM）是一套建立信息化系統工程范圍的手段（詳情請參閱“項目組件分拆法PCDM”一文），可以在相對較短的時間聯同業主即主要項目干系人共同分析項目的最終交付需求，從交付需求中整理出業務邏輯和系統邏輯。
第二步：外觀階段
也許這個階段以“內觀”代替外觀比較貼切，但實際上這個階段的工作保護兩個主要目的，一是讓客戶認同未來交付的成果，二是建立系統的規格。
外觀階段主要是對未來需要交付的系統執行操作規劃（System Operation Planning, SOP）,建立未來的業務邏輯和系統邏輯，同時依據業務邏輯建立系統的數據流，利用系統邏輯建立用戶界面。讓客戶認同未來系統的操作流程，明確過程中的各種界面設計和內容，構建了工程核心的業務邏輯和創建了系統的核心價值，減低開發過程中的返工需求。這個階段的主要交付包括未來的業務定義，數據定義和界面定義三部分。
交付組件為什么可以明確業務流程
PCDM的交付組件是如何限定每個組件內的業務流程或業務邏輯呢！這是因為：
1) 每個交付組件都是在獨立的價值層面上來進行定義的，它們僅僅圍繞價值的交付來進行建立相關的交付組件。每個組件最多說明到通過做什么來生成價值，而不涉及業務邏輯和系統邏輯。
2) 每個交付組件都會明確從那些方面來生成相應的結果或效果，這樣可以在獨立的價值層面上從不同方面來確保最終的系統可以交付所期盼的價值。而如何做和做什么是交付價值的邏輯與系統和業務邏輯相互分離。
3) 這樣每個組件通過價值層面的邏輯來指出通過哪些相關的工作內容來交付價值，同時這些工作內容是價值層面的描述。當我們為每個交付組件建立相關的業務流程時，我們根據業務環境所選擇的業務邏輯在價值層面上的映射必須與交付組件的內容一致，使得業務邏輯可以完全符合價值層面的要求來交付相關的價值，否則我們很難控制每個價值的交付過程或業務流程。
四步開發方法在PCDM交付物定義的引導下，使得我們構建項目的業務操作流程的時間和精力將會被縮短、質量將會被提高。
交付組件與業務模塊
交付組件就是一種業務模塊，所以它可以獲得所有業務模塊的優點。但是，它與業務模塊還是有一些本質區別的。
1) 交付組件是在價值層面對交付組件進行描述，與具體的業務流程或業務邏輯基本分離，不受到具體的業務流程影響。
2) 交付組件可以是交付物定義的組件，同時也可以是由方案所直接轉變而成的交付成果或組件。同時每個交付組件可以包含一個或多個業務模塊。
3) 交付組件主要是針對價值而言的，么個交付組件都通過它自身所描述的工作內容來對交付價值，或通過不同方面的效果或成果使得最終的某一交付物可以生成最終價值的描述。而業務模塊主要是為了業務層面的維護、復用和解耦，在一個項目中業務模塊可能很難明確的在價值層面被描述出來。這是因為它所貢獻的效果可能針對的是另一個價值。
4) 交付組件是通過PCDM方法來確立的。而業務模塊基本上是根據在交付組件內的業務邏輯進行的解耦獲得的，它更加利于復用其它價值層面。
5) 交付組件是與效益或價值同時擴充和維護的，而業務模塊是被包含在交付組件內變更的。
6) 交付組件可以說成是價值層面的邏輯，而業務模塊是業務層面的邏輯。
業務定義
業務定義中所指明的系統模塊是從業務角度來看待的，是PCDM的交付物定義中所包括的內容，它與具體的技術使用無關；如API的調用序列。而且它也不是編程語言中所指的模塊，如像JAVA中提供的包或組件等。同時它也不完全等價于PCDM中所建立的交付組件；一個交付組件可以是一個業務模塊，同時也可以是一個和多個業務模塊的組合。在進行業務層面的系統模塊說明前，我們還是明確一下業務流程在開發體系中的一些本質作用，這樣我們就可以較為清楚地理解業務層面的系統模塊這一概念。
回顧在PCDM中所描述的案例，我們的最終交付物在下圖中描述有關的業務模塊（交付組件）和數據組合（數據組）。
每個交付組件可以是一種業務模塊，它指明了該模塊內應當完成那些任務來帶出客戶期盼的價值。但是交付組件并不是從業務層面思考獲得的，而是從價值層面構成的定義；而這個定義卻指明了業務層面應當完成的任務。可能一個交付組件要包括一個或多個業務模塊的組合（這依賴于定義業務模塊的方法）。實際上每個業務模塊仍然可以明確地存在于價值層面上，對于任何不同項目價值層面可能會有所不同，會出現一個交付組件包含多個業務模塊的現象。由于業務模塊的本身特性和價值層面描述具有同一性的交付組件，使得我們構建的業務流程必然對應了相關的系統接口或組合。所以在制定操作流程時，我們仍然需要考慮到價值層面，即每個業務點不是單純從客戶使用角度建立，更應當將從業務角度來考慮每個業務點中如何來貢獻出項目的價值。[NextPage]
由于每個業務點的制定都考慮到了價值的貢獻，所以一個或多個業務點的輸入和輸出所構成的業務模塊與實際的系統接口調用組合都是用來產生相應價值的，它們之間構成了明確的對應關系。
交付物定義明確指明了每個業務流程上的工作內容，使得交付物所對應的目標可以細化到業務層面，這樣我們可以知道流程中的業務邏輯與項目價值的對應關系。這就是我們建立業務流程的主要目的：通過交付物定義來明確在交付物內的業務邏輯與價值之間的對應關系，可以幫助我們分離不同價值的業務邏輯，從而使得該交付組件或所對應的業務模塊具有高內聚低耦合性。同時這些業務模塊可以由相應的系統接口構成，而且這些系統接口的定義和實現完全可以依照不同的技術標準來制定。而這些業務模塊要么是交付組件，要么一同構成了交付組件。
由于業務模塊的特性，使得業務邏輯和系統邏輯相互分離，同時確保它們是一致的。這樣對于每個業務流程所帶出的相關數據，我們可以通過業務模塊來制定出明確數據定義，這些數據定義將會成為我們構建系統模塊（或接口）和系統架構的基礎。
我們可以通過“業務操作流程、數據定義、界面定義”來代替“需求調研、需求分析和系統設計”。雖然，我們還需詳細的論述數據定義后才可以下該結論，但是在這里我們基本上明確了交付物可以通過系統操作流程帶出的輸入和輸出制定出數據定義，這些數據定義構成了制定系統模塊的基礎。
業務定義：操作流程
為了使得業務操作流程的制定能夠明確的表明，我們需要制定一些基本的限定：
·每個業務操作流程必須指明一個開始點和完結點。
·每個開始點和完結點，以時間、地點或時間的狀態作為標注。
·每個操作流程都會擁有一個或多個業務點。
·每個業務點必須有明確的輸入或輸出，或者是二者兼有。
·每個業務點必須從業務層面指明一個活動或操作，且只有一個。
·每個業務點的輸入和輸出的數據屬于業務層面的數據，但不一定不設計技術的信息。例如，記錄客戶信息中的客戶號，有可能是一個技術信息，但是它是在業務層面的表達，所以不會涉及到技術的具體運用，如不會指明該客戶號可能是一個哈希編碼等等。
·每個操作流程必須有明確的目標，同時這些目標要么是交付的價值，也就是對于交付組件所對應的價值在價值層面做出相關貢獻。
·每個業務點必須是自包含的、限定的，否則任何軟件也無法實現一個非限定性的業務流程，即該業務流程是“不可計算的”。
有了業務操作流程的精確定義，我們就可以為每個交付物的外觀做出精確定義。
數據定義
對于系統操作流程中的每個輸入或輸出，都會成為我們制定數據定義的基礎。這些輸入和輸出會構成相關業務模塊和系統接口的基礎。
在建立初步系統邏輯和業務邏輯抽，我們可以劃分出業務模塊，實際上一個交付組件（或方案所對應的組件）就是一個很好的業務模塊。但是，由于不同價值層面的原因，在某一層面的交付組件有可能包含了明確的另外層面的多個交付組件。所以，我們需要將交付組件劃分為更加明確的業務模塊，而劃分的規則就是在業務層面的高內聚和低耦合；即根據每個業務模塊所對應的業務流程的輸入和輸出制定業務模塊。
根據輸入和輸出建立該業務模塊的數據定義，最終需要整合所有的數據定義成為系統的數據架構或數據定義。一般來說會有兩種方法，面向過程和面向對象。面向過程可以分別建立業務模塊和數據架構，而面向對象需要一同建立領域模型（業務層面的類模型）和動態模型（對象狀態轉移圖），同時領域模型一般來講是數據架構，而非業務模塊；因為，如果以對象來標志業務模塊的話，可能很難明確該模塊所對應的業務目標，那么這種模塊會喪失業務內聚性。另外，需要說明的是數據架構可以根據要使用的技術標準直接建立到系統層面，也可以僅僅建立業務層面的數據架構，這完全依賴于我們使用的技術標準。
最終我們需要利用數據架構建立業務模塊的架構，以使得業務模塊的架構可以與最終的包含在每個模塊內系統模塊或接口的架構相互對稱。數據定義模型包含了業務模塊、數據架構和業務模塊的總體架構。而業務模塊的總體架構僅僅是通過完善交付組件之間的關聯（數據耦合）來完成的。
界面定義
業務流程與交付物外觀”代替“需求與設計。可能細心的讀者會問，怎么在四步方法中沒有需求和設計這兩個活動了呢？是的，在構建四步開發方法時確實將這兩個活動從四步方法中移除了，我們是通過“業務流程與交付物外觀”來代替“需求與設計”的。通過交付組件我們可以明確指出工作內容，同時可以使得業務邏輯和系統邏輯在交付組件上相互對應（或業務模塊），這里的交付組件可以是交付物定義，也可以是方案所對應的一個個單一的組件。 [NextPage]
1) 我們可以獨立地建立該交付組件的業務邏輯，這將帶出明確的數據定義，同時也會帶出相關的業務模塊（如果交付組件內還可以分解出更明確的業務模塊）。
2) 由于業務模塊和交付組件的原因，我們可以等價地利用交付組件或業務模塊來建立出系統在業務層面所對應的架構；同時每個組件內都可以對應明確的系統接口或模塊。
3) 最終我們可以利用業務模塊的架構來等價地建立出系統的架構，同時并不影響每個模塊內系統邏輯的制定。
對于功能需求，我們利用業務模塊將其屏蔽和限定在一個個的交付組件或業務模塊內，使得我們根本不需要從系統角度來建立在項目初期根本就不存在的需求。實際上，客戶一直不知道他自己的需求（功能需求），否則客戶為什么在70%的失敗率下還是要依靠我們來建立功能需求呢！
第三步：構建階段
構建階段的設立是為了使得技術人員可以更加自由地發揮他們的技術特長，從而構建的交付物不僅可以帶出價值，而且是高質量、易維護應用軟件。我們不準備詳細的討論每個技術規范和強制約束該使用那些技術規范，因為我們既不想加入到曠日已久的技術大戰中，也不想再為“名詞百出”的IT界增加新的辭藻。
技術標準選擇
技術標準的選擇是跟客戶是無關的，而且大部份客戶也不太理會。客戶的主要目的是依賴技術人員的專長來為他搭建所需的應用系統，所以技術的應用完全可以由開分人員來進行選擇。但是需要一個系統架構師來確認這個項目的統一技術標準，否則交付物將會因為技術標準的錯誤選擇而失敗。
這里我們僅僅說明交付物和操作流程是如何隔離不同技術方案的。這是因為：
·對于與交付物對應的系統操作流程反映了出了業務的邏輯，同時我們有從業務角度建立出了業務的模塊，使得每個業務模塊之間的耦合度降到最低。
·由于業務模塊（數據定義的一部分）不依賴于具體技術的實現，所以我們可以非常自由地為每個業務模塊賦予不同的技術方案，只要它們之間是相互一致的。
·由于業務模塊隔離了系統邏輯，使得每個業務模塊的邏輯不會受到系統邏輯的變更影響，所以被包含在不同業務模塊的技術方案之間不會被相互影響；對于整個系統架構而言，即使添加或拆除一個業務模塊，也僅僅是增加和取消系統接口的調用，使得整個系統便于維護。
·我們在定義了統一的技術標準規范后，獨立地定義每個業務模塊的系統接口調用和實現。
這里可以引入的技術標準可以包括如SOA、UML、BPEL等。同時也可以使用一些較早的技術標準，如面向過程的編程等等。因為所有的軟件項目都不可能完全以一個技術標準來實現，如嵌入式系統完全可以涉及到更加接近底層的匯編語言。
接口定義
在統一了技術標準規范后便需要獨立地定義每個接口的實現方法。接口定義不同于模塊的建立，如面向對象中的一個對象可以是一個模塊，而么個對象中的方法是一個接口。接口說明了在某一模塊中引入另一個模塊的目的和作用，也就是規定了模塊之間的耦合。
系統中的每個接口，是依據業務模塊和數據關系表來建立的。每個業務模塊說明了系統接口是如何被相互調用而組成業務模塊的。如“顯示報名信息”是一個業務模塊的話，從對象角度可能需要定義出兩個對象，“Booking”和“Booking Layout”兩個對象來分別完成“維護報名信息”和“報名信息屏幕布局”兩個任務。注意，在該案例中我們沒有說明具體的API是如何調用的。
所以，這里我們需要進一步強調業務模塊的制定不要設計任何技術的信息，甚至定義某個對象的接口，不要忘記一個對象的接口有可能涉及系統的邏輯，而是的我們在選擇技術標準時進入一個兩難的境地。
編寫測試
在選擇每個系統模塊或接口的實現方法前，最好根據技術標準和業務模塊的定義制定出系統模塊的測試文檔和整個系統的測試文檔。這對于任何技術標準都是需要的，這樣我們不僅可以有根據的檢驗每個接口的實現，同時我們可以根據則是文檔的制定讓程序員更加明確每個程序實現的約束。
編程規范制定
無論哪種技術標準都會議自身的角度來強調編程的規范，試圖從公眾的角度加以限定幾乎是不可能的。所以，這里我們僅僅說明編程中必須注意的事項，而與具體的技術規范無關。
1. 使用一致的和有意義的變量名；這幾乎是所有糾錯性維護的根源。才將任務試圖根據業務模塊或交付組件來分給不同的技術小組時，一定要制定一致的變量名和數據庫的調用規范；如不要試圖對同一個數據庫中的表使用多個索引。
2. 代碼注釋規范。如果問維護中最大的難點是什么，無疑是對代碼的理解，即使對于面向對象的程序而言，在沒有代碼時試圖讀懂程序也會是一個噩夢。
3. 使用參數。實際上，程序中數據大部分以變量形式出現，否則我們不必在這如此費神。這里的參數是指將一個常量也綁定到某一變量中來。至于是否有相關的語言可以幫助我們實現，我想現在不用我們指出，即使不太精通編程的非專業人員都會指出一兩種來。
4. 代買編排版式需要統一，這會大大增加可讀性。現在有大量的CASE工具來幫助我們實現。
5. 不要將嵌套的IF語句超過3個，雖然這不是必須的規定，但是它已經在業界獲得一致的認可。
6. 對于任何API而言，在小組試圖開發前需要明確相關API至少是在程序中使用的API的正確調用順序。好像這點并不需要強調，只要你登錄UCLA的網站，你就可以找到關于API構成BUG的相關數據挖掘的解決方案，那時你會知道這種錯誤的出現不僅是致命的，而且是十分普遍的。
最后我們沒有明確指明如何進行測試的原因是不同技術規范有不同的測試需求和技巧。
第四步：演示階段
在演示階段主要是通過將交付物與具體的應用環境相結合來帶出客戶所期盼的價值，從而使得項目可以得到驗收。演示階段主要有三個過程：
1) 系統配置：即安裝報告，明確指明系統的環境參數如何設置（如MySQL的安裝信息），指明如何配置相關的系統參數（如設置路徑變量等）。這部分也可以有系統維護人員來協助客戶一同完成。
2) 用戶培訓：由于新的系統的引入，我們還需要按照系統操作規范和交付系統的特征來撰寫培訓計劃和流程，以使得客戶可以明確如何使用和操控系統。
3) 用戶測試：當然最終需要客戶按照項目交付物定義和操作流程來驗收整個系統是否可以帶出我們在項目初期所一同建立的價值。這部分的測試文檔有客戶自己制定。
四步創新軟件開發的作用
任何開發方法都有其相應的作用，四步創新軟件開發方法也不例外；它的作用是：
1) 可以有效的隔離業務邏輯和系統邏輯，使得他們可以單獨的處理；充分發揮了技術人員的技術特長。
2) 具有高度的可維護性，使得我們可以根據客戶提出的維護需求，僅僅修改和擴充相關的交付組件而已，不會影響其他組件的內部結構。
3) 業務與技術可以單獨地變更；也就是技術的變更不會影響業務的邏輯。
4) 可以有效的融合其他技術標準，使得四步創新軟件開發方法應用更加廣泛。
在構建程序上，賦予了構建過程的靈活性，使得程序員可以僅僅考慮給予他們的任務；這樣，加大了程序員的工作效率；最終將會減少開發的時間、減少資源的運用。
實際上，上述的論述過程也反映了自動化時代項目制定功能需求的一面，但不是全部。因為自動化時代僅僅描述了功能需求，但是還需要系統架構來劃分模塊來完成所有的功能需求。該過程更加適應于信息化時代；這也是為什么引入業務模塊的一個根本的原因。雖然，該論述沒有引入數據流與業務流的精確一一對應關系，但是它足以說明系統與業務存在著某種對應關系，使得我們可以從業務角度靈活地部署整個系統。
下次我會把最后如何有效地對四步創新軟件開發項目進行項目管理的方法與大家分享，
作者：黃紹良教授 研究員王柏亮
本文標簽：四步創新軟件開發
* 由于無法獲得聯系方式等原因，本網使用的文字及圖片的作品報酬未能及時支付，在此深表歉意，請《四步創新軟件開發》相關權利人與機電之家網取得聯系。
：鞏經理
：13915946763
：南京塞姆泵業有限公司
