Ivar Jacobson博士 　　

他被認為是影響或改變了整個(gè)軟件工業(yè)開(kāi)發(fā)模式的幾位世界級大師之一，是軟件方法論的一面”旗幟”。他是組件和組件架構、用例、現代業(yè)務(wù)工程、Rational統一過(guò)程等業(yè)界主流方法或技術(shù)的創(chuàng )始人。
　　

Ivar Jacobson博士認為，如果采用不良的軟件過(guò)程，通過(guò)CMM/CMMI的成熟度級別越高，只會(huì )使軟件企業(yè)生產(chǎn)不合格軟件的過(guò)程更加有效率，而不是使企業(yè)開(kāi)發(fā)出更好的軟件。
　　

軟件外包是時(shí)下的一個(gè)熱門(mén)話(huà)題，被我國不少軟件企業(yè)視為一座金礦，而CMM被人們認為是進(jìn)入這個(gè)市場(chǎng)的敲門(mén)磚，為了拿到那張代表資格的CMM認證證書(shū)，不少企業(yè)甚至不惜投入數百萬(wàn)之巨。事實(shí)上，拿到CMM認證在國外并不代表企業(yè)就能提供一個(gè)合格的軟件，著(zhù)名的軟件專(zhuān)家、擁有組件技術(shù)、用例技術(shù)等多項發(fā)明、與Grady Booch、James Rumbaugh一起被稱(chēng)為UML之父的Ivar Jacobson博士在近期訪(fǎng)華期間一再提醒中國的軟件企業(yè)，謹防掉入CMM陷阱。

CMM/CMMI的缺點(diǎn)
　　

CMM/CMMI最早起源于美國國防部。為了改變在采購過(guò)程中頻繁地采購到大量不合格軟件的局面，美國國防部需要一種評估軟件質(zhì)量的方法，這就是要求軟件企業(yè)進(jìn)行CMM/CMMI認證。然而，CMM/CMMI真正解決這個(gè)問(wèn)題了嗎？
　　

CMM/CMMI被認為是一種最成熟、最有效地提高軟件工程化水平的方法和標準，用來(lái)評估和改進(jìn)過(guò)程，它是一個(gè)描述在軟件開(kāi)發(fā)過(guò)程中有待改進(jìn)的關(guān)鍵因素的框架，描述了一個(gè)能用漸進(jìn)方式進(jìn)行改進(jìn)的途徑。它為軟件過(guò)程改進(jìn)提供一個(gè)基礎，將軟件開(kāi)發(fā)從一個(gè)相對來(lái)說(shuō)隨意、不成熟的過(guò)程變成非常成熟的、有規律的、可管理的過(guò)程。
　　

然而，CMM/CMMI也有一些與身俱來(lái)的缺點(diǎn)不容忽視。比如，CMM/CMMI的評估耗資不菲，一個(gè)CMM2級評估就可能達到數百萬(wàn)之巨，而且耗時(shí)很長(cháng)，過(guò)程十分復雜，常常導致效果不太理想。不少企業(yè)的認證流于形式，評估完成后就只留下一大堆文檔，而真正的軟件開(kāi)發(fā)過(guò)程卻依然故我。而且，CMM/CMMI只告訴我們應該怎么做，而沒(méi)有具體地告訴如何做。比如說(shuō)，它要求必須改進(jìn)需求管理，那么到底該如何做需求管理？CMM/CMMI沒(méi)有提供答案。
　　

還有最重要的一點(diǎn)是，不少軟件企業(yè)陷入了一個(gè)誤區，以為單單通過(guò)CMM/CMMI評估就可以解決軟件質(zhì)量不高的問(wèn)題，而忽略了軟件過(guò)程這一真正改善軟件質(zhì)量的環(huán)節。事實(shí)上，完全有可能出現這樣的情況: 軟件成熟度為CMM 1級或2級的企業(yè)開(kāi)發(fā)出的軟件是真正好用的，而有的企業(yè)即使通過(guò)了CMM 5級認證，也無(wú)法保證它交付好的軟件。最糟糕的情形是，如果采用不好的軟件過(guò)程，通過(guò)CMM/CMMI的成熟度級別越高，只會(huì )使軟件企業(yè)生產(chǎn)差勁軟件的過(guò)程變得更加有效率，而不是使企業(yè)開(kāi)發(fā)出更好的軟件。

Ivar Jacobson認為,好的軟件過(guò)程首先一定是基于組件的,在此基礎之上,還要符合迭代開(kāi)發(fā)、用例驅動(dòng)開(kāi)發(fā)和以架構為中心的這三個(gè)最佳實(shí)踐。

合理的軟件過(guò)程是軟件質(zhì)量的基礎
　　

軟件企業(yè)利用CMM框架進(jìn)行軟件質(zhì)量控制的過(guò)程，就像是這個(gè)農夫為牛路鋪瀝青。對于軟件企業(yè)來(lái)說(shuō)，如果從一個(gè)錯誤的軟件過(guò)程開(kāi)始，即使你在這個(gè)上面再改進(jìn)，得到的永遠只是”牛路”。這里更應該考慮的是要選擇一條更好的路，也就是從一開(kāi)始時(shí)，就采用能夠開(kāi)發(fā)出好的軟件的過(guò)程。然后在這個(gè)軟件過(guò)程的基礎上，對這個(gè)軟件進(jìn)行度量，改進(jìn)這個(gè)軟件的過(guò)程,也就是進(jìn)行CMM/CMMI要求的改進(jìn)。

Ivar Jacobson博士認為，從一個(gè)不良的軟件過(guò)程出發(fā)，在此基礎上進(jìn)行改進(jìn)，實(shí)際上會(huì )把軟件開(kāi)發(fā)變得更糟糕，因為你把軟件開(kāi)發(fā)過(guò)程固化了，使日后再想對它進(jìn)行改造，變得更加困難。正確的方法是，先要有一個(gè)好的軟件過(guò)程，這是不容易的，但是值得做的事情。

Ivar Jacobson 說(shuō)，”把一個(gè)好的軟件過(guò)程變得可度量非常容易，但是把一個(gè)可度量的軟件過(guò)程變成一個(gè)好的軟件過(guò)程卻很難”。也就是說(shuō)，只有把一個(gè)好的軟件過(guò)程，即能夠開(kāi)發(fā)出好的軟件的過(guò)程變得可度量才是有益的。而把一個(gè)已經(jīng)經(jīng)過(guò)CMMI改進(jìn)的、可度量的過(guò)程變成一個(gè)真正的能夠開(kāi)發(fā)出好軟件的過(guò)程，這是幾乎不可能的事情。

那么什么是一個(gè)好的軟件過(guò)程？Ivar Jacobson建議從以下幾個(gè)方面進(jìn)行辨別:

　　

Ivar Jacobson提醒軟件開(kāi)發(fā)人員要做聰明的農夫，首先得到一個(gè)正確的軟件過(guò)程; 然后，再考慮去度量它、定義它。因為軟件項目管理的本質(zhì)不是能否描述并度量軟件過(guò)程以及過(guò)程到底怎么樣，而是首先關(guān)注軟件，你是否能很好地開(kāi)發(fā)出合格軟件。重點(diǎn)是得到結果，通過(guò)軟件過(guò)程得到這個(gè)結果，也就是交付的軟件產(chǎn)品。

觀(guān)點(diǎn)碰撞
敏捷開(kāi)發(fā)企圖終結軟件危機
　　

如今在軟件開(kāi)發(fā)領(lǐng)域占絕對主流地位的傳統軟件工程學(xué)思想是大約在20世紀60年代伴隨著(zhù)”軟件危機”言論的出現而誕生的。所謂軟件危機是指在計算機軟件的開(kāi)發(fā)和維護過(guò)程中所遇到的一系列嚴重問(wèn)題，它包含兩方面內容：一是如何開(kāi)發(fā)軟件，以滿(mǎn)足不斷增長(cháng)、日趨復雜的需求；二是如何維護數量不斷膨脹的軟件產(chǎn)品。的確，傳統軟件工程學(xué)思想的誕生，把軟件開(kāi)發(fā)活動(dòng)按照工程化的原則和方法進(jìn)行組織，并一度被認為是擺脫軟件危機的一個(gè)主要出路。
　　

但是，數十年后的今天，人們對于軟件危機的”恐懼”仍沒(méi)有絲毫減弱，相反隨著(zhù)軟件系統的急速膨脹而越發(fā)不可收拾了：對軟件開(kāi)發(fā)成本和進(jìn)度的估計常常不準確，開(kāi)發(fā)成本超出預算，實(shí)際進(jìn)度比預定計劃一再拖延的現象并不罕見(jiàn)；用戶(hù)對”已完成”系統不滿(mǎn)意的現象也經(jīng)常發(fā)生；軟件產(chǎn)品的質(zhì)量往往靠不住，Bug一大堆，補丁一個(gè)接一個(gè)；等等。于是，無(wú)論是產(chǎn)業(yè)界還是理論界，都開(kāi)始對傳統軟件工程學(xué)思想產(chǎn)生懷疑，甚至背叛。因此，關(guān)于軟件到底是”工程”還是”藝術(shù)”的討論一度風(fēng)靡全球。而以迭代式循序漸進(jìn)開(kāi)發(fā)方式為主，以”人”為核心的敏捷開(kāi)發(fā)方法就是在這樣的背景下產(chǎn)生的，它背叛了傳統軟件工程學(xué)中以”過(guò)程”為核心，把設計和開(kāi)發(fā)盡可能分開(kāi)，盡量弱化”人”在整個(gè)工程中地位的思想。
　　

近日，當世界軟件開(kāi)發(fā)領(lǐng)域最具影響力的五位大師之一、敏捷軟件開(kāi)發(fā)方法的早期開(kāi)拓者馬丁·福勒先生來(lái)華與國內軟件高手論道之際，北京大學(xué)軟件學(xué)院院長(cháng)陣鐘老師再次將軟件是”工程”還是”藝術(shù)”這一問(wèn)題擺到了桌面上。而這位軟件教父似乎對這一問(wèn)題早有深入思考，他認為，這一爭論的核心應該在于軟件設計是否要與軟件開(kāi)發(fā)分開(kāi)，這也正是傳統工程化軟件開(kāi)發(fā)方法與敏捷軟件開(kāi)發(fā)方法的重要區別。
　　

作為敏捷軟件開(kāi)發(fā)方法的推動(dòng)者，馬丁先生認為，軟件設計應該和軟件開(kāi)發(fā)緊密結合在一起，采用迭代式開(kāi)發(fā)。軟件開(kāi)發(fā)不能被認為是一個(gè)既定的過(guò)程，因為軟件開(kāi)發(fā)中有太多的變化出現，既定的過(guò)程設置不可能達到合適的預想結果。由于需求變化、技術(shù)更新、人員流動(dòng)等問(wèn)題的存在，許多軟件設計工作應該在軟件開(kāi)發(fā)到一定程度的時(shí)候才能進(jìn)行，兩者不應該在順序上嚴格分開(kāi)。他說(shuō):”至于從哲學(xué)的角度講，到底軟件開(kāi)發(fā)活動(dòng)是藝術(shù)還是工程呢？我很難清晰地界定，也許都是或者都不是。也許我們應該把軟件開(kāi)發(fā)活動(dòng)當做一個(gè)獨立的東西來(lái)對待。”
　　

由此看來(lái)，馬丁先生既不認為軟件開(kāi)發(fā)活動(dòng)應該是一個(gè)先進(jìn)行設計，然后根據 “設計圖紙”進(jìn)行構建的工程化過(guò)程，也不認為軟件開(kāi)發(fā)應該是完全依賴(lài)于開(kāi)發(fā)者頭腦中隨時(shí)蹦出的靈感的藝術(shù)活動(dòng)，因為這兩種傾向在人類(lèi)數十年的軟件開(kāi)發(fā)實(shí)踐中已經(jīng)被證明都不甚完美。而他企圖在兩者之間找到一個(gè)均衡點(diǎn)，這個(gè)均衡點(diǎn)也許正是真正解決”軟件危機”的突破口。
　　

據了解，敏捷開(kāi)發(fā)實(shí)際上包括了許多優(yōu)秀的軟件開(kāi)發(fā)習慣。首先，這種方法改變了軟件測試的流程，在編寫(xiě)代碼前進(jìn)行測試，減少了開(kāi)發(fā)風(fēng)險；其次，可以對軟件進(jìn)行持續集成，即每個(gè)小時(shí)都在集成，任何部件間的沖突都可以隨時(shí)解決；此外，這種方法的”動(dòng)態(tài)規劃”和”重構”做法，意味著(zhù)開(kāi)發(fā)者可以對軟件架構進(jìn)行持續改進(jìn)，可以根據用戶(hù)的需求隨時(shí)進(jìn)行改進(jìn)，而利用傳統的軟件開(kāi)發(fā)方法則很難對軟件的架構進(jìn)行調整，同時(shí)也會(huì )造成成本的大幅增加。