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

1、過程塑造（小型軟件團(tuán)隊(duì)過程改進(jìn)方法）一、從方法到編碼這是一篇偏重于介紹方法學(xué)（特別是Agile方法）實(shí)踐的文章。其讀者對象是那些希望在自己的軟件團(tuán)體中引入某個過程方法，但又不知從何入手的開發(fā)人員、項(xiàng)目經(jīng)理們。本文中所提到的內(nèi)容更適合于應(yīng)用在小型的軟件團(tuán)隊(duì)中。對于較大規(guī)模的軟件團(tuán)隊(duì)，本文中的部分內(nèi)容也適用。 本系列包括： HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知識接力、 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 短期利益和長期利益的權(quán)衡。軟件管理和軟件開發(fā)是截然區(qū)分的嗎？ 對于項(xiàng)目經(jīng)理來說，其職責(zé)是軟件項(xiàng)目的管理，而對于架構(gòu)師、編碼人員來說，其職責(zé)是軟件設(shè)計(jì)和開發(fā)。雖然在一些小型的團(tuán)隊(duì)中，這兩種職責(zé)有時候是同一個人擔(dān)任的，但兩種角色的區(qū)分是必要的。從事過軟件開發(fā)的人都能或多或少的感受到軟件管理和軟件開發(fā)之間客觀存在的溝壑。 我常常聽聽到來自自兩個方方面的聲聲音。一一邊抱怨怨說設(shè)計(jì)計(jì)師、編編程人員員陽奉陰陰違，難難以管束束，導(dǎo)致致已訂立立的軟件件過程形形同虛設(shè)設(shè)。另一一邊抱怨怨軟件過過程存在在

4、諸多不不恰當(dāng)?shù)牡牡胤?，變成了了軟件開開發(fā)的絆絆腳石。 現(xiàn)代的方方法學(xué)理理論以及及相應(yīng)的的過程實(shí)實(shí)踐為我我們奠定定了軟件件開發(fā)科科學(xué)管理理的基礎(chǔ)礎(chǔ)，個中中的翹楚楚包括RRUP和和XP，縱觀這這些方法法、過程程，都非非常強(qiáng)調(diào)調(diào)過程的的流暢、生命周周期的延延續(xù)。而而在實(shí)際際的應(yīng)用用中，我我們卻常常常能夠夠看見對對它們的的不恰當(dāng)當(dāng)?shù)睦斫饨?，不正正確的使使用。尤尤其是那那些希望望在自己己的軟件件團(tuán)體中中引入新新型的方方法過程程新手們們。對于于他們來來說，最最容易犯犯的一個個錯誤就就是忽視視了如何何利用一一個軟件件過程來來創(chuàng)造一一個成功功的軟件件。關(guān)于如何何建立一一個軟件件過程的的資料很很多，但但是這些些

5、資料并并沒有把把為什么么需要過過程，過過程的目目的是什什么之類類的問題題說清楚楚。而這這些資料料的讀者者們，往往往需要要花費(fèi)大大量的時時間，親親自進(jìn)行行實(shí)踐之之后，才才能獲得得這些問問題的答答案，而而付出的的代價(jià)是是教訓(xùn)和和挫折。同樣的的，我和和我的伙伙伴們也也經(jīng)歷了了這樣一一個過程程。因此此，我希希望把我我在過程程應(yīng)用、過程改改造中涉涉及到的的問題例例舉出來來（采用用過程模模式的方方式）。如果大大家能夠夠利用到到這些經(jīng)經(jīng)驗(yàn)（哪哪怕是一一些），那本文文的目的的也就達(dá)達(dá)到了。因此，本文并并不是一一篇專門門討論如如何建立立過程的的文章，也沒有有涉及建建模、設(shè)設(shè)計(jì)、編編碼等方方面的內(nèi)內(nèi)容。但但是本文

6、文中所討討論的內(nèi)內(nèi)容都可可以對以以上的活活動起到到部分的的指導(dǎo)作作用。敏捷？敏敏捷！從開始研研究軟件件工程，我就對對敏捷過過程的概概念情有有獨(dú)衷，但是隨隨著學(xué)習(xí)習(xí)的深入入（所犯犯錯誤的的增多），我發(fā)發(fā)現(xiàn)敏捷捷是無處處不在的的，她是是一種尺尺度，一一種處于于混亂亂和死板之間的的平衡藝藝術(shù)。有有句俏皮皮話說的的是一一放就亂亂，一管管就死，這句句話很好好的點(diǎn)出出了軟件件過程的的一種無無奈性。如果沒沒有嚴(yán)格格的規(guī)定定，軟件件開發(fā)就就陷入一一種混亂亂、無序序的狀態(tài)態(tài)，但是是如果制制定了過過于嚴(yán)格格的規(guī)定定，軟件件人員的的思路又又受到極極大的約約束，管管理成本本也隨之之上升。敏捷正正是一種種處于兩兩個極端

7、端之間微微妙平衡衡的藝術(shù)術(shù)。這種種藝術(shù)難難以完全全表述，但是可可以通過過一些指指導(dǎo)，來來幫助大大家達(dá)到到這種境境界。因此，我我們可以以推想的的到，敏敏捷是見見仁見智智的。每每一個軟軟件團(tuán)體體都有自自身的特特性，其其敏捷過過程必然然都不盡盡相同。如何設(shè)設(shè)計(jì)出成成功的敏敏捷過程程，來保保證軟件件團(tuán)體的的成功呢呢？本文文通過一一些過程程模式的的討論，揭開了了問題的的一角。關(guān)于過過程設(shè)計(jì)計(jì)的完整整的討論論，大家家可以參參考敏捷捷軟件開開發(fā)AAlisstaiir CCockkburrn一一書（該該書近來來將有中中文版面面世），該書詳詳細(xì)的描描述了過過程設(shè)計(jì)計(jì)的來龍龍去脈，以及如如何根據(jù)據(jù)組織的的特點(diǎn)來來

8、選擇適適當(dāng)?shù)倪^過程。因此，雖雖然本文文中并沒沒有特別別提到敏敏捷的字字眼，但但是所討討論的內(nèi)內(nèi)容無不不在敏捷捷思維的的范圍之之內(nèi)。MDA推推動軟件件可重用用框架的的建立我有一個個夢想，希望有有一天能能夠不用用在諸多多的平臺臺之間搖搖來擺去去。雖說說Javva語言言的口號號就是跨跨平臺。但事實(shí)實(shí)上，我我們還是是無法完完全擺脫脫平臺的的束縛。 在UMLL2.00的規(guī)范范中，提提到了一一個MDDA（MModeel DDrivven Arcchittectturee）的概概念。在在眾多的的軟件平平臺中不不知該如如何選擇擇，已經(jīng)經(jīng)演變?yōu)闉楫?dāng)今軟軟件開發(fā)發(fā)的主要要難題。MDAA的存在在目的就就是為了了解決

9、這這個問題題。通過過MDAA技術(shù)，一個UUML的的模型可可以是平平臺無關(guān)關(guān)的，稱稱為PIIM（PPlattforrm-IIndeepenndennt MModeel），也可以以是和特特定平臺臺相關(guān)的的，稱為為PSMM（Pllatfformm-Sppeciificc Moodell）。利利用平臺臺技術(shù)的的軟件商商，可以以專注于于自己的的領(lǐng)域，集中描描述業(yè)務(wù)務(wù)功能，業(yè)務(wù)規(guī)規(guī)則，而而無須考考慮特定定的技術(shù)術(shù)，構(gòu)建建出一個個PIMM，然后后，通過過支持MMDA的的工具，將PIIM轉(zhuǎn)換換（通過過不同PProffilee進(jìn)行映映射）為為一個或或多個PPSM。這時候候的模型型仍然是是UMLL的。但但是，這這

10、個轉(zhuǎn)換換過程雖雖然有工工具的輔輔助，但但仍然需需要外力力的介入入。接下下來，開開發(fā)工具具將會從從PSMM中產(chǎn)生生可執(zhí)行行代碼。這就是是MDAA的思路路，它把把以往以以程序?yàn)闉橹行牡牡拈_發(fā)模模式轉(zhuǎn)變變?yōu)橐栽O(shè)設(shè)計(jì)為中中心的開開發(fā)模式式。 以往的重重用，往往往是基基于代碼碼的，例例如算法法的重用用、界面面組件的的重用，卻往往往沒有將將重用提提升到設(shè)設(shè)計(jì)的層層次上。MDAA為我們們建立可可重用的的框架提提供了一一個很好好的指導(dǎo)導(dǎo)。注意意上面的的這副圖圖，最外外面的兩兩層就表表達(dá)了MMDA可可以用于于設(shè)計(jì)重重用的基基本理念念。倒數(shù)數(shù)第二層層的含義義是利用用MDAA來進(jìn)行行通用軟軟件（例例如事務(wù)務(wù)、目錄錄

11、服務(wù)）的模型型設(shè)計(jì)，倒數(shù)第第一層則則表示MMDA可可以用于于特定業(yè)業(yè)務(wù)領(lǐng)域域的設(shè)計(jì)計(jì)建模。可以想想象，今今后軟件件公司中中的最有有價(jià)值的的資產(chǎn)，就是這這些設(shè)計(jì)計(jì)模型。 本文并不不打算詳詳細(xì)討論論MDAA，除了了簡單的的介紹MMDA的的思路之之外，更更重要的的一點(diǎn)是是企業(yè)可可重用框框架的建建立。軟軟件企業(yè)業(yè)的核心心在于知知識，如如何有效效的將人人腦中的的知識存存儲起來來，并不不斷的使使用和發(fā)發(fā)展，是是軟件企企業(yè)成功功的關(guān)鍵鍵。本文文提到的的可重用用框架，指的就就是將軟軟件開發(fā)發(fā)相關(guān)知知識存儲儲起來的的框架。這個思思路是本本文的一一個核心心思路。在本文文看來，可重用用框架不不但包括括了設(shè)計(jì)計(jì)模型，

12、還包括括了過程程和方法法。軟件件開發(fā)是是在這個個框架之之內(nèi)運(yùn)作作的，同同時反過過來影響響著框架架的完善善和改進(jìn)進(jìn)。 過程塑造造模式語語言下述的模模式都是是從軟件件開發(fā)過過程中，圍繞著著可重用用框架的的建立整整理出來來的一些些經(jīng)驗(yàn)，之所以以整理為為模式的的形式，是因?yàn)闉檫@種方方式有利利于類似似情況的的鑒別和和對其進(jìn)進(jìn)行必要要的擴(kuò)展展。在軟軟件開發(fā)發(fā)中會遇遇到各種種各樣的的問題，以上模模式中討討論到的的問題都都是我們們在實(shí)踐踐中，或或是和其其他開發(fā)發(fā)團(tuán)隊(duì)溝溝通中反反復(fù)遇到到的。因因此堅(jiān)定定了我們們將之整整理為模模式的信信心。目目前我們們得到的的模式并并不多，但是隨隨著經(jīng)驗(yàn)驗(yàn)的增加加，我們們會得到到

13、更多的的積累。 本文介紹紹的模式式都比較較注重權(quán)權(quán)衡的藝藝術(shù)。我我們認(rèn)為為這是敏敏捷思維維的必然然結(jié)果。世界上上并沒有有什么絕絕對的事事情，尤尤其是目目前多變變的社會會中，昨昨天的標(biāo)標(biāo)準(zhǔn)并不不適合于于今天的的環(huán)境。因此，我們的的平衡點(diǎn)點(diǎn)也在不不斷的變變化。傳統(tǒng)、經(jīng)經(jīng)典、學(xué)學(xué)術(shù)的瀑瀑布模型型為我們們建立了了軟件開開發(fā)的基基本過程程，雖然然有各種種新的生生命周期期模型的的提出，但是基基本的過過程并沒沒有太大大的變化化。例如如，增強(qiáng)強(qiáng)性的瀑瀑布過程程是在瀑瀑布模型型的基礎(chǔ)礎(chǔ)上增加加了回溯溯到上一一個階段段的能力力；迭代代式過程程的每一一次迭代代都是一一次微小小的瀑布布生命周周期。在在這個生生命周期期

14、模型中中，信息息在初始始需求收收集階段段生成，并通過過分析、設(shè)計(jì)、編碼、部署等等階段轉(zhuǎn)轉(zhuǎn)化為用用戶最終終需要的的軟件。在這樣樣一個延延續(xù)性極極強(qiáng)的周周期中，我們?nèi)缛绾伪ＷC證信息能能夠得到到正確的的傳遞呢呢？我們們用什么么方法來來避免信信息傳遞遞的失真真呢？我我們?nèi)绾魏卧谶@樣樣一個過過程中處處理人與與人之間間的交互互呢？在在正確傳傳遞信息息的情況況下，我我們又如如何保證證投入的的最小化化呢？這這些問題題正是 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知識接

15、接力模式式所重點(diǎn)點(diǎn)關(guān)注的的。 我不只一一次的見見過為過過程而關(guān)關(guān)注過程程的情況況。產(chǎn)生生這種結(jié)結(jié)果的一一種原因因是“過程麻麻痹癥”。過程程一旦定定型，就就不再改改變，即即便當(dāng)初初制定過過程的環(huán)環(huán)境已經(jīng)經(jīng)發(fā)生了了變化也也是如此此。過程程的制定定一定是是針對特特定的目目標(biāo)的，這個目目標(biāo)就是是開發(fā)出出成功的的軟件，如果不不能夠服服務(wù)于這這個目標(biāo)標(biāo)，遵循循過程又又有什么么意義呢呢？另一一種原因因是過程程被分割割為彼此此獨(dú)立的的片斷，每個開開發(fā)人員員只關(guān)注注自己的的職責(zé)，而忽略略了最終終的軟件件。過程程的 HYPERLINK /developerworks/cn/linux/software_engin

16、eering/Methodology/method2code/index3.html 代代碼是最最終目的的，開發(fā)發(fā)過程中中的所有有活動都都圍繞著著這一目目的而展展開。如如果沒有有最后的的用于交交付的代代碼，軟軟件就無無法成為為軟件。因此，必須保保證過程程能夠產(chǎn)產(chǎn)出代碼碼，而且且是優(yōu)秀秀的代碼碼。 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一致性原原則是軟軟件開發(fā)發(fā)中重要要原則，也是最最令人困困惑的原原則。做做到完全全的一致致性將會會導(dǎo)致高高昂的成成本，而

17、而不一致致又會導(dǎo)導(dǎo)致項(xiàng)目目出現(xiàn)各各種各樣樣的問題題?？梢砸韵氲剑@又是是一個需需要權(quán)衡衡的問題題。軟件件項(xiàng)目中中的一致致性大致致可以分分為兩種種，一種種是不同同工件之之間的一一致性（例如設(shè)設(shè)計(jì)模型型中的類類名稱和和實(shí)際代代碼中的的類名稱稱的一致致性），一種是是工件和和軟件過過程的一一致性（類名稱稱需要滿滿足命名名標(biāo)準(zhǔn)）。我們們?nèi)绾慰伎紤]這兩兩種情況況下的一一致性呢呢？ 人們說管管理既是是科學(xué)也也是藝術(shù)術(shù)，這句句話用來來形容軟軟件工程程再適合合不過了了。如果果說這里里有什么么不夠恰恰當(dāng)?shù)牡氐胤降脑捲?，我倒倒覺得是是軟件件工程的這個個提法有有些許的的欠妥。軟件工工程的思思路源自自于人們們渴望軟軟件

18、開發(fā)發(fā)能夠像像土木工工程那樣樣成熟。但是幾幾十年的的經(jīng)驗(yàn)下下來，大大家可以以肯定，軟件開開發(fā)和土土木工程程有著太太多的不不同：開開發(fā)人員員和建筑筑工人也也有著截截然不同同的差異異，知識識的組裝裝和鋼筋筋混凝土土更是天天差萬別別。（但但為了保保證延續(xù)續(xù)性，我我們在本本文中仍仍然延續(xù)續(xù)軟件工工程的提提法。）因此，軟件工工程需要要在科學(xué)學(xué)和藝術(shù)術(shù)之間求求得權(quán)衡衡，科學(xué)學(xué)的一面面包括了了軟件開開發(fā)規(guī)范范、準(zhǔn)則則、實(shí)踐踐、過程程、方法法；而藝藝術(shù)的一一面則囊囊括了人人員的激激勵、協(xié)協(xié)調(diào)，組組織的設(shè)設(shè)計(jì)等因因素。因因此我們們需要審審視我們們的規(guī)則則、過程程、方法法，它們們是否能能夠發(fā)揮揮出人的的創(chuàng)新性性？

19、或是是它是否否足以約約束人的的行為？這就是是 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index5.html 活躍躍和混亂亂、嚴(yán)謹(jǐn)謹(jǐn)和死板板模式所所要告訴訴我們的的。 應(yīng)該說，本文中中所討論論的模式式更適合合于使用用面向?qū)ο蠹夹g(shù)術(shù)的開發(fā)發(fā)團(tuán)隊(duì)。尤其是是 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index6.html 短期期利益和和長期利利益的權(quán)權(quán)衡模式式。

20、和大大多數(shù)人人一樣，我們最最早也是是過程式式編程陣陣營的一一員。在在經(jīng)過長長時間的的學(xué)習(xí)和和不斷的的犯錯之之后，我我們終于于轉(zhuǎn)向了了面向?qū)ο?。面面向?qū)ο笙笞畲蟮牡暮锰幇艘砸韵聨讉€個方面： 將實(shí)現(xiàn)和和接口分分離，即即把如何何做隱藏藏起來，而把做做什么展展示給客客戶。繼承和多多態(tài)使得得我們能能夠在一一個抽象象的層次次上（基基類和接接口）思思考問題題，并能能夠根據(jù)據(jù)現(xiàn)實(shí)的的需求進(jìn)進(jìn)行靈活活的調(diào)整整（子類類和實(shí)現(xiàn)現(xiàn)）。通過設(shè)計(jì)計(jì)模式和和設(shè)計(jì)技技巧的應(yīng)應(yīng)用，可可以有效效的降低低系統(tǒng)的的不同部部分之間間的耦合合度。尤尤其是簡簡化客戶戶端的代代碼。在使用和和比較過過幾種開開發(fā)語言言和開發(fā)發(fā)環(huán)境之之后

21、，我我們發(fā)現(xiàn)現(xiàn)，其實(shí)實(shí)最關(guān)鍵鍵的并不不是使用用什么樣樣的面向向?qū)ο笳Z語言（或或環(huán)境），關(guān)鍵鍵的是你你運(yùn)用面面向?qū)ο笙笏季S的的能力，或者說說對現(xiàn)實(shí)實(shí)世界的的理解、抽象、映射的的能力。這種能能力決定定了你的的開發(fā)水水平的高高低，而而語言和和環(huán)境只只是一種種重要的的實(shí)現(xiàn)手手段和工工具而已已。而這這種思維維能力，雖然可可以通過過例子和和討論來來進(jìn)行介介紹，但但更關(guān)鍵鍵的還是是在實(shí)踐踐中進(jìn)行行練習(xí)。在本文文討論的的模式中中，我們們會夾帶帶的對這這些內(nèi)容容進(jìn)行討討論。因因?yàn)槲覀儌冋J(rèn)為，開發(fā)思思想和開開發(fā)過程程是無法法區(qū)分的的，否則則，你的的開發(fā)過過程就沒沒有靈魂魂。這也也是我們們的主題題所要強(qiáng)強(qiáng)調(diào)的：從方

22、法法到編碼碼，鑄造造起一個個敏捷的的、流暢暢的過程程，才能能夠保證證開發(fā)過過程的成成功，開開發(fā)軟件件的成功功。 此外，本本篇是總總論性文文章，在在撰寫此此文時，該篇其其實(shí)是最最后完工工的，因因此，建建議大家家在看過過全文之之后，如如果還有有耐心，可以重重看此篇篇，相信信會有另另外一番番收獲。 現(xiàn)在請大大家進(jìn)入入我們的的模式之之旅。 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 二、知識識接力在軟件過過程中，我們?nèi)缛绾伪ＷC證信息能能夠得到到正確的的傳遞呢呢？我

23、們們用什么么方法來來避免信信息傳遞遞的失真真呢？我我們?nèi)绾魏卧谶@樣樣一個過過程中處處理人與與人之間間的交互互呢？在在正確傳傳遞信息息的情況況下，我我們又如如何保證證投入的的最小化化呢？意圖軟件開發(fā)發(fā)過程是是知識傳傳遞、知知識轉(zhuǎn)換換的過程程。注重重知識轉(zhuǎn)轉(zhuǎn)換中的的完整性性，保證證知識經(jīng)經(jīng)過各個個階段和和活動，順利的的轉(zhuǎn)換為為軟件是是極為重重要的。2、示例例元朗公司司是國內(nèi)內(nèi)某銀行行的下屬屬企業(yè)。從年初初開始，公司就就投入了了大量的的人力為為銀行開開發(fā)新版版本的國國際收支支系統(tǒng)?？紤]到到這是一一個非常常龐大的的系統(tǒng)，因此公公司把原原先的軟軟件開發(fā)發(fā)團(tuán)隊(duì)擴(kuò)擴(kuò)大了一一倍，補(bǔ)補(bǔ)充的人人員有些些來自于于其

24、它的的項(xiàng)目組組，有些些人員來來自別的的公司。為了保保證開發(fā)發(fā)的順利利進(jìn)行，項(xiàng)目經(jīng)經(jīng)理引入入了軟件件過程。但是從從一開始始，麻煩煩的事情情就出現(xiàn)現(xiàn)了。項(xiàng)項(xiàng)目組中中的技術(shù)術(shù)人員和和銀行的的領(lǐng)域?qū)＜抑g間不斷出出現(xiàn)意見見相左的的情況。主要的的問題是是后加入入的員工工對目標(biāo)標(biāo)領(lǐng)域不不熟悉，難以配配合領(lǐng)域域?qū)＜业牡墓ぷ?。最糟糕糕的是，某些領(lǐng)領(lǐng)域?qū)＜壹疑硖幃惍惖?，因因此在需需求分析析的中期期，開發(fā)發(fā)團(tuán)隊(duì)邀邀請這些些異地的的領(lǐng)域?qū)＜襾淼降介_發(fā)所所在地，進(jìn)行了了為期兩兩天的討討論會。結(jié)果并并不理想想，討論論會上充充滿了對對原先已已定稿的的需求的的反對性性意見，技術(shù)專專家、領(lǐng)領(lǐng)域?qū)＜壹页吵梢灰粓F(tuán)。需需求分析

25、析階段不不得不在在原先的的基礎(chǔ)上上延長了了50%的時間間。在進(jìn)進(jìn)入設(shè)計(jì)計(jì)和編碼碼階段之之后，問問題少了了許多。但在設(shè)設(shè)計(jì)到編編碼的過過程中仍仍是出了了一些麻麻煩，原原因是新新加入的的人員不不熟悉開開發(fā)團(tuán)隊(duì)隊(duì)的設(shè)計(jì)計(jì)風(fēng)格。經(jīng)過一一番周折折，問題題基本解解決了?？傻鹊降巾?xiàng)目進(jìn)進(jìn)入到測測試階段段，矛盾盾一下子子就凸現(xiàn)現(xiàn)出來了了。測試試報(bào)告指指出，軟軟件中存存在著大大量的問問題，大大部分的的問題都都被定性性為無法法滿足需需求的嚴(yán)嚴(yán)重錯誤誤。經(jīng)過過對錯誤誤的復(fù)審審，排除除了其中中17%的嚴(yán)重重錯誤。經(jīng)過分分析，發(fā)發(fā)現(xiàn)其中中70%的錯誤誤都是發(fā)發(fā)生在后后加入人人員負(fù)責(zé)責(zé)的模塊塊中。而而產(chǎn)生大大量錯誤誤的一

26、個個主要原原因是在在編碼階階段，由由于銀行行啟用了了新的會會計(jì)制度度，導(dǎo)致致大量模模塊被修修改，由由于時間間緊迫，因此沒沒有進(jìn)行行正規(guī)的的需求調(diào)調(diào)研?，F(xiàn)現(xiàn)在看來來，領(lǐng)域域?qū)＜液秃图夹g(shù)專專家對同同一個問問題的理理解并不不相同。最后，項(xiàng)目的的開發(fā)周周期延長長了400%。分析軟件過程程每經(jīng)歷歷一個階階段，就就會發(fā)生生一次知知識轉(zhuǎn)換換的情況況。這種種轉(zhuǎn)換是是由人來來完成的的，這就就是像是是接力一一樣，一一個人把把腦中的的知識以以某種方方式傳遞遞給另一一個人，再有另另一個人人傳遞下下去，直直至編碼碼人員把把這些知知識固化化在最終終的軟件件中。在在軟件成成型之前前，知識識的主要要載體是是文檔和和模型。我們

27、稱稱它們?yōu)闉楣ぜˋrttifaact）。例如如，需求求階段時時，領(lǐng)域域?qū)＜以谠诩夹g(shù)專專家的幫幫助下，將自己己腦中對對領(lǐng)域的的認(rèn)識傳傳遞給技技術(shù)人員員，并最最終形成成需求規(guī)規(guī)格書或或是用例例模型。而在分分析設(shè)計(jì)計(jì)階段，技術(shù)專專家借助助需求規(guī)規(guī)格書，把腦中中對軟件件的初始始認(rèn)識進(jìn)進(jìn)一步轉(zhuǎn)轉(zhuǎn)換為分分析模型型、設(shè)計(jì)計(jì)模型、數(shù)據(jù)模模型等工工件。最最后，在在編碼階階段，編編碼人員員把這些些工件中中隱藏的的知識轉(zhuǎn)轉(zhuǎn)化為軟軟件的形形式。經(jīng)經(jīng)過測試試和部署署，軟件件將會交交付到用用戶手中中。這是是非常典典型的軟軟件開發(fā)發(fā)過程，再簡單單的軟件件開發(fā)也也需要經(jīng)經(jīng)歷上述述的這些些階段。可以看到到，在上上述的軟軟件開

28、發(fā)發(fā)過程中中，知識識形式發(fā)發(fā)生了兩兩次的重重要轉(zhuǎn)換換，知識識所屬角角色也改改變了兩兩次。知知識完成成第一次次的形式式轉(zhuǎn)換之之后，將將成為需需求規(guī)格格書（或或同類工工件）的的形式，知識從從領(lǐng)域?qū)＜业哪X腦中轉(zhuǎn)換換到技術(shù)術(shù)專家的的腦中。然后，知識開開始了第第二次的的形式轉(zhuǎn)轉(zhuǎn)換，形形成設(shè)計(jì)計(jì)模型（以及同同類工件件）。隨隨著知識識從技術(shù)術(shù)專家轉(zhuǎn)轉(zhuǎn)移到編編碼人員員，知識識轉(zhuǎn)換為為其最終終的軟件件形式。在這些些轉(zhuǎn)換的的過程中中，最容容易出現(xiàn)現(xiàn)信息遺遺漏、信信息失真真的情況況。保證證轉(zhuǎn)換過過程中知知識的完完整性和和正確性性，對軟軟件開發(fā)發(fā)具有重重要的意意義。4、問題題如果保保證轉(zhuǎn)換換時知識識的完整整性和正正

29、確性？5、方法法知識轉(zhuǎn)換換的主體體是人，因此我我們主要要的對策策也是針針對人來來展開的的。我們們知道，軟件過過程的特特點(diǎn)就是是：越早早埋下禍禍根對項(xiàng)項(xiàng)目的殺殺傷力越越大。所所以我們們首先需需要重點(diǎn)點(diǎn)防范的的對象應(yīng)應(yīng)該是在在初始需需求分析析階段。需求分分析階段段涉及的的知識非非常的多多，大家家如果有有興趣可可以參看看我的文文章需需求的實(shí)實(shí)踐。但但這里我我們重點(diǎn)點(diǎn)的任務(wù)務(wù)是找出出需求分分析階段段中發(fā)生生知識轉(zhuǎn)轉(zhuǎn)移的關(guān)關(guān)鍵點(diǎn)。領(lǐng)域?qū)＜壹液图夹g(shù)術(shù)專家是是需求階階段中最最重要的的兩種人人，不論論你的項(xiàng)項(xiàng)目和團(tuán)團(tuán)隊(duì)規(guī)模模屬于哪哪一種層層次，一一定都包包含這兩兩種角色色。如果果你的團(tuán)團(tuán)隊(duì)中領(lǐng)領(lǐng)域?qū)＜壹液图夹g(shù)

30、術(shù)專家是是同一種種人，那那么恭喜喜你，你你可以不不用閱讀讀這一段段的內(nèi)容容了?？煽上г趶?qiáng)強(qiáng)調(diào)分工工協(xié)作和和軟件規(guī)規(guī)模不斷斷擴(kuò)大的的今天，這種人人已經(jīng)非非常難找找了。領(lǐng)領(lǐng)域?qū)＜壹沂侵R識的最初初持有者者，其職職責(zé)是為為項(xiàng)目提提供準(zhǔn)確確的、完完整的需需求信息息。技術(shù)術(shù)專家的的職責(zé)則則是幫助助領(lǐng)域?qū)＜彝瓿沙蛇@一項(xiàng)項(xiàng)工作。所以，首先請請保證領(lǐng)領(lǐng)域?qū)＜壹液图夹g(shù)術(shù)專家是是能夠溝溝通的，示例中中的項(xiàng)目目的第一一個問題題就是團(tuán)團(tuán)隊(duì)的新新成員和和領(lǐng)域?qū)＜抑g間存在溝溝通壁壘壘。在我我們的經(jīng)經(jīng)驗(yàn)中，就發(fā)生生過一位位優(yōu)秀的的技術(shù)人人員和一一位資深深的領(lǐng)域域?qū)＜覡帬幊车氖率虑?。剖剖析原因因之后，我們發(fā)發(fā)現(xiàn)，最最主

31、要的的原因是是他們兩兩個人都都太優(yōu)秀秀了，技技術(shù)人員員有一定定的領(lǐng)域域經(jīng)驗(yàn)，領(lǐng)域?qū)＜矣幸灰欢ǖ拈_開發(fā)經(jīng)驗(yàn)驗(yàn)，這導(dǎo)導(dǎo)致了雙雙方在討討論中的的強(qiáng)硬立立場。因因此，如如果遇到到類似的的情況，請對你你的組織織進(jìn)行崗崗位調(diào)整整。但在在執(zhí)行這這項(xiàng)工作作之前，請小心心你的說說辭，不不要傷害害到任何何一個人人。我我們的某某個小組組有麻煩煩，那邊邊非常需需要你的的經(jīng)驗(yàn)和和能力會是一一句不錯錯的說辭辭。其次次，技術(shù)術(shù)專家不不應(yīng)該提提出任何何可能影影響領(lǐng)域域?qū)＜业牡膯栴}。只有領(lǐng)領(lǐng)域?qū)＜壹也拍軌驂蛱岢鲂栊枨?，技技術(shù)專家家起到的的只是輔輔助作用用。因此此請杜絕絕這種情情況。再再次，如如果你的的領(lǐng)域?qū)＜也恢恢灰粋€人人

32、，那么么你需要要考慮領(lǐng)領(lǐng)域?qū)＜壹抑g可可能出現(xiàn)現(xiàn)的不一一致。為為領(lǐng)域團(tuán)團(tuán)隊(duì)指定定一位領(lǐng)領(lǐng)導(dǎo)者是是一種不不錯的做做法。在在我們的的一個項(xiàng)項(xiàng)目中，就曾邀邀請對方方公司的的財(cái)務(wù)總總監(jiān)擔(dān)任任這一角角色。理理由有二二：1、財(cái)務(wù)總總監(jiān)具有有權(quán)威性性；2、財(cái)務(wù)總總監(jiān)了解解公司的的全部運(yùn)運(yùn)作。此此外，如如果領(lǐng)域域?qū)＜曳址植荚诓徊煌攸c(diǎn)點(diǎn)的話，你需要要在該階階段的某某個時期期，安排排需求討討論會，并考慮慮一種能能夠溝通通的方式式，以便便隨時能能夠了解解身處異異地的領(lǐng)領(lǐng)域?qū)＜壹业囊庖娨?。這種種情況對對于那些些擁有分分公司的的公司（例如銀銀行、證證券、保保險(xiǎn)、銷銷售公司司等等）而言非非常的普普遍。因因此，我我們在需

33、需求分析析階段，首先要要處理好好領(lǐng)域?qū)＜液图技夹g(shù)專家家之間的的關(guān)系。應(yīng)該說說，這里里提到的的內(nèi)容不不僅僅適適用于需需求階段段，在整整個的開開發(fā)過程程中都有有用處。需求不是是實(shí)現(xiàn)。需求表表示的是是有什么么（Whhat），并不不關(guān)心如如何做（Howw）。如如果在需需求分析析階段把把精力分分散到了了如何實(shí)實(shí)現(xiàn)需求求上，那那么需求求分析的的效果就就會受到到影響。這體現(xiàn)現(xiàn)在需求求的完整整性和正正確性兩兩個方面面。領(lǐng)域域?qū)＜液秃图夹g(shù)專專家都可可能犯類類似的錯錯誤。領(lǐng)領(lǐng)域?qū)＜壹彝恢荒軌蜥樶槍ψ约杭旱墓ぷ髯鱽砻枋鍪鲂枨螅麜苋菀滓椎陌炎宰约簩τ谟谛枨髮?shí)實(shí)現(xiàn)看法法參雜到到需求描描述中。從項(xiàng)目目的整體

34、體范圍來來看，這這種需求求描述有有時候是是有問題題的。如如果你開開發(fā)的是是一個定定制應(yīng)用用，那問問題還不不大，如如果你開開發(fā)的是是一個產(chǎn)產(chǎn)品，那那么問題題就很嚴(yán)嚴(yán)重了。領(lǐng)域?qū)＜颐枋鍪龅男枨笄笠欢ㄊ鞘悄阈枰膬?nèi)容容嗎？例例如，你你打算開開發(fā)一個個配送的的管理應(yīng)應(yīng)用，但但是領(lǐng)域域?qū)＜野寻汛罅康牡木ɑㄔ诹怂谠认鹊墓舅局腥绾魏螌?shí)現(xiàn)配配送的流流程上，這個過過程可能能適合于于他的公公司，但但是對于于產(chǎn)品而而言，可可能就不不合適，因?yàn)椴⒉⒎撬杏械呐渌退凸径级际褂眠@這種流程程的。好好吧，你你想要的的內(nèi)容和和你不想想要的內(nèi)內(nèi)容混合合在一起起，這使使得你不不得不花花費(fèi)精力力對需求求進(jìn)行進(jìn)進(jìn)一步

35、的的整理。因此，好的做做法是，一開始始就明確確領(lǐng)域?qū)＜覒?yīng)該該提供什什么，而而且，盡盡可能的的提供需需求，而而不是需需求實(shí)現(xiàn)現(xiàn)。多問問一些諸諸如如如果環(huán)境境發(fā)生變變化，你你該如何何做之之類的問問題，否否則你會會發(fā)現(xiàn)，用戶的的需求變變化將會會對你的的軟件造造成很大大的影響響。再說說技術(shù)專專家，技技術(shù)專家家常常犯犯的毛病病是把分分析參雜雜到需求求調(diào)研中中來，從從需求描描述中精精練出一一些業(yè)務(wù)務(wù)實(shí)體（或進(jìn)行行CRCC討論）是可以以的，但但是過早早的考慮慮實(shí)現(xiàn)方方式將會會限制你你的思維維。因此此，請確確保需求求只是需需求，這這樣才能能夠盡可可能保證證需求的的完整性性和正確確性。需求復(fù)審審是非常常重要的

36、的檢查點(diǎn)點(diǎn)。請確確保你正正確的使使用它。需求復(fù)復(fù)審需要要領(lǐng)域?qū)＜液图技夹g(shù)專家家、以及及管理者者的參與與。需求求復(fù)審是是保證需需求完整整性和正正確性的的最后一一道防線線。在很很多的文文章（包包括我的的需求的的實(shí)踐一一文）、過程都都對需求求復(fù)審進(jìn)進(jìn)行了論論述，我我們這里里就不贅贅述了。在實(shí)踐踐過程中中，我們們發(fā)現(xiàn)，需求復(fù)復(fù)審還有有一個好好的方式式，為了了能夠通通過需求求復(fù)審，需求分分析人員員（包括括領(lǐng)域?qū)＜液图技夹g(shù)專家家）會非非常努力力的找出出需求中中的問題題。所以以，在你你的過程程中加入入這個檢檢查點(diǎn)是是非常有有必要的的。好的，如如果這一一切都進(jìn)進(jìn)行順利利的話，最后的的需求規(guī)規(guī)格書應(yīng)應(yīng)該是比

37、比較完美美的，而而技術(shù)專專家也已已經(jīng)從領(lǐng)領(lǐng)域?qū)＜壹夷抢锪肆私獾搅肆俗銐虻牡男畔?，可以開開始下一一階段的的開發(fā)了了。這里里，我們們再花一一些筆墨墨來討論論迭代過過程中，我們?nèi)缛绾翁幚砝硇枨蟆?shí)踐中中，我們們認(rèn)為迭迭代次數(shù)數(shù)并不是是越多越越好，應(yīng)應(yīng)該根據(jù)據(jù)項(xiàng)目規(guī)規(guī)模和團(tuán)團(tuán)隊(duì)特點(diǎn)點(diǎn)進(jìn)行區(qū)區(qū)分，每每一次的的迭代都都可能有有自己的的目標(biāo)。例如首首次迭代代的周期期可能比比較短，其主要要的目標(biāo)標(biāo)定為提提供軟件件原型、驗(yàn)證主主要設(shè)計(jì)計(jì)思路等等。第二二次的迭迭代的周周期可以以長一些些，目標(biāo)標(biāo)可以定定位為實(shí)實(shí)現(xiàn)主要要功能。如果軟軟件規(guī)模模比較大大，也可可以為每每次迭代代設(shè)定需需求范圍圍（或主主要場景景），這這樣就

38、能能夠防止止需求擴(kuò)擴(kuò)散的情情況。這這已經(jīng)超超出了本本文的范范圍，因因此我們們這里只只是簡單單的提一一下。分析階段段是發(fā)生生職責(zé)轉(zhuǎn)轉(zhuǎn)換的重重要階段段。該階階段的成成敗對軟軟件開發(fā)發(fā)至關(guān)重重要。對對于面向向?qū)ο箝_開發(fā)而言言，這個個過程最最主要的的任務(wù)是是對領(lǐng)域域進(jìn)行建建模。比比較好的的方式是是使用UUML來來描述領(lǐng)領(lǐng)域知識識，例如如，我比比較經(jīng)常常使用類類圖來建建立分析析模型，使用順順序圖來來描述動動態(tài)流程程。請確確保技術(shù)術(shù)團(tuán)隊(duì)中中最出色色的分析析建模人人員參與與這個初初始分析析建模的的過程。他的職職責(zé)包括括指導(dǎo)建建模和對對模型進(jìn)進(jìn)行審查查。如果果在一個個迭代過過程中，這個模模型是不不斷演進(jìn)進(jìn)的，

39、這這可以減減少一些些風(fēng)險(xiǎn)。在這個個過程中中，建模模人員可可以吸收收領(lǐng)域知知識，這這對于后后續(xù)階段段中指導(dǎo)導(dǎo)其他開開發(fā)人員員是很重重要的，對公司司的長遠(yuǎn)遠(yuǎn)目標(biāo)也也具有重重要意義義（參見見 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index6.html 短期期利益和和長期利利益的權(quán)權(quán)衡模式式）。如如果建模模人員缺缺少面向向?qū)ο箝_開發(fā)的經(jīng)經(jīng)驗(yàn)，他他會很容容易把對對象變成成一個數(shù)數(shù)據(jù)容器器。這種種方式并并不是不不好，但但它把數(shù)數(shù)據(jù)和行行為區(qū)分分開來，無法站站在一個個抽象的的高度上上對

40、領(lǐng)域域進(jìn)行分分析。很難嚴(yán)格格的區(qū)分分分析階階段和設(shè)設(shè)計(jì)階段段，至少少我是這這么覺得得的。他他們的差差別僅僅僅是在分分析的詳詳細(xì)程度度上（有有點(diǎn)類似似于以往往的概要要設(shè)計(jì)和和詳細(xì)設(shè)設(shè)計(jì)）。在實(shí)踐踐中，我我們發(fā)現(xiàn)現(xiàn)，并沒沒有必要要嚴(yán)格的的區(qū)分它它們，但但是你需需要保證證模型已已經(jīng)完整整的描述述了需求求。這里里可以設(shè)設(shè)置檢查查點(diǎn)來驗(yàn)驗(yàn)證，也也可以在在設(shè)計(jì)模模型出來來之后再再進(jìn)行檢檢查，這這取決于于具體的的項(xiàng)目。因此，我們在在分析階階段和設(shè)設(shè)計(jì)階段段結(jié)束之之前需要要進(jìn)行設(shè)設(shè)計(jì)復(fù)審審。從Marrtinn Foowleer提出出分析模模式的概概念之后后（現(xiàn)在在他的第第二本分分析模式式正在寫寫作中），它就就

41、成為分分析建模模的有利利助手之之一對領(lǐng)域域概念進(jìn)進(jìn)行分析析和建模模，并描描述它們們之間的的關(guān)系（我在點(diǎn)點(diǎn)空間上上的一篇篇讀書筆筆記反應(yīng)應(yīng)了需求求和分析析之間的的關(guān)系）。但是是請千萬萬注意，不要誤誤用和濫濫用分析析模式。因?yàn)槿稳魏畏治鑫瞿Ｊ降牡奶岢觯际腔谀硞€個上下文文環(huán)境中中的需求求的，如如果上下下文環(huán)境境不同，那么模模式就需需要改進(jìn)進(jìn)或改造造。因此此，分析析模式是是一個好好的開始始，但需需要你針針對實(shí)際際需求具具體分析析。在應(yīng)應(yīng)用模式式方面，F(xiàn)raank Busschmmannn的Appplyyingg Paatteernss是一篇篇不錯的的參考文文章，其其中文版版發(fā)布在在點(diǎn)空間間上。請

42、按照逐逐步精化化（迭代代）的方方式來完完善、改改進(jìn)你的的分析模模型。優(yōu)優(yōu)秀的設(shè)設(shè)計(jì)一定定不會過過于復(fù)雜雜。如果果你的分分析模型型出現(xiàn)過過于復(fù)雜雜的情況況，到處處充斥著著復(fù)雜的的關(guān)系網(wǎng)網(wǎng)。那么么，你需需要對你你的設(shè)計(jì)計(jì)進(jìn)行結(jié)結(jié)構(gòu)上的的改進(jìn)。例如，采用分分層（參參見 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/part9/index.html 敏敏捷架構(gòu)構(gòu)設(shè)計(jì)一一文中的的分層模模式）、組件技技術(shù)、或或是使用用單向聯(lián)聯(lián)系。堅(jiān)堅(jiān)持這一一過程，你會發(fā)發(fā)現(xiàn)最后后的設(shè)計(jì)計(jì)是簡潔潔的、完完美的。 在設(shè)計(jì)階階段，要要注意

43、的的事項(xiàng)和和分析階階段相差差不多，例如不不要誤用用和濫用用設(shè)計(jì)模模式。但但是有一一點(diǎn)是需需要額外外強(qiáng)調(diào)的的。當(dāng)分分析模型型已經(jīng)能能夠完整整、正確確的描述述需求之之后，我我們就需需要在設(shè)設(shè)計(jì)模型型中添加加設(shè)計(jì)資資料。例例如對包包、組件件、類、方法的的描述。這時候候，需求求的信息息已經(jīng)被被打散到到軟件的的各個部部分中了了。而設(shè)設(shè)計(jì)模型型在被實(shí)實(shí)現(xiàn)時，設(shè)計(jì)模模型中的的信息又又將進(jìn)入入到代碼碼中。因因此，保保持這些些信息的的一致性性就顯得得非常的的關(guān)鍵。而由于于設(shè)計(jì)模模型處在在中間地地帶，它它的重要要性又是是不言而而喻的?；镜牡奶幚硭妓悸贩譃闉閮刹剑涸谛枨笄蟀l(fā)生改改變時，請同步步更改設(shè)設(shè)計(jì)模型型以及

44、設(shè)設(shè)計(jì)模型型中的信信息。再再由設(shè)計(jì)計(jì)模型驅(qū)驅(qū)動代碼碼的修改改。第一一個步驟驟是需要要手動實(shí)實(shí)現(xiàn)的，但是第第二個步步驟可以以由計(jì)算算機(jī)輔助助實(shí)現(xiàn)，即保持持設(shè)計(jì)模模型和代代碼信息息的一致致性（將將在 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index4.html 一一致性的的思考模模式中討討論）。目前有有很多的的建模工工具都可可以做到到這一點(diǎn)點(diǎn)，甚至至能夠?qū)崒?shí)現(xiàn)產(chǎn)生生最終的的APII文檔。善用這這項(xiàng)功能能，它能能令你事事半功倍倍。 在軟件過過程中設(shè)設(shè)立反饋饋活動，可以有有效的減減

45、少項(xiàng)目目的偏差差。就像像我們騎騎自行車車，很少少能夠走走一條直直線，一一般我們們是根據(jù)據(jù)對目標(biāo)標(biāo)的偏差差進(jìn)行忽忽左忽右右的調(diào)整整。這就就是反饋饋的機(jī)理理。原型型法是一一種不錯錯的反饋饋機(jī)制，根據(jù)我我們的經(jīng)經(jīng)驗(yàn)，視視覺刺激激對用戶戶是最為為關(guān)鍵的的，因此此不論你你的需求求文檔做做的如何何的優(yōu)秀秀，仍然然比不上上一個能能夠看得得見的軟軟件原型型有效。這一實(shí)實(shí)踐很多多的軟件件工程資資料中都都有敘述述，我們們就不深深入了解解了。另另一種反反饋機(jī)制制是漸進(jìn)進(jìn)交付。把軟件件產(chǎn)品分分為多個個迭代周周期，每每個周期期交付一一個可運(yùn)運(yùn)行的軟軟件，在在獲得用用戶的反反饋意見見之后，在下一一個迭代代周期進(jìn)進(jìn)行改進(jìn)進(jìn)

46、，最后后一個迭迭代周期期交付的的就是完完整的軟軟件了。6、對可可重用框框架的改改進(jìn)在在找到了了適合軟軟件企業(yè)業(yè)自身的的知識接接力方法法之后，應(yīng)當(dāng)將將其作為為規(guī)范或或指導(dǎo)意意見，加加入到現(xiàn)現(xiàn)有的軟軟件過程程中。例例如，在在需求分分析完成成之后強(qiáng)強(qiáng)制要求求進(jìn)行需需求評審審。加入入到過程程中的方方法，小小心不要要流于形形式。這這樣，既既付出了了成本，又收不不到應(yīng)用用的效果果。使用用工具也也是保持持知識順順利交接接的重要要方法。例如，采用自自動產(chǎn)生生源代碼碼的工具具，模型型設(shè)計(jì)工工具、幫幫助產(chǎn)生生工具、對象-關(guān)系映映射工具具等等。如果這這些工具具對你的的過程起起到了潤潤滑的作作用，請請規(guī)范和和普及工工

47、具的使使用。7、小結(jié)結(jié)請確保領(lǐng)領(lǐng)域?qū)＜壹液图夹g(shù)術(shù)專家之之間的順順暢溝通通。 完整、準(zhǔn)準(zhǔn)確的描描述需求求。 進(jìn)行需求求復(fù)審和和設(shè)計(jì)復(fù)復(fù)審。保證分析析模型（設(shè)計(jì)模模型）能能夠完整整的描述述需求。 保持需求求信息到到設(shè)計(jì)信信息到代代碼注釋釋的一致致。 使用反饋饋機(jī)制。 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index3.html 三、代碼碼是最終終目過程的最最終目的的是代碼碼，開發(fā)發(fā)過程中中的所有有活動都都圍繞著著這一目目的而展展開。如如果沒有有最后的的用于交交付的代代碼，軟軟件

48、就無無法成為為軟件。因此，必須保保證過程程能夠產(chǎn)產(chǎn)出代碼碼，而且且是優(yōu)秀秀的代碼碼。1、意圖圖無論哪一一種過程程，其最最終目的的都是為為了產(chǎn)生生出可執(zhí)執(zhí)行、并并且可用用的軟件件。因此此軟件過過程中的的各種活活動應(yīng)該該圍繞著著快速、準(zhǔn)確的的實(shí)現(xiàn)這這一目的的而展開開的。2、示例例維力亞軟軟件公司司是一家家合資公公司，由由于有外外資背景景，公司司內(nèi)部很很早就引引入了軟軟件工程程，并嚴(yán)嚴(yán)格的對對人員角角色進(jìn)行行分工。包括領(lǐng)領(lǐng)域建模模人員、架構(gòu)設(shè)設(shè)計(jì)師、高級程程序員、程序員員、界面面設(shè)計(jì)師師等等多多種角色色。每個個人各司司其職，充分發(fā)發(fā)揮出了了分工的的特點(diǎn)。但是隨隨著公司司開發(fā)項(xiàng)項(xiàng)目的逐逐漸增多多，這種

49、種方式也也顯露出出其弊端端來。每每個人的的主要目目標(biāo)都是是為了通通過評審審，而有有時候，就算是是通過評評審的工工件，依依然可能能存在問問題。但但這時候候扯皮就就出現(xiàn)了了。項(xiàng)目目中存在在的一些些中空地地帶。以以及交錯錯地帶，常常發(fā)發(fā)生無人人問津的的情況。開發(fā)過過程的效效率開始始下降，開發(fā)成成本開始始上升。問題雖雖然不是是一下子子出現(xiàn)的的，但是是已經(jīng)逐逐漸變得得嚴(yán)重起起來了。 3、分析析我們在進(jìn)進(jìn)行過程程設(shè)計(jì)，或引入入一個過過程理論論的時候候，有沒沒有思考考過該過過程的每每一個階階段、每每一個活活動的目目的是什什么，它它們對生生成最后后的軟件件有什么么樣的幫幫助，這這些幫助助對于我我們所在在的組織

50、織有意義義嗎。很很多情況況下，我我們并沒沒有這么么做，或或者隨著著軟件過過程的定定型，就就不再思思考這類類的問題題。一開開始并沒沒有什么么了不起起的，但但是當(dāng)軟軟件過程程演變成成了一種種政治體體系的時時候，那那么問題題就會慢慢慢嚴(yán)重重起來。 4、問題題如何讓讓過程圍圍繞著產(chǎn)產(chǎn)出軟件件的核心心目標(biāo)而而不斷演演進(jìn)？5、方法法從上一篇篇介紹的的內(nèi)容中中，我們們知道軟軟件過程程的每一一個階段段都是知知識轉(zhuǎn)換換的過程程，知識識轉(zhuǎn)換的的終點(diǎn)就就是軟件件。問題題在于，我們?nèi)缛绾伪ＷC證這種轉(zhuǎn)轉(zhuǎn)換的效效率呢？ 現(xiàn)代軟件件的發(fā)展展的趨勢勢是重用用。我們們開發(fā)一一個軟件件已經(jīng)很很少會從從最底層層開始編編寫了。我們使

51、使用各種種各樣的的技術(shù)和和平臺。包括數(shù)數(shù)據(jù)庫、分布式式體系、UI機(jī)機(jī)制、業(yè)業(yè)務(wù)元素素等等。因此現(xiàn)現(xiàn)在的軟軟件編寫寫往往都都是站在在巨人的的肩膀上上開始的的。不同同的軟件件組織，肩膀的的高低也也不一樣樣。比如如有的軟軟件組織織使用JJ2EEE平臺，有的軟軟件組織織則使用用.NEET平臺臺。但是是可以肯肯定的一一點(diǎn)是，每個軟軟件組織織都或多多或少的的擁有自自己的平平臺體系系開發(fā)經(jīng)經(jīng)驗(yàn)。這這些經(jīng)驗(yàn)驗(yàn)的表現(xiàn)現(xiàn)形式也也不盡相相同，可可能是保保存在某某些高級級技術(shù)人人員的腦腦中，也也可能是是保存為為文檔、模型或或代碼的的形式。對于單個個的項(xiàng)目目而言，其過程程一定是是從需求求開始，以部署署（以及及后續(xù)維維護(hù)

52、）為為終結(jié)的的。但是是對于長長時間存存在的軟軟件組織織而言，更重要要的是項(xiàng)項(xiàng)目經(jīng)驗(yàn)驗(yàn)、技術(shù)術(shù)經(jīng)驗(yàn)、管理經(jīng)經(jīng)驗(yàn)的積積累。這這樣說可可能過于于抽象，我們舉舉一個具具體的例例子。在在完成了了一個庫庫存管理理項(xiàng)目之之后，我我們把庫庫存管理理的領(lǐng)域域知識制制作為商商業(yè)組件件的形式式，而把把項(xiàng)目中中學(xué)習(xí)到到的一些些編碼的的技巧整整理為模模式的形形式，并并把項(xiàng)目目過程中中積累的的過程方方法添加加到現(xiàn)有有的軟件件過程中中。這些些經(jīng)驗(yàn)的的堆積就就是在一一開始我我們提出出的可重重用框架架。對一一個軟件件團(tuán)隊(duì)的的來說，它的所所有軟件件項(xiàng)目都都應(yīng)該是是圍繞著著這一個個可重用用框架而而展開的的。 迄今為止止，我們們見過

53、的的大多數(shù)數(shù)的可重重用框架架表現(xiàn)形形式都可可以總結(jié)結(jié)為：以以開發(fā)平平臺為基基礎(chǔ)，積積累自己己的商業(yè)業(yè)組件，并以此此為中心心訂立開開發(fā)活動動。這種種形式是是不是最最好并沒沒有定論論，但我我們是抱抱著學(xué)習(xí)習(xí)的態(tài)度度來研究究它的。 以開發(fā)平平臺為基基礎(chǔ)的意意思是軟軟件組織織必須有有自己所所熟悉的的開發(fā)平平臺，其其大部分分的項(xiàng)目目都是在在此基礎(chǔ)礎(chǔ)上進(jìn)行行的。目目前最流流行的兩兩種軟件件開發(fā)平平臺是JJ2EEE和.NNET，但是就就算是同同一個平平臺，不不同的軟軟件組織織對平臺臺內(nèi)部的的側(cè)重也也是不同同的（同同樣對于于J2EEE技術(shù)術(shù)，有的的軟件組組織可能能把JSSP和SServvlett作為核核心選擇

54、擇，而另另一些軟軟件組織織則把重重點(diǎn)放在在EJBB上）。選擇一一種廣泛泛應(yīng)用的的、具有有生命力力的平臺臺技術(shù)是是非常重重要的。因?yàn)槟隳愕目蚣芗軐砸源藶榛A(chǔ)進(jìn)行行，而框框架的轉(zhuǎn)轉(zhuǎn)移成本本是非常常之高的的。雖然然我們在在一開始始介紹的的MDAA思路為為我們繪繪制了一一副平臺臺無關(guān)設(shè)設(shè)計(jì)的美美好愿景景，但是是在目前前階段，我們?nèi)匀匀灰婷鎸Σ煌浖狡脚_造成成的嚴(yán)重重隔閡。 必須指出出的是，我們上上面提到到的開發(fā)發(fā)平臺指指的是在在操作系系統(tǒng)這個個層次之之上的平平臺，也也就是俗俗稱的中中間件平平臺。但但是從中中間件到到最終的的產(chǎn)品之之間有沒沒有過渡渡的平臺臺呢。其其實(shí)可重重用框架架就扮演演了這

55、一一角色。軟件市市場上已已經(jīng)出現(xiàn)現(xiàn)了商業(yè)業(yè)化的可可重用框框架了。IBMM的SaanFrrancciscco框架架就是這這種概念念的代表表。 平臺技術(shù)術(shù)僅僅只只是提供供了一個個技術(shù)，而軟件件組織要要生存和和發(fā)展，還需要要積累和和發(fā)展自自己的商商業(yè)組件件。并將將商業(yè)組組件發(fā)展展成為可可重用框框架。商商業(yè)組件件的好壞壞，直接接和軟件件組織的的能力、經(jīng)驗(yàn)，以及平平臺技術(shù)術(shù)相關(guān)。商業(yè)組組件可能能直接表表現(xiàn)為代代碼的形形式（BBeann、類、COMM組件等等），也也可能只只是描述述性的記記錄（文文檔）。商業(yè)組組件是經(jīng)經(jīng)驗(yàn)積累累而成的的。請注注意，商商業(yè)組件件的設(shè)計(jì)計(jì)并不完完全等同同于面向向?qū)ο箝_開發(fā)，因因

56、為面向向?qū)ο笾恢皇且环N種技術(shù)手手段，但但是商業(yè)業(yè)組件設(shè)設(shè)計(jì)的優(yōu)優(yōu)劣，更更重要的的是對業(yè)業(yè)務(wù)的理理解程度度。舉一一個最淺淺顯的例例子，一一個精通通面向?qū)ο箝_發(fā)發(fā)、面向向組件開開發(fā)的設(shè)設(shè)計(jì)師，讓他介介入他完完全不了了解的行行業(yè)組件件設(shè)計(jì)，他的表表現(xiàn)將會會大打折折扣。到目前為為之，大大家所認(rèn)認(rèn)識的框框架仍然然是技術(shù)術(shù)型的框框架。但但事實(shí)并并非如此此，框架架還包括括了外延延的一系系列軟件件活動。這才是是一個完完整的框框架。結(jié)結(jié)合之前前我們討討論的軟軟件交付付為開發(fā)發(fā)目標(biāo)。我們把把這種開開發(fā)方式式稱為以以可重用用框架為為核心，以交付付為目標(biāo)標(biāo)的軟件件開發(fā)。這其實(shí)實(shí)并不是是什么了了不起的的概念，大部分分

57、的軟件件組織都都已經(jīng)這這么做了了，只是是沒有意意識到自自己的方方式而已已。了解解這一點(diǎn)點(diǎn)，能夠夠幫助軟軟件組織織有效的的改進(jìn)自自身的構(gòu)構(gòu)架。平臺技術(shù)術(shù)和組件件開發(fā)并并不是本本文的重重點(diǎn)，因因此我們們在肯定定了兩者者的重要要性之后后，把精精力轉(zhuǎn)移移到軟件件活動上上。 在擁有一一個框架架核心（平臺和和商業(yè)組組件）之之后，框框架需要要包含這這樣的活活動（或或活動集集）：收收集項(xiàng)目目需求，并將需需求映射射到核心心構(gòu)架上上來。這這其實(shí)就就是需求求階段到到設(shè)計(jì)階階段要做做的事情情。但是是由于我我們的活活動是以以軟件交交付為目目標(biāo)的，因此我我們需要要明確的的指出活活動中的的注意事事項(xiàng)。為映射工工作設(shè)計(jì)計(jì)需求

58、描描述規(guī)格格。需求求并不是是一件容容易的事事。最難難的莫過過于尺度度的把握握了，例例如需求求要多詳詳細(xì)。使使用現(xiàn)成成的技術(shù)術(shù)來定義義需求描描述規(guī)格格，并根根據(jù)核心心框架的的特點(diǎn)進(jìn)進(jìn)行必要要的擴(kuò)展展。例如如，我們們使用成成熟的用用例技術(shù)術(shù)來描述述需求，同時我我們要求求需求按按照不同同類的商商業(yè)組件件進(jìn)行分分類索引引。用例例技術(shù)的的推薦讀讀物是AAlisstaiir CCockkburrn的WWrittingg Efffecctivve UUse Casses一一書，該該書目前前已有英英文影印印版。保證需求求規(guī)格能能夠被項(xiàng)項(xiàng)目成員員所理解解。這里里的項(xiàng)目目成員包包括客戶戶、領(lǐng)域域?qū)＜?、需求調(diào)調(diào)研者

59、、分析模模型設(shè)計(jì)計(jì)師。只只有他們們了解需需求，才才能夠保保證信息息的正確確的傳遞遞。（參參見 HYPERLINK /developerworks/cn/linux/software_engineering/Methodology/method2code/index2.html 知知識接力力模式）。 為實(shí)現(xiàn)需需求制定定分析（設(shè)計(jì)）規(guī)則和和指南 。這是是把需求求映射到到核心構(gòu)構(gòu)架上的的重要步步驟。制制定規(guī)則則是必要要的，但但要小心心，不要要讓規(guī)則則限制住住開發(fā)人人員的創(chuàng)創(chuàng)造力（參見 HYPERLINK /developerworks/cn/linux/software_engineering/Me

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