衡量項(xiàng)目成敗的指標(biāo)

　　從自動(dòng)化到信息化的過(guò)程中，投資應(yīng)用軟件開(kāi)發(fā)的目的已經(jīng)慢慢從原來(lái)“科技應(yīng)用”以提升工作效率轉(zhuǎn)變成科技應(yīng)用所能帶出來(lái)的價(jià)值，這包括提升制造、市場(chǎng)、服務(wù)、和管理的能力。項(xiàng)目贊助人與項(xiàng)目關(guān)系人對(duì)應(yīng)用軟件的驗(yàn)收心態(tài)也起了微妙的變化，但可惜軟件工業(yè)的從業(yè)人員從沒(méi)有認(rèn)識(shí)客戶這種心態(tài)的轉(zhuǎn)變。

　　客戶驗(yàn)收心態(tài)讓今天的軟件從業(yè)人員對(duì)項(xiàng)目交付的過(guò)程帶來(lái)很大的影響。從軟件開(kāi)發(fā)初期的自動(dòng)化歷程，到目前企業(yè)進(jìn)行信息化的終極目標(biāo)，項(xiàng)目贊助人對(duì)自己投資一套軟件所希望達(dá)到的最終目的還是非常清晰，不管是為了提升工作效率，還是為了強(qiáng)化企業(yè)的能力，往往在項(xiàng)目開(kāi)始的時(shí)候項(xiàng)目贊助人已經(jīng)有一個(gè)很明確的思維和方向，問(wèn)題是軟件開(kāi)發(fā)的專家如何能夠提交項(xiàng)目的交付，滿足項(xiàng)目資助人的期盼而已。

　　這種轉(zhuǎn)變讓項(xiàng)目成功的衡量因素也發(fā)生了實(shí)質(zhì)上的變化。項(xiàng)目經(jīng)理被衡量的準(zhǔn)則已經(jīng)不單是否能夠如期在預(yù)算內(nèi)完成交付來(lái)衡量這個(gè)項(xiàng)目是否成功。項(xiàng)目經(jīng)理的項(xiàng)目交付能夠?yàn)轫?xiàng)目贊助人和項(xiàng)目關(guān)系人提供多少效益和能力作為實(shí)際上的衡量指標(biāo)。很多時(shí)候我們認(rèn)為項(xiàng)目已經(jīng)完成，但客戶還是不滿意，還是認(rèn)為未能達(dá)到預(yù)期的成果，原因就在于項(xiàng)目的交付只能做到科技的應(yīng)用，但沒(méi)有帶來(lái)任何價(jià)值可以提升客戶的應(yīng)用效益和能力，所以客戶一直認(rèn)為未能完成驗(yàn)收的確認(rèn)。

　　驚人的數(shù)據(jù)

　　在2005年中期開(kāi)始，在一項(xiàng)對(duì)軟件開(kāi)發(fā)困境的研究過(guò)程中，特別要求23位項(xiàng)目經(jīng)理提供一些有關(guān)返工的簡(jiǎn)單數(shù)據(jù)，要求項(xiàng)目經(jīng)理在項(xiàng)目開(kāi)發(fā)的過(guò)程中簡(jiǎn)單記錄各階段工作需要進(jìn)行返工的次數(shù)，不管是客戶提出返工要求或技術(shù)人員主動(dòng)因應(yīng)開(kāi)發(fā)內(nèi)容需要進(jìn)行返工，目的是希望能夠把握“變動(dòng)”在軟件開(kāi)發(fā)過(guò)程中那些階發(fā)生，然后研究該選擇那些開(kāi)發(fā)模式來(lái)改變我們的軟件開(kāi)發(fā)方法。

　　這批項(xiàng)目在6個(gè)月內(nèi)分別起動(dòng)，原來(lái)的目標(biāo)分別從4個(gè)月到12個(gè)月完成項(xiàng)目的移交。挑選的項(xiàng)目全部均可以把開(kāi)發(fā)過(guò)程分類成“信息調(diào)研”，“需求分析”，“系統(tǒng)設(shè)計(jì)”，“系統(tǒng)開(kāi)發(fā)”，“用戶測(cè)試”，和“項(xiàng)目移交”等6個(gè)階段。

　　32個(gè)月后，有18個(gè)項(xiàng)目所提供的數(shù)據(jù)比較完整，可以進(jìn)行參考和研究，其中有3個(gè)項(xiàng)目在深圳，5個(gè)項(xiàng)目在上海，4個(gè)項(xiàng)目在武漢，6個(gè)項(xiàng)目在北京。其中只有1個(gè)項(xiàng)目能夠順利依時(shí)移交，13個(gè)項(xiàng)目經(jīng)過(guò)不斷修改后完成移交，余下4個(gè)項(xiàng)目仍處于暫停狀態(tài)，繼續(xù)與客戶協(xié)商中。

　　各階段中的數(shù)據(jù)分別可以歸類出6種返工內(nèi)容，分別是邏輯及流程的修改，用戶界面修改，數(shù)據(jù)結(jié)構(gòu)或數(shù)據(jù)組織修改，改變所用的程序語(yǔ)言，系統(tǒng)的反應(yīng)速度和表現(xiàn)未附理想，新增功能或需求的修改，和其他不屬于上述類別的修改。以下是18個(gè)項(xiàng)目所收集的數(shù)據(jù)：



　　數(shù)據(jù)代表的涵義說(shuō)明

　　上述數(shù)據(jù)從2005年11月開(kāi)始收集，分別與23個(gè)項(xiàng)目的負(fù)責(zé)人在數(shù)據(jù)收集完成后進(jìn)行訪談，理解數(shù)據(jù)的準(zhǔn)確性和返工背后的原因，最后對(duì)5個(gè)項(xiàng)目收集的數(shù)據(jù)因未能確認(rèn)其準(zhǔn)確性，故此只采用18個(gè)項(xiàng)目中收集到的數(shù)據(jù)，到去年10月才能夠進(jìn)行匯總、整理、和分析。

　　表格1中的數(shù)據(jù)說(shuō)明大部份的返工分別來(lái)自開(kāi)發(fā)階段，共185次，相當(dāng)于每個(gè)項(xiàng)目平均需要10次以上的返工；在用戶測(cè)試階段，共103次，相當(dāng)于每個(gè)項(xiàng)目平均需要6次以上的返工；信息調(diào)研階段，共60次，相當(dāng)于每個(gè)項(xiàng)目平均需要3次以上的返工；和移交階段，共41次相當(dāng)于每個(gè)項(xiàng)目需要2次以上的返工。至于需求分析和系統(tǒng)設(shè)計(jì)兩個(gè)階段的返工次數(shù)較少，主要原因是客戶基本上不重視這兩個(gè)階段的成果，他們要看的是編程（開(kāi)發(fā)）的結(jié)果，測(cè)試的結(jié)果和移交（應(yīng)用）的結(jié)果。

　　信息調(diào)研階段
　　這個(gè)階段是針對(duì)調(diào)研報(bào)告提交后后被客戶要求對(duì)內(nèi)容調(diào)整和修改的次數(shù)統(tǒng)計(jì)。平均達(dá)到3次以上的返工，主要是對(duì)邏輯和操作流程的理解，占了80％以上。其他20％的修改包括內(nèi)容不全，需要補(bǔ)充或擴(kuò)大調(diào)研的范圍所導(dǎo)致的修改。

　　在這個(gè)過(guò)程中，項(xiàng)目經(jīng)理及高級(jí)系統(tǒng)分析員主要是跟客戶代表進(jìn)行訪談，透過(guò)訪談的內(nèi)容建立功能需求說(shuō)明。調(diào)研報(bào)告的內(nèi)容基本上主要是說(shuō)明軟件的主要功能需求，但沒(méi)有任何一個(gè)項(xiàng)目以任何形式加上明確的范圍說(shuō)明?？蛻糸喿x后會(huì)提出修改的反饋，明確說(shuō)明需要加上那些功能等內(nèi)容在調(diào)研報(bào)告中。經(jīng)過(guò)三數(shù)次的修改后，18個(gè)項(xiàng)目的調(diào)研報(bào)告都沒(méi)有被客戶以任何方式進(jìn)行確認(rèn)，提交后項(xiàng)目經(jīng)理也沒(méi)有要求客戶確認(rèn)后交回項(xiàng)目組。技術(shù)人員便開(kāi)始進(jìn)行下階段的工作。

　　需求分析階段

　　這一個(gè)階段的修改次數(shù)平均只有1.44次，主要的原因是大部份項(xiàng)目經(jīng)理把信息調(diào)研階段中的一些新增功能或需求說(shuō)明包括在上階段中記錄并處理。項(xiàng)目經(jīng)理及系統(tǒng)分析員對(duì)信息調(diào)研和需求分析的工作內(nèi)容相當(dāng)模糊，未能準(zhǔn)確分辨兩個(gè)階段工作的實(shí)際差異。

　　對(duì)項(xiàng)目經(jīng)理及負(fù)責(zé)進(jìn)行調(diào)研的技術(shù)人員來(lái)說(shuō)，不明確需求分析的工作內(nèi)容主要是透過(guò)調(diào)研階段希望客戶能夠提供系統(tǒng)所需的功能需求，所以沒(méi)有任何需求分析的工作需要處理，而進(jìn)行的分析工作只局限與技術(shù)如何能夠做到，換句話說(shuō)，在需求分析的過(guò)程中，他們的重點(diǎn)是如何利用技術(shù)來(lái)達(dá)到目的，這基本上是屬于下一個(gè)階段系統(tǒng)設(shè)計(jì)的實(shí)際工作。

　　系統(tǒng)設(shè)計(jì)階段

　　從需求分析到系統(tǒng)設(shè)計(jì)基本上常常缺乏一個(gè)明確的交接點(diǎn)。像信息調(diào)研和需求分析兩個(gè)階段的交接一樣，缺乏任何明確的階段交付說(shuō)明。大部份項(xiàng)目經(jīng)理也沒(méi)有對(duì)技術(shù)人員說(shuō)明個(gè)別階段的交付物，并監(jiān)控有關(guān)內(nèi)容，除了調(diào)研報(bào)告外，18個(gè)項(xiàng)目都沒(méi)有提供任何分析說(shuō)明（Requirement Statements）或系統(tǒng)設(shè)計(jì)書(shū)。

　　在設(shè)計(jì)階段過(guò)程中，技術(shù)人員多開(kāi)始就客戶提供的功能及需求進(jìn)行編程，首先是編寫(xiě)一、兩個(gè)主要屏幕的影像，進(jìn)而編寫(xiě)有關(guān)邏輯。既然缺乏任何設(shè)計(jì)說(shuō)明，那么任何修改的要求自然被編列在開(kāi)發(fā)過(guò)程中，故此這個(gè)階段與上階段一樣，修改的次數(shù)較少，18個(gè)項(xiàng)目只有25次返工，平均為1.389次。

　　系統(tǒng)開(kāi)發(fā)階段

　　在18個(gè)項(xiàng)目中共記錄185次返工要求，平均每個(gè)項(xiàng)目達(dá)到差不多10次以上的返工或修改，是所有階段返工率最高的一個(gè)環(huán)節(jié)。而且這些返工的要求往往是口頭上的要求，通常發(fā)生在每周面向客戶匯報(bào)進(jìn)度及成果后，客戶審視技術(shù)人員的工作成果（多以演示方式進(jìn)行）后被要求對(duì)有關(guān)程序進(jìn)行調(diào)整或修改。記錄的次數(shù)只記錄整體返工的要求，包括移交完成的交付進(jìn)程中的任何程序的邏輯及界面，并沒(méi)有分辨記錄每一個(gè)模塊或功能的確實(shí)返工次數(shù)。有關(guān)項(xiàng)目經(jīng)理也承認(rèn)實(shí)際的返工要求如果針對(duì)個(gè)別模塊或界面進(jìn)行記錄，次數(shù)可能達(dá)到記錄的七倍或更高。

　　大部份的返工以界面修改為主，平均每個(gè)項(xiàng)目達(dá)到4次，共計(jì)72次數(shù)。第二是新增功能的修改，多基于前期的調(diào)研，分析及設(shè)計(jì)沒(méi)有被包括在內(nèi)的一些額外需求，平均達(dá)到2.39次共43次。接下來(lái)是邏輯或流程的返工，平均超過(guò)2次工37次。數(shù)據(jù)的組織及處理方面，平均超過(guò)1.33次以上工達(dá)到24次數(shù)。往往邏輯及數(shù)據(jù)組織的返工原因多源自功能及界面的返工所影響。

　　用戶測(cè)試階段

　　這是開(kāi)發(fā)過(guò)程中僅次于系統(tǒng)開(kāi)發(fā)階段的第二高返工次數(shù)，達(dá)到103次，平均每個(gè)項(xiàng)目有差不多六次的返工要求。返工的內(nèi)容多以界面修改為主，平均每個(gè)項(xiàng)目被要求界面返工的次數(shù)達(dá)到2.33次，共計(jì)43次。接下來(lái)是數(shù)據(jù)結(jié)構(gòu)及組織的修改，平均次數(shù)達(dá)到1.78次共32次，占第三位的是新增功能所導(dǎo)致的返工，平均每一個(gè)項(xiàng)目有一次的要求工18次。

　　項(xiàng)目移交階段

　　比較突出的只有數(shù)據(jù)結(jié)構(gòu)及組織的返工，平均每一個(gè)項(xiàng)目便需要進(jìn)行1.56次的修改，共達(dá)到28次數(shù)。主要的原因來(lái)自最終用戶對(duì)界面中的數(shù)據(jù)來(lái)源不認(rèn)同，需要來(lái)自其他數(shù)據(jù)庫(kù)的內(nèi)容而進(jìn)行的修改。
　　次數(shù)記錄分析

　　這次調(diào)查的結(jié)果相當(dāng)有意義，從收集到的數(shù)據(jù)可以很清楚地理解目前軟件工業(yè)所面對(duì)的困境，并希望從中找出一個(gè)方向，改善軟件工業(yè)的未來(lái)發(fā)展空間。

　　從收集數(shù)據(jù)后對(duì)項(xiàng)目經(jīng)理進(jìn)行的訪談中發(fā)行，基本上在整個(gè)開(kāi)發(fā)過(guò)程中沒(méi)有任何監(jiān)控及評(píng)估。每一個(gè)工作的內(nèi)容互相重疊，尤其是“信息調(diào)研”，“需求分析”和“系統(tǒng)設(shè)計(jì)”這三個(gè)階段，大部份技術(shù)人員對(duì)每一個(gè)階段的工作目標(biāo)都不太明確，對(duì)于需求的來(lái)源更完全依賴客戶提供。接下來(lái)的“系統(tǒng)設(shè)計(jì)”和“系統(tǒng)開(kāi)發(fā)”這兩個(gè)階段也是互相重疊，一面設(shè)計(jì)，一面開(kāi)發(fā)。到程序編寫(xiě)完成（同時(shí)技術(shù)人員完成初步模塊測(cè)試）后進(jìn)行用戶測(cè)試時(shí)才發(fā)現(xiàn)實(shí)際的工作范圍遠(yuǎn)遠(yuǎn)超過(guò)預(yù)期的估計(jì)，導(dǎo)致大力的返工及修改。正式移交的時(shí)候也需要因應(yīng)用戶的應(yīng)用環(huán)境和地理分布對(duì)項(xiàng)目進(jìn)行調(diào)整。在整個(gè)開(kāi)發(fā)過(guò)程中，收集的數(shù)據(jù)基本上體現(xiàn)了“三邊”（邊想，邊做，邊改）的軟件開(kāi)發(fā)模式應(yīng)用。

　　軟件開(kāi)發(fā)模型又稱軟件生命周期模型，它制定了一系列的步驟或活動(dòng)，軟件開(kāi)發(fā)人員或開(kāi)發(fā)團(tuán)隊(duì)需要在開(kāi)發(fā)中按照軟件模型中指定的步驟來(lái)進(jìn)行軟件開(kāi)發(fā)。實(shí)際上，很少有某個(gè)開(kāi)發(fā)團(tuán)隊(duì)完全遵循開(kāi)發(fā)模型的規(guī)定，這是因?yàn)槊總€(gè)模型都會(huì)有一定的限定條件和應(yīng)用范圍，并不是完全適應(yīng)所有的開(kāi)發(fā)環(huán)境。

　　在這里我們探討一些比較經(jīng)典的開(kāi)發(fā)模型和近來(lái)比較風(fēng)靡的開(kāi)發(fā)模型，同時(shí)說(shuō)明它們的使用范圍和特點(diǎn)。

　　建造修補(bǔ)模型

　　也是我們上述所說(shuō)的“三邊”開(kāi)發(fā)模型。在該模型中不使用規(guī)格說(shuō)明書(shū)（它明確地說(shuō)明了系統(tǒng)的功能需求，從技術(shù)角度定義了我們需要做什么）。同時(shí)該模型也不嘗試去設(shè)計(jì)一個(gè)軟件，僅僅是將所有的軟件構(gòu)思全部用代碼表述，軟件的設(shè)計(jì)和編程思路完全維持在程序員的頭腦中。顯然，它不適應(yīng)小組開(kāi)發(fā)，同時(shí)也不便于維護(hù)。因?yàn)?，我們無(wú)法從程序員的頭腦中“抓出”任何準(zhǔn)確的對(duì)于軟件的任何描述。 [NextPage]

　　瀑布模型

　　為了使得軟件工程可以協(xié)作開(kāi)發(fā)和易于維護(hù)，在自動(dòng)化時(shí)代一種較為有效的模型被開(kāi)發(fā)團(tuán)隊(duì)廣泛的接受，那就是瀑布模型。

　　瀑布模型一般由“需求階段”、“規(guī)格說(shuō)明階段”、“設(shè)計(jì)階段”、“實(shí)現(xiàn)階段”、“集成階段”、和“推廣階段”。為了能夠全面的分析各個(gè)模型的特點(diǎn)，下面需要簡(jiǎn)要地介紹該模型的每個(gè)階段：

　　在需求階段，是由系統(tǒng)分析師來(lái)確定整個(gè)系統(tǒng)的功能需求和非功能需求（如“可靠性和可維護(hù)性”等軟件的特性），然后又客戶和一個(gè)軟件質(zhì)量保證組（Software Quality Assurance，SQA）與客戶一同確定需求。實(shí)際上需求階段包含兩個(gè)活動(dòng)，需求分析與需求獲取。

　　在需求獲得認(rèn)可后需要有同一小組建立規(guī)格說(shuō)明文檔，以文字的方式說(shuō)明系統(tǒng)要做些什么。最終該文檔需要獲得客戶的認(rèn)可，同時(shí)客戶將以該文檔的內(nèi)容來(lái)驗(yàn)收項(xiàng)目。當(dāng)然，在該階段完成后就可以指定軟件項(xiàng)目管理計(jì)劃，來(lái)規(guī)定開(kāi)發(fā)中的每個(gè)活動(dòng)和成果、所需的資源、時(shí)間、成本等。

　　接下來(lái)，系統(tǒng)工程師將會(huì)在明確技術(shù)規(guī)格說(shuō)明書(shū)后，建立出模塊和它們的關(guān)聯(lián)，從而構(gòu)成系統(tǒng)的結(jié)構(gòu)設(shè)計(jì)；所以該活動(dòng)也成為結(jié)構(gòu)設(shè)計(jì)。系統(tǒng)的結(jié)構(gòu)設(shè)計(jì)完成后，某些時(shí)候會(huì)對(duì)每個(gè)模塊選定一個(gè)算法和詳細(xì)的數(shù)據(jù)結(jié)果，這時(shí)是從一個(gè)單一的模塊角度來(lái)進(jìn)行的考慮。當(dāng)完成設(shè)計(jì)后還需要對(duì)設(shè)計(jì)進(jìn)行測(cè)試，一般來(lái)說(shuō)是通過(guò)對(duì)設(shè)計(jì)的認(rèn)為審查來(lái)完成。

　　當(dāng)將設(shè)計(jì)的說(shuō)明交給程序員時(shí)，開(kāi)發(fā)將會(huì)進(jìn)入變成是現(xiàn)階段，這里程序員負(fù)責(zé)每個(gè)模塊程序的編寫(xiě)和測(cè)試，確保程序的測(cè)試結(jié)果與設(shè)計(jì)說(shuō)明中所描述一致。

　　當(dāng)所有程序編寫(xiě)完成后，將會(huì)進(jìn)入集成階段，也就是以產(chǎn)品或系統(tǒng)的角度對(duì)所有模塊進(jìn)行系統(tǒng)級(jí)別的測(cè)試。這里主要的工作就是對(duì)程序進(jìn)行測(cè)試，所以該階段需要編寫(xiě)詳細(xì)的測(cè)試文檔。

　　一旦客戶接受了產(chǎn)品，任何修改（無(wú)論是完善性維護(hù)還是糾錯(cuò)性維護(hù)）都會(huì)被視為維護(hù)階段。這里需要指明的是維護(hù)的順序，可能有些維護(hù)需要回溯到設(shè)計(jì)階段甚至是技術(shù)規(guī)格說(shuō)明書(shū)階段或需求階段。

　　瀑布模型的優(yōu)點(diǎn)是顯而易見(jiàn)的，由于線性的開(kāi)發(fā)結(jié)構(gòu)它更加利于管理。瀑布模型適應(yīng)于自動(dòng)化項(xiàng)目，因?yàn)槟菚r(shí)的功能需求可以從范圍和業(yè)務(wù)流程中準(zhǔn)確識(shí)別；但是，對(duì)于其他類型項(xiàng)目瀑布模型的結(jié)構(gòu)將會(huì)產(chǎn)生致命的缺陷，即客戶在項(xiàng)目初期的需求不明確性導(dǎo)致開(kāi)發(fā)出的產(chǎn)品并不是客戶所需要的。

　　快速原型開(kāi)發(fā)模型

　　對(duì)于該模型大多數(shù)軟件工程師們不會(huì)感覺(jué)到陌生?！翱焖僭汀笔且粋€(gè)與產(chǎn)品子集功能上相同的工作模型。例如，目標(biāo)產(chǎn)品是處理帳務(wù)的財(cái)會(huì)軟件，那么快速原型則需要建立對(duì)應(yīng)功能則是交互的界面和打印的報(bào)表。

　　快速原型基本上與瀑布模型是相一致的。它的第一步是建造一個(gè)快速原型，來(lái)代替需求階段的需求分析和獲取。客戶和未來(lái)的用戶可以使用該快速原型，同時(shí)可以提出反饋，然后程序員進(jìn)一步修改快速原型，客戶再進(jìn)行確認(rèn)；直到捕捉到客戶所有的功能需求為止，也就是客戶認(rèn)為這個(gè)快速原型滿足了它的大多數(shù)要求為止。

　　一旦確定了客戶的需求，就會(huì)進(jìn)入技術(shù)規(guī)格說(shuō)明階段，制定詳細(xì)的規(guī)格說(shuō)明書(shū)，以備系統(tǒng)設(shè)計(jì)師來(lái)設(shè)計(jì)系統(tǒng)。

　　快速原型的引入主要是為了確立明確的功能需求而設(shè)。它的主要構(gòu)思是通過(guò)一個(gè)簡(jiǎn)單的原型，從系統(tǒng)的角度來(lái)引出和明確客戶的期盼和愿望。當(dāng)然它可以使得客戶在第一時(shí)間了解到系統(tǒng)的功能到底是如何運(yùn)作的，但是對(duì)于信息化時(shí)代該方法顯然并不理想。如對(duì)于一個(gè)無(wú)法明確表明的“功能”，我們又如何建立該原型呢？我們到底從何而知到在什么時(shí)間上有客戶確認(rèn)的原型是系統(tǒng)所能夠體現(xiàn)的主要功能呢？我們從何而知該項(xiàng)目的范圍呢？我們有從何而知項(xiàng)目的工作計(jì)劃到底應(yīng)當(dāng)如何制定出里程碑呢？

　　顯然，很多問(wèn)題困擾著快速原型的開(kāi)發(fā)，尤其在今天的信息化項(xiàng)目中油然突出。

　　增量和演化開(kāi)發(fā)模型

　　軟件是建造出來(lái)的，而不是寫(xiě)出來(lái)的。根據(jù)這個(gè)思想，增量模型被設(shè)計(jì)出來(lái)，它主要強(qiáng)調(diào)的是每一步軟件的開(kāi)發(fā)都是建立在前一步軟件開(kāi)發(fā)的基礎(chǔ)之上的。

　　增量模型將會(huì)分階段的交付產(chǎn)品，在每一階段都交付一個(gè)可用的產(chǎn)品，同時(shí)該產(chǎn)品滿足了客戶需求的一個(gè)子集。所以，整個(gè)系統(tǒng)備份為若干個(gè)構(gòu)件，一個(gè)構(gòu)建一個(gè)構(gòu)建地交付產(chǎn)品。那么，在每一個(gè)階段客戶都會(huì)得到一個(gè)滿足了他們某一部分需求的產(chǎn)品，同時(shí)他們可以在其他產(chǎn)品沒(méi)有構(gòu)建出來(lái)時(shí)就可以初步了解該構(gòu)件的使用方法。

　　增量模型的優(yōu)點(diǎn)是顯然的，即減少了客戶對(duì)于新產(chǎn)品的適應(yīng)度、客戶可以分批地為每個(gè)構(gòu)件付款（有利于客戶的資金周轉(zhuǎn)）。但是，增量模型的問(wèn)題也是顯著的，即如何組織一個(gè)開(kāi)放的結(jié)構(gòu)使得該模型不會(huì)退化到建造修補(bǔ)模型。

　　與增量模型相對(duì)應(yīng)的是演化模型，它強(qiáng)調(diào)的是增量和迭代兩個(gè)特征的結(jié)合。演化模型的目標(biāo)是克服瀑布模型中線性開(kāi)發(fā)帶出交付上的風(fēng)險(xiǎn)，即只有到了最終交付時(shí)才獲知哪部分產(chǎn)品需要維護(hù)，這會(huì)使得整個(gè)項(xiàng)目的開(kāi)發(fā)成本和時(shí)間遠(yuǎn)遠(yuǎn)超出預(yù)支。由于在維護(hù)階段修改軟件的費(fèi)用要遠(yuǎn)遠(yuǎn)大于在需求或設(shè)計(jì)階段修改軟件的費(fèi)用，所以演化模型使用了迭代和增量的思想將整個(gè)軟件的開(kāi)發(fā)風(fēng)險(xiǎn)分散到不同構(gòu)建的不同階段。

　　演化模型的主要步驟是首先開(kāi)發(fā)出系統(tǒng)的一個(gè)核心功能，使得客戶可以與開(kāi)發(fā)人員一同確認(rèn)該功能，這樣開(kāi)發(fā)人員將會(huì)得到第一手的經(jīng)驗(yàn)；開(kāi)發(fā)人員將會(huì)根據(jù)客戶的反饋進(jìn)一步開(kāi)發(fā)出其他功能或進(jìn)一步擴(kuò)充該功能；最終，知道建立一個(gè)完整的系統(tǒng)位置。

　　而且每一次開(kāi)發(fā)都會(huì)是涉及“風(fēng)險(xiǎn)分析”、“原型建立”、“實(shí)現(xiàn)原型”、“評(píng)估原型”。這樣會(huì)構(gòu)成多次迭代來(lái)完成整個(gè)系統(tǒng)的開(kāi)發(fā)。


　　演化模型的特點(diǎn)基本上與增量模型一致，但是對(duì)于演化模型的管理是一個(gè)主要的阻力，也就是我們很難確認(rèn)整個(gè)系統(tǒng)的里程碑，成本和時(shí)間基線。

　　統(tǒng)一過(guò)程模型

　　這里和下面介紹的開(kāi)發(fā)模型是近期在業(yè)界比較風(fēng)靡的兩個(gè)主要的模型；而對(duì)于它的應(yīng)用效果，由于各種原因，我們不給出具體的評(píng)估，僅僅是是從使用角度進(jìn)行一個(gè)簡(jiǎn)單分析（或者是提出一些疑問(wèn)）。

　　為了利用從上述模型的成功和失敗的歷史中學(xué)到的一些有益于軟件工程的知識(shí)，統(tǒng)一過(guò)程模型尋求了一中方法來(lái)改進(jìn)原有的過(guò)程，包括瀑布模型、演化模型等。也就是，統(tǒng)一過(guò)程融入了瀑布模型的線性結(jié)構(gòu)和演化模型的增量和迭代思想。

　　統(tǒng)一過(guò)程首相建立了整個(gè)項(xiàng)目的不同階段，它包括“初始階段”、“細(xì)化階段”、“構(gòu)造階段”、“移交階段”。同時(shí)對(duì)于每個(gè)階段中保留了瀑布模型的活動(dòng)，這里被稱為工作流，即從需求、分析到設(shè)計(jì)和實(shí)現(xiàn)、測(cè)試這五個(gè)活動(dòng)。所以，我們可以將其理解為一個(gè)二維坐標(biāo)，工作流是一個(gè)豎坐標(biāo)，階段構(gòu)成了橫坐標(biāo)。但是，二維坐標(biāo)并不是統(tǒng)一過(guò)程的主要思想，它的主要思想是每個(gè)豎坐標(biāo)制定的活動(dòng)可能會(huì)產(chǎn)生多次迭代，每個(gè)迭代會(huì)隨著橫坐標(biāo)（階段）的進(jìn)展而產(chǎn)生變更，會(huì)逐漸減少直至最終消失。

　　每個(gè)階段可以構(gòu)成一個(gè)里程碑，在每個(gè)里程碑上可以捕捉到軟件項(xiàng)目生命周期中的重要決策點(diǎn)。如初始階段關(guān)注的是項(xiàng)目計(jì)劃和風(fēng)險(xiǎn)評(píng)估，細(xì)化階段關(guān)注的是系統(tǒng)的總體構(gòu)架，構(gòu)造階段建立系統(tǒng)等。

　　正如我們開(kāi)始所說(shuō)的，我們并不準(zhǔn)備對(duì)該模型進(jìn)行評(píng)價(jià)。這里僅僅是提出一些問(wèn)題供大家思考。首先，我們?nèi)绾沃烂總€(gè)里程碑的制定點(diǎn)？其次，如何確立我們建立出了完整的功能需求？再次，每個(gè)階段中到底要包含多少個(gè)迭代（階段中的子階段）？最終，如何維護(hù)在每次迭代中需求、設(shè)計(jì)、代碼等的一致性？

　　業(yè)務(wù)構(gòu)件開(kāi)發(fā)模型

　　業(yè)務(wù)構(gòu)件開(kāi)發(fā)其實(shí)并不屬于軟件開(kāi)發(fā)模型，它僅僅是一個(gè)利用業(yè)務(wù)角度來(lái)架構(gòu)整個(gè)系統(tǒng)的一種手段（沒(méi)有使用“方法”一詞主要是與開(kāi)發(fā)模型中的方法系進(jìn)行區(qū)別，以免造成歧義）。 [NextPage]

　　實(shí)際上，面向業(yè)務(wù)構(gòu)建整個(gè)系統(tǒng)是需要一個(gè)完善的開(kāi)發(fā)模型來(lái)說(shuō)明它如運(yùn)作的，這也是本書(shū)的主題之一。所以，在這里僅僅介紹當(dāng)前較為流行的主要架構(gòu)的特征。

　　現(xiàn)在最為主要的分為兩種，一是以服務(wù)角度（服務(wù)構(gòu)件）來(lái)建立系統(tǒng)架構(gòu)，二是以業(yè)務(wù)流程角度建立系統(tǒng)架構(gòu)。但是，實(shí)際上他們討論的都是同一件事情，即先確立業(yè)務(wù)流程，再以服務(wù)為單元架構(gòu)系統(tǒng)。

　　那么，這些方法是否可行呢？實(shí)踐證明他們是可行的，但是效果并不十分理想（不要忘記今天項(xiàng)目的70%的失敗率）。我們也不準(zhǔn)備分析它們的優(yōu)缺點(diǎn)，僅是想指出在使用它們時(shí)讀者應(yīng)當(dāng)考慮的問(wèn)題。如，如何知道一個(gè)業(yè)務(wù)流程是客戶所需的呢？如何縮短建立業(yè)務(wù)流程的時(shí)間和提高每個(gè)流程的明確度（任務(wù)明確）呢？如何確立不同業(yè)務(wù)構(gòu)建之間的架構(gòu)是合理的呢？如何確立一個(gè)業(yè)務(wù)構(gòu)件是必需的呢？

　　模型在信息化項(xiàng)目應(yīng)用分析

　　在對(duì)這些模型進(jìn)一步剖析前，我們有必要在回顧一下我們的艱難歷程，來(lái)判斷是否在信息時(shí)代我們可以使用上述的軟件過(guò)程就可以達(dá)到那些模型所承諾的目標(biāo)呢？

　　對(duì)于瀑布模型，在信息化時(shí)代已經(jīng)很難獲得在自動(dòng)化時(shí)代的成功了。因?yàn)?，我們很難再像自動(dòng)化時(shí)代那樣，存在一個(gè)業(yè)務(wù)流程來(lái)確立系統(tǒng)的功能需求，那么規(guī)格說(shuō)明書(shū)和設(shè)計(jì)就會(huì)顯得蒼白無(wú)力。反之，規(guī)格說(shuō)明書(shū)和設(shè)計(jì)反而使得系統(tǒng)的構(gòu)建更加復(fù)雜，因?yàn)槿魏涡枨蟮淖兏紩?huì)或多或少地?fù)p害系統(tǒng)的模塊劃分和系統(tǒng)架構(gòu)，那么試想對(duì)于一個(gè)10萬(wàn)行代碼的項(xiàng)目而言，如果需求的變更致使設(shè)計(jì)階段的成果超過(guò)了一半產(chǎn)生了變更，那么至少這種開(kāi)發(fā)模型已不再是瀑布模型。因?yàn)槠俨寄Ｐ偷奶攸c(diǎn)就是穩(wěn)固的近似線性結(jié)構(gòu)的開(kāi)發(fā)結(jié)構(gòu)。

　　對(duì)于快速原型而言，信息化項(xiàng)目則是它的“阿喀琉斯腳踝”。因?yàn)?，信息化?xiàng)目不再是傳統(tǒng)的自動(dòng)化改善，而是系統(tǒng)帶出客戶期盼的價(jià)值。那么，我們又如何建立一個(gè)原型讓客戶體驗(yàn)?zāi)?？試想，如果我們建立出一模一樣的未?lái)系統(tǒng)所對(duì)應(yīng)的原型，那么我們希望客戶告訴我們什么呢？這個(gè)系統(tǒng)是界面還是報(bào)表，顯然這根本不可能的；客戶都不知道他們的業(yè)務(wù)操作流程是如何運(yùn)轉(zhuǎn)的，又如何告訴我們這些界面可提供什么呢。當(dāng)然，原型法的目的是引導(dǎo)客戶的需求來(lái)完善系統(tǒng)，但是我們又如何知道一個(gè)原型對(duì)于捕捉這些界面上的需求或報(bào)表的需求到底是否完整呢；無(wú)論是客戶還是我們根本不知道我們?cè)谧鍪裁?，到底什么時(shí)候才是客戶滿意度獲得了滿足呢？

　　演化過(guò)程顯然更不會(huì)在信息化時(shí)代獲得成功，如果我們先開(kāi)發(fā)出系統(tǒng)的核心功能，然后根據(jù)以構(gòu)建的功能進(jìn)一步向“系統(tǒng)”挺進(jìn)。那么，在客戶和我們都不知道系統(tǒng)如何提供價(jià)值時(shí)，試問(wèn)哪個(gè)功能才是核心功能呢？我們尚且不知道我們交付什么時(shí)，試問(wèn)我們?cè)趺粗佬枰嗌俅蔚趴梢詷?gòu)建出最終的系統(tǒng)呢？即使在最佳假設(shè)的情況下（客戶決定了核心功能，雖然不知道多少次迭代，但是可以預(yù)估最大上限），系統(tǒng)的頻繁變更會(huì)使得最終我們退化到建造修補(bǔ)模型。

　　那么，現(xiàn)在風(fēng)靡業(yè)界的統(tǒng)一過(guò)程又如何呢？因?yàn)?，在前面我們已?jīng)說(shuō)明不會(huì)對(duì)該模型評(píng)價(jià)，所以我們不會(huì)具體分析該模型在信息化時(shí)代的效果如何。在這里，我們只是想提出兩個(gè)問(wèn)題：范圍從哪里建立呢？如何通過(guò)迭代來(lái)明確地說(shuō)明在這次迭代中功能需求是否完整呢？

　　軟件開(kāi)發(fā)過(guò)程分析

　　很多軟件工程師都會(huì)問(wèn)自己，“為什么不能像建筑設(shè)計(jì)師那樣輕松呢？”，或是問(wèn)“為什么不能像服裝設(shè)計(jì)師那樣美妙的工作呢？”。是的，我們多么羨慕建筑設(shè)計(jì)師?。含F(xiàn)存的任何一座建筑物都不會(huì)再建筑時(shí)更改其初期的建筑設(shè)計(jì)。當(dāng)然，軟件工程的主要特征就是可變性。但是，正如我們?cè)谇懊嫠f(shuō)的，任何事物都會(huì)有其界限，要是超越了這個(gè)自然的界限無(wú)疑我們將付出慘重的代價(jià)。

　　大多數(shù)軟件過(guò)程的提出不是為了停留在學(xué)院內(nèi)供學(xué)生來(lái)考試和學(xué)習(xí)的，軟件過(guò)程的制定是為了從過(guò)去的經(jīng)驗(yàn)和學(xué)到的知識(shí)中解決和改善原有過(guò)程的問(wèn)題，從而使得項(xiàng)目的成功率大大增加。

　　雖然我們分析了這些軟件構(gòu)成在信息化項(xiàng)目中的弊病，但是我們還沒(méi)有明確這些過(guò)程的特征；所以我們還分析這些軟件過(guò)程是否解決了它們所要解決的問(wèn)題后，我們才可以準(zhǔn)確的分析它們。

　　這里我們僅僅分析瀑布模型、快速原型模型、演化模型。

　　瀑布模型的引入是為了解決最初的建造修補(bǔ)模型的無(wú)序化或無(wú)結(jié)構(gòu)化引入的，瀑布模型希望將構(gòu)建軟件的過(guò)程“程序化”，使得我們可以明確我們每一個(gè)活動(dòng)的特征，如是開(kāi)發(fā)還是編碼。這樣我們可以根據(jù)不同的活動(dòng)特征和產(chǎn)物（包括對(duì)應(yīng)產(chǎn)物的文檔）進(jìn)行規(guī)范化管理。但是，該模型能夠成功被應(yīng)用是有其依賴的條件的，那就是項(xiàng)目范圍必須明確。所以，自動(dòng)化時(shí)代該模型得到了廣泛的成功應(yīng)用。但是，由于該模型需要在項(xiàng)目初期建立明確的、穩(wěn)固的需求（所有后續(xù)活動(dòng)的原點(diǎn)）。所以在信息化時(shí)代基本上該模型的假設(shè)被徹底地毀滅。沒(méi)有明確的范圍，那么過(guò)多的變更將會(huì)超越軟件可變性的極限，即使在不考慮成本的情況下，軟件的構(gòu)建依然無(wú)法成功。

　　快速開(kāi)發(fā)原型希望能夠解決需求不明確的問(wèn)題，所以引入了快速原型使得可以通過(guò)引導(dǎo)客戶的期盼來(lái)明確系統(tǒng)的功能需求。顯然，通過(guò)我們?cè)诘谝徽碌摹靶枨笈c范圍”中的論述，我們知道功能需求與客戶需求是有區(qū)別的。試圖將引導(dǎo)客戶告訴我們功能需求，我們必然會(huì)在項(xiàng)目開(kāi)發(fā)中面臨更多的變更。因?yàn)椋蛻舾嬷覀兊娜魏涡畔⑹且f(shuō)明最終系統(tǒng)的質(zhì)量要求，而不是系統(tǒng)的功能需求；如在“特長(zhǎng)班報(bào)名項(xiàng)目”中，我們可能建立了一個(gè)“報(bào)名菜單”界面來(lái)引導(dǎo)客戶對(duì)于報(bào)名系統(tǒng)的功能需求，可是我們又如何知道到什么時(shí)候才可以獲得客戶的完全認(rèn)同呢？可能唯一的答案就是，客戶說(shuō)這些就是我所要的。好的，我們接下來(lái)按照模型的要求進(jìn)行了相應(yīng)的活動(dòng)，最終帶出了產(chǎn)品?？墒牵蛻魠s在驗(yàn)收時(shí)說(shuō)，“啊，我忘了這個(gè)報(bào)名系統(tǒng)還需要這樣展示……”；接下來(lái)，當(dāng)我們按照客戶的要求修改完后，修改后的版本又提交給客戶，客戶又說(shuō)，“噢，我現(xiàn)在覺(jué)得應(yīng)當(dāng)改變一下報(bào)表的內(nèi)容，應(yīng)當(dāng)加入……這些數(shù)據(jù)”，然后我們有去修改數(shù)據(jù)庫(kù)，則必然會(huì)影響某些程序的編碼，所以我們還需修改程序、甚至系統(tǒng)的架構(gòu)。這些情況還會(huì)不斷發(fā)生，最終我們?cè)谝粋€(gè)無(wú)法預(yù)測(cè)的時(shí)間上，達(dá)到了軟件可變性的極限，或者在沒(méi)有達(dá)到可變性極限之前我們項(xiàng)目嚴(yán)重超支、超時(shí)。

　　經(jīng)過(guò)多次的使用，我們發(fā)現(xiàn)好像這種包含了原型的線性結(jié)構(gòu)仍然解決不了任何問(wèn)題?！败浖こ谈静荒芤跃€性結(jié)構(gòu)來(lái)開(kāi)發(fā)嗎！”大多數(shù)軟件工程師們發(fā)現(xiàn)了這個(gè)現(xiàn)象。所以，很自然的“迭代”和“增量”這兩個(gè)特性被認(rèn)為是軟件工程所必須涵蓋的特性，然后又很自然的“演化模型”被開(kāi)發(fā)出來(lái)解決非線性結(jié)構(gòu)問(wèn)題，實(shí)際上是要解決“不明確的功能需求”這一問(wèn)題。當(dāng)然，如果問(wèn)題都不能明確，顯然答案的制定必定是錯(cuò)誤的。這種方法從開(kāi)發(fā)角度而言，會(huì)有與不斷的變更致使軟件的變更接近極限。

　　軟件開(kāi)發(fā)過(guò)程活動(dòng)分析

　　通過(guò)上述的分析，我們知道每個(gè)模型對(duì)會(huì)針對(duì)不同的問(wèn)題而設(shè)置活動(dòng)以及活動(dòng)之間的結(jié)構(gòu)，從而構(gòu)成了軟件過(guò)程。最終在對(duì)軟件過(guò)程特征和在信息化時(shí)代的適應(yīng)性進(jìn)行了分析后，我們還要分析一下各個(gè)活動(dòng)的特征來(lái)明確我們?cè)撊绾谓鉀Q問(wèn)題。

　　這里我們僅僅分析與問(wèn)題最為相關(guān)的“需求階段”和“設(shè)計(jì)階段”，同時(shí)我們把“規(guī)格說(shuō)明書(shū)階段”納入“需求階段”進(jìn)行論述，這樣我們可以更加接近問(wèn)題的本質(zhì)。

　　需求階段的任務(wù)是根據(jù)項(xiàng)目的范圍來(lái)建立出形同的功能需求。它開(kāi)始于客戶給出的范圍，結(jié)束于系統(tǒng)功能需求的建立；這里需要系統(tǒng)分析師根據(jù)項(xiàng)目的范圍建立出每個(gè)范圍內(nèi)所需要的功能需求。適用于該階段的技術(shù)一般為調(diào)查、走訪、快速原型的建立；通過(guò)這些方法系統(tǒng)分析師可以明確地建立出系統(tǒng)的功能需求。另外，我們也知道了快速原型使用的條件是存在明確的范圍。

　設(shè)計(jì)階段的任務(wù)是根據(jù)功能需求說(shuō)明（規(guī)格說(shuō)明書(shū)）劃分出系統(tǒng)的模塊和建立出系統(tǒng)的架構(gòu)。它開(kāi)始于明確的需求規(guī)格說(shuō)明書(shū)，結(jié)束于系統(tǒng)模塊和架構(gòu)的生成；這里需要系統(tǒng)工程師、數(shù)據(jù)庫(kù)架構(gòu)師和其他相關(guān)技術(shù)人員的參與共同建立出系統(tǒng)的架構(gòu)。適用于該階段的技術(shù)可謂是數(shù)不勝數(shù)，但是這些技術(shù)可以分為幾類，如面向?qū)ο?、面向過(guò)程、面向業(yè)務(wù)等?，F(xiàn)在，為了適應(yīng)變更和復(fù)用等問(wèn)題，也出現(xiàn)了各種不同的設(shè)計(jì)技術(shù)，如UML、SOA（嚴(yán)格地說(shuō)SOA是一種標(biāo)準(zhǔn)）等。

　　我們發(fā)現(xiàn)，這兩個(gè)活動(dòng)基本上被所有的開(kāi)發(fā)模型所采用，甚至包括演化模型，它們也需要一個(gè)結(jié)構(gòu)設(shè)計(jì)，否則很難構(gòu)成系統(tǒng)來(lái)被客戶所使用。那么，我們便產(chǎn)生一個(gè)疑問(wèn)，為什么需求與設(shè)計(jì)都被用于解決不同問(wèn)題的模型所采納。難道這是巧合，還是必然現(xiàn)象？

　　至少我們從常識(shí)中可以明確一點(diǎn)，這兩者對(duì)于軟件工程而言必不可少。倘若不知道客戶的需求，那么我們建造什么呢？倘若設(shè)計(jì)不存在系統(tǒng)是否還能協(xié)作運(yùn)行呢？那么，除了常識(shí)意外還有其他原因嗎。從軟件的角度來(lái)看待，功能需求說(shuō)明了每個(gè)范圍內(nèi)系統(tǒng)所需做的事情，設(shè)計(jì)從技術(shù)角度建立出模塊，以使得每個(gè)模塊易于被維護(hù)、易于復(fù)用、易于團(tuán)隊(duì)開(kāi)發(fā)，更為重要的是降低模塊之間的耦合度。

　　通過(guò)需求與設(shè)計(jì)我們基本上明確了系統(tǒng)的模塊與這些模塊如何來(lái)完成功能需求的，這也是大多數(shù)軟件過(guò)程所一致認(rèn)可的。但是，問(wèn)題卻出在了這個(gè)被廣泛認(rèn)可的過(guò)程之中。我們的功能需求是從技術(shù)層面考量的，系統(tǒng)的設(shè)計(jì)也就自然的從技術(shù)層面來(lái)建構(gòu)的?？墒沁@些都屬于瀑布模型的特征，也是問(wèn)題的根源。我們必須承認(rèn)軟件不是無(wú)限制可變的，同時(shí)我們還需承認(rèn)工程是被限定在一個(gè)有限的條件下來(lái)完成的。所以，如果我們不能解決問(wèn)題的根源“不明確的需求”，那么任何依賴于“需求與分析”這兩個(gè)活動(dòng)的模型，都會(huì)失敗于項(xiàng)目中不斷的變更。雖然我們所述的各種模型由于各種不同的原因失敗于信息化項(xiàng)目，但是不明確的范圍是導(dǎo)致了“需求與設(shè)計(jì)”階段失敗的“罪魁禍?zhǔn)住薄?

　　缺乏明確的項(xiàng)目范圍，我們沒(méi)有辦法管理后期的變動(dòng)或返工要求。這方面我們可以建立明確的項(xiàng)目范圍和正確執(zhí)行調(diào)研的工作，（請(qǐng)參考“降低開(kāi)發(fā)過(guò)程中的變動(dòng)依賴項(xiàng)目范圍管理”一文），相信可以大大減低項(xiàng)目的延誤。但要提供科技應(yīng)用的價(jià)值，必須利用項(xiàng)目組件分拆法PCDM才能夠滿足贊助人即干系人的期盼。但仍然不能夠保證余下的設(shè)計(jì)，開(kāi)發(fā)，測(cè)試和移交能夠順利完成。

　　我們必須有一套明確的方式，讓我們可以處理系統(tǒng)的邏輯，未來(lái)應(yīng)用的流程，用戶的界面設(shè)計(jì)，和思考軟件應(yīng)用的環(huán)境，才能夠有效保證項(xiàng)目能夠成功。

　　其實(shí)大部份的返工不是技術(shù)上的應(yīng)用問(wèn)題，是業(yè)務(wù)上的應(yīng)用問(wèn)題，是界面定義的問(wèn)題，是理解客戶的期盼并構(gòu)建可以提供預(yù)期效益和能力的問(wèn)題。

　　創(chuàng)新的開(kāi)發(fā)思維：四步開(kāi)發(fā)模型

　　四步開(kāi)發(fā)方法是針對(duì)軟件開(kāi)發(fā)過(guò)程而不是一套技術(shù)規(guī)范或標(biāo)準(zhǔn)。這套軟件開(kāi)發(fā)體系的設(shè)計(jì)概念不但適用于軟件開(kāi)發(fā)，更可應(yīng)用于產(chǎn)品研發(fā)和其它科研項(xiàng)目中。整個(gè)體系的設(shè)計(jì)構(gòu)思可以利用以下的例子加以說(shuō)明：

　　假設(shè)我們買(mǎi)了一套新房子，首先我們必須明確這個(gè)空間需要提供那些生活的地方，如睡房，書(shū)房，飯廳，廚房，洗手間等主要應(yīng)用空間，是我們購(gòu)買(mǎi)新房的主要目的，也是整套新房的主要組件。接下來(lái)我們便需要決定每一個(gè)組件所需的家具、設(shè)備和布置，在知道每一個(gè)房間的最終用途后，我們才知道需要那些家具或設(shè)備，這些房間的用途，家具和設(shè)備便成為裝修后的交付定義。也許我們明確知道需要一張桌子，不管是從家具店里購(gòu)買(mǎi)，還是找工匠打做，我們一定依據(jù)最終的交付物定義來(lái)思考，或者更明確的說(shuō)：知道這張桌子的最終利用目的，是用來(lái)打麻將？用來(lái)放計(jì)算機(jī)，用來(lái)書(shū)寫(xiě)，用來(lái)用膳，用來(lái)開(kāi)會(huì)，用來(lái)裝飾，有或者主要作為用膳的工具但可以偶爾用來(lái)打麻將？其中一樣或多樣的目的都可以說(shuō)是需要一張桌子的最終目的（Ultimate Purpose），是可以在理解這些最終目的后利用PCDM轉(zhuǎn)變成最終交付物說(shuō)明[NextPage] （Deliverable Statements）的依據(jù)。這些目的已經(jīng)構(gòu)成最終交付的主要構(gòu)思，加上應(yīng)用的地域和環(huán)境，直接影響交付物的外觀和大小。

　　有了需要一張桌子的最終目的和建立的交付物定義，接下來(lái)我們考慮的便是這件交付物的外觀（Appearance），是圓的，方的，長(zhǎng)型的，橢圓型的，折合型的，，需要抽柜的，需要附加柜的，用三叉條腳，普通四腳，兩邊板塊豎立或交叉對(duì)立支撐？玻璃桌面？雕花桌面？外觀的設(shè)計(jì)直接影響交付的最終外表?？紤]外觀的時(shí)候也需要考慮擺放（應(yīng)用）的環(huán)境，桌子是放在房中央？還是靠窗？依附角落？或平常依附角落，用的時(shí)候拉到房中央？這些都會(huì)影響到最終交付物的外觀。外觀帶出三種內(nèi)容，一種是UI定義，同時(shí)需要建立業(yè)務(wù)流的內(nèi)容，最后利用業(yè)務(wù)流和UI定義建立系統(tǒng)的數(shù)據(jù)流和數(shù)據(jù)定義。這都可以透過(guò)“系統(tǒng)操作規(guī)劃（System Operation Planning, SOP）”實(shí)現(xiàn)（下期我會(huì)詳細(xì)說(shuō)明SOP的應(yīng)用方法）。

　　明確了最終目的和外觀，便可以進(jìn)入“建設(shè)”（Construct）或采購(gòu)階段，技術(shù)人員可以在這個(gè)時(shí)候考慮所采用的組合技術(shù)和材料，包括桌子的組合是透過(guò)釘子，螺絲結(jié)合，還是焊接，楔口結(jié)合等技術(shù)和工具應(yīng)用？技術(shù)的應(yīng)用也直接影響交付物的質(zhì)量和投資成本。不同的技術(shù)應(yīng)用同樣可以打做相同的結(jié)果。成功的建設(shè)過(guò)程來(lái)自前期對(duì)最終目的所帶出來(lái)的交付說(shuō)明和外觀的理解得到客戶的認(rèn)同，任何妥協(xié)也應(yīng)該在這個(gè)時(shí)候達(dá)成共識(shí)，否則在建設(shè)過(guò)程中便常需要對(duì)最終交付進(jìn)行修改，最后出來(lái)的交付一定未能獲得客戶認(rèn)同。

　　當(dāng)然，最后便是把交付物與應(yīng)用環(huán)境結(jié)合，看看是否能演繹（Demonstrate）出客戶預(yù)期的最終目的，讓交付物與環(huán)境結(jié)合成一個(gè)完整的驗(yàn)收過(guò)程。環(huán)境包括應(yīng)用部門(mén)，人員，培訓(xùn)， 硬件配置等等。



　　　　　　　　　　　　　　　　　　圖表 1：創(chuàng)新的開(kāi)發(fā)思維，四步軟件開(kāi)發(fā)管理模型

　　項(xiàng)目針對(duì)最終交付，從項(xiàng)目管理的角度去考慮軟件開(kāi)發(fā)，更應(yīng)該從交付作為驗(yàn)收的最終產(chǎn)物，而不是需求。在整套開(kāi)發(fā)體系的架構(gòu)中，需求只能當(dāng)作系統(tǒng)的質(zhì)量指標(biāo)。這套體系把過(guò)去的傳統(tǒng)開(kāi)發(fā)條件依據(jù)項(xiàng)目管理的交付方針結(jié)合，帶出一套創(chuàng)新的開(kāi)發(fā)理念和方法。

　　四步軟件開(kāi)發(fā)的特色

　　這套體系的最大特色是擺脫過(guò)去軟件項(xiàng)目未能把握客戶需求的困境。是針對(duì)交付物而構(gòu)成的開(kāi)發(fā)過(guò)程，也就是通過(guò)交付物的定義，到交付物的外觀的確定，再到使用技術(shù)讓外觀得以實(shí)現(xiàn)、以及組合交付物，最后通過(guò)交付物與具體環(huán)境的演繹帶出客戶期盼的價(jià)值。

　　同時(shí)可以完善地處理表格1 中所產(chǎn)生的種種問(wèn)題。從項(xiàng)目起動(dòng)根據(jù)PCDM“交付物”的作用和特點(diǎn)對(duì)交付物的最終建立整合成一套完整的模型，也就是說(shuō)整個(gè)模型是以交付物為核心的，而不是像其他模型僅僅將交付物作為需求或技術(shù)應(yīng)用的一個(gè)輸入。

　　為了以交付物為核心，那么我們不去定義一個(gè)交付物的功能需求（這方面應(yīng)該由技術(shù)人員對(duì)交付的最終目的建立系統(tǒng)的需求，從中帶出技術(shù)人員的創(chuàng)新思維），而是“完善”交付物的定義，也就是說(shuō)定義交付物的詳細(xì)外觀（或存在的各種形式），從而我們獲得的是一個(gè)交付物的形式化的、詳細(xì)的外觀定義；實(shí)際上，是脫離參雜了太多技術(shù)因素的功能角度去定義交付物的形式化的詳細(xì)定義，而是以反映交付物自身特性的外觀角度將主要構(gòu)思和交付物的目的轉(zhuǎn)變成形式化的、詳細(xì)的外觀定義。

　　通過(guò)外觀的定義，技術(shù)人員可以準(zhǔn)確的實(shí)施技術(shù)以使交付物得以實(shí)現(xiàn)，實(shí)際上去除了從功能角度定義交付物所帶給技術(shù)上的局限和復(fù)雜性；而從外觀入手使得技術(shù)的實(shí)施完全可以追溯到交付物的直接定義（即主要構(gòu)思和外觀），使得最終結(jié)果與原始的概念一致；“技術(shù)的不同應(yīng)用可以帶出同一結(jié)果”這一現(xiàn)象的產(chǎn)生是以有了相應(yīng)明確的、客戶確認(rèn)的、“可過(guò)渡”的定義為前提的，而該體系是從交付物的外觀的詳細(xì)定義入手，所以不同技術(shù)的應(yīng)用都會(huì)圍繞著交付物的外觀和目的來(lái)實(shí)施的，所以會(huì)按照各自的外觀特點(diǎn)“過(guò)渡”到由不同技術(shù)帶出的同一結(jié)果上。

　　這個(gè)開(kāi)發(fā)模型可以讓技術(shù)人員在構(gòu)建過(guò)程中盡量發(fā)揮本身的技術(shù)能力，只有能夠依據(jù)目的和SOP的要求完成交付，并進(jìn)行環(huán)境組合，最后通過(guò)交付物的演繹帶出項(xiàng)目的根本效益。

　　下次我會(huì)更詳細(xì)說(shuō)明系統(tǒng)操作規(guī)劃和四步開(kāi)發(fā)模型的應(yīng)用方法的內(nèi)容。讓大家能夠思考是否能夠取得目前我們慣用的開(kāi)發(fā)模型。