小型軟件團(tuán)隊(duì)過程改進(jìn)方法

1、過程塑造（小型軟件團(tuán)隊(duì)過程改進(jìn)方法）一、從方法到編碼這是一篇偏重于介紹方法學(xué)（特不是Agile方法）實(shí)踐的文章。其讀者對(duì)象是那些希望在自己的軟件團(tuán)體中引入某個(gè)過程方法，但又不知從何入手的開發(fā)人員、項(xiàng)目經(jīng)理們。本文中所提到的內(nèi)容更適合于應(yīng)用在小型的軟件團(tuán)隊(duì)中。關(guān)于較大規(guī)模的軟件團(tuán)隊(duì)，本文中的部分內(nèi)容也適用。 本系列包括： HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知識(shí)接力、 HYPERLINK /developerworks/cn/linux/softwa

2、re_engineering/Methodology/method2code/index3.html 代碼是最終目、 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性的考慮、 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index5.html 活躍和混亂、嚴(yán)謹(jǐn)和死板、 HYPERLINK /developerworks/cn/linux/s

3、oftware_engineering/Methodology/method2code/index6.html 短期利益和長(zhǎng)期利益的權(quán)衡。軟件治理和軟件開發(fā)是截然區(qū)分的嗎？ 關(guān)于項(xiàng)目經(jīng)理來講，其職責(zé)是軟件項(xiàng)目的治理，而關(guān)于架構(gòu)師、編碼人員來講，其職責(zé)是軟件設(shè)計(jì)和開發(fā)。盡管在一些小型的團(tuán)隊(duì)中，這兩種職責(zé)有時(shí)候是同一個(gè)人擔(dān)任的，但兩種角色的區(qū)分是必要的。從事過軟件開發(fā)的人都能或多或少的感受到軟件治理和軟件開發(fā)之間客觀存在的溝壑。 我常常聽到來自兩個(gè)方面的聲音。一邊抱怨講設(shè)計(jì)師、編程人員陽奉陰違，難以管束，導(dǎo)致已訂立的軟件過程形同虛設(shè)。另一邊抱怨軟件過程存在諸多不恰當(dāng)?shù)牡攸c(diǎn)，變成了軟件開發(fā)的絆腳石。

4、 現(xiàn)代的方法學(xué)理論以及相應(yīng)的過程實(shí)踐為我們奠定了軟件開發(fā)科學(xué)治理的基礎(chǔ)，個(gè)中的翹楚包括RUP和XP，縱觀這些方法、過程，都特不強(qiáng)調(diào)過程的流暢、生命周期的連續(xù)。而在實(shí)際的應(yīng)用中，我們卻常常能夠看見對(duì)它們的不恰當(dāng)?shù)睦斫?，不正確的使用。尤其是那些希望在自己的軟件團(tuán)體中引入新型的方法過程新手們。關(guān)于他們來講，最容易犯的一個(gè)錯(cuò)誤確實(shí)是忽視了如何利用一個(gè)軟件過程來制造一個(gè)成功的軟件。關(guān)于如何建立一個(gè)軟件過程的資料專門多，然而這些資料并沒有把什么緣故需要過程，過程的目的是什么之類的問題講清晰。而這些資料的讀者們，往往需要花費(fèi)大量的時(shí)刻，親自進(jìn)行實(shí)踐之后，才能獲得這些問題的答案，而付出的代價(jià)是教訓(xùn)和挫折。同樣

5、的，我和我的伙伴們也經(jīng)歷了如此一個(gè)過程。因此，我希望把我在過程應(yīng)用、過程改造中涉及到的問題例舉出來（采納過程模式的方式）。假如大伙兒能夠利用到這些經(jīng)驗(yàn)（哪怕是一些），那本文的目的也就達(dá)到了。因此，本文并不是一篇專門討論如何建立過程的文章，也沒有涉及建模、設(shè)計(jì)、編碼等方面的內(nèi)容。然而本文中所討論的內(nèi)容都能夠?qū)σ陨系幕顒?dòng)起到部分的指導(dǎo)作用。敏捷？敏捷！ 從開始研究軟件工程，我就對(duì)敏捷過程的概念情有獨(dú)衷，然而隨著學(xué)習(xí)的深入（所犯錯(cuò)誤的增多），我發(fā)覺敏捷是無處不在的，她是一種尺度，一種處于混亂和死板之間的平衡藝術(shù)。有句俏皮話講的是一放就亂，一管就死，這句話專門好的點(diǎn)出了軟件過程的一種無奈性。假如沒有嚴(yán)

6、格的規(guī)定，軟件開發(fā)就陷入一種混亂、無序的狀態(tài)，然而假如制定了過于嚴(yán)格的規(guī)定，軟件人員的思路又受到極大的約束，治理成本也隨之上升。敏捷正是一種處于兩個(gè)極端之間微妙平衡的藝術(shù)。這種藝術(shù)難以完全表述，然而能夠通過一些指導(dǎo)，來關(guān)心大伙兒達(dá)到這種境地。 因此，我們能夠推想的到，敏捷是見仁見智的。每一個(gè)軟件團(tuán)體都有自身的特性，其敏捷過程必定都不盡相同。如何設(shè)計(jì)出成功的敏捷過程，來保證軟件團(tuán)體的成功呢？本文通過一些過程模式的討論，揭開了問題的一角。關(guān)于過程設(shè)計(jì)的完整的討論，大伙兒能夠參考敏捷軟件開發(fā)Alistair Cockburn一書（該書近來將有中文版面世），該書詳細(xì)的描述了過程設(shè)計(jì)的來龍去脈，以及如何

7、依照組織的特點(diǎn)來選擇適當(dāng)?shù)倪^程。 因此，盡管本文中并沒有特不提到敏捷的字眼，然而所討論的內(nèi)容無不在敏捷思維的范圍之內(nèi)。 MDA推動(dòng)軟件可重用框架的建立 我有一個(gè)夢(mèng)想，希望有一天能夠不用在諸多的平臺(tái)之間搖來擺去。雖講Java語言的口號(hào)確實(shí)是跨平臺(tái)。但事實(shí)上，我們依舊無法完全擺脫平臺(tái)的束縛。 在UML2.0的規(guī)范中，提到了一個(gè)MDA（Model Driven Architecture）的概念。在眾多的軟件平臺(tái)中不知該如何選擇，差不多演變?yōu)楫?dāng)今軟件開發(fā)的要緊難題。MDA的存在目的確實(shí)是為了解決那個(gè)問題。通過MDA技術(shù)，一個(gè)UML的模型能夠是平臺(tái)無關(guān)的，稱為PIM（Platform-Independe

8、nt Model），也能夠是和特定平臺(tái)相關(guān)的，稱為PSM（Platform-Specific Model）。利用平臺(tái)技術(shù)的軟件商，能夠?qū)Ｗ⒂谧约旱念I(lǐng)域，集中描述業(yè)務(wù)功能，業(yè)務(wù)規(guī)則，而無須考慮特定的技術(shù)，構(gòu)建出一個(gè)PIM，然后，通過支持MDA的工具，將PIM轉(zhuǎn)換（通過不同Profile進(jìn)行映射）為一個(gè)或多個(gè)PSM。這時(shí)候的模型仍然是UML的。然而，那個(gè)轉(zhuǎn)換過程盡管有工具的輔助，但仍然需要外力的介入。接下來，開發(fā)工具將會(huì)從PSM中產(chǎn)生可執(zhí)行代碼。這確實(shí)是MDA的思路，它把以往以程序?yàn)橹行牡拈_發(fā)模式轉(zhuǎn)變?yōu)橐栽O(shè)計(jì)為中心的開發(fā)模式。 以往的重用，往往是基于代碼的，例如算法的重用、界面組件的重用，卻往往沒

9、有將重用提升到設(shè)計(jì)的層次上。MDA為我們建立可重用的框架提供了一個(gè)專門好的指導(dǎo)。注意上面的這副圖，最不處的兩層就表達(dá)了MDA能夠用于設(shè)計(jì)重用的差不多理念。倒數(shù)第二層的含義是利用MDA來進(jìn)行通用軟件（例如事務(wù)、目錄服務(wù)）的模型設(shè)計(jì)，倒數(shù)第一層則表示MDA能夠用于特定業(yè)務(wù)領(lǐng)域的設(shè)計(jì)建模。能夠想象，今后軟件公司中的最有價(jià)值的資產(chǎn)，確實(shí)是這些設(shè)計(jì)模型。 本文并不打算詳細(xì)討論MDA，除了簡(jiǎn)單的介紹MDA的思路之外，更重要的一點(diǎn)是企業(yè)可重用框架的建立。軟件企業(yè)的核心在于知識(shí)，如何有效的將人腦中的知識(shí)存儲(chǔ)起來，并不斷的使用和進(jìn)展，是軟件企業(yè)成功的關(guān)鍵。本文提到的可重用框架，指的確實(shí)是將軟件開發(fā)相關(guān)知識(shí)存儲(chǔ)起

10、來的框架。那個(gè)思路是本文的一個(gè)核心思路。在本文看來，可重用框架不但包括了設(shè)計(jì)模型，還包括了過程和方法。軟件開發(fā)是在那個(gè)框架之內(nèi)運(yùn)作的，同時(shí)反過來阻礙著框架的完善和改進(jìn)。 過程塑造模式語言下述的模式差不多上從軟件開發(fā)過程中，圍繞著可重用框架的建立整理出來的一些經(jīng)驗(yàn)，之因此整理為模式的形式，是因?yàn)檫@種方式有利于類似情況的鑒不和對(duì)其進(jìn)行必要的擴(kuò)展。在軟件開發(fā)中會(huì)遇到各種各樣的問題，以上模式中討論到的問題差不多上我們?cè)趯?shí)踐中，或是和其他開發(fā)團(tuán)隊(duì)溝通中反復(fù)遇到的。因此堅(jiān)決了我們將之整理為模式的信心。目前我們得到的模式并不多，然而隨著經(jīng)驗(yàn)的增加，我們會(huì)得到更多的積存。 本文介紹的模式都比較注重權(quán)衡的藝術(shù)。

11、我們認(rèn)為這是敏捷思維的必定結(jié)果。世界上并沒有什么絕對(duì)的情況，尤其是目前多變的社會(huì)中，昨天的標(biāo)準(zhǔn)并不適合于今天的環(huán)境。因此，我們的平衡點(diǎn)也在不斷的變化。 傳統(tǒng)、經(jīng)典、學(xué)術(shù)的瀑布模型為我們建立了軟件開發(fā)的差不多過程，盡管有各種新的生命周期模型的提出，然而差不多的過程并沒有太大的變化。例如，增強(qiáng)性的瀑布過程是在瀑布模型的基礎(chǔ)上增加了回溯到上一個(gè)時(shí)期的能力；迭代式過程的每一次迭代差不多上一次微小的瀑布生命周期。在那個(gè)生命周期模型中，信息在初始需求收集時(shí)期生成，并通過分析、設(shè)計(jì)、編碼、部署等時(shí)期轉(zhuǎn)化為用戶最終需要的軟件。在如此一個(gè)連續(xù)性極強(qiáng)的周期中，我們?nèi)绾伪ＷC信息能夠得到正確的傳遞呢？我們用什么方法來

12、幸免信息傳遞的失真呢？我們?nèi)绾卧谌绱艘粋€(gè)過程中處理人與人之間的交互呢？在正確傳遞信息的情況下，我們又如何保證投入的最小化呢？這些問題正是 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知識(shí)接力模式所重點(diǎn)關(guān)注的。 我不只一次的見過為過程而關(guān)注過程的情況。產(chǎn)生這種結(jié)果的一種緣故是“過程麻痹癥”。過程一旦定型，就不再改變，即便當(dāng)初制定過程的環(huán)境差不多發(fā)生了變化也是如此。過程的制定一定是針對(duì)特定的目標(biāo)的，那個(gè)目標(biāo)確實(shí)是開發(fā)出成功的軟件，假如不能夠服務(wù)于那個(gè)目標(biāo)，遵循

13、過程又有什么意義呢？另一種緣故是過程被分割為彼此獨(dú)立的片斷，每個(gè)開發(fā)人員只關(guān)注自己的職責(zé)，而忽略了最終的軟件。過程的 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index3.html 代碼是最終目的，開發(fā)過程中的所有活動(dòng)都圍繞著這一目的而展開。假如沒有最后的用于交付的代碼，軟件就無法成為軟件。因此，必須保證過程能夠產(chǎn)出代碼，而且是優(yōu)秀的代碼。 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/

14、method2code/index4.html 一致性原則是軟件開發(fā)中重要原則，也是最令人困惑的原則。做到完全的一致性將會(huì)導(dǎo)致高昂的成本，而不一致又會(huì)導(dǎo)致項(xiàng)目出現(xiàn)各種各樣的問題。能夠想到，這又是一個(gè)需要權(quán)衡的問題。軟件項(xiàng)目中的一致性大致能夠分為兩種，一種是不同工件之間的一致性（例如設(shè)計(jì)模型中的類名稱和實(shí)際代碼中的類名稱的一致性），一種是工件和軟件過程的一致性（類名稱需要滿足命名標(biāo)準(zhǔn)）。我們?nèi)绾慰紤]這兩種情況下的一致性呢？ 人們講治理既是科學(xué)也是藝術(shù)，這句話用來形容軟件工程再適合只是了。假如講那個(gè)地點(diǎn)有什么不夠恰當(dāng)?shù)牡攸c(diǎn)的話，我倒覺得是軟件工程的那個(gè)提法有些許的欠妥。軟件工程的思路源自于人們渴望

15、軟件開發(fā)能夠像土木工程那樣成熟。然而幾十年的經(jīng)驗(yàn)下來，大伙兒能夠確信，軟件開發(fā)和土木工程有著太多的不同：開發(fā)人員和建筑工人也有著截然不同的差異，知識(shí)的組裝和鋼筋混凝土更是天差萬不。（但為了保證連續(xù)性，我們?cè)诒疚闹腥匀贿B續(xù)軟件工程的提法。）因此，軟件工程需要在科學(xué)和藝術(shù)之間求得權(quán)衡，科學(xué)的一面包括了軟件開發(fā)規(guī)范、準(zhǔn)則、實(shí)踐、過程、方法；而藝術(shù)的一面則囊括了人員的激勵(lì)、協(xié)調(diào)，組織的設(shè)計(jì)等因素。因此我們需要審視我們的規(guī)則、過程、方法，它們是否能夠發(fā)揮出人的創(chuàng)新性？或是它是否足以約束人的行為？這確實(shí)是 HYPERLINK /developerworks/cn/linux/software_engine

16、ering/Methodology/method2code/index5.html 活躍和混亂、嚴(yán)謹(jǐn)和死板模式所要告訴我們的。 應(yīng)該講，本文中所討論的模式更適合于使用面向?qū)ο蠹夹g(shù)的開發(fā)團(tuán)隊(duì)。尤其是 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index6.html 短期利益和長(zhǎng)期利益的權(quán)衡模式。和大多數(shù)人一樣，我們最早也是過程式編程陣營(yíng)的一員。在通過長(zhǎng)時(shí)刻的學(xué)習(xí)和不斷的犯錯(cuò)之后，我們終于轉(zhuǎn)向了面向?qū)ο蟆Ｃ嫦驅(qū)ο笞畲蟮暮锰幇艘韵聨讉€(gè)方面： 將實(shí)現(xiàn)和接口分離，即把如何做隱藏起來，

17、而把做什么展示給客戶。 繼承和多態(tài)使得我們能夠在一個(gè)抽象的層次上（基類和接口）考慮問題，并能夠依照現(xiàn)實(shí)的需求進(jìn)行靈活的調(diào)整（子類和實(shí)現(xiàn)）。 通過設(shè)計(jì)模式和設(shè)計(jì)技巧的應(yīng)用，能夠有效的降低系統(tǒng)的不同部分之間的耦合度。尤其是簡(jiǎn)化客戶端的代碼。 在使用和比較過幾種開發(fā)語言和開發(fā)環(huán)境之后，我們發(fā)覺，事實(shí)上最關(guān)鍵的并不是使用什么樣的面向?qū)ο笳Z言（或環(huán)境），關(guān)鍵的是你運(yùn)用面向?qū)ο笏季S的能力，或者講對(duì)現(xiàn)實(shí)世界的理解、抽象、映射的能力。這種能力決定了你的開發(fā)水平的高低，而語言和環(huán)境只是一種重要的實(shí)現(xiàn)手段和工具而已。而這種思維能力，盡管能夠通過例子和討論來進(jìn)行介紹，但更關(guān)鍵的依舊在實(shí)踐中進(jìn)行練習(xí)。在本文討論的模式

18、中，我們會(huì)夾帶的對(duì)這些內(nèi)容進(jìn)行討論。因?yàn)槲覀冋J(rèn)為，開發(fā)思想和開發(fā)過程是無法區(qū)分的，否則，你的開發(fā)過程就沒有靈魂。這也是我們的主題所要強(qiáng)調(diào)的：從方法到編碼，鑄造起一個(gè)敏捷的、流暢的過程，才能夠保證開發(fā)過程的成功，開發(fā)軟件的成功。 此外，本篇是總論性文章，在撰寫此文時(shí)，該篇事實(shí)上是最后完工的，因此，建議大伙兒在看過全文之后，假如還有耐心，能夠重看此篇，相信會(huì)有另外一番收獲。 現(xiàn)在請(qǐng)大伙兒進(jìn)入我們的模式之旅。 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 二、知識(shí)

19、接力 在軟件過程中，我們?nèi)绾伪ＷC信息能夠得到正確的傳遞呢？我們用什么方法來幸免信息傳遞的失真呢？我們?nèi)绾卧谌绱艘粋€(gè)過程中處理人與人之間的交互呢？在正確傳遞信息的情況下，我們又如何保證投入的最小化呢？意圖軟件開發(fā)過程是知識(shí)傳遞、知識(shí)轉(zhuǎn)換的過程。注重知識(shí)轉(zhuǎn)換中的完整性，保證知識(shí)通過各個(gè)時(shí)期和活動(dòng)，順利的轉(zhuǎn)換為軟件是極為重要的。2、示例 元朗公司是國(guó)內(nèi)某銀行的下屬企業(yè)。從年初開始，公司就投入了大量的人力為銀行開發(fā)新版本的國(guó)際收支系統(tǒng)?？紤]到這是一個(gè)特不龐大的系統(tǒng)，因此公司把原先的軟件開發(fā)團(tuán)隊(duì)擴(kuò)大了一倍，補(bǔ)充的人員有些來自于其它的項(xiàng)目組，有些人員來自不的公司。為了保證開發(fā)的順利進(jìn)行，項(xiàng)目經(jīng)理引入了軟件

20、過程。然而從一開始，苦惱的情況就出現(xiàn)了。項(xiàng)目組中的技術(shù)人員和銀行的領(lǐng)域?qū)＜抑g不斷出現(xiàn)意見相左的情況。要緊的問題是后加入的職員對(duì)目標(biāo)領(lǐng)域不熟悉，難以配合領(lǐng)域?qū)＜业墓ぷ?。最糟糕的是，某些領(lǐng)域?qū)＜疑硖幃惖?，因此在需求分析的中期，開發(fā)團(tuán)隊(duì)邀請(qǐng)這些異地的領(lǐng)域?qū)＜襾淼介_發(fā)所在地，進(jìn)行了為期兩天的討論會(huì)。結(jié)果并不理想，討論會(huì)上充滿了對(duì)原先已定稿的需求的反對(duì)性意見，技術(shù)專家、領(lǐng)域?qū)＜页吵梢粓F(tuán)。需求分析時(shí)期不得不在原先的基礎(chǔ)上延長(zhǎng)了50%的時(shí)刻。在進(jìn)入設(shè)計(jì)和編碼時(shí)期之后，問題少了許多。但在設(shè)計(jì)到編碼的過程中仍是出了一些苦惱，緣故是新加入的人員不熟悉開發(fā)團(tuán)隊(duì)的設(shè)計(jì)風(fēng)格。通過一番周折，問題差不多解決了?？傻鹊巾?xiàng)目

21、進(jìn)入到測(cè)試時(shí)期，矛盾一下子就凸現(xiàn)出來了。測(cè)試報(bào)告指出，軟件中存在著大量的問題，大部分的問題都被定性為無法滿足需求的嚴(yán)峻錯(cuò)誤。通過對(duì)錯(cuò)誤的復(fù)審，排除了其中17%的嚴(yán)峻錯(cuò)誤。通過分析，發(fā)覺其中70%的錯(cuò)誤差不多上發(fā)生在后加入人員負(fù)責(zé)的模塊中。而產(chǎn)生大量錯(cuò)誤的一個(gè)要緊緣故是在編碼時(shí)期，由于銀行啟用了新的會(huì)計(jì)制度，導(dǎo)致大量模塊被修改，由于時(shí)刻緊迫，因此沒有進(jìn)行正規(guī)的需求調(diào)研?，F(xiàn)在看來，領(lǐng)域?qū)＜液图夹g(shù)專家對(duì)同一個(gè)問題的理解并不相同。最后，項(xiàng)目的開發(fā)周期延長(zhǎng)了40%。分析軟件過程每經(jīng)歷一個(gè)時(shí)期，就會(huì)發(fā)生一次知識(shí)轉(zhuǎn)換的情況。這種轉(zhuǎn)換是由人來完成的，這確實(shí)是像是接力一樣，一個(gè)人把腦中的知識(shí)以某種方式傳遞給另一

22、個(gè)人，再有另一個(gè)人傳遞下去，直至編碼人員把這些知識(shí)固化在最終的軟件中。在軟件成型之前，知識(shí)的要緊載體是文檔和模型。我們稱它們?yōu)楣ぜˋrtifact）。例如，需求時(shí)期時(shí)，領(lǐng)域?qū)＜以诩夹g(shù)專家的關(guān)心下，將自己腦中對(duì)領(lǐng)域的認(rèn)識(shí)傳遞給技術(shù)人員，并最終形成需求規(guī)格書或是用例模型。而在分析設(shè)計(jì)時(shí)期，技術(shù)專家借助需求規(guī)格書，把腦中對(duì)軟件的初始認(rèn)識(shí)進(jìn)一步轉(zhuǎn)換為分析模型、設(shè)計(jì)模型、數(shù)據(jù)模型等工件。最后，在編碼時(shí)期，編碼人員把這些工件中隱藏的知識(shí)轉(zhuǎn)化為軟件的形式。通過測(cè)試和部署，軟件將會(huì)交付到用戶手中。這是特不典型的軟件開發(fā)過程，再簡(jiǎn)單的軟件開發(fā)也需要經(jīng)歷上述的這些時(shí)期。能夠看到，在上述的軟件開發(fā)過程中，知識(shí)形式

23、發(fā)生了兩次的重要轉(zhuǎn)換，知識(shí)所屬角色也改變了兩次。知識(shí)完成第一次的形式轉(zhuǎn)換之后，將成為需求規(guī)格書（或同類工件）的形式，知識(shí)從領(lǐng)域?qū)＜业哪X中轉(zhuǎn)換到技術(shù)專家的腦中。然后，知識(shí)開始了第二次的形式轉(zhuǎn)換，形成設(shè)計(jì)模型（以及同類工件）。隨著知識(shí)從技術(shù)專家轉(zhuǎn)移到編碼人員，知識(shí)轉(zhuǎn)換為其最終的軟件形式。在這些轉(zhuǎn)換的過程中，最容易出現(xiàn)信息遺漏、信息失確實(shí)情況。保證轉(zhuǎn)換過程中知識(shí)的完整性和正確性，對(duì)軟件開發(fā)具有重要的意義。4、問題假如保證轉(zhuǎn)換時(shí)知識(shí)的完整性和正確性？5、方法 知識(shí)轉(zhuǎn)換的主體是人，因此我們要緊的對(duì)策也是針對(duì)人來展開的。我們明白，軟件過程的特點(diǎn)確實(shí)是：越早埋下禍根對(duì)項(xiàng)目的殺傷力越大。因此我們首先需要重點(diǎn)防

24、范的對(duì)象應(yīng)該是在初始需求分析時(shí)期。需求分析時(shí)期涉及的知識(shí)特不的多，大伙兒假如有興趣能夠參看我的文章需求的實(shí)踐。但那個(gè)地點(diǎn)我們重點(diǎn)的任務(wù)是找出需求分析時(shí)期中發(fā)生知識(shí)轉(zhuǎn)移的關(guān)鍵點(diǎn)。領(lǐng)域?qū)＜液图夹g(shù)專家是需求時(shí)期中最重要的兩種人，不論你的項(xiàng)目和團(tuán)隊(duì)規(guī)模屬于哪一種層次，一定都包含這兩種角色。假如你的團(tuán)隊(duì)中領(lǐng)域?qū)＜液图夹g(shù)專家是同一種人，那么恭喜你，你能夠不用閱讀這一段的內(nèi)容了。惋惜在強(qiáng)調(diào)分工協(xié)作和軟件規(guī)模不斷擴(kuò)大的今天，這種人差不多特不難找了。領(lǐng)域?qū)＜沂侵R(shí)的最初持有者，其職責(zé)是為項(xiàng)目提供準(zhǔn)確的、完整的需求信息。技術(shù)專家的職責(zé)則是關(guān)心領(lǐng)域?qū)＜彝瓿蛇@一項(xiàng)工作。因此，首先請(qǐng)保證領(lǐng)域?qū)＜液图夹g(shù)專家是能夠溝通的，

25、示例中的項(xiàng)目的第一個(gè)問題確實(shí)是團(tuán)隊(duì)的新成員和領(lǐng)域?qū)＜抑g存在溝通壁壘。在我們的經(jīng)驗(yàn)中，就發(fā)生過一位優(yōu)秀的技術(shù)人員和一位資深的領(lǐng)域?qū)＜覡?zhēng)吵的情況。剖析緣故之后，我們發(fā)覺，最要緊的緣故是他們兩個(gè)人都太優(yōu)秀了，技術(shù)人員有一定的領(lǐng)域經(jīng)驗(yàn)，領(lǐng)域?qū)＜矣幸欢ǖ拈_發(fā)經(jīng)驗(yàn)，這導(dǎo)致了雙方在討論中的強(qiáng)硬立場(chǎng)。因此，假如遇到類似的情況，請(qǐng)對(duì)你的組織進(jìn)行崗位調(diào)整。但在執(zhí)行這項(xiàng)工作之前，請(qǐng)小心你的講辭，不要損害到任何一個(gè)人。我們的某個(gè)小組有苦惱，那邊特不需要你的經(jīng)驗(yàn)和能力會(huì)是一句不錯(cuò)的講辭。其次，技術(shù)專家不應(yīng)該提出任何可能阻礙領(lǐng)域?qū)＜业膯栴}。只有領(lǐng)域?qū)＜也拍軌蛱岢鲂枨?，技術(shù)專家起到的只是輔助作用。因此請(qǐng)杜絕這種情況。再次

26、，假如你的領(lǐng)域?qū)＜也恢灰粋€(gè)人，那么你需要考慮領(lǐng)域?qū)＜抑g可能出現(xiàn)的不一致。為領(lǐng)域團(tuán)隊(duì)指定一位領(lǐng)導(dǎo)者是一種不錯(cuò)的做法。在我們的一個(gè)項(xiàng)目中，就曾邀請(qǐng)對(duì)方公司的財(cái)務(wù)總監(jiān)擔(dān)任這一角色。理由有二：1、財(cái)務(wù)總監(jiān)具有權(quán)威性；2、財(cái)務(wù)總監(jiān)了解公司的全部運(yùn)作。此外，假如領(lǐng)域?qū)＜曳植荚诓煌攸c(diǎn)的話，你需要在該時(shí)期的某個(gè)時(shí)期，安排需求討論會(huì)，并考慮一種能夠溝通的方式，以便隨時(shí)能夠了解身處異地的領(lǐng)域?qū)＜业囊庖姟＿@種情況關(guān)于那些擁有分公司的公司（例如銀行、證券、保險(xiǎn)、銷售公司等等）而言特不的普遍。因此，我們?cè)谛枨蠓治鰰r(shí)期，首先要處理好領(lǐng)域?qū)＜液图夹g(shù)專家之間的關(guān)系。應(yīng)該講，那個(gè)地點(diǎn)提到的內(nèi)容不僅僅適用于需求時(shí)期，在整個(gè)的

27、開發(fā)過程中都有用處。需求不是實(shí)現(xiàn)。需求表示的是有什么（What），并不關(guān)懷如何做（How）。假如在需求分析時(shí)期把精力分散到了如何實(shí)現(xiàn)需求上，那么需求分析的效果就會(huì)受到阻礙。這體現(xiàn)在需求的完整性和正確性兩個(gè)方面。領(lǐng)域?qū)＜液图夹g(shù)專家都可能犯類似的錯(cuò)誤。領(lǐng)域?qū)＜彝荒軌蜥槍?duì)自己的工作來描述需求，而他會(huì)專門容易的把自己關(guān)于需求實(shí)現(xiàn)看法參雜到需求描述中。從項(xiàng)目的整體范圍來看，這種需求描述有時(shí)候是有問題的。假如你開發(fā)的是一個(gè)定制應(yīng)用，那問題還不大，假如你開發(fā)的是一個(gè)產(chǎn)品，那么問題就專門嚴(yán)峻了。領(lǐng)域?qū)＜颐枋龅男枨笠欢ㄊ悄阈枰膬?nèi)容嗎？例如，你打算開發(fā)一個(gè)配送的治理應(yīng)用，然而領(lǐng)域?qū)＜野汛罅康木ㄔ诹怂谠?/p>

28、先的公司中如何實(shí)現(xiàn)配送的流程上，那個(gè)過程可能適合于他的公司，然而關(guān)于產(chǎn)品而言，可能就不合適，因?yàn)椴⒎撬械呐渌凸径际褂眠@種流程的。好吧，你想要的內(nèi)容和你不想要的內(nèi)容混合在一起，這使得你不得不花費(fèi)精力對(duì)需求進(jìn)行進(jìn)一步的整理。因此，好的做法是，一開始就明確領(lǐng)域?qū)＜覒?yīng)該提供什么，而且，盡可能的提供需求，而不是需求實(shí)現(xiàn)。多問一些諸如假如環(huán)境發(fā)生變化，你該如何做之類的問題，否則你會(huì)發(fā)覺，用戶的需求變化將會(huì)對(duì)你的軟件造成專門大的阻礙。再講技術(shù)專家，技術(shù)專家常常犯的毛病是把分析參雜到需求調(diào)研中來，從需求描述中精練出一些業(yè)務(wù)實(shí)體（或進(jìn)行CRC討論）是能夠的，然而過早的考慮實(shí)現(xiàn)方式將會(huì)限制你的思維。因此，請(qǐng)確

29、保需求只是需求，如此才能夠盡可能保證需求的完整性和正確性。需求復(fù)審是特不重要的檢查點(diǎn)。請(qǐng)確保你正確的使用它。需求復(fù)審需要領(lǐng)域?qū)＜液图夹g(shù)專家、以及治理者的參與。需求復(fù)審是保證需求完整性和正確性的最后一道防線。在專門多的文章（包括我的需求的實(shí)踐一文）、過程都對(duì)需求復(fù)審進(jìn)行了論述，我們那個(gè)地點(diǎn)就不贅述了。在實(shí)踐過程中，我們發(fā)覺，需求復(fù)審還有一個(gè)好的方式，為了能夠通過需求復(fù)審，需求分析人員（包括領(lǐng)域?qū)＜液图夹g(shù)專家）會(huì)特不努力的找出需求中的問題。因此，在你的過程中加入那個(gè)檢查點(diǎn)是特不有必要的。好的，假如這一切都進(jìn)行順利的話，最后的需求規(guī)格書應(yīng)該是比較完美的，而技術(shù)專家也差不多從領(lǐng)域?qū)＜夷莾毫私獾搅俗銐虻?/p>

30、信息，能夠開始下一時(shí)期的開發(fā)了。那個(gè)地點(diǎn)，我們?cè)倩ㄒ恍┕P墨來討論迭代過程中，我們?nèi)绾翁幚硇枨?。?shí)踐中，我們認(rèn)為迭代次數(shù)并不是越多越好，應(yīng)該依照項(xiàng)目規(guī)模和團(tuán)隊(duì)特點(diǎn)進(jìn)行區(qū)分，每一次的迭代都可能有自己的目標(biāo)。例如首次迭代的周期可能比較短，其要緊的目標(biāo)定為提供軟件原型、驗(yàn)證要緊設(shè)計(jì)思路等。第二次的迭代的周期能夠長(zhǎng)一些，目標(biāo)能夠定位為實(shí)現(xiàn)要緊功能。假如軟件規(guī)模比較大，也能夠?yàn)槊看蔚O(shè)定需求范圍（或要緊場(chǎng)景），如此就能夠防止需求擴(kuò)散的情況。這差不多超出了本文的范圍，因此我們那個(gè)地點(diǎn)只是簡(jiǎn)單的提一下。分析時(shí)期是發(fā)生職責(zé)轉(zhuǎn)換的重要時(shí)期。該時(shí)期的成敗對(duì)軟件開發(fā)至關(guān)重要。關(guān)于面向?qū)ο箝_發(fā)而言，那個(gè)過程最要緊的任

31、務(wù)是對(duì)領(lǐng)域進(jìn)行建模。比較好的方式是使用UML來描述領(lǐng)域知識(shí)，例如，我比較經(jīng)常使用類圖來建立分析模型，使用順序圖來描述動(dòng)態(tài)流程。請(qǐng)確保技術(shù)團(tuán)隊(duì)中最出色的分析建模人員參與那個(gè)初始分析建模的過程。他的職責(zé)包括指導(dǎo)建模和對(duì)模型進(jìn)行審查。假如在一個(gè)迭代過程中，那個(gè)模型是不斷演進(jìn)的，這能夠減少一些風(fēng)險(xiǎn)。在那個(gè)過程中，建模人員能夠汲取領(lǐng)域知識(shí)，這關(guān)于后續(xù)時(shí)期中指導(dǎo)其他開發(fā)人員是專門重要的，對(duì)公司的長(zhǎng)遠(yuǎn)目標(biāo)也具有重要意義（參見 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index6.html

32、短期利益和長(zhǎng)期利益的權(quán)衡模式）。假如建模人員缺少面向?qū)ο箝_發(fā)的經(jīng)驗(yàn)，他會(huì)專門容易把對(duì)象變成一個(gè)數(shù)據(jù)容器。這種方式并不是不行，但它把數(shù)據(jù)和行為區(qū)分開來，無法站在一個(gè)抽象的高度上對(duì)領(lǐng)域進(jìn)行分析。 專門難嚴(yán)格的區(qū)分分析時(shí)期和設(shè)計(jì)時(shí)期，至少我是這么覺得的。他們的差不僅僅是在分析的詳細(xì)程度上（有點(diǎn)類似于以往的概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)）。在實(shí)踐中，我們發(fā)覺，并沒有必要嚴(yán)格的區(qū)分它們，然而你需要保證模型差不多完整的描述了需求。那個(gè)地點(diǎn)能夠設(shè)置檢查點(diǎn)來驗(yàn)證，也能夠在設(shè)計(jì)模型出來之后再進(jìn)行檢查，這取決于具體的項(xiàng)目。因此，我們?cè)诜治鰰r(shí)期和設(shè)計(jì)時(shí)期結(jié)束之前需要進(jìn)行設(shè)計(jì)復(fù)審。從Martin Fowler提出分析模式的概念之

33、后（現(xiàn)在他的第二本分析模式正在寫作中），它就成為分析建模的有利助手之一對(duì)領(lǐng)域概念進(jìn)行分析和建模，并描述它們之間的關(guān)系（我在點(diǎn)空間上的一篇讀書筆記反應(yīng)了需求和分析之間的關(guān)系）。然而請(qǐng)千萬注意，不要誤用和濫用分析模式。因?yàn)槿魏畏治瞿Ｊ降奶岢?，差不多上基于某個(gè)上下文環(huán)境中的需求的，假如上下文環(huán)境不同，那么模式就需要改進(jìn)或改造。因此，分析模式是一個(gè)好的開始，但需要你針對(duì)實(shí)際需求具體分析。在應(yīng)用模式方面，F(xiàn)rank Buschmann的Applying Patterns是一篇不錯(cuò)的參考文章，其中文版公布在點(diǎn)空間上。請(qǐng)按照逐步精化（迭代）的方式來完善、改進(jìn)你的分析模型。優(yōu)秀的設(shè)計(jì)一定可不能過于復(fù)雜。假如你

34、的分析模型出現(xiàn)過于復(fù)雜的情況，到處充斥著復(fù)雜的關(guān)系網(wǎng)。那么，你需要對(duì)你的設(shè)計(jì)進(jìn)行結(jié)構(gòu)上的改進(jìn)。例如，采納分層（參見 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/part9/index.html 敏捷架構(gòu)設(shè)計(jì)一文中的分層模式）、組件技術(shù)、或是使用單向聯(lián)系。堅(jiān)持這一過程，你會(huì)發(fā)覺最后的設(shè)計(jì)是簡(jiǎn)潔的、完美的。 在設(shè)計(jì)時(shí)期，要注意的事項(xiàng)和分析時(shí)期相差不多，例如不要誤用和濫用設(shè)計(jì)模式。然而有一點(diǎn)是需要額外強(qiáng)調(diào)的。當(dāng)分析模型差不多能夠完整、正確的描述需求之后，我們就需要在設(shè)計(jì)模型中添加設(shè)計(jì)資料。例如對(duì)包、組件、類、

35、方法的描述。這時(shí)候，需求的信息差不多被打散到軟件的各個(gè)部分中了。而設(shè)計(jì)模型在被實(shí)現(xiàn)時(shí)，設(shè)計(jì)模型中的信息又將進(jìn)入到代碼中。因此，保持這些信息的一致性就顯得特不的關(guān)鍵。而由于設(shè)計(jì)模型處在中間地帶，它的重要性又是不言而喻的。差不多的處理思路分為兩步：在需求發(fā)生改變時(shí)，請(qǐng)同步更改設(shè)計(jì)模型以及設(shè)計(jì)模型中的信息。再由設(shè)計(jì)模型驅(qū)動(dòng)代碼的修改。第一個(gè)步驟是需要手動(dòng)實(shí)現(xiàn)的，然而第二個(gè)步驟能夠由計(jì)算機(jī)輔助實(shí)現(xiàn)，即保持設(shè)計(jì)模型和代碼信息的一致性（將在 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/ind

36、ex4.html 一致性的考慮模式中討論）。目前有專門多的建模工具都能夠做到這一點(diǎn)，甚至能夠?qū)崿F(xiàn)產(chǎn)生最終的API文檔。善用這項(xiàng)功能，它能令你事半功倍。 在軟件過程中設(shè)立反饋活動(dòng)，能夠有效的減少項(xiàng)目的偏差。就像我們騎自行車，專門少能夠走一條直線，一般我們是依照對(duì)目標(biāo)的偏差進(jìn)行忽左忽右的調(diào)整。這確實(shí)是反饋的機(jī)理。原型法是一種不錯(cuò)的反饋機(jī)制，依照我們的經(jīng)驗(yàn)，視覺刺激對(duì)用戶是最為關(guān)鍵的，因此不論你的需求文檔做的如何的優(yōu)秀，仍然比不上一個(gè)能夠看得見的軟件原型有效。這一實(shí)踐專門多的軟件工程資料中都有敘述，我們就不深入了解了。另一種反饋機(jī)制是漸進(jìn)交付。把軟件產(chǎn)品分為多個(gè)迭代周期，每個(gè)周期交付一個(gè)可運(yùn)行的軟件

37、，在獲得用戶的反饋意見之后，在下一個(gè)迭代周期進(jìn)行改進(jìn)，最后一個(gè)迭代周期交付的確實(shí)是完整的軟件了。6、對(duì)可重用框架的改進(jìn) 在找到了適合軟件企業(yè)自身的知識(shí)接力方法之后，應(yīng)當(dāng)將其作為規(guī)范或指導(dǎo)意見，加入到現(xiàn)有的軟件過程中。例如，在需求分析完成之后強(qiáng)制要求進(jìn)行需求評(píng)審。加入到過程中的方法，小心不要流于形式。如此，既付出了成本，又收不到應(yīng)用的效果。使用工具也是保持知識(shí)順利交接的重要方法。例如，采納自動(dòng)產(chǎn)生源代碼的工具，模型設(shè)計(jì)工具、關(guān)心產(chǎn)生工具、對(duì)象-關(guān)系映射工具等等。假如這些工具對(duì)你的過程起到了潤(rùn)滑的作用，請(qǐng)規(guī)范和普及工具的使用。7、小結(jié)請(qǐng)確保領(lǐng)域?qū)＜液图夹g(shù)專家之間的順暢溝通。 完整、準(zhǔn)確的描述需求。

38、 進(jìn)行需求復(fù)審和設(shè)計(jì)復(fù)審。 保證分析模型（設(shè)計(jì)模型）能夠完整的描述需求。 保持需求信息到設(shè)計(jì)信息到代碼注釋的一致。 使用反饋機(jī)制。 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index3.html 三、代碼是最終目 過程的最終目的是代碼，開發(fā)過程中的所有活動(dòng)都圍繞著這一目的而展開。假如沒有最后的用于交付的代碼，軟件就無法成為軟件。因此，必須保證過程能夠產(chǎn)出代碼，而且是優(yōu)秀的代碼。1、意圖 不管哪一種過程，其最終目的差不多上為了產(chǎn)生出可執(zhí)行、同時(shí)可用的軟件。因此軟件過程中的各種活

39、動(dòng)應(yīng)該圍繞著快速、準(zhǔn)確的實(shí)現(xiàn)這一目的而展開的。 2、示例 維力亞軟件公司是一家合資公司，由于有外資背景，公司內(nèi)部專門早就引入了軟件工程，并嚴(yán)格的對(duì)人員角色進(jìn)行分工。包括領(lǐng)域建模人員、架構(gòu)設(shè)計(jì)師、高級(jí)程序員、程序員、界面設(shè)計(jì)師等等多種角色。每個(gè)人各司其職，充分發(fā)揮出了分工的特點(diǎn)。然而隨著公司開發(fā)項(xiàng)目的逐漸增多，這種方式也顯露出其弊端來。每個(gè)人的要緊目標(biāo)差不多上為了通過評(píng)審，而有時(shí)候，就確實(shí)是通過評(píng)審的工件，依舊可能存在問題。但這時(shí)候扯皮就出現(xiàn)了。項(xiàng)目中存在的一些中空地帶。以及交錯(cuò)地帶，常常發(fā)生無人問津的情況。開發(fā)過程的效率開始下降，開發(fā)成本開始上升。問題盡管不是一下子出現(xiàn)的，然而差不多逐漸變得嚴(yán)

40、峻起來了。 3、分析 我們?cè)谶M(jìn)行過程設(shè)計(jì)，或引入一個(gè)過程理論的時(shí)候，有沒有考慮過該過程的每一個(gè)時(shí)期、每一個(gè)活動(dòng)的目的是什么，它們對(duì)生成最后的軟件有什么樣的關(guān)心，這些關(guān)心關(guān)于我們所在的組織有意義嗎。專門多情況下，我們并沒有這么做，或者隨著軟件過程的定型，就不再考慮這類的問題。一開始并沒有什么了不起的，然而當(dāng)軟件過程演變成了一種政治體系的時(shí)候，那么問題就會(huì)慢慢嚴(yán)峻起來。 4、問題如何讓過程圍繞著產(chǎn)出軟件的核心目標(biāo)而不斷演進(jìn)？ 5、方法 從上一篇介紹的內(nèi)容中，我們明白軟件過程的每一個(gè)時(shí)期差不多上知識(shí)轉(zhuǎn)換的過程，知識(shí)轉(zhuǎn)換的終點(diǎn)確實(shí)是軟件。問題在于，我們?nèi)绾伪ＷC這種轉(zhuǎn)換的效率呢？ 現(xiàn)代軟件的進(jìn)展的趨勢(shì)是

41、重用。我們開發(fā)一個(gè)軟件差不多專門少會(huì)從最底層開始編寫了。我們使用各種各樣的技術(shù)和平臺(tái)。包括數(shù)據(jù)庫(kù)、分布式體系、UI機(jī)制、業(yè)務(wù)元素等等。因此現(xiàn)在的軟件編寫往往差不多上站在巨人的肩膀上開始的。不同的軟件組織，肩膀的高低也不一樣。比如有的軟件組織使用J2EE平臺(tái)，有的軟件組織則使用.NET平臺(tái)。然而能夠確信的一點(diǎn)是，每個(gè)軟件組織都或多或少的擁有自己的平臺(tái)體系開發(fā)經(jīng)驗(yàn)。這些經(jīng)驗(yàn)的表現(xiàn)形式也不盡相同，可能是保存在某些高級(jí)技術(shù)人員的腦中，也可能是保存為文檔、模型或代碼的形式。關(guān)于單個(gè)的項(xiàng)目而言，其過程一定是從需求開始，以部署（以及后續(xù)維護(hù)）為終結(jié)的。然而關(guān)于長(zhǎng)時(shí)刻存在的軟件組織而言，更重要的是項(xiàng)目經(jīng)驗(yàn)、技

42、術(shù)經(jīng)驗(yàn)、治理經(jīng)驗(yàn)的積存。如此講可能過于抽象，我們舉一個(gè)具體的例子。在完成了一個(gè)庫(kù)存治理項(xiàng)目之后，我們把庫(kù)存治理的領(lǐng)域知識(shí)制作為商業(yè)組件的形式，而把項(xiàng)目中學(xué)習(xí)到的一些編碼的技巧整理為模式的形式，并把項(xiàng)目過程中積存的過程方法添加到現(xiàn)有的軟件過程中。這些經(jīng)驗(yàn)的堆積確實(shí)是在一開始我們提出的可重用框架。對(duì)一個(gè)軟件團(tuán)隊(duì)的來講，它的所有軟件項(xiàng)目都應(yīng)該是圍繞著這一個(gè)可重用框架而展開的。 迄今為止，我們見過的大多數(shù)的可重用框架表現(xiàn)形式都能夠總結(jié)為：以開發(fā)平臺(tái)為基礎(chǔ)，積存自己的商業(yè)組件，并以此為中心訂立開發(fā)活動(dòng)。這種形式是不是最好并沒有定論，但我們是抱著學(xué)習(xí)的態(tài)度來研究它的。 以開發(fā)平臺(tái)為基礎(chǔ)的意思是軟件組織必須

43、有自己所熟悉的開發(fā)平臺(tái)，其大部分的項(xiàng)目差不多上在此基礎(chǔ)上進(jìn)行的。目前最流行的兩種軟件開發(fā)平臺(tái)是J2EE和.NET，然而就確實(shí)是同一個(gè)平臺(tái)，不同的軟件組織對(duì)平臺(tái)內(nèi)部的側(cè)重也是不同的（同樣關(guān)于J2EE技術(shù)，有的軟件組織可能把JSP和Servlet作為核心選擇，而另一些軟件組織則把重點(diǎn)放在EJB上）。選擇一種廣泛應(yīng)用的、具有生命力的平臺(tái)技術(shù)是特不重要的。因?yàn)槟愕目蚣軐?huì)以此為基礎(chǔ)進(jìn)行，而框架的轉(zhuǎn)移成本是特不之高的。盡管我們?cè)谝婚_始介紹的MDA思路為我們繪制了一副平臺(tái)無關(guān)設(shè)計(jì)的美好愿景，然而在目前時(shí)期，我們?nèi)匀灰鎸?duì)不同軟件平臺(tái)造成的嚴(yán)峻隔閡。 必須指出的是，我們上面提到的開發(fā)平臺(tái)指的是在操作系統(tǒng)那個(gè)

44、層次之上的平臺(tái)，也確實(shí)是俗稱的中間件平臺(tái)。然而從中間件到最終的產(chǎn)品之間有沒有過渡的平臺(tái)呢。事實(shí)上可重用框架就扮演了這一角色。軟件市場(chǎng)上差不多出現(xiàn)了商業(yè)化的可重用框架了。IBM的SanFrancisco框架確實(shí)是這種概念的代表。 平臺(tái)技術(shù)僅僅只是提供了一個(gè)技術(shù)，而軟件組織要生存和進(jìn)展，還需要積存和進(jìn)展自己的商業(yè)組件。并將商業(yè)組件進(jìn)展成為可重用框架。商業(yè)組件的好壞，直接和軟件組織的能力、經(jīng)驗(yàn)，以及平臺(tái)技術(shù)相關(guān)。商業(yè)組件可能直接表現(xiàn)為代碼的形式（Bean、類、COM組件等），也可能只是描述性的記錄（文檔）。商業(yè)組件是經(jīng)驗(yàn)積存而成的。請(qǐng)注意，商業(yè)組件的設(shè)計(jì)并不完全等同于面向?qū)ο箝_發(fā)，因?yàn)槊嫦驅(qū)ο笾皇且?/p>

45、種技術(shù)手段，然而商業(yè)組件設(shè)計(jì)的優(yōu)劣，更重要的是對(duì)業(yè)務(wù)的理解程度。舉一個(gè)最淺顯的例子，一個(gè)精通面向?qū)ο箝_發(fā)、面向組件開發(fā)的設(shè)計(jì)師，讓他介入他完全不了解的行業(yè)組件設(shè)計(jì)，他的表現(xiàn)將會(huì)大打折扣。 到目前為之，大伙兒所認(rèn)識(shí)的框架仍然是技術(shù)型的框架。但事實(shí)并非如此，框架還包括了外延的一系列軟件活動(dòng)。這才是一個(gè)完整的框架。結(jié)合之前我們討論的軟件交付為開發(fā)目標(biāo)。我們把這種開發(fā)方式稱為以可重用框架為核心，以交付為目標(biāo)的軟件開發(fā)。這事實(shí)上并不是什么了不起的概念，大部分的軟件組織都差不多這么做了，只是沒有意識(shí)到自己的方式而已。了解這一點(diǎn)，能夠關(guān)心軟件組織有效的改進(jìn)自身的構(gòu)架。 平臺(tái)技術(shù)和組件開發(fā)并不是本文的重點(diǎn)，因

46、此我們?cè)诖_信了兩者的重要性之后，把精力轉(zhuǎn)移到軟件活動(dòng)上。 在擁有一個(gè)框架核心（平臺(tái)和商業(yè)組件）之后，框架需要包含如此的活動(dòng)（或活動(dòng)集）：收集項(xiàng)目需求，并將需求映射到核心構(gòu)架上來。這事實(shí)上確實(shí)是需求時(shí)期到設(shè)計(jì)時(shí)期要做的情況。然而由于我們的活動(dòng)是以軟件交付為目標(biāo)的，因此我們需要明確的指出活動(dòng)中的注意事項(xiàng)。 為映射工作設(shè)計(jì)需求描述規(guī)格。需求并不是一件容易的事。最難的莫過于尺度的把握了，例如需求要多詳細(xì)。使用現(xiàn)成的技術(shù)來定義需求描述規(guī)格，并依照核心框架的特點(diǎn)進(jìn)行必要的擴(kuò)展。例如，我們使用成熟的用例技術(shù)來描述需求，同時(shí)我們要求需求按照不同類的商業(yè)組件進(jìn)行分類索引。用例技術(shù)的推舉讀物是Alistair C

47、ockburn的Writing Effective Use Cases一書，該書目前已有英文影印版。 保證需求規(guī)格能夠被項(xiàng)目成員所理解。那個(gè)地點(diǎn)的項(xiàng)目成員包括客戶、領(lǐng)域?qū)＜?、需求調(diào)研者、分析模型設(shè)計(jì)師。只有他們了解需求，才能夠保證信息的正確的傳遞。（參見 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知識(shí)接力模式）。 為實(shí)現(xiàn)需求制定分析（設(shè)計(jì)）規(guī)則和指南 。這是把需求映射到核心構(gòu)架上的重要步驟。制定規(guī)則是必要的，但要小心，不要讓規(guī)則限制住開發(fā)人員的制造力（參

48、見 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index5.html 活躍和混亂、嚴(yán)謹(jǐn)和死板模式）。規(guī)則的形式可能是設(shè)計(jì)規(guī)范、分析模式、類庫(kù)、組件重用等等。在指南中提供示例，描述如何將需求轉(zhuǎn)換為設(shè)計(jì)模型是一種不錯(cuò)的做法。同樣好的做法還包括了模式指南。 確保測(cè)試貫穿了需求模型和設(shè)計(jì)模型。我們終于提到了測(cè)試。測(cè)試在軟件過程中扮演著重要的角色。但遺憾的是在本文中直接提到的機(jī)會(huì)并不多，從某個(gè)角度上看。 HYPERLINK /developerworks/cn/linux/softwar

49、e_engineering/Methodology/method2code/index2.html 知識(shí)接力模式中提到的復(fù)審事實(shí)上也確實(shí)是一種測(cè)試。測(cè)試的信息都包含在需求模型和設(shè)計(jì)模型之中，例如前置條件和后置條件。在完成需求模型和設(shè)計(jì)模型時(shí)同步完成測(cè)試用例是一種特不行的做法（我們的團(tuán)隊(duì)正是采納這種做法），然而需要小心文檔一致性（參見 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性的考慮模式）的所需要付出的額外成本。 如同在 HYPERLINK /dev

50、eloperworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知識(shí)接力模式中提到的那樣，讓領(lǐng)域?qū)＜摇⒓軜?gòu)師和高級(jí)開發(fā)人員對(duì)需求模型和設(shè)計(jì)模型進(jìn)行復(fù)審。 原型方法能夠有效的關(guān)心最終軟件的成功。所謂原型方法，確實(shí)是選取系統(tǒng)的某個(gè)部分（最直接或風(fēng)險(xiǎn)最高的部分，通常是界面原型）， 實(shí)現(xiàn)并呈現(xiàn)給用戶，以獲得反饋，為后續(xù)的活動(dòng)提供指導(dǎo)。原型方法最大的好處是能夠關(guān)心用戶認(rèn)識(shí)軟件，消除用戶的疑慮，并發(fā)掘潛藏的需求。圍繞著是否拋棄原型這一全然問題，原型方法能夠分為漸進(jìn)原型方法和舍棄型原型方法。前者是在一個(gè)軟件原型的基礎(chǔ)

51、上不斷的演進(jìn)，并最終進(jìn)展為可用的軟件，后者則是在開發(fā)出原型之后就將它舍棄。漸進(jìn)原型方法充分利用了原型，然而由于缺乏前期設(shè)計(jì)，可能會(huì)導(dǎo)致最終產(chǎn)品存在性能或設(shè)計(jì)問題。舍棄型原型克服了那個(gè)問題，然而它白費(fèi)了原型開發(fā)的那段時(shí)刻。不論采納何種方法，最重要的是在項(xiàng)目一開始就決定采納哪一種原型方法。模棱兩可的使用兩種方法是兵家大忌。最終你無法利用任何一種方法的優(yōu)點(diǎn)，而所有的缺點(diǎn)都將降臨到你身上。相較而言，漸進(jìn)型原型方法更適合于應(yīng)用在小型項(xiàng)目上，因?yàn)轫?xiàng)目并不復(fù)雜的話，設(shè)計(jì)的改進(jìn)比較容易。關(guān)于一個(gè)擁有構(gòu)架的團(tuán)隊(duì)而言，把原型方法納入構(gòu)架之中是專門有意義的。假如構(gòu)架足夠成數(shù)，迅速開發(fā)出一個(gè)原型并不是什么專門困難的情

52、況。如此就能夠在投入最小化的情況下獲得原型方法的優(yōu)勢(shì)。假如情況是如此的話，舍棄型原型方法大概更適合一些。 在 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知識(shí)接力模式中，我們簡(jiǎn)要的提到了設(shè)計(jì)模型信息和代碼信息的轉(zhuǎn)換問題。使用建模工具來自動(dòng)從設(shè)計(jì)模型抽取信息，并生成項(xiàng)目的代碼。這種方法能夠大幅度的提高軟件開發(fā)效率，并對(duì)軟件的最終交付有專門大的關(guān)心。同樣，將代碼中的信息轉(zhuǎn)回到設(shè)計(jì)模型中（屬于反向工程的一部分）也是有意義的。假如缺少如此的工具，那么請(qǐng)人為的保證信

53、息的同步，因此，并沒有必要保持實(shí)時(shí)的同步（參見 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性的考慮模式）。 軟件的成功和測(cè)試活動(dòng)是無法區(qū)分的。我們前面簡(jiǎn)單的討論過測(cè)試信息是來源于需求的。測(cè)試信息隨著需求模型的生成而生成，并通過設(shè)計(jì)模型進(jìn)行轉(zhuǎn)換，在軟件過程進(jìn)入到實(shí)現(xiàn)時(shí)期時(shí)，測(cè)試信息最終被轉(zhuǎn)變?yōu)閱卧獪y(cè)試用例的形式。單元測(cè)試用例可能是針對(duì)單個(gè)方法的單個(gè)用例，也可能是針對(duì)某個(gè)開發(fā)包的幾組用例。我們需要注意兩點(diǎn)，首先是在軟件過程中保證那個(gè)流程的順暢和正確。就像

54、在 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知識(shí)接力模式中討論的那樣，正確、完整的信息傳遞保證了最終軟件的成功出產(chǎn)，測(cè)試信息的成功傳遞保證了最終軟件的可用性。測(cè)試是軟件的保證。因此，我們需要幾個(gè)活動(dòng)來保證測(cè)試信息的成功： 從需求模型中生成同意測(cè)試。該活動(dòng)把需求映射到測(cè)試上。在那個(gè)活動(dòng)中，不但要注意功能性需求（如完成的功能），還需要注意非功能性需求（性能要求）。同樣的，同意測(cè)試也需要同意復(fù)審。能夠按照需求的組織方式來組織同意測(cè)試。 設(shè)計(jì)模型完成之后，同意

55、測(cè)試差不多細(xì)化到模型的各個(gè)元素上了（例如包、類）。該項(xiàng)活動(dòng)和將需求映射到設(shè)計(jì)的活動(dòng)是同步進(jìn)行的。因?yàn)樗鼈兲幚淼男畔⑹翘夭活愃频?。和同意測(cè)試一樣，這兩個(gè)活動(dòng)都需要由團(tuán)隊(duì)來保證。 在進(jìn)入編碼時(shí)期之后，開發(fā)人員依照同意測(cè)試和設(shè)計(jì)模型，將會(huì)為自己負(fù)責(zé)的部分設(shè)計(jì)編寫單元測(cè)試。單元測(cè)試的編寫順序是否優(yōu)先于編碼，這取決于各人的看法。關(guān)于這方面的討論，能夠參看XP的單元測(cè)試實(shí)踐。從我個(gè)人的經(jīng)驗(yàn)來看，先寫單元測(cè)試，再寫代碼不失為一個(gè)專門好的方法，另一種做法是，讓兩個(gè)緊密合作的開發(fā)人員相互為對(duì)方編寫單元測(cè)試。 其次，我們需要保證測(cè)試的最小單元單元測(cè)試的成功。所謂皮之不存，毛將焉附。單元測(cè)試沒有組織好，最后的軟件是

56、可不能成功的： 需要注意單元測(cè)試的覆蓋率。那個(gè)地點(diǎn)的覆蓋率指的是是否能夠完全檢測(cè)出錯(cuò)誤所在。比如邊界條件的測(cè)試等。開發(fā)團(tuán)隊(duì)中的架構(gòu)師之類的角色需要為此負(fù)責(zé)，假如無法檢查所有的單元測(cè)試，那么能夠進(jìn)行抽查和代碼復(fù)審會(huì)議的形式。后者是一種專門優(yōu)秀的做法。從代碼中抽取出一段，開發(fā)人員一起分析單元測(cè)試存在哪些問題，會(huì)使得大伙兒編寫單元測(cè)試的功力不斷的增長(zhǎng)。 單元測(cè)試一定要是自動(dòng)化的。Junit確實(shí)是一個(gè)不錯(cuò)的自動(dòng)化測(cè)試框架。保證單元測(cè)試的自動(dòng)化，同時(shí)幸免單元測(cè)試和特定環(huán)境相關(guān)，如此就能夠順利的進(jìn)行回歸測(cè)試。這關(guān)于迭代式的軟件開發(fā)是特不必要的。同時(shí)，我們也應(yīng)該認(rèn)識(shí)到，單元測(cè)試的穩(wěn)定性取決于設(shè)計(jì)的穩(wěn)定性。我

57、們能夠想象，假如測(cè)試的類方法的參數(shù)、命名都發(fā)生改變，那么測(cè)試是確信需要重新組織的。因此，面向?qū)ο蟮某橄笏季S關(guān)于現(xiàn)代軟件開發(fā)而言是費(fèi)產(chǎn)重要的。為了做到測(cè)試的自動(dòng)化，盡量幸免將邏輯硬編碼在界面中，并小心的處理數(shù)據(jù)庫(kù)。能夠嘗試著建立測(cè)試數(shù)據(jù)庫(kù)。 假如測(cè)試的內(nèi)容需要并入核心構(gòu)架，那么這部分的測(cè)試工作需要增加，并對(duì)構(gòu)架可能的修改進(jìn)行測(cè)試。因此，學(xué)習(xí)開源軟件的做法，將構(gòu)架的穩(wěn)定版本和開發(fā)版本相區(qū)分是比較保險(xiǎn)的。 讓測(cè)試活動(dòng)隨著軟件開發(fā)的進(jìn)行而進(jìn)行，讓測(cè)試活動(dòng)貫穿整個(gè)開發(fā)周期。這有點(diǎn)類似于全面質(zhì)量治理的思想。因?yàn)檐浖_發(fā)過程的失敗并不是突然而至的，而是在平常的不經(jīng)意間一點(diǎn)一點(diǎn)的積存起來的。使用測(cè)試活動(dòng)來消除

58、這種微小的不穩(wěn)定性，能夠大幅度的提高最終軟件的質(zhì)量。然而，在一個(gè)團(tuán)隊(duì)中引入正規(guī)的。頻繁的測(cè)試活動(dòng)是需要耐心的。能夠先從單元測(cè)試著手，慢慢的普及這種做法。 測(cè)試活動(dòng)能夠衍生為日創(chuàng)建和冒煙測(cè)試。關(guān)于有復(fù)數(shù)的開發(fā)人員參與的軟件項(xiàng)目，就無法幸免正視集成測(cè)試的局面。有過類似經(jīng)驗(yàn)的人都能夠想象的到這種集成測(cè)試的難度。專門有一句話是描述這種局面的：我們差不多花了90%的時(shí)刻來完成90%的軟件，但我們還需要90%的時(shí)刻來完成剩下的10%?，F(xiàn)代的軟件往往都包括成百上千的文件，這些文件的編譯鏈接的過程是專門復(fù)雜的。而日創(chuàng)建的思想確實(shí)是每天進(jìn)行一次如此的過程，形成一個(gè)可執(zhí)行文件。但這只是日創(chuàng)建第一部分內(nèi)容。日創(chuàng)建還

59、需要對(duì)軟件進(jìn)行冒煙測(cè)試，測(cè)試的要緊內(nèi)容確實(shí)是單元測(cè)試中所編寫的內(nèi)容，保證軟件能夠通過所有的測(cè)試。 日創(chuàng)建需要留下一些調(diào)試的時(shí)刻，尤其是在軟件開發(fā)初期，不同開發(fā)人員的代碼整合在一起出現(xiàn)問題的可能性極大。隨著對(duì)這項(xiàng)實(shí)踐的熟悉程度，問題會(huì)逐漸減少。日創(chuàng)建能夠?qū)ｉT明顯的提高產(chǎn)品質(zhì)量，以及提升團(tuán)隊(duì)的士氣。盡管日創(chuàng)建活動(dòng)需要付出額外的一些成本，然而相關(guān)于集成測(cè)試的不可控，這些成本依舊值得的。 6、小結(jié)投資于框架能夠保證軟件開發(fā)的成功。 應(yīng)用有效的實(shí)踐活動(dòng)來完善框架。 將需求映射到核心框架上來。 使用原型法。 注意測(cè)試活動(dòng)。 假如可能，使用日創(chuàng)建，并進(jìn)行冒煙測(cè)試。 規(guī)則不同于指南。規(guī)則是目標(biāo)受眾所必須遵守的

60、，而指南是建議目標(biāo)受眾遵守的。 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 四、一致性的考慮 一致性原則是軟件開發(fā)中重要原則，也是最令人困惑的原則。做到完全的一致性將會(huì)導(dǎo)致高昂的成本，而不一致又會(huì)導(dǎo)致項(xiàng)目出現(xiàn)各種各樣的問題。能夠想到，這又是一個(gè)需要權(quán)衡的問題。1、意圖 軟件過程中的大部分工件都需要保持其相互之間的一致性。但是，工件越多，保持一致性的開銷也就越大。我們需要在一致性和成本之間保持平衡。2、示例 天利軟件公司的項(xiàng)目經(jīng)理正在為開發(fā)過程中出現(xiàn)的大量的