適合我國軟件文化的開發模式研究
衡量項目成敗的指標
從自動化到信息化的過程中，投資應用軟件開發的目的已經慢慢從原來“科技應用”以提升工作效率轉變成科技應用所能帶出來的價值，這包括提升制造、市場、服務、和管理的能力。項目贊助人與項目關系人對應用軟件的驗收心態也起了微妙的變化，但可惜軟件工業的從業人員從沒有認識客戶這種心態的轉變。
客戶驗收心態讓今天的軟件從業人員對項目交付的過程帶來很大的影響。從軟件開發初期的自動化歷程，到目前企業進行信息化的終極目標，項目贊助人對自己投資一套軟件所希望達到的最終目的還是非常清晰，不管是為了提升工作效率，還是為了強化企業的能力，往往在項目開始的時候項目贊助人已經有一個很明確的思維和方向，問題是軟件開發的專家如何能夠提交項目的交付，滿足項目資助人的期盼而已。
這種轉變讓項目成功的衡量因素也發生了實質上的變化。項目經理被衡量的準則已經不單是否能夠如期在預算內完成交付來衡量這個項目是否成功。項目經理的項目交付能夠為項目贊助人和項目關系人提供多少效益和能力作為實際上的衡量指標。很多時候我們認為項目已經完成，但客戶還是不滿意，還是認為未能達到預期的成果，原因就在于項目的交付只能做到科技的應用，但沒有帶來任何價值可以提升客戶的應用效益和能力，所以客戶一直認為未能完成驗收的確認。
驚人的數據
在2005年中期開始，在一項對軟件開發困境的研究過程中，特別要求23位項目經理提供一些有關返工的簡單數據，要求項目經理在項目開發的過程中簡單記錄各階段工作需要進行返工的次數，不管是客戶提出返工要求或技術人員主動因應開發內容需要進行返工，目的是希望能夠把握“變動”在軟件開發過程中那些階發生，然后研究該選擇那些開發模式來改變我們的軟件開發方法。
這批項目在6個月內分別起動，原來的目標分別從4個月到12個月完成項目的移交。挑選的項目全部均可以把開發過程分類成“信息調研”，“需求分析”，“系統設計”，“系統開發”，“用戶測試”，和“項目移交”等6個階段。
32個月后，有18個項目所提供的數據比較完整，可以進行參考和研究，其中有3個項目在深圳，5個項目在上海，4個項目在武漢，6個項目在北京。其中只有1個項目能夠順利依時移交，13個項目經過不斷修改后完成移交，余下4個項目仍處于暫停狀態，繼續與客戶協商中。
各階段中的數據分別可以歸類出6種返工內容，分別是邏輯及流程的修改，用戶界面修改，數據結構或數據組織修改，改變所用的程序語言，系統的反應速度和表現未附理想，新增功能或需求的修改，和其他不屬于上述類別的修改。以下是18個項目所收集的數據：
數據代表的涵義說明
上述數據從2005年11月開始收集，分別與23個項目的負責人在數據收集完成后進行訪談，理解數據的準確性和返工背后的原因，最后對5個項目收集的數據因未能確認其準確性，故此只采用18個項目中收集到的數據，到去年10月才能夠進行匯總、整理、和分析。
表格1中的數據說明大部份的返工分別來自開發階段，共185次，相當于每個項目平均需要10次以上的返工；在用戶測試階段，共103次，相當于每個項目平均需要6次以上的返工；信息調研階段，共60次，相當于每個項目平均需要3次以上的返工；和移交階段，共41次相當于每個項目需要2次以上的返工。至于需求分析和系統設計兩個階段的返工次數較少，主要原因是客戶基本上不重視這兩個階段的成果，他們要看的是編程（開發）的結果，測試的結果和移交（應用）的結果。
信息調研階段
這個階段是針對調研報告提交后后被客戶要求對內容調整和修改的次數統計。平均達到3次以上的返工，主要是對邏輯和操作流程的理解，占了80％以上。其他20％的修改包括內容不全，需要補充或擴大調研的范圍所導致的修改。
在這個過程中，項目經理及高級系統分析員主要是跟客戶代表進行訪談，透過訪談的內容建立功能需求說明。調研報告的內容基本上主要是說明軟件的主要功能需求，但沒有任何一個項目以任何形式加上明確的范圍說明。客戶閱讀后會提出修改的反饋，明確說明需要加上那些功能等內容在調研報告中。經過三數次的修改后，18個項目的調研報告都沒有被客戶以任何方式進行確認，提交后項目經理也沒有要求客戶確認后交回項目組。技術人員便開始進行下階段的工作。
需求分析階段
這一個階段的修改次數平均只有1.44次，主要的原因是大部份項目經理把信息調研階段中的一些新增功能或需求說明包括在上階段中記錄并處理。項目經理及系統分析員對信息調研和需求分析的工作內容相當模糊，未能準確分辨兩個階段工作的實際差異。
對項目經理及負責進行調研的技術人員來說，不明確需求分析的工作內容主要是透過調研階段希望客戶能夠提供系統所需的功能需求，所以沒有任何需求分析的工作需要處理，而進行的分析工作只局限與技術如何能夠做到，換句話說，在需求分析的過程中，他們的重點是如何利用技術來達到目的，這基本上是屬于下一個階段系統設計的實際工作。
系統設計階段
從需求分析到系統設計基本上常常缺乏一個明確的交接點。像信息調研和需求分析兩個階段的交接一樣，缺乏任何明確的階段交付說明。大部份項目經理也沒有對技術人員說明個別階段的交付物，并監控有關內容，除了調研報告外，18個項目都沒有提供任何分析說明（Requirement Statements）或系統設計書。
在設計階段過程中，技術人員多開始就客戶提供的功能及需求進行編程，首先是編寫一、兩個主要屏幕的影像，進而編寫有關邏輯。既然缺乏任何設計說明，那么任何修改的要求自然被編列在開發過程中，故此這個階段與上階段一樣，修改的次數較少，18個項目只有25次返工，平均為1.389次。
系統開發階段
在18個項目中共記錄185次返工要求，平均每個項目達到差不多10次以上的返工或修改，是所有階段返工率最高的一個環節。而且這些返工的要求往往是口頭上的要求，通常發生在每周面向客戶匯報進度及成果后，客戶審視技術人員的工作成果（多以演示方式進行）后被要求對有關程序進行調整或修改。記錄的次數只記錄整體返工的要求，包括移交完成的交付進程中的任何程序的邏輯及界面，并沒有分辨記錄每一個模塊或功能的確實返工次數。有關項目經理也承認實際的返工要求如果針對個別模塊或界面進行記錄，次數可能達到記錄的七倍或更高。
大部份的返工以界面修改為主，平均每個項目達到4次，共計72次數。第二是新增功能的修改，多基于前期的調研，分析及設計沒有被包括在內的一些額外需求，平均達到2.39次共43次。接下來是邏輯或流程的返工，平均超過2次工37次。數據的組織及處理方面，平均超過1.33次以上工達到24次數。往往邏輯及數據組織的返工原因多源自功能及界面的返工所影響。
用戶測試階段
這是開發過程中僅次于系統開發階段的第二高返工次數，達到103次，平均每個項目有差不多六次的返工要求。返工的內容多以界面修改為主，平均每個項目被要求界面返工的次數達到2.33次，共計43次。接下來是數據結構及組織的修改，平均次數達到1.78次共32次，占第三位的是新增功能所導致的返工，平均每一個項目有一次的要求工18次。
項目移交階段
比較突出的只有數據結構及組織的返工，平均每一個項目便需要進行1.56次的修改，共達到28次數。主要的原因來自最終用戶對界面中的數據來源不認同，需要來自其他數據庫的內容而進行的修改。
次數記錄分析
這次調查的結果相當有意義，從收集到的數據可以很清楚地理解目前軟件工業所面對的困境，并希望從中找出一個方向，改善軟件工業的未來發展空間。
從收集數據后對項目經理進行的訪談中發行，基本上在整個開發過程中沒有任何監控及評估。每一個工作的內容互相重疊，尤其是“信息調研”，“需求分析”和“系統設計”這三個階段，大部份技術人員對每一個階段的工作目標都不太明確，對于需求的來源更完全依賴客戶提供。接下來的“系統設計”和“系統開發”這兩個階段也是互相重疊，一面設計，一面開發。到程序編寫完成（同時技術人員完成初步模塊測試）后進行用戶測試時才發現實際的工作范圍遠遠超過預期的估計，導致大力的返工及修改。正式移交的時候也需要因應用戶的應用環境和地理分布對項目進行調整。在整個開發過程中，收集的數據基本上體現了“三邊”（邊想，邊做，邊改）的軟件開發模式應用。
軟件開發模型又稱軟件生命周期模型，它制定了一系列的步驟或活動，軟件開發人員或開發團隊需要在開發中按照軟件模型中指定的步驟來進行軟件開發。實際上，很少有某個開發團隊完全遵循開發模型的規定，這是因為每個模型都會有一定的限定條件和應用范圍，并不是完全適應所有的開發環境。
在這里我們探討一些比較經典的開發模型和近來比較風靡的開發模型，同時說明它們的使用范圍和特點。
建造修補模型
也是我們上述所說的“三邊”開發模型。在該模型中不使用規格說明書（它明確地說明了系統的功能需求，從技術角度定義了我們需要做什么）。同時該模型也不嘗試去設計一個軟件，僅僅是將所有的軟件構思全部用代碼表述，軟件的設計和編程思路完全維持在程序員的頭腦中。顯然，它不適應小組開發，同時也不便于維護。因為，我們無法從程序員的頭腦中“抓出”任何準確的對于軟件的任何描述。 [NextPage]
瀑布模型
為了使得軟件工程可以協作開發和易于維護，在自動化時代一種較為有效的模型被開發團隊廣泛的接受，那就是瀑布模型。
瀑布模型一般由“需求階段”、“規格說明階段”、“設計階段”、“實現階段”、“集成階段”、和“推廣階段”。為了能夠全面的分析各個模型的特點，下面需要簡要地介紹該模型的每個階段：
在需求階段，是由系統分析師來確定整個系統的功能需求和非功能需求（如“可靠性和可維護性”等軟件的特性），然后又客戶和一個軟件質量保證組（Software Quality Assurance，SQA）與客戶一同確定需求。實際上需求階段包含兩個活動，需求分析與需求獲取。
在需求獲得認可后需要有同一小組建立規格說明文檔，以文字的方式說明系統要做些什么。最終該文檔需要獲得客戶的認可，同時客戶將以該文檔的內容來驗收項目。當然，在該階段完成后就可以指定軟件項目管理計劃，來規定開發中的每個活動和成果、所需的資源、時間、成本等。
接下來，系統工程師將會在明確技術規格說明書后，建立出模塊和它們的關聯，從而構成系統的結構設計；所以該活動也成為結構設計。系統的結構設計完成后，某些時候會對每個模塊選定一個算法和詳細的數據結果，這時是從一個單一的模塊角度來進行的考慮。當完成設計后還需要對設計進行測試，一般來說是通過對設計的認為審查來完成。
當將設計的說明交給程序員時，開發將會進入變成是現階段，這里程序員負責每個模塊程序的編寫和測試，確保程序的測試結果與設計說明中所描述一致。
當所有程序編寫完成后，將會進入集成階段，也就是以產品或系統的角度對所有模塊進行系統級別的測試。這里主要的工作就是對程序進行測試，所以該階段需要編寫詳細的測試文檔。
一旦客戶接受了產品，任何修改（無論是完善性維護還是糾錯性維護）都會被視為維護階段。這里需要指明的是維護的順序，可能有些維護需要回溯到設計階段甚至是技術規格說明書階段或需求階段。
瀑布模型的優點是顯而易見的，由于線性的開發結構它更加利于管理。瀑布模型適應于自動化項目，因為那時的功能需求可以從范圍和業務流程中準確識別；但是，對于其他類型項目瀑布模型的結構將會產生致命的缺陷，即客戶在項目初期的需求不明確性導致開發出的產品并不是客戶所需要的。
快速原型開發模型
對于該模型大多數軟件工程師們不會感覺到陌生。“快速原型”是一個與產品子集功能上相同的工作模型。例如，目標產品是處理帳務的財會軟件，那么快速原型則需要建立對應功能則是交互的界面和打印的報表。
快速原型基本上與瀑布模型是相一致的。它的第一步是建造一個快速原型，來代替需求階段的需求分析和獲取。客戶和未來的用戶可以使用該快速原型，同時可以提出反饋，然后程序員進一步修改快速原型，客戶再進行確認；直到捕捉到客戶所有的功能需求為止，也就是客戶認為這個快速原型滿足了它的大多數要求為止。
一旦確定了客戶的需求，就會進入技術規格說明階段，制定詳細的規格說明書，以備系統設計師來設計系統。
快速原型的引入主要是為了確立明確的功能需求而設。它的主要構思是通過一個簡單的原型，從系統的角度來引出和明確客戶的期盼和愿望。當然它可以使得客戶在第一時間了解到系統的功能到底是如何運作的，但是對于信息化時代該方法顯然并不理想。如對于一個無法明確表明的“功能”，我們又如何建立該原型呢？我們到底從何而知到在什么時間上有客戶確認的原型是系統所能夠體現的主要功能呢？我們從何而知該項目的范圍呢？我們有從何而知項目的工作計劃到底應當如何制定出里程碑呢？
顯然，很多問題困擾著快速原型的開發，尤其在今天的信息化項目中油然突出。
增量和演化開發模型
軟件是建造出來的，而不是寫出來的。根據這個思想，增量模型被設計出來，它主要強調的是每一步軟件的開發都是建立在前一步軟件開發的基礎之上的。
增量模型將會分階段的交付產品，在每一階段都交付一個可用的產品，同時該產品滿足了客戶需求的一個子集。所以，整個系統備份為若干個構件，一個構建一個構建地交付產品。那么，在每一個階段客戶都會得到一個滿足了他們某一部分需求的產品，同時他們可以在其他產品沒有構建出來時就可以初步了解該構件的使用方法。
增量模型的優點是顯然的，即減少了客戶對于新產品的適應度、客戶可以分批地為每個構件付款（有利于客戶的資金周轉）。但是，增量模型的問題也是顯著的，即如何組織一個開放的結構使得該模型不會退化到建造修補模型。
與增量模型相對應的是演化模型，它強調的是增量和迭代兩個特征的結合。演化模型的目標是克服瀑布模型中線性開發帶出交付上的風險，即只有到了最終交付時才獲知哪部分產品需要維護，這會使得整個項目的開發成本和時間遠遠超出預支。由于在維護階段修改軟件的費用要遠遠大于在需求或設計階段修改軟件的費用，所以演化模型使用了迭代和增量的思想將整個軟件的開發風險分散到不同構建的不同階段。
演化模型的主要步驟是首先開發出系統的一個核心功能，使得客戶可以與開發人員一同確認該功能，這樣開發人員將會得到第一手的經驗；開發人員將會根據客戶的反饋進一步開發出其他功能或進一步擴充該功能；最終，知道建立一個完整的系統位置。
而且每一次開發都會是涉及“風險分析”、“原型建立”、“實現原型”、“評估原型”。這樣會構成多次迭代來完成整個系統的開發。
演化模型的特點基本上與增量模型一致，但是對于演化模型的管理是一個主要的阻力，也就是我們很難確認整個系統的里程碑，成本和時間基線。
統一過程模型
這里和下面介紹的開發模型是近期在業界比較風靡的兩個主要的模型；而對于它的應用效果，由于各種原因，我們不給出具體的評估，僅僅是是從使用角度進行一個簡單分析（或者是提出一些疑問）。
為了利用從上述模型的成功和失敗的歷史中學到的一些有益于軟件工程的知識，統一過程模型尋求了一中方法來改進原有的過程，包括瀑布模型、演化模型等。也就是，統一過程融入了瀑布模型的線性結構和演化模型的增量和迭代思想。
統一過程首相建立了整個項目的不同階段，它包括“初始階段”、“細化階段”、“構造階段”、“移交階段”。同時對于每個階段中保留了瀑布模型的活動，這里被稱為工作流，即從需求、分析到設計和實現、測試這五個活動。所以，我們可以將其理解為一個二維坐標，工作流是一個豎坐標，階段構成了橫坐標。但是，二維坐標并不是統一過程的主要思想，它的主要思想是每個豎坐標制定的活動可能會產生多次迭代，每個迭代會隨著橫坐標（階段）的進展而產生變更，會逐漸減少直至最終消失。
每個階段可以構成一個里程碑，在每個里程碑上可以捕捉到軟件項目生命周期中的重要決策點。如初始階段關注的是項目計劃和風險評估，細化階段關注的是系統的總體構架，構造階段建立系統等。
正如我們開始所說的，我們并不準備對該模型進行評價。這里僅僅是提出一些問題供大家思考。首先，我們如何知道每個里程碑的制定點？其次，如何確立我們建立出了完整的功能需求？再次，每個階段中到底要包含多少個迭代（階段中的子階段）？最終，如何維護在每次迭代中需求、設計、代碼等的一致性？
業務構件開發模型
業務構件開發其實并不屬于軟件開發模型，它僅僅是一個利用業務角度來架構整個系統的一種手段（沒有使用“方法”一詞主要是與開發模型中的方法系進行區別，以免造成歧義）。 [NextPage]
實際上，面向業務構建整個系統是需要一個完善的開發模型來說明它如運作的，這也是本書的主題之一。所以，在這里僅僅介紹當前較為流行的主要架構的特征。
現在最為主要的分為兩種，一是以服務角度（服務構件）來建立系統架構，二是以業務流程角度建立系統架構。但是，實際上他們討論的都是同一件事情，即先確立業務流程，再以服務為單元架構系統。
那么，這些方法是否可行呢？實踐證明他們是可行的，但是效果并不十分理想（不要忘記今天項目的70%的失敗率）。我們也不準備分析它們的優缺點，僅是想指出在使用它們時讀者應當考慮的問題。如，如何知道一個業務流程是客戶所需的呢？如何縮短建立業務流程的時間和提高每個流程的明確度（任務明確）呢？如何確立不同業務構建之間的架構是合理的呢？如何確立一個業務構件是必需的呢？
模型在信息化項目應用分析
在對這些模型進一步剖析前，我們有必要在回顧一下我們的艱難歷程，來判斷是否在信息時代我們可以使用上述的軟件過程就可以達到那些模型所承諾的目標呢？
對于瀑布模型，在信息化時代已經很難獲得在自動化時代的成功了。因為，我們很難再像自動化時代那樣，存在一個業務流程來確立系統的功能需求，那么規格說明書和設計就會顯得蒼白無力。反之，規格說明書和設計反而使得系統的構建更加復雜，因為任何需求的變更都會或多或少地損害系統的模塊劃分和系統架構，那么試想對于一個10萬行代碼的項目而言，如果需求的變更致使設計階段的成果超過了一半產生了變更，那么至少這種開發模型已不再是瀑布模型。因為瀑布模型的特點就是穩固的近似線性結構的開發結構。
對于快速原型而言，信息化項目則是它的“阿喀琉斯腳踝”。因為，信息化項目不再是傳統的自動化改善，而是系統帶出客戶期盼的價值。那么，我們又如何建立一個原型讓客戶體驗呢？試想，如果我們建立出一模一樣的未來系統所對應的原型，那么我們希望客戶告訴我們什么呢？這個系統是界面還是報表，顯然這根本不可能的；客戶都不知道他們的業務操作流程是如何運轉的，又如何告訴我們這些界面可提供什么呢。當然，原型法的目的是引導客戶的需求來完善系統，但是我們又如何知道一個原型對于捕捉這些界面上的需求或報表的需求到底是否完整呢；無論是客戶還是我們根本不知道我們在做什么，到底什么時候才是客戶滿意度獲得了滿足呢？
演化過程顯然更不會在信息化時代獲得成功，如果我們先開發出系統的核心功能，然后根據以構建的功能進一步向“系統”挺進。那么，在客戶和我們都不知道系統如何提供價值時，試問哪個功能才是核心功能呢？我們尚且不知道我們交付什么時，試問我們怎么知道需要多少次迭代才可以構建出最終的系統呢？即使在最佳假設的情況下（客戶決定了核心功能，雖然不知道多少次迭代，但是可以預估最大上限），系統的頻繁變更會使得最終我們退化到建造修補模型。
那么，現在風靡業界的統一過程又如何呢？因為，在前面我們已經說明不會對該模型評價，所以我們不會具體分析該模型在信息化時代的效果如何。在這里，我們只是想提出兩個問題：范圍從哪里建立呢？如何通過迭代來明確地說明在這次迭代中功能需求是否完整呢？
軟件開發過程分析
很多軟件工程師都會問自己，“為什么不能像建筑設計師那樣輕松呢？”，或是問“為什么不能像服裝設計師那樣美妙的工作呢？”。是的，我們多么羨慕建筑設計師啊：現存的任何一座建筑物都不會再建筑時更改其初期的建筑設計。當然，軟件工程的主要特征就是可變性。但是，正如我們在前面所說的，任何事物都會有其界限，要是超越了這個自然的界限無疑我們將付出慘重的代價。
大多數軟件過程的提出不是為了停留在學院內供學生來考試和學習的，軟件過程的制定是為了從過去的經驗和學到的知識中解決和改善原有過程的問題，從而使得項目的成功率大大增加。
雖然我們分析了這些軟件構成在信息化項目中的弊病，但是我們還沒有明確這些過程的特征；所以我們還分析這些軟件過程是否解決了它們所要解決的問題后，我們才可以準確的分析它們。
這里我們僅僅分析瀑布模型、快速原型模型、演化模型。
瀑布模型的引入是為了解決最初的建造修補模型的無序化或無結構化引入的，瀑布模型希望將構建軟件的過程“程序化”，使得我們可以明確我們每一個活動的特征，如是開發還是編碼。這樣我們可以根據不同的活動特征和產物（包括對應產物的文檔）進行規范化管理。但是，該模型能夠成功被應用是有其依賴的條件的，那就是項目范圍必須明確。所以，自動化時代該模型得到了廣泛的成功應用。但是，由于該模型需要在項目初期建立明確的、穩固的需求（所有后續活動的原點）。所以在信息化時代基本上該模型的假設被徹底地毀滅。沒有明確的范圍，那么過多的變更將會超越軟件可變性的極限，即使在不考慮成本的情況下，軟件的構建依然無法成功。
快速開發原型希望能夠解決需求不明確的問題，所以引入了快速原型使得可以通過引導客戶的期盼來明確系統的功能需求。顯然，通過我們在第一章的“需求與范圍”中的論述，我們知道功能需求與客戶需求是有區別的。試圖將引導客戶告訴我們功能需求，我們必然會在項目開發中面臨更多的變更。因為，客戶告知我們的任何信息是要說明最終系統的質量要求，而不是系統的功能需求；如在“特長班報名項目”中，我們可能建立了一個“報名菜單”界面來引導客戶對于報名系統的功能需求，可是我們又如何知道到什么時候才可以獲得客戶的完全認同呢？可能唯一的答案就是，客戶說這些就是我所要的。好的，我們接下來按照模型的要求進行了相應的活動，最終帶出了產品。可是，客戶卻在驗收時說，“啊，我忘了這個報名系統還需要這樣展示……”；接下來，當我們按照客戶的要求修改完后，修改后的版本又提交給客戶，客戶又說，“噢，我現在覺得應當改變一下報表的內容，應當加入……這些數據”，然后我們有去修改數據庫，則必然會影響某些程序的編碼，所以我們還需修改程序、甚至系統的架構。這些情況還會不斷發生，最終我們在一個無法預測的時間上，達到了軟件可變性的極限，或者在沒有達到可變性極限之前我們項目嚴重超支、超時。
經過多次的使用，我們發現好像這種包含了原型的線性結構仍然解決不了任何問題。“軟件工程根本不能以線性結構來開發嗎！”大多數軟件工程師們發現了這個現象。所以，很自然的“迭代”和“增量”這兩個特性被認為是軟件工程所必須涵蓋的特性，然后又很自然的“演化模型”被開發出來解決非線性結構問題，實際上是要解決“不明確的功能需求”這一問題。當然，如果問題都不能明確，顯然答案的制定必定是錯誤的。這種方法從開發角度而言，會有與不斷的變更致使軟件的變更接近極限。
軟件開發過程活動分析
通過上述的分析，我們知道每個模型對會針對不同的問題而設置活動以及活動之間的結構，從而構成了軟件過程。最終在對軟件過程特征和在信息化時代的適應性進行了分析后，我們還要分析一下各個活動的特征來明確我們該如何解決問題。
這里我們僅僅分析與問題最為相關的“需求階段”和“設計階段”，同時我們把“規格說明書階段”納入“需求階段”進行論述，這樣我們可以更加接近問題的本質。
需求階段的任務是根據項目的范圍來建立出形同的功能需求。它開始于客戶給出的范圍，結束于系統功能需求的建立；這里需要系統分析師根據項目的范圍建立出每個范圍內所需要的功能需求。適用于該階段的技術一般為調查、走訪、快速原型的建立；通過這些方法系統分析師可以明確地建立出系統的功能需求。另外，我們也知道了快速原型使用的條件是存在明確的范圍。
設計階段的任務是根據功能需求說明（規格說明書）劃分出系統的模塊和建立出系統的架構。它開始于明確的需求規格說明書，結束于系統模塊和架構的生成；這里需要系統工程師、數據庫架構師和其他相關技術人員的參與共同建立出系統的架構。適用于該階段的技術可謂是數不勝數，但是這些技術可以分為幾類，如面向對象、面向過程、面向業務等。現在，為了適應變更和復用等問題，也出現了各種不同的設計技術，如UML、SOA（嚴格地說SOA是一種標準）等。
我們發現，這兩個活動基本上被所有的開發模型所采用，甚至包括演化模型，它們也需要一個結構設計，否則很難構成系統來被客戶所使用。那么，我們便產生一個疑問，為什么需求與設計都被用于解決不同問題的模型所采納。難道這是巧合，還是必然現象？
至少我們從常識中可以明確一點，這兩者對于軟件工程而言必不可少。倘若不知道客戶的需求，那么我們建造什么呢？倘若設計不存在系統是否還能協作運行呢？那么，除了常識意外還有其他原因嗎。從軟件的角度來看待，功能需求說明了每個范圍內系統所需做的事情，設計從技術角度建立出模塊，以使得每個模塊易于被維護、易于復用、易于團隊開發，更為重要的是降低模塊之間的耦合度。
通過需求與設計我們基本上明確了系統的模塊與這些模塊如何來完成功能需求的，這也是大多數軟件過程所一致認可的。但是，問題卻出在了這個被廣泛認可的過程之中。我們的功能需求是從技術層面考量的，系統的設計也就自然的從技術層面來建構的。可是這些都屬于瀑布模型的特征，也是問題的根源。我們必須承認軟件不是無限制可變的，同時我們還需承認工程是被限定在一個有限的條件下來完成的。所以，如果我們不能解決問題的根源“不明確的需求”，那么任何依賴于“需求與分析”這兩個活動的模型，都會失敗于項目中不斷的變更。雖然我們所述的各種模型由于各種不同的原因失敗于信息化項目，但是不明確的范圍是導致了“需求與設計”階段失敗的“罪魁禍首”。
缺乏明確的項目范圍，我們沒有辦法管理后期的變動或返工要求。這方面我們可以建立明確的項目范圍和正確執行調研的工作，（請參考“降低開發過程中的變動依賴項目范圍管理”一文），相信可以大大減低項目的延誤。但要提供科技應用的價值，必須利用項目組件分拆法PCDM才能夠滿足贊助人即干系人的期盼。但仍然不能夠保證余下的設計，開發，測試和移交能夠順利完成。
我們必須有一套明確的方式，讓我們可以處理系統的邏輯，未來應用的流程，用戶的界面設計，和思考軟件應用的環境，才能夠有效保證項目能夠成功。
其實大部份的返工不是技術上的應用問題，是業務上的應用問題，是界面定義的問題，是理解客戶的期盼并構建可以提供預期效益和能力的問題。
創新的開發思維：四步開發模型
四步開發方法是針對軟件開發過程而不是一套技術規范或標準。這套軟件開發體系的設計概念不但適用于軟件開發，更可應用于產品研發和其它科研項目中。整個體系的設計構思可以利用以下的例子加以說明：
假設我們買了一套新房子，首先我們必須明確這個空間需要提供那些生活的地方，如睡房，書房，飯廳，廚房，洗手間等主要應用空間，是我們購買新房的主要目的，也是整套新房的主要組件。接下來我們便需要決定每一個組件所需的家具、設備和布置，在知道每一個房間的最終用途后，我們才知道需要那些家具或設備，這些房間的用途，家具和設備便成為裝修后的交付定義。也許我們明確知道需要一張桌子，不管是從家具店里購買，還是找工匠打做，我們一定依據最終的交付物定義來思考，或者更明確的說：知道這張桌子的最終利用目的，是用來打麻將？用來放計算機，用來書寫，用來用膳，用來開會，用來裝飾，有或者主要作為用膳的工具但可以偶爾用來打麻將？其中一樣或多樣的目的都可以說是需要一張桌子的最終目的（Ultimate Purpose），是可以在理解這些最終目的后利用PCDM轉變成最終交付物說明[NextPage] （Deliverable Statements）的依據。這些目的已經構成最終交付的主要構思，加上應用的地域和環境，直接影響交付物的外觀和大小。
有了需要一張桌子的最終目的和建立的交付物定義，接下來我們考慮的便是這件交付物的外觀（Appearance），是圓的，方的，長型的，橢圓型的，折合型的，，需要抽柜的，需要附加柜的，用三叉條腳，普通四腳，兩邊板塊豎立或交叉對立支撐？玻璃桌面？雕花桌面？外觀的設計直接影響交付的最終外表。考慮外觀的時候也需要考慮擺放（應用）的環境，桌子是放在房中央？還是靠窗？依附角落？或平常依附角落，用的時候拉到房中央？這些都會影響到最終交付物的外觀。外觀帶出三種內容，一種是UI定義，同時需要建立業務流的內容，最后利用業務流和UI定義建立系統的數據流和數據定義。這都可以透過“系統操作規劃（System Operation Planning, SOP）”實現（下期我會詳細說明SOP的應用方法）。
明確了最終目的和外觀，便可以進入“建設”（Construct）或采購階段，技術人員可以在這個時候考慮所采用的組合技術和材料，包括桌子的組合是透過釘子，螺絲結合，還是焊接，楔口結合等技術和工具應用？技術的應用也直接影響交付物的質量和投資成本。不同的技術應用同樣可以打做相同的結果。成功的建設過程來自前期對最終目的所帶出來的交付說明和外觀的理解得到客戶的認同，任何妥協也應該在這個時候達成共識，否則在建設過程中便常需要對最終交付進行修改，最后出來的交付一定未能獲得客戶認同。
當然，最后便是把交付物與應用環境結合，看看是否能演繹（Demonstrate）出客戶預期的最終目的，讓交付物與環境結合成一個完整的驗收過程。環境包括應用部門，人員，培訓， 硬件配置等等。
圖表 1：創新的開發思維，四步軟件開發管理模型
項目針對最終交付，從項目管理的角度去考慮軟件開發，更應該從交付作為驗收的最終產物，而不是需求。在整套開發體系的架構中，需求只能當作系統的質量指標。這套體系把過去的傳統開發條件依據項目管理的交付方針結合，帶出一套創新的開發理念和方法。
四步軟件開發的特色
這套體系的最大特色是擺脫過去軟件項目未能把握客戶需求的困境。是針對交付物而構成的開發過程，也就是通過交付物的定義，到交付物的外觀的確定，再到使用技術讓外觀得以實現、以及組合交付物，最后通過交付物與具體環境的演繹帶出客戶期盼的價值。
同時可以完善地處理表格1 中所產生的種種問題。從項目起動根據PCDM“交付物”的作用和特點對交付物的最終建立整合成一套完整的模型，也就是說整個模型是以交付物為核心的，而不是像其他模型僅僅將交付物作為需求或技術應用的一個輸入。
為了以交付物為核心，那么我們不去定義一個交付物的功能需求（這方面應該由技術人員對交付的最終目的建立系統的需求，從中帶出技術人員的創新思維），而是“完善”交付物的定義，也就是說定義交付物的詳細外觀（或存在的各種形式），從而我們獲得的是一個交付物的形式化的、詳細的外觀定義；實際上，是脫離參雜了太多技術因素的功能角度去定義交付物的形式化的詳細定義，而是以反映交付物自身特性的外觀角度將主要構思和交付物的目的轉變成形式化的、詳細的外觀定義。
通過外觀的定義，技術人員可以準確的實施技術以使交付物得以實現，實際上去除了從功能角度定義交付物所帶給技術上的局限和復雜性；而從外觀入手使得技術的實施完全可以追溯到交付物的直接定義（即主要構思和外觀），使得最終結果與原始的概念一致；“技術的不同應用可以帶出同一結果”這一現象的產生是以有了相應明確的、客戶確認的、“可過渡”的定義為前提的，而該體系是從交付物的外觀的詳細定義入手，所以不同技術的應用都會圍繞著交付物的外觀和目的來實施的，所以會按照各自的外觀特點“過渡”到由不同技術帶出的同一結果上。
這個開發模型可以讓技術人員在構建過程中盡量發揮本身的技術能力，只有能夠依據目的和SOP的要求完成交付，并進行環境組合，最后通過交付物的演繹帶出項目的根本效益。
下次我會更詳細說明系統操作規劃和四步開發模型的應用方法的內容。讓大家能夠思考是否能夠取得目前我們慣用的開發模型。
從自動化到信息化的過程中，投資應用軟件開發的目的已經慢慢從原來“科技應用”以提升工作效率轉變成科技應用所能帶出來的價值，這包括提升制造、市場、服務、和管理的能力。項目贊助人與項目關系人對應用軟件的驗收心態也起了微妙的變化，但可惜軟件工業的從業人員從沒有認識客戶這種心態的轉變。
客戶驗收心態讓今天的軟件從業人員對項目交付的過程帶來很大的影響。從軟件開發初期的自動化歷程，到目前企業進行信息化的終極目標，項目贊助人對自己投資一套軟件所希望達到的最終目的還是非常清晰，不管是為了提升工作效率，還是為了強化企業的能力，往往在項目開始的時候項目贊助人已經有一個很明確的思維和方向，問題是軟件開發的專家如何能夠提交項目的交付，滿足項目資助人的期盼而已。
這種轉變讓項目成功的衡量因素也發生了實質上的變化。項目經理被衡量的準則已經不單是否能夠如期在預算內完成交付來衡量這個項目是否成功。項目經理的項目交付能夠為項目贊助人和項目關系人提供多少效益和能力作為實際上的衡量指標。很多時候我們認為項目已經完成，但客戶還是不滿意，還是認為未能達到預期的成果，原因就在于項目的交付只能做到科技的應用，但沒有帶來任何價值可以提升客戶的應用效益和能力，所以客戶一直認為未能完成驗收的確認。
驚人的數據
在2005年中期開始，在一項對軟件開發困境的研究過程中，特別要求23位項目經理提供一些有關返工的簡單數據，要求項目經理在項目開發的過程中簡單記錄各階段工作需要進行返工的次數，不管是客戶提出返工要求或技術人員主動因應開發內容需要進行返工，目的是希望能夠把握“變動”在軟件開發過程中那些階發生，然后研究該選擇那些開發模式來改變我們的軟件開發方法。
這批項目在6個月內分別起動，原來的目標分別從4個月到12個月完成項目的移交。挑選的項目全部均可以把開發過程分類成“信息調研”，“需求分析”，“系統設計”，“系統開發”，“用戶測試”，和“項目移交”等6個階段。
32個月后，有18個項目所提供的數據比較完整，可以進行參考和研究，其中有3個項目在深圳，5個項目在上海，4個項目在武漢，6個項目在北京。其中只有1個項目能夠順利依時移交，13個項目經過不斷修改后完成移交，余下4個項目仍處于暫停狀態，繼續與客戶協商中。
各階段中的數據分別可以歸類出6種返工內容，分別是邏輯及流程的修改，用戶界面修改，數據結構或數據組織修改，改變所用的程序語言，系統的反應速度和表現未附理想，新增功能或需求的修改，和其他不屬于上述類別的修改。以下是18個項目所收集的數據：
數據代表的涵義說明
上述數據從2005年11月開始收集，分別與23個項目的負責人在數據收集完成后進行訪談，理解數據的準確性和返工背后的原因，最后對5個項目收集的數據因未能確認其準確性，故此只采用18個項目中收集到的數據，到去年10月才能夠進行匯總、整理、和分析。
表格1中的數據說明大部份的返工分別來自開發階段，共185次，相當于每個項目平均需要10次以上的返工；在用戶測試階段，共103次，相當于每個項目平均需要6次以上的返工；信息調研階段，共60次，相當于每個項目平均需要3次以上的返工；和移交階段，共41次相當于每個項目需要2次以上的返工。至于需求分析和系統設計兩個階段的返工次數較少，主要原因是客戶基本上不重視這兩個階段的成果，他們要看的是編程（開發）的結果，測試的結果和移交（應用）的結果。
信息調研階段
這個階段是針對調研報告提交后后被客戶要求對內容調整和修改的次數統計。平均達到3次以上的返工，主要是對邏輯和操作流程的理解，占了80％以上。其他20％的修改包括內容不全，需要補充或擴大調研的范圍所導致的修改。
在這個過程中，項目經理及高級系統分析員主要是跟客戶代表進行訪談，透過訪談的內容建立功能需求說明。調研報告的內容基本上主要是說明軟件的主要功能需求，但沒有任何一個項目以任何形式加上明確的范圍說明。客戶閱讀后會提出修改的反饋，明確說明需要加上那些功能等內容在調研報告中。經過三數次的修改后，18個項目的調研報告都沒有被客戶以任何方式進行確認，提交后項目經理也沒有要求客戶確認后交回項目組。技術人員便開始進行下階段的工作。
需求分析階段
這一個階段的修改次數平均只有1.44次，主要的原因是大部份項目經理把信息調研階段中的一些新增功能或需求說明包括在上階段中記錄并處理。項目經理及系統分析員對信息調研和需求分析的工作內容相當模糊，未能準確分辨兩個階段工作的實際差異。
對項目經理及負責進行調研的技術人員來說，不明確需求分析的工作內容主要是透過調研階段希望客戶能夠提供系統所需的功能需求，所以沒有任何需求分析的工作需要處理，而進行的分析工作只局限與技術如何能夠做到，換句話說，在需求分析的過程中，他們的重點是如何利用技術來達到目的，這基本上是屬于下一個階段系統設計的實際工作。
系統設計階段
從需求分析到系統設計基本上常常缺乏一個明確的交接點。像信息調研和需求分析兩個階段的交接一樣，缺乏任何明確的階段交付說明。大部份項目經理也沒有對技術人員說明個別階段的交付物，并監控有關內容，除了調研報告外，18個項目都沒有提供任何分析說明（Requirement Statements）或系統設計書。
在設計階段過程中，技術人員多開始就客戶提供的功能及需求進行編程，首先是編寫一、兩個主要屏幕的影像，進而編寫有關邏輯。既然缺乏任何設計說明，那么任何修改的要求自然被編列在開發過程中，故此這個階段與上階段一樣，修改的次數較少，18個項目只有25次返工，平均為1.389次。
系統開發階段
在18個項目中共記錄185次返工要求，平均每個項目達到差不多10次以上的返工或修改，是所有階段返工率最高的一個環節。而且這些返工的要求往往是口頭上的要求，通常發生在每周面向客戶匯報進度及成果后，客戶審視技術人員的工作成果（多以演示方式進行）后被要求對有關程序進行調整或修改。記錄的次數只記錄整體返工的要求，包括移交完成的交付進程中的任何程序的邏輯及界面，并沒有分辨記錄每一個模塊或功能的確實返工次數。有關項目經理也承認實際的返工要求如果針對個別模塊或界面進行記錄，次數可能達到記錄的七倍或更高。
大部份的返工以界面修改為主，平均每個項目達到4次，共計72次數。第二是新增功能的修改，多基于前期的調研，分析及設計沒有被包括在內的一些額外需求，平均達到2.39次共43次。接下來是邏輯或流程的返工，平均超過2次工37次。數據的組織及處理方面，平均超過1.33次以上工達到24次數。往往邏輯及數據組織的返工原因多源自功能及界面的返工所影響。
用戶測試階段
這是開發過程中僅次于系統開發階段的第二高返工次數，達到103次，平均每個項目有差不多六次的返工要求。返工的內容多以界面修改為主，平均每個項目被要求界面返工的次數達到2.33次，共計43次。接下來是數據結構及組織的修改，平均次數達到1.78次共32次，占第三位的是新增功能所導致的返工，平均每一個項目有一次的要求工18次。
項目移交階段
比較突出的只有數據結構及組織的返工，平均每一個項目便需要進行1.56次的修改，共達到28次數。主要的原因來自最終用戶對界面中的數據來源不認同，需要來自其他數據庫的內容而進行的修改。
次數記錄分析
這次調查的結果相當有意義，從收集到的數據可以很清楚地理解目前軟件工業所面對的困境，并希望從中找出一個方向，改善軟件工業的未來發展空間。
從收集數據后對項目經理進行的訪談中發行，基本上在整個開發過程中沒有任何監控及評估。每一個工作的內容互相重疊，尤其是“信息調研”，“需求分析”和“系統設計”這三個階段，大部份技術人員對每一個階段的工作目標都不太明確，對于需求的來源更完全依賴客戶提供。接下來的“系統設計”和“系統開發”這兩個階段也是互相重疊，一面設計，一面開發。到程序編寫完成（同時技術人員完成初步模塊測試）后進行用戶測試時才發現實際的工作范圍遠遠超過預期的估計，導致大力的返工及修改。正式移交的時候也需要因應用戶的應用環境和地理分布對項目進行調整。在整個開發過程中，收集的數據基本上體現了“三邊”（邊想，邊做，邊改）的軟件開發模式應用。
軟件開發模型又稱軟件生命周期模型，它制定了一系列的步驟或活動，軟件開發人員或開發團隊需要在開發中按照軟件模型中指定的步驟來進行軟件開發。實際上，很少有某個開發團隊完全遵循開發模型的規定，這是因為每個模型都會有一定的限定條件和應用范圍，并不是完全適應所有的開發環境。
在這里我們探討一些比較經典的開發模型和近來比較風靡的開發模型，同時說明它們的使用范圍和特點。
建造修補模型
也是我們上述所說的“三邊”開發模型。在該模型中不使用規格說明書（它明確地說明了系統的功能需求，從技術角度定義了我們需要做什么）。同時該模型也不嘗試去設計一個軟件，僅僅是將所有的軟件構思全部用代碼表述，軟件的設計和編程思路完全維持在程序員的頭腦中。顯然，它不適應小組開發，同時也不便于維護。因為，我們無法從程序員的頭腦中“抓出”任何準確的對于軟件的任何描述。 [NextPage]
瀑布模型
為了使得軟件工程可以協作開發和易于維護，在自動化時代一種較為有效的模型被開發團隊廣泛的接受，那就是瀑布模型。
瀑布模型一般由“需求階段”、“規格說明階段”、“設計階段”、“實現階段”、“集成階段”、和“推廣階段”。為了能夠全面的分析各個模型的特點，下面需要簡要地介紹該模型的每個階段：
在需求階段，是由系統分析師來確定整個系統的功能需求和非功能需求（如“可靠性和可維護性”等軟件的特性），然后又客戶和一個軟件質量保證組（Software Quality Assurance，SQA）與客戶一同確定需求。實際上需求階段包含兩個活動，需求分析與需求獲取。
在需求獲得認可后需要有同一小組建立規格說明文檔，以文字的方式說明系統要做些什么。最終該文檔需要獲得客戶的認可，同時客戶將以該文檔的內容來驗收項目。當然，在該階段完成后就可以指定軟件項目管理計劃，來規定開發中的每個活動和成果、所需的資源、時間、成本等。
接下來，系統工程師將會在明確技術規格說明書后，建立出模塊和它們的關聯，從而構成系統的結構設計；所以該活動也成為結構設計。系統的結構設計完成后，某些時候會對每個模塊選定一個算法和詳細的數據結果，這時是從一個單一的模塊角度來進行的考慮。當完成設計后還需要對設計進行測試，一般來說是通過對設計的認為審查來完成。
當將設計的說明交給程序員時，開發將會進入變成是現階段，這里程序員負責每個模塊程序的編寫和測試，確保程序的測試結果與設計說明中所描述一致。
當所有程序編寫完成后，將會進入集成階段，也就是以產品或系統的角度對所有模塊進行系統級別的測試。這里主要的工作就是對程序進行測試，所以該階段需要編寫詳細的測試文檔。
一旦客戶接受了產品，任何修改（無論是完善性維護還是糾錯性維護）都會被視為維護階段。這里需要指明的是維護的順序，可能有些維護需要回溯到設計階段甚至是技術規格說明書階段或需求階段。
瀑布模型的優點是顯而易見的，由于線性的開發結構它更加利于管理。瀑布模型適應于自動化項目，因為那時的功能需求可以從范圍和業務流程中準確識別；但是，對于其他類型項目瀑布模型的結構將會產生致命的缺陷，即客戶在項目初期的需求不明確性導致開發出的產品并不是客戶所需要的。
快速原型開發模型
對于該模型大多數軟件工程師們不會感覺到陌生。“快速原型”是一個與產品子集功能上相同的工作模型。例如，目標產品是處理帳務的財會軟件，那么快速原型則需要建立對應功能則是交互的界面和打印的報表。
快速原型基本上與瀑布模型是相一致的。它的第一步是建造一個快速原型，來代替需求階段的需求分析和獲取。客戶和未來的用戶可以使用該快速原型，同時可以提出反饋，然后程序員進一步修改快速原型，客戶再進行確認；直到捕捉到客戶所有的功能需求為止，也就是客戶認為這個快速原型滿足了它的大多數要求為止。
一旦確定了客戶的需求，就會進入技術規格說明階段，制定詳細的規格說明書，以備系統設計師來設計系統。
快速原型的引入主要是為了確立明確的功能需求而設。它的主要構思是通過一個簡單的原型，從系統的角度來引出和明確客戶的期盼和愿望。當然它可以使得客戶在第一時間了解到系統的功能到底是如何運作的，但是對于信息化時代該方法顯然并不理想。如對于一個無法明確表明的“功能”，我們又如何建立該原型呢？我們到底從何而知到在什么時間上有客戶確認的原型是系統所能夠體現的主要功能呢？我們從何而知該項目的范圍呢？我們有從何而知項目的工作計劃到底應當如何制定出里程碑呢？
顯然，很多問題困擾著快速原型的開發，尤其在今天的信息化項目中油然突出。
增量和演化開發模型
軟件是建造出來的，而不是寫出來的。根據這個思想，增量模型被設計出來，它主要強調的是每一步軟件的開發都是建立在前一步軟件開發的基礎之上的。
增量模型將會分階段的交付產品，在每一階段都交付一個可用的產品，同時該產品滿足了客戶需求的一個子集。所以，整個系統備份為若干個構件，一個構建一個構建地交付產品。那么，在每一個階段客戶都會得到一個滿足了他們某一部分需求的產品，同時他們可以在其他產品沒有構建出來時就可以初步了解該構件的使用方法。
增量模型的優點是顯然的，即減少了客戶對于新產品的適應度、客戶可以分批地為每個構件付款（有利于客戶的資金周轉）。但是，增量模型的問題也是顯著的，即如何組織一個開放的結構使得該模型不會退化到建造修補模型。
與增量模型相對應的是演化模型，它強調的是增量和迭代兩個特征的結合。演化模型的目標是克服瀑布模型中線性開發帶出交付上的風險，即只有到了最終交付時才獲知哪部分產品需要維護，這會使得整個項目的開發成本和時間遠遠超出預支。由于在維護階段修改軟件的費用要遠遠大于在需求或設計階段修改軟件的費用，所以演化模型使用了迭代和增量的思想將整個軟件的開發風險分散到不同構建的不同階段。
演化模型的主要步驟是首先開發出系統的一個核心功能，使得客戶可以與開發人員一同確認該功能，這樣開發人員將會得到第一手的經驗；開發人員將會根據客戶的反饋進一步開發出其他功能或進一步擴充該功能；最終，知道建立一個完整的系統位置。
而且每一次開發都會是涉及“風險分析”、“原型建立”、“實現原型”、“評估原型”。這樣會構成多次迭代來完成整個系統的開發。
演化模型的特點基本上與增量模型一致，但是對于演化模型的管理是一個主要的阻力，也就是我們很難確認整個系統的里程碑，成本和時間基線。
統一過程模型
這里和下面介紹的開發模型是近期在業界比較風靡的兩個主要的模型；而對于它的應用效果，由于各種原因，我們不給出具體的評估，僅僅是是從使用角度進行一個簡單分析（或者是提出一些疑問）。
為了利用從上述模型的成功和失敗的歷史中學到的一些有益于軟件工程的知識，統一過程模型尋求了一中方法來改進原有的過程，包括瀑布模型、演化模型等。也就是，統一過程融入了瀑布模型的線性結構和演化模型的增量和迭代思想。
統一過程首相建立了整個項目的不同階段，它包括“初始階段”、“細化階段”、“構造階段”、“移交階段”。同時對于每個階段中保留了瀑布模型的活動，這里被稱為工作流，即從需求、分析到設計和實現、測試這五個活動。所以，我們可以將其理解為一個二維坐標，工作流是一個豎坐標，階段構成了橫坐標。但是，二維坐標并不是統一過程的主要思想，它的主要思想是每個豎坐標制定的活動可能會產生多次迭代，每個迭代會隨著橫坐標（階段）的進展而產生變更，會逐漸減少直至最終消失。
每個階段可以構成一個里程碑，在每個里程碑上可以捕捉到軟件項目生命周期中的重要決策點。如初始階段關注的是項目計劃和風險評估，細化階段關注的是系統的總體構架，構造階段建立系統等。
正如我們開始所說的，我們并不準備對該模型進行評價。這里僅僅是提出一些問題供大家思考。首先，我們如何知道每個里程碑的制定點？其次，如何確立我們建立出了完整的功能需求？再次，每個階段中到底要包含多少個迭代（階段中的子階段）？最終，如何維護在每次迭代中需求、設計、代碼等的一致性？
業務構件開發模型
業務構件開發其實并不屬于軟件開發模型，它僅僅是一個利用業務角度來架構整個系統的一種手段（沒有使用“方法”一詞主要是與開發模型中的方法系進行區別，以免造成歧義）。 [NextPage]
實際上，面向業務構建整個系統是需要一個完善的開發模型來說明它如運作的，這也是本書的主題之一。所以，在這里僅僅介紹當前較為流行的主要架構的特征。
現在最為主要的分為兩種，一是以服務角度（服務構件）來建立系統架構，二是以業務流程角度建立系統架構。但是，實際上他們討論的都是同一件事情，即先確立業務流程，再以服務為單元架構系統。
那么，這些方法是否可行呢？實踐證明他們是可行的，但是效果并不十分理想（不要忘記今天項目的70%的失敗率）。我們也不準備分析它們的優缺點，僅是想指出在使用它們時讀者應當考慮的問題。如，如何知道一個業務流程是客戶所需的呢？如何縮短建立業務流程的時間和提高每個流程的明確度（任務明確）呢？如何確立不同業務構建之間的架構是合理的呢？如何確立一個業務構件是必需的呢？
模型在信息化項目應用分析
在對這些模型進一步剖析前，我們有必要在回顧一下我們的艱難歷程，來判斷是否在信息時代我們可以使用上述的軟件過程就可以達到那些模型所承諾的目標呢？
對于瀑布模型，在信息化時代已經很難獲得在自動化時代的成功了。因為，我們很難再像自動化時代那樣，存在一個業務流程來確立系統的功能需求，那么規格說明書和設計就會顯得蒼白無力。反之，規格說明書和設計反而使得系統的構建更加復雜，因為任何需求的變更都會或多或少地損害系統的模塊劃分和系統架構，那么試想對于一個10萬行代碼的項目而言，如果需求的變更致使設計階段的成果超過了一半產生了變更，那么至少這種開發模型已不再是瀑布模型。因為瀑布模型的特點就是穩固的近似線性結構的開發結構。
對于快速原型而言，信息化項目則是它的“阿喀琉斯腳踝”。因為，信息化項目不再是傳統的自動化改善，而是系統帶出客戶期盼的價值。那么，我們又如何建立一個原型讓客戶體驗呢？試想，如果我們建立出一模一樣的未來系統所對應的原型，那么我們希望客戶告訴我們什么呢？這個系統是界面還是報表，顯然這根本不可能的；客戶都不知道他們的業務操作流程是如何運轉的，又如何告訴我們這些界面可提供什么呢。當然，原型法的目的是引導客戶的需求來完善系統，但是我們又如何知道一個原型對于捕捉這些界面上的需求或報表的需求到底是否完整呢；無論是客戶還是我們根本不知道我們在做什么，到底什么時候才是客戶滿意度獲得了滿足呢？
演化過程顯然更不會在信息化時代獲得成功，如果我們先開發出系統的核心功能，然后根據以構建的功能進一步向“系統”挺進。那么，在客戶和我們都不知道系統如何提供價值時，試問哪個功能才是核心功能呢？我們尚且不知道我們交付什么時，試問我們怎么知道需要多少次迭代才可以構建出最終的系統呢？即使在最佳假設的情況下（客戶決定了核心功能，雖然不知道多少次迭代，但是可以預估最大上限），系統的頻繁變更會使得最終我們退化到建造修補模型。
那么，現在風靡業界的統一過程又如何呢？因為，在前面我們已經說明不會對該模型評價，所以我們不會具體分析該模型在信息化時代的效果如何。在這里，我們只是想提出兩個問題：范圍從哪里建立呢？如何通過迭代來明確地說明在這次迭代中功能需求是否完整呢？
軟件開發過程分析
很多軟件工程師都會問自己，“為什么不能像建筑設計師那樣輕松呢？”，或是問“為什么不能像服裝設計師那樣美妙的工作呢？”。是的，我們多么羨慕建筑設計師啊：現存的任何一座建筑物都不會再建筑時更改其初期的建筑設計。當然，軟件工程的主要特征就是可變性。但是，正如我們在前面所說的，任何事物都會有其界限，要是超越了這個自然的界限無疑我們將付出慘重的代價。
大多數軟件過程的提出不是為了停留在學院內供學生來考試和學習的，軟件過程的制定是為了從過去的經驗和學到的知識中解決和改善原有過程的問題，從而使得項目的成功率大大增加。
雖然我們分析了這些軟件構成在信息化項目中的弊病，但是我們還沒有明確這些過程的特征；所以我們還分析這些軟件過程是否解決了它們所要解決的問題后，我們才可以準確的分析它們。
這里我們僅僅分析瀑布模型、快速原型模型、演化模型。
瀑布模型的引入是為了解決最初的建造修補模型的無序化或無結構化引入的，瀑布模型希望將構建軟件的過程“程序化”，使得我們可以明確我們每一個活動的特征，如是開發還是編碼。這樣我們可以根據不同的活動特征和產物（包括對應產物的文檔）進行規范化管理。但是，該模型能夠成功被應用是有其依賴的條件的，那就是項目范圍必須明確。所以，自動化時代該模型得到了廣泛的成功應用。但是，由于該模型需要在項目初期建立明確的、穩固的需求（所有后續活動的原點）。所以在信息化時代基本上該模型的假設被徹底地毀滅。沒有明確的范圍，那么過多的變更將會超越軟件可變性的極限，即使在不考慮成本的情況下，軟件的構建依然無法成功。
快速開發原型希望能夠解決需求不明確的問題，所以引入了快速原型使得可以通過引導客戶的期盼來明確系統的功能需求。顯然，通過我們在第一章的“需求與范圍”中的論述，我們知道功能需求與客戶需求是有區別的。試圖將引導客戶告訴我們功能需求，我們必然會在項目開發中面臨更多的變更。因為，客戶告知我們的任何信息是要說明最終系統的質量要求，而不是系統的功能需求；如在“特長班報名項目”中，我們可能建立了一個“報名菜單”界面來引導客戶對于報名系統的功能需求，可是我們又如何知道到什么時候才可以獲得客戶的完全認同呢？可能唯一的答案就是，客戶說這些就是我所要的。好的，我們接下來按照模型的要求進行了相應的活動，最終帶出了產品。可是，客戶卻在驗收時說，“啊，我忘了這個報名系統還需要這樣展示……”；接下來，當我們按照客戶的要求修改完后，修改后的版本又提交給客戶，客戶又說，“噢，我現在覺得應當改變一下報表的內容，應當加入……這些數據”，然后我們有去修改數據庫，則必然會影響某些程序的編碼，所以我們還需修改程序、甚至系統的架構。這些情況還會不斷發生，最終我們在一個無法預測的時間上，達到了軟件可變性的極限，或者在沒有達到可變性極限之前我們項目嚴重超支、超時。
經過多次的使用，我們發現好像這種包含了原型的線性結構仍然解決不了任何問題。“軟件工程根本不能以線性結構來開發嗎！”大多數軟件工程師們發現了這個現象。所以，很自然的“迭代”和“增量”這兩個特性被認為是軟件工程所必須涵蓋的特性，然后又很自然的“演化模型”被開發出來解決非線性結構問題，實際上是要解決“不明確的功能需求”這一問題。當然，如果問題都不能明確，顯然答案的制定必定是錯誤的。這種方法從開發角度而言，會有與不斷的變更致使軟件的變更接近極限。
軟件開發過程活動分析
通過上述的分析，我們知道每個模型對會針對不同的問題而設置活動以及活動之間的結構，從而構成了軟件過程。最終在對軟件過程特征和在信息化時代的適應性進行了分析后，我們還要分析一下各個活動的特征來明確我們該如何解決問題。
這里我們僅僅分析與問題最為相關的“需求階段”和“設計階段”，同時我們把“規格說明書階段”納入“需求階段”進行論述，這樣我們可以更加接近問題的本質。
需求階段的任務是根據項目的范圍來建立出形同的功能需求。它開始于客戶給出的范圍，結束于系統功能需求的建立；這里需要系統分析師根據項目的范圍建立出每個范圍內所需要的功能需求。適用于該階段的技術一般為調查、走訪、快速原型的建立；通過這些方法系統分析師可以明確地建立出系統的功能需求。另外，我們也知道了快速原型使用的條件是存在明確的范圍。
設計階段的任務是根據功能需求說明（規格說明書）劃分出系統的模塊和建立出系統的架構。它開始于明確的需求規格說明書，結束于系統模塊和架構的生成；這里需要系統工程師、數據庫架構師和其他相關技術人員的參與共同建立出系統的架構。適用于該階段的技術可謂是數不勝數，但是這些技術可以分為幾類，如面向對象、面向過程、面向業務等。現在，為了適應變更和復用等問題，也出現了各種不同的設計技術，如UML、SOA（嚴格地說SOA是一種標準）等。
我們發現，這兩個活動基本上被所有的開發模型所采用，甚至包括演化模型，它們也需要一個結構設計，否則很難構成系統來被客戶所使用。那么，我們便產生一個疑問，為什么需求與設計都被用于解決不同問題的模型所采納。難道這是巧合，還是必然現象？
至少我們從常識中可以明確一點，這兩者對于軟件工程而言必不可少。倘若不知道客戶的需求，那么我們建造什么呢？倘若設計不存在系統是否還能協作運行呢？那么，除了常識意外還有其他原因嗎。從軟件的角度來看待，功能需求說明了每個范圍內系統所需做的事情，設計從技術角度建立出模塊，以使得每個模塊易于被維護、易于復用、易于團隊開發，更為重要的是降低模塊之間的耦合度。
通過需求與設計我們基本上明確了系統的模塊與這些模塊如何來完成功能需求的，這也是大多數軟件過程所一致認可的。但是，問題卻出在了這個被廣泛認可的過程之中。我們的功能需求是從技術層面考量的，系統的設計也就自然的從技術層面來建構的。可是這些都屬于瀑布模型的特征，也是問題的根源。我們必須承認軟件不是無限制可變的，同時我們還需承認工程是被限定在一個有限的條件下來完成的。所以，如果我們不能解決問題的根源“不明確的需求”，那么任何依賴于“需求與分析”這兩個活動的模型，都會失敗于項目中不斷的變更。雖然我們所述的各種模型由于各種不同的原因失敗于信息化項目，但是不明確的范圍是導致了“需求與設計”階段失敗的“罪魁禍首”。
缺乏明確的項目范圍，我們沒有辦法管理后期的變動或返工要求。這方面我們可以建立明確的項目范圍和正確執行調研的工作，（請參考“降低開發過程中的變動依賴項目范圍管理”一文），相信可以大大減低項目的延誤。但要提供科技應用的價值，必須利用項目組件分拆法PCDM才能夠滿足贊助人即干系人的期盼。但仍然不能夠保證余下的設計，開發，測試和移交能夠順利完成。
我們必須有一套明確的方式，讓我們可以處理系統的邏輯，未來應用的流程，用戶的界面設計，和思考軟件應用的環境，才能夠有效保證項目能夠成功。
其實大部份的返工不是技術上的應用問題，是業務上的應用問題，是界面定義的問題，是理解客戶的期盼并構建可以提供預期效益和能力的問題。
創新的開發思維：四步開發模型
四步開發方法是針對軟件開發過程而不是一套技術規范或標準。這套軟件開發體系的設計概念不但適用于軟件開發，更可應用于產品研發和其它科研項目中。整個體系的設計構思可以利用以下的例子加以說明：
假設我們買了一套新房子，首先我們必須明確這個空間需要提供那些生活的地方，如睡房，書房，飯廳，廚房，洗手間等主要應用空間，是我們購買新房的主要目的，也是整套新房的主要組件。接下來我們便需要決定每一個組件所需的家具、設備和布置，在知道每一個房間的最終用途后，我們才知道需要那些家具或設備，這些房間的用途，家具和設備便成為裝修后的交付定義。也許我們明確知道需要一張桌子，不管是從家具店里購買，還是找工匠打做，我們一定依據最終的交付物定義來思考，或者更明確的說：知道這張桌子的最終利用目的，是用來打麻將？用來放計算機，用來書寫，用來用膳，用來開會，用來裝飾，有或者主要作為用膳的工具但可以偶爾用來打麻將？其中一樣或多樣的目的都可以說是需要一張桌子的最終目的（Ultimate Purpose），是可以在理解這些最終目的后利用PCDM轉變成最終交付物說明[NextPage] （Deliverable Statements）的依據。這些目的已經構成最終交付的主要構思，加上應用的地域和環境，直接影響交付物的外觀和大小。
有了需要一張桌子的最終目的和建立的交付物定義，接下來我們考慮的便是這件交付物的外觀（Appearance），是圓的，方的，長型的，橢圓型的，折合型的，，需要抽柜的，需要附加柜的，用三叉條腳，普通四腳，兩邊板塊豎立或交叉對立支撐？玻璃桌面？雕花桌面？外觀的設計直接影響交付的最終外表。考慮外觀的時候也需要考慮擺放（應用）的環境，桌子是放在房中央？還是靠窗？依附角落？或平常依附角落，用的時候拉到房中央？這些都會影響到最終交付物的外觀。外觀帶出三種內容，一種是UI定義，同時需要建立業務流的內容，最后利用業務流和UI定義建立系統的數據流和數據定義。這都可以透過“系統操作規劃（System Operation Planning, SOP）”實現（下期我會詳細說明SOP的應用方法）。
明確了最終目的和外觀，便可以進入“建設”（Construct）或采購階段，技術人員可以在這個時候考慮所采用的組合技術和材料，包括桌子的組合是透過釘子，螺絲結合，還是焊接，楔口結合等技術和工具應用？技術的應用也直接影響交付物的質量和投資成本。不同的技術應用同樣可以打做相同的結果。成功的建設過程來自前期對最終目的所帶出來的交付說明和外觀的理解得到客戶的認同，任何妥協也應該在這個時候達成共識，否則在建設過程中便常需要對最終交付進行修改，最后出來的交付一定未能獲得客戶認同。
當然，最后便是把交付物與應用環境結合，看看是否能演繹（Demonstrate）出客戶預期的最終目的，讓交付物與環境結合成一個完整的驗收過程。環境包括應用部門，人員，培訓， 硬件配置等等。
圖表 1：創新的開發思維，四步軟件開發管理模型
項目針對最終交付，從項目管理的角度去考慮軟件開發，更應該從交付作為驗收的最終產物，而不是需求。在整套開發體系的架構中，需求只能當作系統的質量指標。這套體系把過去的傳統開發條件依據項目管理的交付方針結合，帶出一套創新的開發理念和方法。
四步軟件開發的特色
這套體系的最大特色是擺脫過去軟件項目未能把握客戶需求的困境。是針對交付物而構成的開發過程，也就是通過交付物的定義，到交付物的外觀的確定，再到使用技術讓外觀得以實現、以及組合交付物，最后通過交付物與具體環境的演繹帶出客戶期盼的價值。
同時可以完善地處理表格1 中所產生的種種問題。從項目起動根據PCDM“交付物”的作用和特點對交付物的最終建立整合成一套完整的模型，也就是說整個模型是以交付物為核心的，而不是像其他模型僅僅將交付物作為需求或技術應用的一個輸入。
為了以交付物為核心，那么我們不去定義一個交付物的功能需求（這方面應該由技術人員對交付的最終目的建立系統的需求，從中帶出技術人員的創新思維），而是“完善”交付物的定義，也就是說定義交付物的詳細外觀（或存在的各種形式），從而我們獲得的是一個交付物的形式化的、詳細的外觀定義；實際上，是脫離參雜了太多技術因素的功能角度去定義交付物的形式化的詳細定義，而是以反映交付物自身特性的外觀角度將主要構思和交付物的目的轉變成形式化的、詳細的外觀定義。
通過外觀的定義，技術人員可以準確的實施技術以使交付物得以實現，實際上去除了從功能角度定義交付物所帶給技術上的局限和復雜性；而從外觀入手使得技術的實施完全可以追溯到交付物的直接定義（即主要構思和外觀），使得最終結果與原始的概念一致；“技術的不同應用可以帶出同一結果”這一現象的產生是以有了相應明確的、客戶確認的、“可過渡”的定義為前提的，而該體系是從交付物的外觀的詳細定義入手，所以不同技術的應用都會圍繞著交付物的外觀和目的來實施的，所以會按照各自的外觀特點“過渡”到由不同技術帶出的同一結果上。
這個開發模型可以讓技術人員在構建過程中盡量發揮本身的技術能力，只有能夠依據目的和SOP的要求完成交付，并進行環境組合，最后通過交付物的演繹帶出項目的根本效益。
下次我會更詳細說明系統操作規劃和四步開發模型的應用方法的內容。讓大家能夠思考是否能夠取得目前我們慣用的開發模型。
本文標簽：適合我國軟件文化的開發模式研究
* 由于無法獲得聯系方式等原因，本網使用的文字及圖片的作品報酬未能及時支付，在此深表歉意，請《適合我國軟件文化的開發模式研究》相關權利人與機電之家網取得聯系。
：鞏經理
：13915946763
：南京塞姆泵業有限公司
