破解印度CMM模式困境 中國軟件的發(fā)展之路

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

CMM等軟件過程標(biāo)準(zhǔn)最初是由于印度軟件提供商的積極采納而為人們所熟知的，印度軟件廠商也最先達(dá)到最高的一致性標(biāo)準(zhǔn)——CMM 5，他們讓市場(chǎng)認(rèn)為CMM（特別是CMM 5）就意味著能夠可靠、可預(yù)測(cè)地交付高質(zhì)量的商業(yè)軟件。加上印度極具優(yōu)勢(shì)的勞動(dòng)力價(jià)格和大量受過訓(xùn)練的程序員，特別是印度的軟件公司還是流程方面的天才，使得軟件開發(fā)項(xiàng)目潮水般地涌入印度，讓印度軟件公司很快成為軟件開發(fā)、軟件維護(hù)、系統(tǒng)集成與運(yùn)營等與軟件相關(guān)的各種項(xiàng)目的主角。然而，最近幾年CMM這一軟件過程遭到了挑戰(zhàn)。

印度軟件模式的困境

CMM由于其提高交付成功率的辦法而大受青睞。CMM注重過程、度量標(biāo)準(zhǔn)以及可重復(fù)性，從某種意義上說它確實(shí)讓交付變得更可預(yù)測(cè)，并且在某些特定情況下，一些變更造成的影響也變得更可預(yù)測(cè)。但在CMM管理下的“瀑布模型”給軟件開發(fā)帶來高度紀(jì)律性的同時(shí)，用戶對(duì)軟件開發(fā)的滿意度并未提高。

問題的根源在于: 業(yè)務(wù)需求的變化促使企業(yè)不斷調(diào)整它們的軟件功能。在CMM模式下，瀑布式開發(fā)過程雖然已經(jīng)很清楚地定義了需求變更的處理過程，但需求變更的成本非常高，即使很小的變更也需要大量的流程變更和返工。因此企業(yè)經(jīng)常會(huì)陷入兩難的境地: 要么重新制定關(guān)鍵項(xiàng)目的計(jì)劃并接受延期發(fā)布，要么將新需求推遲到下次軟件發(fā)布再完成。而當(dāng)今的商業(yè)環(huán)境瞬息萬變，幾個(gè)月的拖延往往意味著市場(chǎng)機(jī)會(huì)的喪失。

在一些項(xiàng)目中，印度的軟件公司引發(fā)了客戶事后的強(qiáng)烈不滿，因?yàn)榻桓兜能浖⒉环峡蛻舢?dāng)前的需求。更讓客戶難以接受的是，CMM 5的嚴(yán)格讓客戶無話可說，因?yàn)榻桓兜能浖呀?jīng)做到了合同中規(guī)定的一切。有些西方買家開始諷刺CMM，他們把CMM叫做“Costs More Money”（花更多的錢）。

事實(shí)上，按階段方式定義流程（瀑布模型）的基礎(chǔ)是一個(gè)假設(shè)，即客戶知道他們將來需要什么，意味著客戶必須在分析階段就決定具體功能的內(nèi)容。實(shí)際情況是，在項(xiàng)目的某些時(shí)間點(diǎn)，客戶可能對(duì)變更的需求非常強(qiáng)烈，以至于要求項(xiàng)目必須適應(yīng)這些變更。這時(shí)客戶能做的選擇少得可憐: 交付時(shí)間延期，付更多的費(fèi)用，或者開始考慮第二個(gè)版本。

現(xiàn)在再看人們常說的“讓開發(fā)軟件如同建設(shè)橋梁”這句話也值得商榷。建橋所用的過程是為建設(shè)一個(gè)堅(jiān)固耐用的產(chǎn)品而設(shè)計(jì)的，這種產(chǎn)品一旦建好就能用很多年。而對(duì)于重要的軟件而言，在當(dāng)前版本完成以后，它還有必要隨著需求的變化而改變，正是由于這方面的原因，那些建立在工程學(xué)原理之上的軟件過程方法無法很好地適應(yīng)變化就毫不令人驚訝了。因?yàn)檫m應(yīng)變化根本就不是其關(guān)注的東西。