摘要: 1、操作符“==” 用來比較兩個操作元是否相等，這兩個操作元既可以是基本類型，也可以是引用類型。 代碼01： /**  * Demo01.java  *  * Provider: CoderDream's Studio  *  * History  ...  閱讀全文

知識管理我的Blog上談的比較少，我也不是這方面的專家，但知識和技能，經驗，方法論，實踐，思維思考都有關系。因此知識管理也是我關心的內容內容，包括個人知識和企業級和團隊的知識管理。在2,3年前通過思維導圖畫的IT知識體系結構就是在這方面的一些實踐，目的就是如何真正讓知識發揮作用和創造效益。個人認為現在很多流行的知識管理系統都是輔助性的工具而已，關鍵還是是否真正的理解的知識管理的目標，理解了目標才知道如何做好知識管理，讓知識管理真正的發揮作用。

1.第一個層次-形成知識庫

知識庫首先不是資料庫，不是上傳一大堆資料就完成知識庫的建設了。資料必須經過多維屬性的整理才能夠真正入庫，資料的關鍵字,TAG標簽，多維度的分類都是屬于資料的重要屬性。而且入庫的資料必須是有價值的資料，必須是經過我們分析，抽取和整理后的資料，這樣可以減少后期其他人在無用的資料上面浪費時間。資料入庫后完成了第一步，后面重要的就是知識的分享，一個資料能夠在知識庫中下載了不是分享，要成為知識的分享就需要對資料附加上團隊中他人的評論，學習筆記和心得，有了這些就完成了知識庫的基本建設。

在第一個層次上面，我們可以看到現在棲息谷或其他很多論壇的資料下載都是停留在資料庫的層次上面。因此也就出現了我們前面常說的問題，論壇用戶面對一大堆挪列的資料往往無從下手。我們的硬盤成為了我們資料收集的工具，而我們的大腦卻根本還沒有啟動，更談不上如何去將這些資料轉化為系統的知識。從這點上再來看豆瓣網，豆瓣本身不存儲任何的書籍和影音資料，但更多的針對書籍和影響的學習筆記，評論和相關小組更容易讓理論性的東西轉化為知識。

2.第二層次-形成知識地圖

如果你不知道要到哪里去，給你張地圖也沒有用。但現在的問題是很多人知道往哪里去？他們有明確的想法想增加哪方面的知識或者說想提高哪方面的技能，但我們卻很難針對他們給出一張類似于學習路線的知識地圖。

在知識庫建立和發布好以后重點就是要去形成知識地圖，知識地圖一方面應該是正對某一個業務領域或者應用場景需要的知識形成一個完整的知識體系結構圖，讓大家對要學習某項知識或技能有個全局的認識，同時也讓每個人看清楚自己在地圖中的位置?？辞宄四阍诘貓D中的位置，才能夠知道如何達到目的地。

找到自己的位置后，就要發揮地圖的第二個作用，如何在通過地圖一步步的達到自己的目標，應該遵循什么樣的行走路線，哪些地方需要慢慢走去體會，哪些地方可以跳躍下。要能夠把行走路線準確的畫出來，則需要理清楚知識和知識間的關系，哪些是關鍵約束和依賴關系，哪些是可選的依賴關系。把這些依賴關系理清楚后，知識路線自然就出來了。

針對處于不同位置的人，知識路線往往是不同的，我們可以給出常規的最佳路線，但無法給出針對每個人的最佳路線。所以有時候不要盲目的去迷信他人的學習路線，適合自己的路線才是最好的路線。由于無法解決個性化的最佳路線問題，需要過渡到第三個層次。

3.第三層次-從經驗到方法論，模式的不斷積累

任何知識管理工具和系統，如果走不到第三個層次則始終是停留在使用階段，而無法真正過渡到創造階段。我們進行的知識管理應該站在了前人的肩膀上面，后面要做的就是通過自我知識的學習形成相關的經驗，大家通過知識平臺的討論和固化，將我們的經驗積累為相關的方法論和模式。方法論會告訴我們遇到河流你需要通過橋過去，搭橋過去，或者說學習游泳技能過去；遇到山你可以爬過去，打個隧道過去，也可以繞過去。你可以根據你自己的情況選擇相關的方法。所以有了這些大家共同積累下來的方法論和模式，再給你一張地圖的時候，你不一定安裝常規的學習路線走，你可以在方法論和模式的指導下創造出更多的行走路線，你要做的是根據自己的技能特點和面臨的場景，選擇最適合自己的學習路線。

知識管理的過程就是PDCA的過程，就是不斷的和朋友分析和討論自己的學習心得和經驗，通過將經驗固化為過程和特定的方法論和模式。知識能夠真正的創造價值就在于知識能夠以最快和最便捷的速度別它人所吸收，并轉為自我的技能；知識真正的能夠為企業創造價值就在于在形成經驗技能后，個體能夠將經驗和心得分享，企業對經驗和心得進行整合為不斷完善方法論和模式的過程。

原文鏈接：http://developer.51cto.com/art/200710/57527.htm

十五個秘決搞定你想要的晉升，拿到你應得的薪水

怎樣評定一名軟件開發人員？這是一個頗為奇怪的問題。現在已經有了很多的理論和形式來做這件事，人力資源部門也試著幫你管理和反省自己的行為。然而，怎樣才是一個偉大的軟件開發人員，在今天，你該怎樣發展你的職業生涯？以下是我評定團隊中軟件開發人員的“軍規”。按照這些技巧和規則，你可以改善你的現狀，由一個優秀的程序員，成為一名偉大的程序員。

1、時間花在寫精彩的代碼上

這里說的不是數量，而是質量。對此，一種歪曲是：要數量，也要質量。你也許會很多次的遇到以下的兩種情境：

情境A：你有一個發瘋似的能寫代碼的程序員，事情似乎在進展中……然后，Bug開始不斷出現，你們也不知道為什么，好像永遠補不完。補完十個，又出來五個，現在你手里的，就是一大堆代碼……

情境B：你現在有一個看起來很聰明的程序員，你面試他的時候，他似乎無所不知，能把理論說的頭頭是道。然而，你留給他三個任務，三個星期以后，他還在做一些三天就該干完的事。這下該你困惑了，他這么聰明，他知道generics（詳見備注），多線程的一切事情，甚至還能給祖母級的人講解什么是指針，讓老太太興奮的想去編程?？墒恰趺词裁炊紱]完成？

于是，在夢境中——你寫出了堪稱偉大的代碼，——偉大的代碼是偉大的程序員寫出來的，他睿智，明白代碼的真正品質所在。寫代碼就像托尼•霍克在玩滑板一樣自然優美，看上去就令人愉快。這些程序員以讓你眼花的速度搞定一切，他們知道每個問題應該處理多長時間，也不會追捧尋覓所謂的世界最好解決方案，弄很多線程很多層來寫一個簡單的游戲。他們寫的程序沒有Bug，因為寫的時候自己測試過了，在睡覺時也在寫代碼說的就是這樣的人。這些程序員太寶貴了。

2、闡明問題

可以明確的是：即使有問題暫時處理不了，還有成百上千的方法去解決。有些人反應很迅速，很快就能提出多種解決方案。然而，一個偉大的程序員應該在做出行動以前清晰闡明問題——創建文檔或用白板表達出來。他們寫郵件給項目的管理者，這樣表述：“我想和你說說我是怎么理解這個問題的，我們能這樣處理嗎？”然后他們就會動手給你多種方案。

對，這些人明白自己看問題和闡明立場的方式，而這理解方式大概不會是問題創建者所想要被理解的。請牢記這就是關鍵所在。一名偉大的程序員在嘗試解決問題以前，一定要完全的理解它。你百分百搞明白了嗎？沒有？百分之九十九？——回去再多問些問題，確保百分之百理解清楚了。

3、怎樣著手解決問題

那一搞明白了問題，就開始動手寫代碼？錯！一個偉大的程序員應該按照規劃，開始思考面臨的多種選擇，基于問題開始考慮最好的解決方案。我覺的這像一場國際象棋比賽。你知道每個棋可以怎么走，知道所有的游戲規則。但是你會馬上走棋嗎？不，你要審時度勢，制訂計劃，緊盯對手，分析其通常的做法。和這一樣，在你coding解決問題以前，你也要這么做。

看看問題，計算出需要怎樣的結果，你的時間能怎么安排，預期的質量，你必須用的工具，……好了，開工吧！

4、對代碼的信任

作為項目管理者，你怎么相信他們的代碼。有些程序員，你可以對他們說：“我星期五就要結果”?！瞧谖宓搅耍闶盏搅诉@樣的Email：“代碼我都已經檢查過了，現在就等著測試了。”你很放心，只會有很少的瑕疵在質量確保的團隊被查到。當然，還有些輕率的例子，一些程序員在郵件里是這樣說的：“我還沒弄完，星期一上午我會最先完成它”。你不太確信這東西，發現很多Bug，很長時間基本上不能用。又得花上幾個星期清理代碼中的Bug。

關鍵：你對一個開發人員越有信心，他離成為一個偉大的程序員的距離就越近。想象你是你的管理者，如果他并不擔心你的代碼，會給你多少信心和勇氣！

5、對方案的信任

和對代碼的信任是一回事——如果你手上有偉大的程序員，你就會對解決方案有信心。這些程序員同時也是偉大的建筑師。他們剖析整個問題，指出問題需要怎樣去解決。這就不只是用偉大的代碼編程的問題了，很大程度取決于你怎樣構筑解決方案。這是關鍵，而且會讓你在軟件世界里出類拔萃。

6、滿足客戶需求

一天下來，你寫出了最棒的代碼、用了最好的框架和最好的解決方案，但這真的能迎合用戶的需求嗎？恐怕根本不是那么回事兒。你搞砸了。盡管現在多次失手，一個偉大的程序員還是會正中靶心，找出客戶需要的，給用戶逐步展示他們所需要的無bug的最終版本。需求正中靶心的同時，用戶滿意了。

7、不斷升級

偉大的程序員會積極主動地把自己的技術升級。他們對知識的態度就像餓貓見著了牛奶，他們從不用上級催促給自己設定目標、不用經理要求他們完成任務，因為他們自己就已經安排OK了。

他們發現自己想要參加的大會就會給公司寫Email“本人非常想參加今年的Tech-Ed大會。我將用心研習，并對作出貢獻。我預計這可節省<金錢/其他原因>。如果可行，不知公司是否幫我支付此行？”如果我收到這樣的郵件，我不僅會幫他支付參會費用，他的路費我也會全程買單。

偉大的程序員們永遠會關注例如.net用戶組或Java用戶組的所有用戶群體。他們參加本地的技術會議，并從中汲取知識。你會看所有最新博客和最新的雜志嗎？現在列出你最喜歡的前5個開發博客。你能做到嗎？你應該像參加基督教青年會那樣輕松做到。做到這些，可以很好的幫助你延伸你的思路！你將會不斷獲得更好的點子！你會得到更好的回報！

8、團隊奉獻

你可以是團隊中最棒的那個人，可是如果你不是最好的程序員、不是建筑師、不是團隊里最有活力的人，那么對我來說，如果你不能分享或對你的團隊有幫助，你的價值就會大打折扣。一個好的程序員會使自己周圍的人同樣強大起來。試想一下，好程序員會不斷完善自己的知識和能力，如果他們不和周圍的人分享他們的知識，他們從哪兒能獲得更多呢？

他們不斷學習新東西，發掘新技術，但是不會讓其他人知道他們這么做了。一個好的程序員會準時完成方案，但是那是在催促和團隊得不到休息的前提下。然而一個偉大的程序員則會與團隊中所有的項目保持聯系，在需要的時候還可以出手幫忙。他們會如是說：“我注意到A團隊的項目進行到xx進度了，如果不介意的話，我想我可以幫忙？”

9、做好會議記錄

做好會議記錄絕對至關重要！開會期間，大家花大量時間來說明了新觀點、新主張、集體討論還有提出了新設計方案，可是會議結束后卻沒有人可以拿得出會議記錄，簡直沒什么比這更糟糕的事情了。即使你有會議大綱，我還是期望見到參會的每一個人員都可以帶著紙和筆（當然對于程序員來說筆記本則堪稱完美）。一個偉大的程序員會注意到這點。他們會記下所有的會議記錄，并且在會議結束的的時候說：“就剛才的會議，我著重記錄了幾點：XX…… 我是否記錄全了呢？”

接下來，偉大的程序員就會把他做好的會議記錄分發給項目管理者，列出會議時間、會議主題和參會者。接下來，是會議項目的標題和重要條目。在這之后，就是這些議題的詳細記錄。一個好的程序員沒有做會議記錄，并在會議上對提出的每項事宜都點頭稱是，那只能寄希望于他的記憶力足夠好了。隨后，他會給你發郵件讓你看看他的改動，你得回頭提醒他忘記的不多，百分之九十的都沒錯?！@不是浪費時間嘛！根本不是這么回事！所以，做好你的會議記錄。

10、孺子可教和接受批評

如果你讀到這兒了，就表明你有希望接受這些建議，并在以后的開發行動中嘗試執行。對，程序員的另一項重要能力就是向他人學習并且能夠接受批評。通過把自己變為一個虛心受教的人，像海綿一樣快速吸收大量知識，畢竟在編程的路上你還有很多前輩。當然，也許他們在寫代碼的歲月里慢慢生了銹，甚至傷痕累累，但是他們畢竟曾披荊斬棘跨過無數的坎兒。對于做出正確決定，他們又著瞬間的本能，讓你不得不服。處于他們這個位置，很樂于見到你的成長和成功。

所以，只要你是個偉大的程序員，就會理所當然的擁有理想的工作環境。如果你不斷改善技能、虛心好學、在別人給出的意見和批評中總結錯誤并得以改善，我向你保證你將會成為一個偉大的程序員而不只是想象自己變得偉大而已。如果你總把自己想象成為“精英”而不進步，那你只是自欺欺人。如果你不成長，你甚至不能停留到原地，等待你的只有滅亡！

11、公司需要的時候總能出現

這如同等價交易。如果你為一家偉大的公司工作，他們會給你足夠的彈性。公司不會限制你如何工作，不限制你開始或結束的時間，也不會限制你什么時候停下來歇歇。公司會鼓勵你在休息時間做做操，甚至會在你和團隊成員出去吃飯的時候為你們買單……在繁復大量而緊張的工作后，公司會放你幾天小假。諸如此類。

然而，毫無疑問，與前面的這些美事兒隨之而來的是責任。如果趕上時間緊還得出活兒，偉大的程序員則建議你即使在周末也要加班。即使干得再晚也得把活兒干完。你看，偉大的程序員是要為自己的創作負責的。這雖不是必需的，但這是偉大程序員的標志之一。有些人只想朝九晚五的上班，他們可能不錯，但是成不了偉大的程序員。偉大的程序員是團隊中干到最后的那個，把作品視為完美的藝術，與團隊成員親如一家。

12、衣著職業化

你永遠也不知道一個客戶會什么時候突然拜訪。你也永遠不會預知什么時候突然要參加一個會議，不是每一件事都在計劃中的。你得隨時準備好展現自己。一個好的程序員周一到周五穿著普普通通，甚至有可能穿牛仔裝和運動鞋來上班。在某些周五，他們穿著T恤，短褲和運動鞋出現。當一個客戶突然在周五出現，要談一個大項目，你沒法把衣衫不整的他一塊兒叫上。

一個偉大的程序員周一到周五都穿著職業化，衣服也能帶來成績。如果你不在意穿著，你也會因為穿的太奇怪而得不到晉升。毫無疑問，套裝和領帶還是很能提升你自己的。我向你保證，一套得體大方的西服套裝會讓你在今年就覺的物超所值。

13、溝通能力

這是另外的判定條件。這世上有太多優秀程序員，卻沒幾個偉大的程序員。為什么呢？因為大多數程序員不善交流。交流的層次很多：從發電子郵件、參加小型SCRUM開發小組會議到大一些的主管會議，水平逐漸提升。這樣你就能在數百人參加的會議上自如地展示你的軟件。在會議上你不需要有好演技，但是至少要清晰明了地表達你的觀點。你的溝通能力越強，你的職業道路就會走得越遠！

概要：想要成為管理人員，你的溝通能力得分至少要打到9到10分。甚至你在會議上只講了幾分鐘，或只一個小匯報，你都需要非常好的表達能力。別只是在你的每天的工作日志寥寥寫上“修補1371個bug”，你要做的是盡可能描述清楚如何在這么艱難的情況下解決了問題。闡明你的方法，說明你如何保證這個bug不再出現。你就不再為你的日志發愁了。這會是你向經理展示自己的精彩演出。

14、目標設定的技巧

好的程序員日復一日的做你安排給他們做的事情，貫穿始終。他們并不往遠看，不對明年、5年甚至10年后作打算。一些好程序員雖然知道自己想要什么，卻沒有具體計劃去實現。偉大的程序員則給自己訂立年度、未來5年的目標，而且大概預期到自己10年后的發展。

偉大的程序員有了目標不會只是想象，他們會具體實施。他們會根據具體情況，在預期的時間做具體的事情。他們會詳細地制訂明年的計劃，包括要上的課程、要完成的項目甚至包括他們需要建立的人際關系。

15、組織技巧

把所有事情整合在一起的最關鍵要素是組織。你可能是世界上最好的程序員，但如果你不善于組織你所做的事兒，你的工作將陷入癱瘓，最終喪失優勢。偉大的程序員保持自己工作平臺的整潔有序，保留所有的筆記并調理清晰。他們標出自己的會議日程表。他們有專門的收件箱給日程郵件、會議和新任務分類。他們保留文檔并能在需要時迅速找到所需。

額外要提到的：激情

偉大的程序員如果沒有熱情，那么他的工作也并不偉大。好的程序員有了熱情來對待他的工作、方案和團隊，那么他比偉大的程序員還要偉大。

在回顧的時候，我用這些標準來評判我的開發團隊。我給我的團隊盡可能最好的環境，作為回報，我想要他們都成為最偉大的程序員。你可以用這些標準來評判你的團隊，或者你本身就是一名程序員，請用這張列表來盡可能地改造自己來超越同儕。

備注：Generics是程序設計語言的一種技術，指將程序中數據類型進行參數化，它本質上是對程序的數據類型進行一次抽象，擴展語言的表達能力，同時支持更大粒度的代碼復用。對于一些數據類型參數化的類和方法來說，它們往往具有更好的可讀性、可復用性和可靠性。在設計集合類和它們的抽象操作時，往往需要將它們定義為與具體數據類型無關，在這種情況下，使用Generics就是非常適合的。

英文原文鏈接：http://www.realsoftwaredevelopment.com/2007/08/how-to-rate-a-s.html

1、應用軟件系統架構設計的“七種武器”
2、如何進行軟件架構設計？
3、動態擴展struts-menu

作者：高艷明（來源：51CMM）  http://www.csai.cn  2003年05月19日
原文鏈接：http://edu.csai.cn/rjsp/NO000014.htm

 

引子

　　CMM理論和知識是最近幾年的熱點，在最近兩年的系統分析員上午試卷中都有一題考察CMM知識的，一般有3-5分的樣子。估計未來的系統分析員考試還會有這方面的考題。即使不考，我們的系統分析員也應該掌握這方面的知識，因為將來從事的系統分析與設計的工作也離不開CMM理論和知識，因為即使我們所在的公司不去進行CMM評估，CMM理論知識對于我們不斷的進行公司的軟件過程改進有一定的借鑒意義，從而有助于軟件質量的提高，進而提升公司產品的市場競爭力。

摘要

　　本文是根據這兩年試題中涉及CMM知識而特為廣大考友搜集整理的關于CMM的基礎知識的文章。主要內容是有關CMM的基本概念、CMM的基本框架和對CMM的正確態度等。希望這篇文章對你有所幫助，謝謝。

　　CMM（Capability Marurity Model，軟件能力成熟度模型）是于1984年美國國會與美國主要的公司和研究中心合作創立的一個由聯邦資助的非盈利組織——軟件工程研究所（Software Engineering Institute,SEI）的一個早期研究成果。該模型提供了軟件工程成果和管理方法的框架，自90年代提出以來，已在北美、歐洲和日本成功地應用?，F在該模型已成為事實上的軟件過程改進的工業標準。下面我們來一起學習有關CMM的一些基礎知識。

一、 CMM基本概念

　　過程（Process）：為實現既定目標的一系列操作步驟[IEEE-STD-610].
軟件過程（Software Process）：指人們用于開發和維護軟件及其相關產品的一系列活動、方法、時間和革新。其中相關產品是指項目計劃、設計文檔、編碼、測試和用戶手冊。當一個企業逐步走向成熟，軟件過程的定義也會日趨完善，其企業內部的過程實施將更具有一致性。

　　軟件過程能力（Software Process Capability）：描述了在遵循一個軟件過程后能夠得到的預期結果的界限范圍。該指標是對能力的一種衡量，用它可以預測一個組織（企業）在承接下一個軟件項目時，所能期望得到的最可能的結果。

　　軟件過程性能（Software Process Performance）：表示遵循一個軟件過程后所得到的實際結果。（與軟件過程能力有區別，軟件過程能力關注的是實際得到的結果，而軟件過程性能關注的是期望得到的結果。由于項目要求和客觀環境的差異，軟件過程性能不可能充分反應軟件過程整體能力，即軟件過程能立受限于它的環境。）

　　軟件過程成熟度（Software Process Maturity）：是指一個具體的軟件過程被明確地定義、管理、評價、控制和產生實效的程度。所謂成熟度包含著能力的一種增長潛力，同時也表明了組織（企業）實施軟件過程的實際水平。隨著組織軟件過程成熟度能力的不斷提高，組織內部通過對過程的規范化和對成員的技術培訓，軟件過程也將會被他的使用者關注和不斷修改完善。從而使軟件的質量、生產率和生產周期的到改善。

　　CMM是軟件過程能力成熟度模型（Capacity Maturity Model）的簡稱，是卡內基－梅隆大學軟件工程研究院為了滿足美國聯邦政府評估軟件供應商能力的要求，于1986年開始研究的模型，并于1991年正式推出了CMM 1.0 版。CMM自問世以來備受關注，在一些發達國家和地區得到了廣泛應用，成為衡量軟件公司軟件開發管理水平的重要參考因素和軟件過程改進事實上的工業標準。

　　CMMI（Capability Maturity Model Integration）即能力成熟度模型集成，這也是美國國防部的一個設想，他們想把現在所有的以及將被發展出來的各種能力成熟度模型，集成到一個框架中去。這個框架有兩個功能，第一，軟件獲取方法的改革；第二，建立一種從集成產品與過程發展的角度出發、包含健全的系統開發原則的過程改進。

　　關鍵過程（區）域（Key Process Area）是指一系列相互關聯的操作活動，這些活動反映了一個軟件組織改進軟件過程時所必須滿足的條件。也就是說，關鍵過程域標識了達到某個成熟程度級別時所必須滿足的條件。在CMM中一共有18個關鍵過程域，分布在第二至五級中。

　　關鍵實踐（Key Practices）：是指關鍵過程域種的一些主要實踐活動。每個關鍵過程域最終由關鍵實踐所組成，通過實現這些關鍵實踐達到關鍵過程域的目標。一般情況下，關鍵實踐描述了該“做什么”，但沒有規定“如何”去達到這些目標。

　　軟件過程評估（Software Process Assessment）是用來判斷一個組織當前所涉及的軟件過程的能力狀態，判斷下一個組織所面向得更高層次上的與軟件過程相關的課題，以及利用組織的鼎力支持來對該組織的軟件過程進行有效的改進。

　　軟件能力評價是（Software Capability Appraisal）用來判斷有意承擔某個軟件項目的軟件組織的軟件過程能力，或是判斷已進行的軟件過程所處的狀態是否正確或是否正常。

　　軟件工程組（Software Engineering Group）：負責一個項目的軟件開發和維護活動的團體。活動包括需求分析、設計、編碼和測試等。

　　軟件相關組（Software Related Groups）：代表一種軟件工程科目的團體，它支持但不直接負責軟件開發或維護工作，如軟件質量保證組、軟件配置管理組合軟件工程過程組等等。在CMM的關鍵實踐中，軟件相關組通常應該根據關鍵過程域和組織的上下文來理解。

　　軟件工程過程組（Software Engineering Process Group）：是由專家組成的組，他們推進組織采用的軟件過程的定義、維護和改進工作。在關鍵實踐中，這個組織通常指“負責組織軟件過程活動的組”。

　　系統工程組（System Engineering Group）：是負責下列工作的個人的團體：分析系統需求；將系統需求分配給硬件、軟件和其他成分；規定硬件、軟件和其他成分的界面；監控這些成分的設計和開發以保證它們符合其規格說明。

　　系統測試組（System Test Group）：是一些負責策劃和完成獨立的軟件系統測試的團體，測試的目的是為了確定軟件產品是否滿足對它的需求。

　　軟件質量保證組（Software Quality Assurance Group）：是一些計劃和實施項目的質量保證的團體，其工作目的是保證軟件過程的步驟和標準是否得到遵守。

　　軟件配置管理組（Software Configuration Management Group）：是一些負責策劃、協調和實施軟件項目的正式配置活動的團體。

　　培訓組（Training Group）：是一些負責協調和安排組織培訓活動的團體。通常這個組織負責準備和講授大多數培訓課程并協調其他培訓方式的使用。

二、 CMM 的基本框架

　　任何一個軟件的開發、維護和軟件組織的發展離不開軟件過程，而軟件過程經歷了不成熟到成熟、不完善到完善的發展過程。它不是一朝一夕就能成功的，需要持續不斷的對軟件過程進行改進，才能取得最終的成效。CMM就是根據這一指導思想設計出來的。該模型為了正確和有序地引導軟件過程活動的開展，建立一個能夠有效地描述和表示的軟件過程的改進框架，使其能夠對各階段軟件過程的任務和管理起指導作用。該模型一產品質量的概念和軟件工程的經驗教訓為基礎，指導企業如何控制開發、維護軟件的生產過程和如何制定一套與之相適應的軟件過程及管理體系。

（一）分級標準

　　CMM模型描述和分析了軟件過程能力的發展程度，確立了一個軟件過程成熟程度的分級標準，如圖1示。一方面軟件組織利用它可以評估自己當前的過程成熟度，并以此提出嚴格的軟件質量標準和過程改進的方法和策略，通過不斷的努力去達到更高的成熟程度。另一方面，該標準也可以作為用戶對軟件組織的一種評價標準，使之在選擇軟件開發商時不再是盲目的和無把握的。

圖 1 軟件過程成熟度的級別

　　CMM的分級結構可以描述為：

　?、?、初始級：軟件過程的特點是無秩序的，有時甚至是混亂的。軟件過程定義幾乎處于無章法和步驟可循的狀態，軟件產品所取得的成功往往依賴于極個別人的努力和機遇。

　?、凇⒖芍貜图墸阂呀⒘嘶镜捻椖抗芾磉^程，可用于對成本、進度和功能特性進行跟蹤。對類似的應用項目，有章可循并能重復以往所取得的成功。

　?、?、已定義級：用于管理的和工程的軟件過程均已文檔化、標準化，并形成了整個軟件組織的標準軟件過程。全部項目均采用與實際情況相吻合的、適當修改后的標準軟件過程來進行操作。

　?、?、以管理級：軟件過程和產品質量有詳細的度量標準。軟件過程和產品質量得到了定量的認識和控制。

　?、?、優化級：通過對來自過程、新概念和新技術等方面的各種有用信息的定量分析，能夠不斷地、持續地對促進過程進行改進。

　　除第一級外，每一級都設定了一組目標，如果達到了這組目標，則表明達到了這個成熟級別，自然可以向下一級別邁進。CMM體系不主張跨級別的進化。因為從第二級開始，每一個低級別的實現均是高級別實現的基礎。

（二）CMM的主要內容

　　CMM為軟件企業的過程能力提供了一個階梯式的進化框架，它采用分層的方式來解釋起組成部分，如圖2示。在第二至第五個成熟等級中，每個等級包含一個內部結構的概念，關于內部結構詳細描述將在下面CMM內部結構的一欄中進行。

圖 2 CMM的五個成熟等級

　　每一級向上一級邁進的過程中都有其特定的改進計劃，具體情況如下。

　　初始級的改進方向是：建立項目過程管理，是使規范化管理，保障項目的承諾；艷進行需求管理方面的工作，建立用戶域軟件項目之間的溝通，使項目真正反映用戶的需求；建立各種軟件項目幾乎，如軟件開發計劃、軟件質量保證計劃、軟件配置管理計劃、軟件測試計劃、風險管理計劃及過車改進計劃等；積極開展軟件質量保證活動（SQA）。

　　可重復級的改進方向是：不再按項目制定軟件過程，而是總結各種項目的成功經驗，使之規則化，把具體經驗歸納為權組織的標準軟件過程，把改進軟件組織的整體軟件過程能力的軟件過程活動，作為軟件開發組織的責任；確定全組織的標準軟件過程，把軟件工程及管理活動集成到一個穩固確定的軟件過程中，從而可以跨項目改進軟件過程效果，也可以作為軟件過程剪裁的基礎；建立軟件工程過程小組（SPEG）長期承擔評估域調整軟件過程的任務，以適應未來軟件項目的要求；積累數據，建立組織的軟件過程庫及軟件過程相關的文檔；加強培訓。
已定義級的改進方向是：著手軟件過程的定量分析，已達到定量地控制軟件項目過程的效果；通過軟件的質量管理達到軟件質量的目標。

　　已管理級的改進方向是：防范缺陷，不僅在發現了問題能及時改進，而且應采取特定行動防止將來出現這類缺陷；主動進行技術改革管理、標識、選擇和評價新技術，是有效的新技術能在開發組織中實施；進行過程變更管理，定義過程改進的目的，經常不斷地進行過程改進。

　　優化級的改進目方向是：保持持續不斷的軟件過程改進。

（三）CMM的內部結構

　　CMM為軟件過程能力的提高提供了一條改進的途徑。CMM由5個成熟度等級組成，每個成熟度等級有著各自的功能。除第一級外，CMM的每一級按完全相同的內部結構構成的，如圖3。成熟度等級為頂層，不同的成熟度等級反映了軟件組織的軟件過程能力和該組織可能實現預期結果的程度。

圖3 CMM的內部結構圖

　　在CMM中，每個成熟度等級（第一級除外）規定了不同的關鍵過程域，一個軟件組織如果希望達到某一個成熟度級別，就必須完全滿足關鍵過程域所規定的要求，即滿足關鍵古城域的目標。每一級的關鍵過程域的詳細情況見表1。

表1 關鍵過程域的分類

（四）軟件過程評估和軟件能力評價

　　軟件過程評估所針對的是軟件組織自身內部軟件過程的改進問題，目的在于法子按缺陷，提出改進方向。評估組以CMM模型為指引調查、鑒別軟件過程中的問題，翻過來將這些問題與CMM關鍵實踐活動所提出的指導一起用于確定組織的軟件過程改進策略。

　　軟件能力評價是對接受評價者在一定條件下、規定時間內能否完成特定項目的能力考核，即承擔風險的系數大小。評價包括承包者是否有能力按計劃開發軟件產品，是否能按預算完成等。通過利用CMM模型確定評價結果后，就可以利用這些結果確定選擇某一承包商的風險。也可以用來判斷承包者的工作進程，推動他們愛進軟件過程。
CMM為評估和評價提供了一個參考框架，指出了在評估和評價中通常采用的佛農步驟，如圖4示。

圖 4 軟件過程評估和軟件能力評價的步驟

　　具體來說，評估過程是：選擇一個工作組；完成問卷調查和取樣工作；結果分析；現場訪問；與CMM模型對照分析；依據關鍵過程域的基本情況列出評估提綱。以上步驟在軟件過程評估和軟件能力評價題勾勒很有參考價值的方法，但在具體操作時以下這些特點也值得考慮：

　　①、在現場訪問和考察中，充分運用成熟度問卷和結果分析為依據。

　?、?、以CMM模型作為現場調查的路線圖。

　?、?、利用CMM中的關鍵過程域定義軟件過程中的優點和缺陷，從中發現差異。

　　④、對關鍵過程域目標是否備滿足的實際情況出發，分析滿意程度，寫出書面報告。

　　盡管軟件過程評估和軟件能力評價有很多相似之處，但由于其目的和結果的不同，它們之間的差異也是必然存在的，如：

　?、?、軟件過程評估和軟件能力評價在出發點和目標上的不同，使得會談目的、調查范圍、收集的信息和輸出的表示方式上有著本質的不同。尤其在一些細節規范方面，評估和評價的方法有很大差異。

　　②、軟件過程評估和軟件能力評價的結果和結果所起的作用不同。因為兩者的側重點不一樣，即使是對同一個應用項目，運用相同的方法，也不會得出相同的結果。

　　③、被評估和評價單位的態度對評估和評價活動的影響。評估在某種意義上被評估單位的態度較積極，而評價在某種意義上被評價單位的態度可能比較慎重。軟件過程評估是在一個開放的、互相協作的環境中進行的，而軟件能力評價往往是在有較大的阻力的環境中進行的。

（五）CMM的組織保證

　　當人們面對CMM實施時，首先想到的就是人員的構成和各種小組的劃分。它是實施CMM的組織保證，是一切活動的基礎。CMM在制定軟件過程實施中本著盡量不和具體的組織機構和組織形式相聯系的原則，為的是提供一個獨立于具體企業而又有廣泛指導意義的模型框架。但在實施各種軟件關鍵實踐中，不可避免地要涉及到角色和組織結構。所以為了使CMM能夠使用域各種級別和各種規模的企業，SEI提出了一個相對抽象的組織結構，它與組織、項目、人員（角色）相關聯，具有自己特定的術語，而且可能不同于其他組織所用的名詞。例如基本概念中提到的主要的軟件工作組的概念。

三、 正確的態度看待CMM

　　SEI的CMM并不是軟件開發的方法學，也不是產品模板，更不是過程法律。CMM是過程改進的途徑，是一套指南，幫助你通過持續的重復、測量和提煉，穩步創造與凈化開發環境。CMM的假定是：如果你實施一個不斷重復、測量和提煉的大綱，作為環境改進的副產物，質量便會自然的提高。不要把CMM設想為一套規則，而應將它理解為一個學科，做事的一般方法。在這套指南下運作，你會發現這里有著廣闊的空間，讓你剪裁和塑造自己的大綱，以適應組織的特定要求。

　　CMM不采用“用這種方法做這類事”的風格，它也不對由問題的IT組織提供快速的糾正方案。CMM是一個指南針，指導你如何逃離暴風雪。CMM是一個大綱，要求你對整個IT組織的有關部分，從高層領導到軟件生產的第一次線工作者，都做出堅定的、長期的實施承諾。成熟的過程不可能在已也之間實現。

　　在如何解釋CMM建議時，它允許極大的靈活性。CMM意識到，IT組織之間存在著很大的差別。他們的客戶不同，使用的工具不同，人員智力和專業背景不同，從事的項目屬于不同的類型，規模大小不同，要求也各不相同。因而，他們應當以自己的方式走向成熟。在一處活用的東西，在另一處未必適用。這一點非常重要，中國部分軟件公司的前車之鑒也從某種程度上給了我們建議和經驗教訓，那就是，要靈活應用CMM，不要幻想一夜就有成效。

小結

　　本文只是根據這兩年的試題和自己的預測向廣大系分考友提供一些CMM方面的知識。CMM不是重點，但也有可能會考到一些知識，如基本概念等。在搜集資料和整理著篇文章時，遇到了一個矛盾，那就是：我要提供足夠的資料以使讀者不必花費金錢再去買一本書就可以復習有關CMM的知識，而同時又不能放太多的內容使讀者浪費太多的時間在這上面。最后采取了一個折衷的辦法，那就是盡量滿足考試需求的情況下減少篇幅。在此聲明，本文所涉及的內容只是本人的預測，并不是說考試范圍不會超過本文的內容。所以有時間的朋友還是盡可能的擴大這方面知識面。希望這篇文章對你有幫助，謝謝。

不同于單機游戲和網絡游戲，Flash游戲大多為休閑型的小游戲。盡管如此，不少可玩性很高的Flash游戲還是會讓我們津津有味的玩上一整天。這里有10款老外們選出來的最容易上癮的Flash游戲，準備好沉迷吧。

01 - Bejeweled

訪問：10款最容易上癮的Flash游戲

所謂“80后”，是指22~27歲之間、受過高等教育、剛剛畢業走向社會或者擁有幾年工作經驗年輕的一代。
不可否認，“80后”已成為職場上迅速成長的中豎力量，尤其是在國內的研發領域。每個時代都有自己的特點，如果用幾個比較典型的正面詞句形容他們應該是：聰明、有主見、有能力。
那身為“80后”的技術人員找工作為什么還這么難呢？ 因為，還可以用幾個比較典型的負面詞句形容他們：缺乏責任感、定位不清、困難而退。

從參加面試看責任感

    就拿面試這件事來說吧，流程大多是：電話簡單溝通，約時間?初試（開發人員多是筆試）?復試?確認薪水、上班時間入職。

    十一長假之前的一周，某公司約候選人參加研發筆試、面試。在約面試的電話里，公司特別強調如果您本周不方便（很多候選人會回老家），我們可以把筆試（面 試）安排在十一之后進行。有12人在電話里說可以到公司參加筆試，令人失望的是，筆試當天只來了3位，其余8人在未做任何說明的情況下沒有出現。

    因為開發人員是所有應聘者中素質最高的群體，公司前臺打電話向每個未到的候選了解原因，看看是在電話里沒說清地址，還是別的什么原因，導致了大家的缺席。最終的反饋是：2人電話不接、2人電話關機、4人臨時有事。

……

    每次與公司技術負責人或者HR溝通，”80后”的職業素質都會成為核心話題之一。而缺乏責任感又是最經常被提到的。候選人認為面試不來，對自己只不過是少 個求職機會而已，公司則認為這件事足以體現候選人對工作沒有責任心。有這種品質在身，很難讓我們在事業上有什么建樹。

    所謂一花一世界，求職過程中任何點上體現出缺乏責任感都會被馬上淘汰。公司的邏輯是：如果不負責任的人進了公司，那么造成的損害絕不止耽誤時間這么簡單，很可能是項目的延誤甚至是失敗。

   不可否認，現在就業壓力大，大部分人都對求職抱的態度都是普遍撤網重點培養。得到面試通知后，發現公司離家太遠或者剛好被另一家錄用的事兒時有發生。“中國這么大，接到面試不去的又不是我一個，沒什么大不了。”也是很多人的正常想法。

    我們回頭看看這種行為給同齡人帶來的傷害吧——由于相當部分”80后”技術人員在面試給人留下沒有責任感的印象，很多公司規定關鍵崗位不用25歲以下人 士。更有甚者，因為幾個人的原因，某學校的畢業生在公司都成為不約見面試的對象。也許我們已找到工作，安然自得，但同齡人呢？校友呢？是否有必要更多考慮 一下。

   其實，比默默消失更恰當的處理方式有很多，這不但能體現自身素質、節省雙方時間，還能為自己贏得機會。比如：

   可以在電話里直接說因為路遠、已有工作機會希望下次合作，即禮貌回絕（這樣節省雙方時間）；

   也可告訴HR時間不方便，能否另外安排時間（相信任何智力正常的公司HR相信都會另行安排溝通時間）；

   如果能在得知是哪家公司通知我們面試之后，能說出公司的情況，必然能在面試之前為我們自己加分。只需要事先做小小功課，上網看一下公司介紹即可。（體現我們的高素質）。

    如此，即會豎立”80后”的風采，也會被冠以XX學校畢業生素質高的贊譽，何樂而不為！

從談薪水看自我定位

    80年代的研發候選人對自己的認識常走兩個極端，要么瘋狂自信、要么超級自卑，歸根到底還是對自己的認識不清楚，難以準確定位自己、定位自己在群體中的地位。很多候選人因此失去了機會。

瘋狂自信

    只在公司工作三周即被辭退的小F

     擁有2年的JAVA開發經驗的F面試時向公司要求5K薪水。此時的他自信滿滿。“我就值這么多！”這是F在談及薪水時說的一句話。

    公司方面綜合筆試、面試的結果，給出的薪水范圍是3K——4K。

    HR：“公司希望你能在工作中證明自己的能力。試用最多能提供3K的薪水，如果能順利轉正，我相信薪水會達到您的要求。這樣可以嗎？”
F：“行吧。希望公司能信守承諾。”

    只是短短的3周之后，F就被公司解聘。理由很簡單，水平不足、學習能力一般，加之對自己不切實的定位導致了眼高手低。部門最后的意見是：此人工作中的能力不足，短期內也很難提高，建議此人即刻解聘。

    自信，也請以能力為基礎！

超級自卑

    自信相對的是自卑。談及薪水。很多候選人以“在這兒生活費太貴，公司支付的薪水要滿足生活吧！”為理由提出薪水要求。而不是從能給公司做出什么貢獻、如何體現自身價值為出發點提出薪水要求。

    這背后反映的是“我不知道自己為什么應該拿這么多錢！我也不知道自己值多少！為什么值！”

    無論是瘋狂自信，還是超級自卑，技術管理層普遍對此有一個共識——不能認清自己的人，干好工作的機率和效率都會很低。定位不清的候選人很難被錄用，企業認為與其找這種人來拖項目后腿，不如不用。

    不像歐美國家，開發人員職業發展穩定、有明確的晉升路線，做為快速發展的社會國內形式變化太快，很多時候我們無所適從也是客觀條件導致，比如：今天還在做開發，明天可能就被轉去支持銷售成為售前等等。很多時候，我們對自己不是不想定位，是無法定位。

    掌握下面一些基本方法，也話讓我們機會給自己相對準確的定位。

   1. 先按以下渠道了解市場價

   向資力相當、已找到工作的朋友詢問薪水情況（大概范圍即可），從而了解自己平均市值；
請教自己的師兄、師姐，能力出從的他們一定已工作有成，從他們那里可以掌握薪水幾年后的增長情況。

    2. 正確估價

   了解目前自己同齡人的薪水之后，給自己估個起薪（原則是：比你自己認為的薪水，至少低一檔。掌握全面信息之后，我們反而可能傾向于高估自己的價格），然后向應聘公司咨詢入職幾年后的薪水增長情況，最終做綜合判斷。

入職即閃看對待困難的態度

    下面說說最讓部門經理和HR感到瘋狂的事吧——入職即閃。

    這也是最讓公司發瘋的事之一。

    求職過程中，無論是公司，還是候選人都付出了時間成本、精力成本，雙方確定合作意向之后，候選人入職成為了公司正式員工。求職時信誓旦旦的候選人，只工作了1周（1天）就一聲不吭地離開了公司，當被問及理由時，多回答：“工作不適合自己”。

    應該說這個理由是對公司和候選人自己的極大嘲弄——雙方都缺乏判斷力，公司不知道應該找什么樣的人加盟，候選人不知道真正來干什么、什么是適合自己的。

    以上現象的原因可能有：

工作壓力大

    社會競爭的加劇導致了每個公司必須全力做到最好，才有可能生存。公司面臨的壓力，在工作中被完全轉嫁給員工。但剛剛走出校門的”80后”沒有做好這方面的 準備，巨大壓力撲面而來的時候感覺不知所措，比如：入職第一天簡單培訓之后就開始代碼的編寫或者對產品的支持，更多的東西要在工作中學。
很多人說“80后”像草莓，表面看起來很光鮮，但不能碰、也不能壓。這也許是真的，但更重要的是處事的方法。

遇到壓力、困難，沒有正確解決方法

    因為只要工作，都會有壓力，大小不同而已。逃避無疑是面對壓力時，成本最低的方法，但長遠來看也是代價最高的方法。

   “入職即閃”的離開，不會令公司感到惋惜。試想公司是不愿意請不能正確面對和處理壓力的人加盟的。
當然，很多公司沒有完善的入司 管理制度，培訓不到位，新人入職不安排專人帶領熟悉情況是絕大部分公司存在的問題。這導致了工作中遇到的困難比想向的大、遇事找不到或者沒有正確解決方 法，于是造成了離職。這可能也是很多人原因進500強的原因，有完善的培訓、升職、薪酬體系。

     關于處理壓力的方法我們先分享下面的故事。

    某家長常教育孩子做事要竭盡全力，一天孩子與父母出門，發現路邊石頭很漂亮，想搬塊大石頭回家收藏，抱起之后走了一段路，因為石頭太重搬不動了。雖然舍不 得，但已沒有力氣，孩子準備放棄。此時，父親到流淚的孩子身邊問：“做事不是要盡全力嗎？”孩子回答：“確實沒有力氣了。”“有啊！”父親邊說，邊抱起石 頭大步走向家的方向，“！永遠不要忘記，我也是你力量的一部分！”

    工作中，在我們盡力之后，還有無法處理的困難、無法面對的壓力，那么向更有經驗的同事、朋友請教是個好方法。相信我們的現在正是他們的昨天，我們正在經歷的他們都經歷過，在如果正確應對和處理方面，他們一定會特別愿意分享經驗、幫助我們。

    無法處理時，救助可能是最好的方法。不要害怕說出“幫我一下！”這句話。

    在成長型的公司里，大家互相幫助會成為一種習慣，成為一種企業文化。相信這種文化也是“80后”一代所期望的。大家一起面對壓力、處理問題會比一個人獨自解決問題用時更短、效率更高。

寫在最后的話

     以上事件中出現的候選人均為“80后”。曾經有人說，不要以時間來劃分人，因為每個人的情況都有不同。與此同時，我們更應該承認：每一個時代的人都有自己的共同社會背景和大環境，這些東西造就了很多共同的特征。所以，“60后”、“70后”、“80后”這樣的劃分為我們的判斷提供了基礎。

    在經歷了3000場面試之后，我可以肯定地說，與同齡人相比“80后”的技術人員給公司HR留下的印象是：更具可素性、擁有更高的可信度、更有潛力。他們正在（已經）成為技術隊伍中的生力軍！
面對壓力大、社會變化快，尤其是開發知識不斷更迭的新一代職場人，必然要磨礪出比上一代更有效的方法正確應對。這是社會發展的要求，應該也是我們自我提高的必由之路。

下載方法：不能直接用下載工具下載，要先進入頁面，然后點擊下載，就可以用迅雷等下載工具下載了：

1、Addison Wesley.Core Javaserver Faces
http://cid-220e2223d106b456.skydrive.live.com/self.aspx/Public/JSF/Addison%20Wesley.Core%20Javaserver%20Faces%20Jun%202004.chm.rar

2、Manning.JavaServer.Faces.in.Action
http://cid-220e2223d106b456.skydrive.live.com/self.aspx/Public/JSF/Manning.JavaServer.Faces.in.Action.pdf.rar

3、Appress Pro JSF and Ajax Building Rich Internet Components
http://cid-220e2223d106b456.skydrive.live.com/self.aspx/Public/JSF/Apress.Pro.JSF.and.Ajax.Building.Rich.Internet.Components.Feb.2006.pdf.rar

4、OReilly.JavaServer Faces JSF
http://cid-220e2223d106b456.skydrive.live.com/self.aspx/Public/JSF/OReilly.JavaServer%20Faces%20JSF.rar

5、Wiley.Mastering.JavaServer.Faces
http://cid-220e2223d106b456.skydrive.live.com/self.aspx/Public/JSF/Wiley.Mastering.JavaServer.Faces.Jun.2004.pdf.rar 1、live.com，將瀏覽器的語言改為en-us，通過下面的鏈接進入：
http://get.live.com/en-us/wl/signup

2、live.cn，將瀏覽器語言改為zh-cn，通過下面的鏈接進入：
http://get.live.com/getlive/overview

01、Eclipse中使用正則表達式進行多行替換
02、JSEclipse，加速Eclipse下的JavaScript開發
03、全面解析腹部鍛煉四誤區
04、了解 Java EE 5
05、在 Eclipse Help 中如何組織 Java API 參考文檔
06、uml時序圖