面向對象的uml與java總chapter

1、Software Development with UML Copyright Ken Lunn 2003開發(fā)過程管理楊天劍Software Development with UML Copyright Ken Lunn 2003組織機構在不同軟件開發(fā)中所扮演的角色組織機構是軟件開發(fā)的基礎。好的組織機構無論應用什么工具和技術，都會使開發(fā)獲得成功；有問題的組織機構，即使使用最好的工具也會將事情弄糟。這并不意味著有一種特殊類型的組織機構注定會取得成功。沒有完美的組織機構，對于同樣的任務，完全不同的組織機構能夠同樣獲得成功。事實上，不同的技術，不同的管理方法和不同的技能特點適合不同的組織和環(huán)境 這一

2、點并不難理解，但可悲的是還需要明確地指出來。我們將從不同的組織類型開始，接下來，將討論一些典型的角色。至于每種組織的類型是怎樣使用每種角色的，并不是簡短的介紹文字所能包含的。最后，我們會著眼于一個實例的研究，看一下它們在軟件生產中是如何進行組織的。Software Development with UML Copyright Ken Lunn 2003組織機構的類型Charles Handy ，在“Gods of Management” ( Handy , 1995 ）一書中描述了四種典型的組織文化。每一種都有自己的成功之處，并且每一種都會在一些任務中比其他幾種有優(yōu)勢。這些文化容易吸引特定類型

3、的人。在開始時，文化并不總是明顯的，在現(xiàn)實中，真實的組織結構將是多種文化的混合。理解文化的類型有助于合適的與可接受類型的開發(fā)。在一個實行俱樂部文化的公司中，設立較強的基于角色的軟件開發(fā)組織是沒有什么益處的 這不會取得成功。認識你周圍的文化類型能有助于實現(xiàn)目標并且避免不必要的沖突。Software Development with UML Copyright Ken Lunn 2003基于角色的文化基于角色的文化傾向于大的有良好規(guī)范的組織機構。人們把過程分成幾個組成部分，并且根據這些部分規(guī)劃工作。人員和小組是專業(yè)化的。遵循正式的工作方式，進行定期的辦公會議并在組織機構的不同部分之間采用標準的信息

4、交流方法。這些組織機構善于完成重復的任務。許多成熟的IT系統(tǒng)以這種方式進行管理。團隊是明確定義的，并且工作按照時間表來執(zhí)行。不利的方面是，分等級的組織結構不擅長開始新的和創(chuàng)造性的冒險，也不擅長在壓力下進行快速生產?；诮巧奈幕矚g“組織圖表”，如圖所示。在基于角色文化的組織中，管理人員在說明其角色時，首先要給出組織圖表，指出他的位置、老板是誰以及誰向他報告?；诮巧奈幕瘯验_發(fā)排列成定義明確的部分。會有一個項目辦公室負責規(guī)劃和提供資源，還有業(yè)務分析部、系統(tǒng)設計部、設計人員、開發(fā)人員或編程人員、數(shù)據庫小組、測試小組以及幫助臺。每一個重要角色區(qū)域都會有管理人員和在各階段把握項目方向的項目管理人

5、員。統(tǒng)一過程看起來鼓勵這種組織類型，統(tǒng)一過程定義的角色不只適合于統(tǒng)一過程，也能夠應用在其他類型的組織中。Software Development with UML Copyright Ken Lunn 2003Figure 6.1 A typical organization chart in a role-based companySoftware Development with UML Copyright Ken Lunn 2003俱樂部文化俱樂部文化中有一個很強的中心人物，這個人與和他志趣相投的人在一起，并讓他們擔任很強的責任，但也期待結果與忠誠。任何與這種文化有沖突的人都會很快離開或

6、導致組織解散。優(yōu)點：俱樂部文化幾乎沒有正式的管理機制，信息的相互溝通是直接的，小的軟件公司傾向于這樣的運作方式。這樣的組織能對形勢做出快速的反應，并能很快地將想像付諸實施。缺點：他們被中心人物的想法所左右，一旦組織的核心瓦解，他們將很快失去方向。你可以通過管理者介紹他們團隊的方式來了解俱樂部文化。俱樂部文化強調個體與個性，使用名字而不是角色的稱謂，即用名字稱呼高級員工。在員工的名片上常常有重要的頭銜，但主要說明他們是誰，而不是他們的職位高低?；诰銟凡康奈幕幌窕诮巧幕菢訃栏襁M行控制。在 IT 開發(fā)中，個體可以有許多角色。不會有正式的文檔生成，并且，需要快速得出結論。在俱樂部文化中，你必

7、須在給定的時間內拿出問題的解決方案，如果是因為需要了解系統(tǒng)的所有階段和修正所有的分析與設計的模型而不能完成任務將不被認可；你要么在這里修改代碼，要么另找一份工作。Software Development with UML Copyright Ken Lunn 2003任務文化任務文化集中在特殊的任務上。任務文化關注于結果，并且，為了完成目標，會改變其內部的組織結構。其中，沒有明確的角色劃分。一旦任務完成，這些人員就會離開。任務文化是能夠在團隊中工作的有很高技能的那些個人的充分體現(xiàn)。他們工資很高，而又十分高效。 lT 顧問和研究機構傾向于任務文化，他們常應邀解決一些特殊的問題。任務文化的不利方面

8、是，當問題得以解決，以及生產或服務從創(chuàng)造性階段轉向維護階段之后，任務文化也就失去了意義。由于職員以及管理人員經常討論問題及其解決方法，因此，你能夠識別出這是一個基于任務的文化。他們通常快速地了解新的形勢，并且提出觀點。任務文化不如俱樂部文化那樣看重個性，也不看重角色?；谌蝿盏奈幕褂盟杏杏玫姆椒?。如果利用 UML 建模有助于得到更好的解決方法，任務文化也會使用。如果直接租用代碼工作最好，他們同樣將那樣做。結論產生于過程之前，由于任務文化招募新成員是面向那些有成就的，有很高技能的人，因此他們通常會做出很好的結果，但卻疏于形成正式的文檔，并且難以維護。Software Development

9、with UML Copyright Ken Lunn 2003存在的文化存在的文化主要是由以個體工作的專業(yè)人士構成。典型的例子有初級律師、高級律師和醫(yī)生。具有專門技能的個體是受推崇的，并且，在這里組織機構給予個體相應的支持。這些環(huán)境中的管理人員比他們管理的個體的地位要低。盡管現(xiàn)代社會的壓力把大學推向基于角色的文化，但還是與存在的文化很相似。很少有 IT 組織是基于這種模型的。存在的文化不傾向于開發(fā)軟件，除非作為一種擴展專業(yè)技能的手段。如果你正在攻讀陣博士學位，會發(fā)現(xiàn)自己就處在這種文化之中。但是，大多數(shù)情況下你會以個人的身份工作，磨練自己的才能，而不只是制造出產品團隊中的一個成員。對于還沒有畢

10、業(yè)的大學生，當他們走進一個行業(yè)會碰到的一個問題是，他們成長時所處的文化在很大程度卜是存在的文化，并且，他們兒乎沒有參與其他類型文化的親身經驗。作為學生，他們主要以個體行動，并且，他們承擔的絕大多數(shù)工作是針對個人而不是針對一個團隊的。一些教育環(huán)境設法在他們的環(huán)節(jié)中增加一些團隊的觀念，但是對于大部分學生而言，教育環(huán)境卻力圖發(fā)展并證明個人的才能，至少在 lT 學科方面是這樣。Software Development with UML Copyright Ken Lunn 2003混合文化很少有組織在文化上是單純的?；诮巧慕M織常常允許甚至促進不同形式的亞文化群。例如，常常會建立一個基于任務的研究小

11、組，以及基于俱樂部文化的商品銷售部門。在組織發(fā)展中，俱樂部文化常會充分發(fā)展到角色文化。有時候俱樂部文化設立基于角色的亞文化群來管理例行的長期工作。對于軟件開發(fā)來說，哪種文化是適當?shù)哪?？首先，不同的文化使用其特殊的方式來解決軟件開發(fā)這個問題。它們不回避基本的軟件開發(fā)過程，但是，在具體操作上，卻有相當大的區(qū)別。知道你工作所處的文化和你的偏好是十分重要的。我的絕大部分工作經歷是基于任務文化的（研究和開發(fā)，以及咨詢），它是大型的并且基于角色文化的一部分。我同樣花費了相當多的時間在存在的文化上（大學研究）。最近，我加人了俱樂部文化，在開始時我并沒有認清這種種文化。很快，我就與高級經理一起工作了，但是我懷

12、疑我認為倉促的且高風險決策的正確性。對這些決策的反對使我很快離開中心，在俱樂部文化中，我僅僅工作兩年就被淘汰出局。Software Development with UML Copyright Ken Lunn 2003混合文化對文化的理解對我們在方法的選擇方面確實有所幫助。與其他形式的組織相比，統(tǒng)一過程更適合于基于角色的組織機構。事實上，大部分模型驅動的方法論都可能在這種形式的文化中找到根源?；谌蝿盏奈幕暨x一些模型和方法論的某些部分。俱樂部文化會采用所有他們喜歡的方法，但是，過于正式的形式是不受歡迎的。極限編程和許多輕量級的方法將目標對準那些更看重交付成果的組織機構，它們似乎更適合俱樂部

13、文化和基于任務的文化，而不是基于角色的文化。Software Development with UML Copyright Ken Lunn 2003項目的主要角色1、指導小組對于大規(guī)模軟件開發(fā)來說，需要有一些高水平的團隊負責設定項目的目標并提供經費通常稱之為指導小組。對于一些項目和一些組織，指導小組是現(xiàn)有的一組管理人員 不是公司的董事會，就是某些正式的管理委員會。有時候，對于特殊類型的項目，要建立專門的指導小組。指導小組制定項目的主要目標。這些目標可能會隨著時間改變，可能因為市場發(fā)生變化也可能因為項目開發(fā)中的實際情況而出現(xiàn)不同的局限性或可能性。關于目標的對一話將在小組與項目的管理層的內部進行

14、。指導小組掌握著項目經費。通常是根據定期進度報告，階段性地發(fā)放經費。資金的發(fā)放要取得預計的目標。在第 7 章討論的成本效益模型對于項目的批準和進度跟蹤是十分重要的。指導小組對項目中的高級別風險進行監(jiān)控。項目失敗是軟件開發(fā)生命期的一種實際情況。有時候這是項目的內在原因引起的，源于糟糕的管理或技術的固有風險。有時候，原因在項目之外，比如業(yè)務活動的衰退或組織目標的改變。指導小組要負責終止那些不再具有可行性的項目。Software Development with UML Copyright Ken Lunn 2003不同文化組織中的指導小組基于角色的組織通常會建立管理和委員會機構來履行指導小組的職責

15、。委員的選擇要取決于項目的規(guī)模和重要性。對于 ICANDO 化學制品這種重要的項目，作為指導委員會的是 ICANDo 化學制品董事會。俱樂部文化有起指導小組作用的中心人物，或者，中心人物將建立由選出的個體組成的指導小組。對于 ICANDO UK零售交易，市場經理建立了一個包括他本人、他的財政經理、他的 IT 經理以及零售促銷業(yè)務經理在內的指導團隊?；谌蝿盏奈幕粌A向于建立他們自己的正式指導小組，但是，他們通常是一個大規(guī)模文化的一部分（或是為其工作），而這個大規(guī)模文化將會建立一個指導小組。給客戶的咨詢將報告給客戶設立的指導小組。對于 ICANDO 的儲站安全應用，研究機構舉辦6個月一次的會議。

16、這個會議是在研究部門和業(yè)務執(zhí)行部門高級經理間進行的，用來檢查項目的進展情況。Software Development with UML Copyright Ken Lunn 2003項目中的主要角色2、項目經理通常是指派一個個體擔當管理項目的角色。項目經理向指導小組報告，并且負責協(xié)調項目中的各個部分。項目經理的關鍵任務是確保項目按計劃進行、實施項目的資源就緒、識別并指出風險和項目按時交付。項目管理是一個需要不斷進行協(xié)商的角色?；诮巧慕M織比較正統(tǒng)，包括了常規(guī)的計劃和不同團隊的管理人員參與的進度會議。一些獨立的小組有可能同時針對多個項目工作，不時也會有一些資源上的沖突。同樣，這些工作需要有規(guī)劃

17、并進行沖突處理。在基于任務的組織中，項目管理人員更愿意參與到過程中，可能會從中直接收集到許多信息。在俱樂部文化中，項目經理可能是核心的一部分，并且可以自由地按他或她認為適合的方式組織項目。Software Development with UML Copyright Ken Lunn 2003其他角色在所有的組織中，指導小組和項目經理可能以某些不同的形式出現(xiàn)。對基于角色的組織機構來說，接下來的角色是具有代表性的。在基于任務或基于俱樂部的組織機構中，這些角色可能會合并在一起，或者在某些不常見的實例中被去掉。Software Development with UML Copyright Ken L

18、unn 2003編程人員編程人員使用多種開發(fā)工具和語言，像 Java 或 visual Basic，他們按照設計構建部分系統(tǒng)。他們的工作主要是從類圖、順序圖和已設計出的接口原型開始的。他們發(fā)現(xiàn)，查閱用例文檔是很有用的。數(shù)據庫設計師數(shù)據庫設計師負責下層的數(shù)據庫表，以及所有與維護一個安全可靠數(shù)據庫有關的事情。這是一個從設計組中單獨分離出來的關鍵的專門領域。他們使用設計組的輸出，并且與編程人員緊密合作。他們關心形式化，確保事務得到可靠處理，確保有適當?shù)臄?shù)據備份和恢復的過程。Software Development with UML Copyright Ken Lunn 2003系統(tǒng)工程師當系統(tǒng)構建完

19、成之后需要被部署，首先在測試環(huán)境中部署并最終進入到用戶環(huán)境中。在系統(tǒng)部署過程中，系統(tǒng)工程師由構架師（architect）、編程人員和數(shù)據庫設計師指導。他們負責系統(tǒng)運行的可靠性，系統(tǒng)整體的安全性，以及日常的管理任務，比如數(shù)據庫備份等。測試人員通常編程人員會對自己的工作進行“單元測試”。也就是說，他們確定自己的那部分工作可靠并符合要求。然而，依賴開發(fā)人員對系統(tǒng)進行測試并不是好的習慣。測試人員會通過業(yè)務過程定義和用例定義來構建一個測試策略，按實際中的使用方式來測試系統(tǒng)。他們執(zhí)行測試，并且生成出錯報告。Software Development with UML Copyright Ken Lunn 2

20、003幫助臺操作員一旦系統(tǒng)運行起來，不可避免會有錯誤產生?？赡軓暮唵蔚膯栴}，如用戶忘記密碼，到程序給出錯誤結果，甚至是系統(tǒng)根本不能工作。通常，組織機構有一個幫助臺作為第一個呼叫點。幫助臺操作員記錄報告的問題，然后找一些人解決問題，對問題進行追蹤直到完全解決。中間管理大型項目被分成若干個小組，由管理人員管理。這些管理者負責項目的一部分，例如業(yè)務分析或設計、實現(xiàn)。他們關心自己小組日常的問題，并與其他小組協(xié)作。他們與項目經理們一起合作，確定工作時間表與同意交付的決策。在同一時間，一個小組常?？赡苡泻芏囗椖浚芾碚邔鶕?yōu)先權進行資源分配。Software Development with UML

21、Copyright Ken Lunn 2003構架師構架師負責系統(tǒng)的整體結構，以及構建系統(tǒng)使 JIJ 的一具他們與設計者進行大員的討論，確保各部分恰當結合。在構建系統(tǒng)方面，構架師通常是具備相當才能并且經驗豐富的設計者。一般說來，他們會是設計小組的一部分，在項目設計中起到領導作用，并且對設討一的質量進行監(jiān)控。 業(yè)務分析者業(yè)務分析者通過與人們合作來理解業(yè)務是怎樣運作的。他們生成過程圖來概括一個業(yè)務領域，用劇本分析來確定業(yè)務過程中的主要路徑和替代路徑。他們還使用活動圖來提供過程的工作流描述。他們將識別支持現(xiàn)有業(yè)務過程的用例，或者待開發(fā)的業(yè)務過程用例。業(yè)務分析者經常給出系統(tǒng)的測試方案。Software

22、 Development with UML Copyright Ken Lunn 2003系統(tǒng)分析者系統(tǒng)分析者關心一個系統(tǒng)是怎樣在業(yè)務內部運作的。他們設計出用例的細節(jié)，使用劇本分析決定系統(tǒng)運作的主要路徑和替代路徑。他們將勾畫接口，并且很可能與開發(fā)者合作完成接口原型。系統(tǒng)分析者將會經常參與決定系統(tǒng)需求的數(shù)據，并且得出一些高層次的類圖。 設計人員設計人員負責使用系統(tǒng)分析者的工作成果，并且把它們映射到系統(tǒng)的構架上。他們決定驅動這個系統(tǒng)的對象類和屏幕細節(jié)，與構架師一起對系統(tǒng)構架做出調整。設計人員的輸出是一個關于系統(tǒng)要構建什么的規(guī)范說明書Software Development with UML Cop

23、yright Ken Lunn 2003風險管理正如我們之前所討論的，軟件開發(fā)是一項有風險的活動。需要在項目的所有層次上承認風險，并且必須要有風險處理程序。從項目小組最高級成員到最低級成員，在風險發(fā)生的時候，大家必須共同來關注風險，并且，要迅速采取行動來消除風險。處理風險的現(xiàn)代方法是迭代方法。某些應用程序在短的階段中開發(fā)，定期整合成完整的產品。只要有可能，就部署中間產品。這對于徹底快速解決問題很有效，而不是成年累月地把問題積攢下來。我們先前討論的另一種方法是風險登記。風險登記允許所有項目組成員提出他們識別的風險。需要按照他們提出的嚴重程度來評估風險，并指派一些人采取行動將風險減到最小，或者，最

24、理想地消除風險。風險需要提交到項目會議的議程中來。推遲處理風險是不可取的。取決于嚴重性，管理人員可能要跟蹤風險。Software Development with UML Copyright Ken Lunn 2003進度與資源的計劃為一個項目組織資源是一項復雜的活動。通常使用一個做計劃的工具。理解一個項目中的依賴關系是必要的。開發(fā)的任何部分都需要經歷開發(fā)過程的所有階段。良好的計劃依賴于精確的評估。在一個項目的初期階段，這是一定有問題的。因為在沒有經驗的情況下，我們沒有基礎來估計需要多久才能構建軟件的一個部分。開發(fā)常會遇到無法預料的障礙。迭代方法能對項目下一個階段的評估給出參考。制訂計劃時需要考慮資源沖突。小組中進入和發(fā)出的工作流程不可能是平衡的。分析資料將會成批到達。測試小組在項目上將有一段雖短但卻密集的工作時期。通常，如果把所有的活動按發(fā)生順序設置成首尾相連，花費的時間會相當長，因為中間階段人們都在從事不同的工作。項目規(guī)模越大，評估就越困難。沒有計劃，項目就像是一艘小船在廣闊的充滿危險的海洋上漂泊。小組中的每一個成員都要清楚整個計劃，以及他們在計劃中充當?shù)慕巧ｍ椖拷浝砀鶕媱潄矶ㄆ跈z