2012軟件設計師復習的綜合資料

1、 上學吧（）第 PAGE183 頁，共 NUMPAGES183頁上學吧為您提供“軟件設計師”資料下載：http:/ 在遠古的堯、舜時代，黃河流域經(jīng)常發(fā)生了大水災，洪水橫流，五谷不收，家破人亡。所以堯派鯀去治水，鯀沿用了過去的傳統(tǒng)法子，水來土擋，用土筑堤，堵塞漏洞。但由于洪水兇猛，不斷沖擊土墻，結果弄得堤毀墻塌，洪水反而鬧得更兇了。鯀治水九年，勞民傷財，并沒有把洪水制服，是一事無成。 舜接替堯后，就把鯀辦罪處死，隨后命鯀的兒子禹繼續(xù)治水。大禹領命之后，尋找到了以前治水失敗的教訓，最后決定用疏導的辦法來治理水患。大禹帶領百姓是鑿了一座又一座大山，開了一條又一條河渠，把黃河的主流加深加寬，把支流疏通

2、與主流相接。同時，把原來的高處培修得更高，把原來的低地疏濬得更深，便自然形成了陸地和湖澤。把這些大小湖澤與大小支流連結起來，洪水就能暢通無阻地流向大海了。 相傳大禹三過家門而不入，把整個身心都用在開山挖河的事業(yè)中。大禹用疏導的辦法治水終于獲得了成功。大禹治水，為民造福，永受華夏子孫所稱頌，永為炎黃后裔所懷念。 集成與構件 “集成”是看到了信息化建設中的一個個信息孤島，數(shù)據(jù)不能交換，資源不能共享，業(yè)務不能協(xié)同，如同洪水泛濫一樣。傳統(tǒng)的應用集成EAI是典型的“堵”法，可以說總是在事后解決問題，是頭痛醫(yī)頭、腳痛醫(yī)腳，治標不治本的辦法。碰到了集成問題，才去想辦法去解決,而解決眼前問題的同時又帶來更多和

3、更復雜的其它集成問題。所以，就如同鯀治水一樣，鯀沒有把洪水制服，EAI當然也不可能從根本上解決信息資源共享利用的問題。 因此解決信息孤島，要學大禹治水，“疏”比“堵”更重要?！岸隆笔且粫r的、眼前的，“疏”是長遠的，一勞永逸的。與集成的事到臨頭相比，構件就是“疏”的方法，是從源頭上去堵。在構件體系下，信息資源將按標準、有層次的通過構件展開，數(shù)據(jù)是構件、展現(xiàn)是構件、流程是構件、服務是構件，一切皆構件。好比大禹治水，開山鑿渠是構件庫，主流支流是大小構件，貫通無阻是統(tǒng)一標準。 所以，構件可以實現(xiàn)信息資源的大“治”，用計算機術語來講，就是“同構”，標準統(tǒng)一，架構統(tǒng)一，建設統(tǒng)一，管理統(tǒng)一，開發(fā)、部署、運行

4、與維護實現(xiàn)同構，信息孤島從設計源頭上被消滅。 從測試角度看用戶手冊在軟件質量中的地位 對于軟件，開發(fā)者往往只注意到其功能和性能，而忽略了用戶手冊。其實用戶手冊也是衡量軟件好壞的一個重要標準。好的用戶手冊可以幫助用戶快速入門，是用戶正確、充分使用軟件的前提。對于開發(fā)者來說，好的用戶手冊可以減少培訓和售后服務的費用。所以在測試中，不能忽略用戶手冊的重要性，應從以下多個方面考察用戶手冊的質量。 用戶手冊的完整性重點考察用戶手冊內容的全面性與完整性，從總體上把握用戶手冊的質量。這一項看似簡單，但在實際測試中我們發(fā)現(xiàn)，很多開發(fā)商還是無法做到這一基本標準。很多軟件由于開發(fā)過于倉卒，在付諸使用時，用戶手冊中

5、缺少關于某些模塊的說明，讓用戶使用起來比較困難。在測試工程師的眼里，優(yōu)秀的用戶手冊內容應該是包括軟件的所有功能模塊。 用戶手冊的描述與軟件實際功能的一致性考察用戶手冊與軟件實際功能的一致程度。當確認用戶手冊基本完整后，我們還要注意用戶手冊與實際功能描述是否一致。這種問題往往是由用戶手冊跟不上軟件版本的更新速度造成的。對用戶來說，容易造成對描述不一致的功能的誤解和苫螅?進而影響用戶對軟件的使用。優(yōu)秀的用戶手冊應該根據(jù)軟件的升級而及時更新，手冊描述應該與軟件實際功能保持一致。 用戶手冊的易理解性考察用戶手冊對關鍵、重要的操作有無圖文說明，文字、圖表，是否易于理解。對于關鍵、重要的操作僅僅只有文字說

6、明肯定是不夠的，應該附以圖表使說明更為直觀、明了。優(yōu)秀的用戶手冊應該是圖文并舉，易于理解。 用戶手冊提供學習操作的實例考察對主要功能和關鍵操作提供的應用實例是否豐富，提供的實例描述是否詳細。當前大量軟件的用戶手冊只有簡單的圖文說明，而無應用實例。這樣的用戶手冊看起來就像是軟件界面的簡單拷貝，對于用戶來說，實際上沒有什么幫助。例如財務軟件，用戶手冊就應該提供具體建帳實例及具體帳務處理的實例，這樣才能使用戶看完用戶手冊后，能夠獨立完成新帳套的建立并逐漸學會使用軟件處理帳務信息。優(yōu)秀的用戶手冊不僅要對主要功能和關鍵操作提供應用實例，而且對實例的描述應做到詳細、充分，易于用戶理解。 用戶手冊的印刷與包

7、裝質量考察用戶手冊包裝的商品化程度，印刷質量。有些用戶手冊是簡單打印、裝訂而成，過于粗糙，不易于用戶保存。優(yōu)秀的用戶手冊應提供商品化包裝，并且印刷精美。軟件的質量是由各個方面構成的，用戶手冊就是其中重要的一環(huán)。特別是在當前軟件業(yè)快速增長的時期，軟件開發(fā)者過于注重功能與性能而忽略用戶手冊，使得用戶手冊的質量問題尤顯突出。所以對于測試人員應該充分認識到用戶手冊的重要性，嚴把用戶手冊的質量關，以促使軟件整體質量有一個提高。 從菜鳥到大師細看程序員的五種層次軟件界一個無可爭議的事實是，不同程序員的效率有差別，而且差別很大。許多專家將優(yōu)秀程序員和一般程序員區(qū)分地很清楚。大多數(shù)研究得出結論認為，一般程序員

8、跟優(yōu)秀程序員之間在工作效率和質量上存在10：1的關系：優(yōu)秀程序員和水平較差的程序員的編碼時間比例為1：20；debugging時間比為1：25；代碼數(shù)量比是5：1；程序執(zhí)行速度比例是10：1。而且發(fā)現(xiàn)，程序員的代碼質量和效率跟工作經(jīng)驗沒有關系。讓我們看看一些軟件大腕們是如何看待優(yōu)秀程序員和一般程序員的：Randall E. Stross：無論是從軟件標準、創(chuàng)造性、開發(fā)速度、還是設計思路或者解決問題的能力上來說，優(yōu)秀程序員比差的程序員都何止好一點。Bill Gates：一個優(yōu)秀的機床工值一個一般機床工的好幾倍，而一個優(yōu)秀程序員值一個一般程序員的10000倍。Robert C. Martin：90

9、%的代碼是由10%的程序員寫出來的。程序員因此被分為五大類：1. 大師級程序員（Visionary/Artist Programmer/）大師級程序員是軟件界絕對的稀有種族，他們可以創(chuàng)造出99.9%的程序員所創(chuàng)造不出來的東西。他們發(fā)明新的應用和軟件模式來驅動軟件產(chǎn)業(yè)的發(fā)展。Napster, Netscape以及World Wide Web都是大師級程序員創(chuàng)造的。對他們而言，軟件更多的是藝術而非科學。在這個級別，速度和質量不是最重要的，他們創(chuàng)造出的財富才是最重要的。許多開發(fā)團隊或者公司頂多也就一個大師級程序員，通常是這個公司的技術創(chuàng)始人或者CTO。2. 開拓者程序員（Trailblazer Pr

10、ogrammer）開拓者程序員通常帶來很好的主意和趨勢。他們通常是最終產(chǎn)品的原型創(chuàng)作者，他們一天做出的事情大部分程序員需要幾周甚至幾個月。開拓者程序員總是在嘗試新工具、新技術，不斷地學習和搜尋方法來提高工作效率，并通常是其他程序員的導師和老師，而且你經(jīng)常會發(fā)現(xiàn)當其他程序員早已離開的時候他們卻依然工作到深夜。盡管這樣級別的程序員工資很高，但是每個成功的公司或團隊還是應該配備一兩個開拓者程序員。3.骨干程序員（ Workhorse Programmer）骨干程序員是一個公司或者開發(fā)團隊的脊柱，這些人盡管不是很有創(chuàng)新性，但往往比較高效且值得信賴。給一位骨干程序員一套模板和合適的工具，他們總能以最短的

11、時間交出錯誤最少的代碼。4.機械程序員（ Drone Programmer）許多程序員就是朝九晚五地為了填塞下自己錢包的機械程序員。他們不愿意接觸新技術、避免學習新事物。許多公司或者開發(fā)團隊都有許多這樣的機械程序員，因為他們很便宜，但豈不知更貴的程序員才真正地更便宜。5.白癡程序員（ Idiot Programmer）林子大了什么鳥都有，軟件領域也不例外。編程需要抽象和邏輯思維，然而一些尚不具備此能力者由于向往著不錯的薪水而加入了該領域。白癡程序員總是對最簡單的算法也搞不清楚，他們總是錯過軟件截止日期，終日無所獲。白癡程序員最好的出路就是換行。 從三十六計看軟件測試之計1三十六計是根據(jù)我國古代

12、卓越的軍事思想和豐富的斗爭經(jīng)驗總結而成的兵書，古人用兵最講究謀略，在中國古代戰(zhàn)爭史上，精彩的謀略計策層出不窮，令人眼花繚亂，但萬變不離其宗，大抵都逃不過這三十六計的范圍。時至今日，“三十六計”在我們日常的工作和生活中，同樣可以有很廣泛的應用。我是一名軟件測試工程師，并熱愛軟件測試這一職業(yè)，目前從事測試已有一段時間，我很愿意將自已在從事軟件測試工作中積累的一些經(jīng)驗，以及一些心得體會，借助三十六計中的若干計謀加以說明，與諸位同行分享。總說【原文】 六六三十六，數(shù)中有術，術中有數(shù)。陰陽燮理，機在其中。機不可設，設則不中。 【解析】“兵以詐立”，多謀者勝。用兵要講究謀略，“運籌帷幄，決勝千里之外”。同

13、樣的道理，無論從事什么樣的工作，都需要講究方式、方法。有了正確的方式方法，或者適時的運用一些小技巧，往往可以收到事半功倍的奇效。第一計瞞天過?！驹摹?備周則意怠；常見則不疑。陰在陽之內，不在陽之對。太陽，太陰。 【譯文】 防備周全時，更容易麻痹大意；習以為常的事，也常會失去警戒。秘密潛藏在公開的事物里，并非存在于公開暴露的事物之外。公開暴露的事物發(fā)展到極端，就形成了最隱秘的潛藏狀態(tài)。 【解析】long,long ago,there is a 很厲害的程序員，名叫關羽，他是計算機專業(yè)科班出身，又擁有二十幾年的編程開發(fā)經(jīng)驗，是當之無愧的資深軟件工程師。雖然關羽的專業(yè)水平無庸置疑，但是他有一個缺點

14、，就是自視過高，驕傲不可一世，他常常認為自己寫的代碼十分完美，幾乎已經(jīng)到了自戀的程度。他看不起測試人員，對他們提出的程序錯誤不僅不屑修改，甚至于不肯承認，并經(jīng)常與測試人員起爭執(zhí)。有一年他在湖北荊州負責一個十分重要的大型系統(tǒng)的開發(fā)，而負責這個系統(tǒng)測試工作的正是關羽向來都瞧不起的呂蒙。這個呂蒙原本學歷不高，只有中專文化程度，并且還不大注重學習，提高自己的能力。直到有一次被他的上司孫權教育了一頓，從此發(fā)奮圖強，進步神速，技術能力迅速提高，早已不是當日的吳下阿蒙。起先呂蒙將發(fā)現(xiàn)的錯誤上報給關羽，關羽并不理會，還是如同以往一樣，找出許多理由來搪塞，一會兒說這是個技術難點，無法修改，一會兒又說這是當初的需

15、求沒有寫清楚。這呂蒙早就清楚關羽的為人，從此也不與關羽多加爭辯，只是兢兢業(yè)業(yè)的做著自己的工作，將自己在測試過程中發(fā)現(xiàn)的所有小錯誤一一如實記錄了下來。等到測試報告出來的時候，關羽傻了眼。由于他一時疏忽而犯下的一個小錯誤，并且錯誤擴散到整個系統(tǒng)的每個角落，已經(jīng)無法修改?？蛻舸鬄椴粷M，項目終于失?。《习逡粴庵乱舶殃P羽炒了魷魚。關羽的一世英名就這樣毀在自己的大意上面。這就是在IT業(yè)界流傳很廣，十分有名的“關羽大意失荊州”的故事。從這個故事中我們可以得到以下幾個教訓：1、越是厲害的人物，越容易陰溝里翻船，水平很高的程序員，也很容易因為不注意細節(jié)而犯下一些低級的錯誤。所以身為一名測試者，不能迷信權威或

16、專家，對就是對，錯就是錯，要勇于懷疑一切。時刻牢記我們代表的是最終用戶，并建立這樣一個觀點：即使一個錯誤不是程序本身的原因，而是因為操作不便而使用戶造成，嚴格說來，那仍然是一個錯誤。從三十六計看軟件測試之計22、測試者與開發(fā)者的地位是相對獨立，但絕不是勢同水火，雙方彼此同樣是項目組的成員，在保證軟件產(chǎn)品質量這個大方向上是一致的，彼此都應該互相尊重對方的勞動成果，虛心對待。關羽的直接領導諸葛亮早就告誡過他這一點，讓他一定要尊重測試組的勞動成果，不要雙方鬧翻?？申P羽硬是不聽，于是造成項目失敗。 3、在測試工作中，測試者與程序員的溝通是十分重要的。在雙方互相尊重的基礎上，彼此都要本著對事不對人的原則

17、，保持嚴謹?shù)目茖W態(tài)度，共同完成軟件的開發(fā)。上面的故事中，呂蒙的做法其實也不是十分的正確，不僅遭到了大量關羽的fans的指責，而且長久背負著做人不厚道的罵名，這些倒不重要，更為重要的是，最終整個系統(tǒng)、整個開發(fā)團隊失敗了，他同樣是個失敗者。更好的做法是在測試的工作中，就要注重溝通問題，當一個錯誤一直不被修改的時候，與開發(fā)人員溝通失敗后，應該及時上報給項目的管理者，盡早尋求解決的方法，而不是將錯誤一直留到測試結束后才暴露出來，此時的錯誤可能已經(jīng)造成十分嚴重的后果，測試報告寫得再漂亮也已經(jīng)沒有多大的意義?；谝陨详愒~，本庭宣判：本案關羽負主要責任，呂蒙負次要責任。關羽斬首，呂蒙打五十大板！_4、想要做

18、好測試工作，學歷和技術并不是最重要的，重要的是要有責任心和細心，中專畢業(yè)證書是中專學校發(fā)的，大學畢業(yè)證書是大學發(fā)的，而有了責任心和細心的測試員，就不再是普通的測試工程師，而是優(yōu)秀的測試工程師了。在開發(fā)一個軟件產(chǎn)品的過程中，每一個程序員都需要跟成千上萬行的代碼打交道，他們自己寫的代碼就像大寶SOD蜜一樣的天天見，看多了難免叫人頭昏眼花胸悶心煩再加上每天都看見的東西，很容易就會產(chǎn)生思維定式。一個人偶爾犯錯并不可怕，可怕的是他對錯誤熟視無睹，錯啊錯啊的就習慣了，于是很自然的把錯的當成對的。俗話說“老虎也有打盹的時候”，水平再高的程序員也會有犯錯誤的時候，因此必然會有一些錯誤和缺陷是很難被自身發(fā)現(xiàn)的，

19、其原因可能是他在閱讀需求規(guī)格的時候惦記著那天和女朋友吵架的事情開了小差，從而沒有好好地理解需求；也可能是他那天正好失戀心情不好而犯迷糊，更可氣的是他居然說女朋友都跟別人跑了我的程序寫得那么好有什么用，我偏要這么寫所以說沒有BUG的軟件是不存在的（否則廣大和我一樣的軟件測試工作者靠什么混飯吃？_）?！瓣幵陉栔畠?，不在陽之對”，我們那些無比智慧而英明的祖先在這里清楚的告訴我們，一個軟件產(chǎn)品中最大、最致命的BUG，往往不是如你想象的那么隱蔽、那么難找，而經(jīng)常是潛伏在你最沒有防備、以為最不可能出錯的那些地方。這便再一次的證明了這樣一個道理：在軟件的世界里，不是缺少BUG，而是缺少發(fā)現(xiàn)BUG的眼睛！初學

20、者福音C語言的編程風格 縮進格式 Tab是8個字符,于是縮進也是8個字符.有很多怪異的風格,他們將縮進格式定義為4個字符(設置為2個字符!)的深度,這就象試圖將PI定義為3一樣讓人難以接受. 理由是:縮進的大小是為了清楚的定義一個塊的開始和結束.特別是當你已經(jīng)在計算機前面呆了20多個小時了以后,你會發(fā)現(xiàn)一個大的縮進格式使得你對程序的理解更容易. 現(xiàn)在,有一些人說,使用8個字符的縮進使得代碼離右邊很近,在80個字符寬度的終端屏幕上看程序很難受.回答是,但你的程序有3個以上的縮進的時候,你就應該修改你的程序. 總之,8個字符的縮進使得程序易讀,還有一個附加的好處,就是它能在你將程序變得嵌套層數(shù)太多

21、的時候給你警告.這個時候,你應該修改你的程序. 大符號的位置另外一個C程序編程風格的問題是對大括號的處理.同縮進大小不同,幾乎沒有什么理由去選擇一種而不選擇另外一種風格,但有一種推薦的風格,它是Kernighan和Ritchie的經(jīng)典的那本書帶來的,它將開始的大括號放在一行的最后,而將結束大括號放在一行的第一位,如下所示: if (x is true) we do y 然而,還有一種特殊的情況:命名函數(shù):開始的括號是放在下一行的第一位,如下:int function(int x) body of function 所有非正統(tǒng)的人會非難這種不一致性,但是,所有思維正常的人明白: (第一) K&R

22、是_對_的,(第二)如果K&R不對,請參見第一條. (:-)另外,函數(shù)也是特殊的,不一定非得一致. 需要注意的是結束的括號在它所占的那一行是空的,_除了_它跟隨著同一條語句的繼續(xù)符號.如while在do-while循環(huán)中,或者else在if語句中.如下: do body of do-loop while (condition); 以及if (x = y) . else if (x y) . else 理由: K&R. 另外,注意到這種大括號的放置方法減小了空行的數(shù)量,但卻沒有減少可讀性.于是,在屏幕大小受到限制的時候,你就可以有更多的空行來寫些注釋了. 命名系統(tǒng)C是一種簡潔的語言,那么,命名也

23、應該是簡潔的.同MODULE-2以及ASCAL語言不同的是,C程序員不使用諸如ThisVariableIsATemporaryCounter之類的命名方式.一個C語言的程序員會將之命名為tmp,這很容易書寫,且并不是那么難以去理解. 然而,當混合類型的名字不得不出現(xiàn)的時候,描述性名字對全局變量來說是必要的了.調用一個名為foo全局的函數(shù)是很讓人惱火的.全局變量(只有你必須使用的時候才使用它) ,就象全局函數(shù)一樣,需要描述性的命名方式.假如你有一個函數(shù)用來計算活動用戶的數(shù)量,你應該這樣命名-count_active_users()-或另外的相近的形式,你不應命名為cntusr(). 有一種稱為H

24、ungarian命名方式,它將函數(shù)的類型編碼寫入變量名中,這種方式是腦子有毛病的一種表現(xiàn)編譯器知道這個類型而且會去檢查它,而這樣只會迷惑程序員. -知道為什么Micro$oft為什么會生產(chǎn)這么多臭蟲程序了把!. 局部變量的命名應該短小精悍.假如你有一個隨機的整數(shù)循環(huán)計數(shù)器,它有可能有i,如果沒有任何可能使得它能被誤解的話,將其寫作loop_counter是效率低下的.同樣的,tmp可以是任何臨時數(shù)值的函數(shù)變量. 如果你害怕混淆你的局部變量的名字,還有另外一個問題,就是稱function-growth-hormone-imbalancesyndrome. 函數(shù)函數(shù)應該短小而迷人,而且它只作一件事

25、情.它應只覆蓋一到兩個屏幕(80*24一屏),并且只作一件事情,而且將它做好.(這不就是UNIX的風格嗎,譯者注). 一個函數(shù)的最大長度和函數(shù)的復雜程度以及縮進大小成反比.于是,如果你已經(jīng)寫了簡單但長度較長的的函數(shù),而且你已經(jīng)對不同的情況做了很多很小的事情,寫一個更長一點的函數(shù)也是無所謂的. 然而,假如你要寫一個很復雜的函數(shù),而且你已經(jīng)估計到假如一般人讀這個函數(shù),他可能都不知道這個函數(shù)在說些什么,這個時候,使用具有描述性名字的有幫助的函數(shù). 另外一個需要考慮的是局部變量的數(shù)量.他們不應該超過5-10個,否則你有可能會出錯.重新考慮這個函數(shù),將他們分割成更小的函數(shù).人的大腦通?？梢院苋菀椎挠涀?

26、件不同的事情,超過這個數(shù)量會引起混亂.你知道你很聰明,但是你可能仍想去明白2周以前的做的事情. 注釋注釋是一件很好的事情,但是過多的注釋也是危險的,不要試圖區(qū)解釋你的代碼是注釋如何如何的好:你應該將代碼寫得更好,而不是花費大量的時間去解釋那些糟糕的代碼. 通常情況下,你的注釋是說明你的代碼做些什么,而不是怎么做的.而且,要試圖避免將注釋插在一個函數(shù)體里:假如這個函數(shù)確實很復雜,你需要在其中有部分的注釋,你應該回到第四章看看.你可以寫些簡短的注釋來注明或警告那些你認為特別聰明(或極其丑陋)的部分,但是你必須要避免過多.取而代之的是,將注釋寫在函數(shù)前,告訴別人它做些什么事情,和可能為什么要這樣做.

27、 你已經(jīng)深陷其中了. 不要著急.你有可能已經(jīng)被告之GUN emacs會自動的幫你處理C的源代碼格式,而且你已經(jīng)看到它確實如此,但是,缺省的情況下,它的作用還是不盡如人意(實際上,他們比隨便敲出來的東西還要難看- ainfinite number of monkeys typing into GNU emacs would never make a good program) 于是,你可以要么不要使用GUN emacs,要么讓它使用sanervalules.使用后者,你需要將如下的語句輸入到你的.emacs文件中.(defun linux-c-mode() C mode with adjuste

28、d defaults for use with the Linux kernel.(interactive) (c-mode) (c-set-styleK&R) (setq c-basic-offset8) 這會定義一個M-x Linux-c-mode的命令.當你hacking一個模塊的時候,如何你將-*- linux-c -*-輸入在最開始的兩行,這個模式會自動起作用.而且,你也許想加入如下(setq auto-mode-alist (cons (/usr/src/linux.*/.*.ch$ . linux-c-mode) auto-mode-alist) 到你的.emacs文件中,這樣的

29、話,當你在/usr/src/linux下編輯文件的時候,它會自動切換到linux-c-mode . 但是,假如你還不能讓emaces去自動處理文件的格式,不要緊張,你還有一樣東西: 縮進 . GNU的縮進格式也很死板,這就是你為什么需要加上幾行命令選項.然而,這還不算太壞,因為GNU縮進格式的創(chuàng)造者也記得K&R的權威, (GNU沒有罪,他們僅僅是在這件事情上錯誤的引導了人們) ,你要做的就只有輸入選項-kr -i8(表示K&R,縮進8個字符). 縮進有很多功能,特別是當它建議你重新格式你的代碼的時候,你應該看看幫助.但要記住: 縮進不是風格很差的程序的萬靈丹.成長的煩惱：初涉設計模式相信很多人

30、都喜歡看這部喜劇，我是很喜歡，里面包括了成長中的悲歡離合，你在其中可以尋找你成長的足跡。 編程成長之路何嘗不是這樣的呢？故事就是從這里開始的。小王是剛畢業(yè)的學生，進入一家軟件公司，薪水不錯。年輕人充滿干勁，有著遠大的目標。前三天參加了公司的培訓，三天沒寫代碼了，手癢。第四天，項目經(jīng)理走過來說：“小王，寫一個整型鏈表的排序算法吧，我們在項目中要用?！泵芭菔切⊥踉谀X海中第一個浮現(xiàn)出來的。翻開某某圣經(jīng)，摘了段冒泡算法，修改了一些代碼的書寫風格（有些圣經(jīng)代碼風格不咱的），代碼大致如此： BOOL Sort(ListInt) 冒泡排序算法 比較語句 return TRUE； 小王檢查了一下，還用測試用例

31、測試了一把，確保萬無一失，交給了經(jīng)理。經(jīng)理說了句不錯，樂壞了小王。第二天，經(jīng)理跑過來說：“把你昨天的代碼改一下，現(xiàn)在要比較浮點型了，還有能否速度上提高一點？”小王上網(wǎng)查了一下，選擇了快速排序算法，不忘把昨天寫的備份了一把，然后在昨天函數(shù)的基礎上改。代碼大致如此： BOOL Sort(ListInt) 快速排序算法 比較語句 return TRUE； Easy嗎？測試交差。 一年后鏡頭切換小王坐在計算機前熟練的編寫著程序，而且旁邊還放著本設計模式的書。知道了面向對象編程，知道了設計模式，但理解還不夠深刻。排序算法也演變成比較文件名了。一日經(jīng)理過來說：“小王，現(xiàn)在我們的排序算法要用在嵌入式平臺中，

32、你做一些算法的研究工作，給出一份報告。”這不是策略模式的典型應用嗎？定義一系列的算法，把它們一個個封裝起來，并且使他們可以相互轉換。這樣，小王把一些流行的排序算法都試了一遍，總共有七八種，換一種算法速度也很快，新的算法插入到系統(tǒng)中，老算法從系統(tǒng)中退休，實現(xiàn)插件式替換。 CSort *pSort new CBubbleSort; CClient.ListSort(pSort);如果要改成快速排序，只要如此： CSort *pSort new CQuickSort; CClient.ListSort(pSort);測試交差，當然經(jīng)理自己也有想法，又讓小王試了另外的幾個算法，小王都能輕松的完成。策略

33、模式的作用在這里淋漓盡致的發(fā)揮了，小王心里特別有成就感。過了些日子，客戶提出需要按文件名、日期進行排序，小王覺得這還是比較簡單的，改代碼的主要工作是copy-paste，就四個函數(shù)，也就很快完成了。客戶的需求是不會停止的，為了加強功能，提出需要按文件大小、文件的類型排序，天知道客戶還會提出什么要求。“再也不能這樣活”，小王聽著歌，陷入了沉思?！芭判虻乃惴ê捅容^算法分開來會如何呢？把它們脫耦，使得二者可以獨立地變化。這句話怎么這么熟悉，我肯定在哪里看到過?！毙⊥趺Ψ_設計模式，開始查閱。“Got it，這不就是橋梁模式（Bridge）。”一陣欣喜，馬上就干。 客戶端代碼如下： CSort *pS

34、ort = new CQuickSort; CCompareType *pType = new CNameCompare; pSort-SetType(pType); pSort-Sort(pList); 哈哈，客戶們，你們盡管提要求吧。 測試之顛，必先利其器孔子曰：“工欲善其事,必先利其器”，其大體意思是：孔子告訴子貢，一個做手工或工藝的人，要想把工作完成，做得完善，應該先把工具準備好。時至今日想起此話很有道理，在我們的測試工作中又何嘗不是呢！只是對其“器”即所謂的工具的范圍更廣了而也。在紛繁復雜和反復無常的測試工作中其所用的“器”那是至關重要的，其器可以從兩方面來講：一方面是測試時所具備的

35、工具；另一方面則是測試人員本身，這一點是對器的含義的衍生，相對前者就更加重要了。工具是基礎，是開展一切事項的根本前提，在人類起源之初因為原始的高級動物具備了工具從而使之開始勞動，進而成為現(xiàn)在我們人類，可想而知其工具的魅力所在。在測試工作中使用一個好的測試工具是很有必要的，目前市場上所出現(xiàn)的測試工具不難分出如下幾類：為減少重復測試工作的自動化測試工具高精度專業(yè)化的專用測試工具軟件開發(fā)過程中各階段使用的輔助測試工具面對如此繁多的測試工具我們應該如何對待呢？其實每一個工具均有其自身的特點，這也是每個工具存在的唯一理由，不可能有一種工具什么都能做，或者什么都不能做，要是真有什么都不能做的工具那就不叫工

36、具了。在這里需要強調的是并不是使用的工具越多測試工作就做得越好，其實即使在經(jīng)濟上允許的情況下使用了一些沒有必要使用的工具也許是一種累贅，況且據(jù)我所知很多公司都不愿意把大把的錢花在買測試工具上，更何況該測試工具是一種累贅。簡單來講就是在當前環(huán)境下我們要使用適合當前項目和符合公司及團隊運作的測試工具。所謂的當前環(huán)境是指目前在項目進度和項目預算這種前提下是否允許我們使用某個測試工具；所謂適合當前項目是指是否在這個具體的項目中使用這個測試工具能夠提高測試效果和效率；所謂的符合公司及團隊運作是指公司及團隊的發(fā)展戰(zhàn)略及相關規(guī)程是否能夠使這個測試工具能夠更好的運作起來以此來發(fā)揮其最佳效果。分析好以上所說的“

37、三個所謂”的問題，對于決定是否需要這個測試工具那是一件非常容易的事了，如果沒有解決好以上“三個所謂”的問題那么就最好不要選用這個測試工具。關于如何選擇一個測試工具請參考WAYNE先生的一文如何選擇嵌入式白盒測試工具，在此文中對于測試工具的選擇有非常精辟的闡述。那么擁有一個非常適合的在業(yè)界也是比較優(yōu)秀的測試工具就夠了嗎？當然不是了，要不測試人員就要下崗了。測試人員是靈魂，工具畢竟只是個聽從指揮和執(zhí)行命令的一個實體，不能像人一樣發(fā)揮主觀能動性，不具思維，更不用說是發(fā)散思維了，不能執(zhí)行一些創(chuàng)造性的工作。所以說除了有一個非常適合的在業(yè)界比較優(yōu)秀的測試工具之外，更重要的還需要一個非常優(yōu)秀的測試人員，需要

38、這個靈魂來*縱測試工作的一切。一個優(yōu)秀的測試人員具備如下素質是很有必要的：一、軟件開發(fā)和設計功底，這個是基礎，如果一個不懂得開發(fā)的人員來做測試工作其實很容易想象測試工作是多么的糟糕，其道理也很簡單，在此也不再提及，但很遺憾的是在這個觀點上往往會有人知錯犯錯，導致總是會有一些測試人員不是很懂得開發(fā)的一些東西，這種現(xiàn)狀希望在不久后會徹底消失；二、測試理論和測試思想，這點就很容易理解了，這也是作為一個測試人員的基礎，要做到這點相對比較容一些；三、不僅要學會使用測試工具，更要在平時的測試工作中加以提煉創(chuàng)造測試工具，以至更好的為測試工作服務，提高測試效率和測試工作的共用性；四、測試人員個人的素養(yǎng)，這里主

39、要是指個人的溝通、交流等方面的能力，還有就是測試人員所具備的比較特殊的發(fā)散思維和逆向思維。在測試工作中除擁有一個好的測試人員外，更加擁有一個適合的比較優(yōu)秀的測試工具，這兩者相結合，那么做好一項測試工作就很容易了，只要擁有了這兩項利器相信測試工作會獲得更大的成功，需要說明的是并不是每一項測試工作一定需要測試工具來輔助完成，而是需要應該需要的工具。當然還需要組織及團隊有效的推動和支撐，這樣其測試工作將會發(fā)揮到極致，以至登上華山之顛！時至那時，測試行業(yè)的發(fā)展將會拔開云霧陽光普照。測試工程師的十二最測試工程師最開心的事:發(fā)現(xiàn)了一個很嚴重的bug,特別是那種隱藏很深,邏輯性的錯誤.偶第一次發(fā)現(xiàn)這種問題的

40、時候,聽到上司和開發(fā)人員的表揚時,高興的就想扭pp.不過現(xiàn)在慢慢矜持些了,呵呵. 測試工程師最提心吊膽的事:版本release出去后,客戶發(fā)現(xiàn)了很多或很嚴重的bug.經(jīng)過緊張的系統(tǒng)測試之后,好不容易可以輕松一下了,卻又陷入了每天擔心正在做驗收或使用的客戶一封郵件或一個電話說產(chǎn)品有問題.碰到好些的老板還會比較樂觀的看這樣的問題,最慘的就是有些人一頓臭罵,之前的辛苦,加班全部都給抹殺了.測試工程師最憎恨聽到的話:為什么這個bug沒有在測試的發(fā)現(xiàn)呢?這句話經(jīng)常是客戶發(fā)現(xiàn)bug后,老板對測試人員的質問.當然這里排除那種很明顯的錯誤.其實誰都知道bug是不可能全部發(fā)現(xiàn)的,這句話其實也是客戶對大頭,大頭對

41、小兵一級一級問下來的.除了希望測試人員警惕之外,還有更多的是一種踢貓的行為.對于這句話,偶第一次聽到這句話的反映是我們怎么可能發(fā)現(xiàn)所有的bug呢,后來變成制造bug的人不是我們,是開發(fā),到現(xiàn)在的讓我查查我的日志,問問開發(fā)這個bug的原因,為什么我們會沒有找到,下次我們會怎樣的回復.測試工程師最郁悶的事:剛才那個版本打包打錯了,你們要重測.新版本來了,馬上投入緊張的測試,希望能夠多找些bug.沒想到辛苦了可能大半天,開發(fā)人員說打包打錯了,你重測吧.這種情況雖然可以通過規(guī)范流程之類的辦法控制發(fā)生的機率,但人總會犯錯,多少而已.碰到這樣,你除了提醒開發(fā)部門下次注意,你除了重測沒有太多辦法.測試工程師

42、最不想面對的事:在測試晚期或最新的版本里發(fā)現(xiàn)了以前一直存在的問題,特別是當問題很嚴重時決定到底報不報bug.報嗎,開發(fā)人員肯定會問以前有沒有這個問題,不報嗎,客戶發(fā)現(xiàn)更慘.畢竟客戶或老板的責備比開發(fā)部門或主管的責備輕許多,最后還是會報到bug庫里的.測試工程師最不想做的事:申請版本推遲發(fā)布.由于在版本發(fā)現(xiàn)了太多的問題,覺得產(chǎn)品不能達到發(fā)布的標準,建議公司推遲發(fā)布產(chǎn)品.這時雖然大家都知道產(chǎn)品有問題,盡管你自己也不希望這樣,但誰都覺得你是一個制造麻煩的人,畢竟市場的壓力很大呀.測試工程師最丟人的事:辛苦的發(fā)現(xiàn)了一個bug,居然是該配的參數(shù)沒有配等一些自己的失誤造成的.有些該注意的地方居然測試時忘了

43、,找出的問題給開發(fā)人員一頓臭扁,無比丟人啦.測試工程師最怕的事:一天,甚至幾天都沒有發(fā)現(xiàn)一個bug!經(jīng)過一段時間的bug高峰期后,有段時間會發(fā)現(xiàn)bug數(shù)量的減少,最可怕的就是一天都沒有發(fā)現(xiàn)一個bug.偶有時會難過的吃飯都沒心情.搞得偶的開發(fā)朋友說了一句最讓人吐血的話:要不要我在代碼里放幾個bug給你呀,hoho測試工程師最傷心的事:每年的調薪,發(fā)bonus或發(fā)股票時,測試工程師總比開發(fā)工程師少.偶有一同事在調薪的第二天就申請轉開發(fā),說測試太沒前途了.測試工程師最有力的保護方法:把你認為是bug的問題都提交到一個正式的,可以追蹤的地方(一般來說是bug庫).有時總會碰到一些很小的或是很難判斷的問

44、題,猶豫一定是否要報,特別是一些UI的問題.有時問開發(fā)人員,他們可能會輕描淡寫的回復你導致你沒有report它.但多年的經(jīng)驗一定要報,了解bug流程走向的人都知道,后面還有人verify,還有開發(fā)經(jīng)理判斷,如果不是bug,自然他們會回復,會寫明原因.說白了,出了問題也不是你的事情.當然一開始經(jīng)驗不足時會收到一些白眼球,但慢慢經(jīng)驗多了,對系統(tǒng)熟悉了,自然這種情況會少些.人也可以從一些問題中發(fā)現(xiàn)自己的弱點.但如果不報,那天客戶提出來,你除了懊悔還要面對指責,嚴重的炒魷魚.測試工程師最任重道遠的事:測試驅動開發(fā).碰到這種開發(fā)模式的項目,既是測試揚眉吐氣的機會,也是可能會陷你于深淵的惡潭.你就必須打起

45、十二分的精神.等于你在引導開發(fā),有什么問題一定要提出來,否則你就等著被盲目的牽著鼻子走了.測試工程師最期待的事:測試能夠越來越受重視,測試工程師的考核越來越合理. 操作系統(tǒng)UML與面向對象數(shù)據(jù)庫考試模塊指導操作系統(tǒng)和數(shù)據(jù)庫是程序員和軟件設計師每年的必考內容，從1987年到2005年春季軟考都少不了它們的身影。 近年來，程序員和軟件設計師大綱雖做了一些大的改動，但操作系統(tǒng)部分變動并不是很大，上午分值多是1到5分之間，下午是不確定出題，也就是可能會出到，也可能沒有。但不可大意，如2004年秋季下午題的第四題就是道操作系統(tǒng)題。另外，在出題形式上更趨于具體的分析，而不再是純粹的概念題。如PV原語操作就

46、比較多偏向于對生產(chǎn)者/消費者問題的解答。大綱所列知識點雖不能全部都涉及到。不過再通過我們對歷年題型的綜合分析后(特別是1995到2005春季)，可以明確的是操作系統(tǒng)方面的題目，一般集中在進程，存儲管理和作業(yè)管理這幾個方面。1998年到2000年這幾年的操作系統(tǒng)，有很多是重復出題，而且都集中在上面說的幾個方面。希望各位考生在復習時把主要精力放在主要知識點上。數(shù)據(jù)庫在程序員和軟件設計師的出題中比重不小。分值上午一般會有5分左右，下午有和軟件工程結合出題，或者與UML聯(lián)合出題的情況。這種結合多是考查ER模型到關系模式的轉換，以及用SQL來建立關系模式，2005年春季考試上下午都有數(shù)據(jù)庫的題，且下午是

47、獨立題目。而且我們思達網(wǎng)校的老師一致認為這是考生朋友們應該牢牢抓住分數(shù)的部分。具體的重點是很清晰的，ER模型和關系模式之間的轉換，關系代數(shù)，關系演算，范式，SQL語言(查詢的比重較大)。復習時應注意掌握以上這些知識點。面對對象和UML是新大綱的新要求，可以參考的并不多。不過對概念的考查火力比較強，考生很不容易在面對對象方面的眾多概念中拿到分，這就要求考生朋友們一定要注意平時在復習時就把這些內容有意加強記憶。UML是在下午題中出現(xiàn)，從2004年春季考到2005年春季考的下午試題中發(fā)現(xiàn)出題UML的火力點多在對各種靜態(tài)圖和動態(tài)圖。采用簡化原型法進行需求分析順序階段的觀點2，改變了傳統(tǒng)的自頂向下的開發(fā)

48、模式，降低了軟件需求的風險，因此得到了廣泛的應用，特別是在致力于某一領域MIS開發(fā)的軟件公司，如致力于電力MIS開發(fā)的公司。但作者在長期的MIS需求分析過程中，發(fā)現(xiàn)原型法有以下缺陷：1）原型的設計和修改工作量大，增加了系統(tǒng)的開發(fā)成本；2）由于用戶不關心或不理解原型的概念和實現(xiàn)，而且存在較大期望，使得與實際系統(tǒng)差別較大的原型增加了需求分析人員與用戶的交流難度；無論是水平原型，還是垂直原型都不能反映實際系統(tǒng)的全貌；3）軟件需求主要包括：功能需求、界面需求、性能需求、環(huán)境需求、可靠性需求、安全保密需求、資源使用需求、軟件成本消耗與開發(fā)進度需求和目標需求3。原型法中的原型難以表達軟件的后七項需求；4）

49、原型法強調用戶和開發(fā)人員不斷對原型進行不斷修改和補充，直到用戶感到滿意為止。在時間緊和任務重的大型MIS項目中，這種情況實際難以保證，特別是在用戶單位和開發(fā)單位距離較遠時。本文結合管理信息系統(tǒng)項目實施的實踐，提出一種新的需求分析方法-簡化原型法。這種方法根據(jù)數(shù)據(jù)庫應用的特點，將需求分析分為兩個階段，并簡化了作為需求分析工具的系統(tǒng)原型。 2 簡化原型法需求分析的第一個階段管理信息系統(tǒng)屬于數(shù)據(jù)庫應用。數(shù)據(jù)庫應用需求分析應該圍繞數(shù)據(jù)，而不是功能展開，因此應該首先解決有什么，然后再明確做什么4。第一個階段就是要解決有什么，即由項目經(jīng)理與用戶進行協(xié)商，確定系統(tǒng)的技術協(xié)議，因此可以稱為技術協(xié)議階段。技術協(xié)

50、議需要開發(fā)方的項目經(jīng)理與用戶單位的技術主管簽字并蓋章，并以合同附件的形式存在。技術協(xié)議的主要內容有：系統(tǒng)的邊界、系統(tǒng)處理的業(yè)務、與其它系統(tǒng)的接口、工程的進度控制、培訓安排和技術服務承諾。 2.1 系統(tǒng)的邊界系統(tǒng)的邊界規(guī)定系統(tǒng)覆蓋的作業(yè)范圍，主要有地理邊界（規(guī)定系統(tǒng)運行的部門、分支單位等）、操作員范圍（規(guī)定操作系統(tǒng)的所有操作員身份、分布和大致權限）和業(yè)務范圍（規(guī)定系統(tǒng)處理的業(yè)務，對于不處理的邊沿業(yè)務特別明確指出）。 2.2 系統(tǒng)處理的業(yè)務系統(tǒng)處理的業(yè)務涵蓋系統(tǒng)處理的所有業(yè)務，包括各種業(yè)務的描述、數(shù)據(jù)來源、實現(xiàn)要求。但是業(yè)務規(guī)定不要求過細，可以對應實際系統(tǒng)中的一個模塊。如：電力MIS中輸電設施管理

51、子系統(tǒng)中的線路設備管理，不詳細描述線路設備管理中的所有功能。 2.3 與其它系統(tǒng)的接口與其它系統(tǒng)的接口明確規(guī)定接口的系統(tǒng)、功能和實施單位。在接口的實施單位中明確是由開發(fā)方完成，還是由開發(fā)方協(xié)助第三方完成。 2.4 工程的進度控制工程的進度控制規(guī)定工程的開始、結束日期和具體工程項目的名稱、完成時間、地點、完成標志及責任分工。具體項目一般包括：采購設備到達現(xiàn)場、采購設備安裝調試、完成網(wǎng)絡布線、開發(fā)準備階段、業(yè)務需求調查、系統(tǒng)分析和設計、軟件編制、現(xiàn)場調試、數(shù)據(jù)準備及錄入、功能確認、試運行和系統(tǒng)驗收。責任分工規(guī)定雙方對于具體項目的工作內容和配合方式。在配合方式中規(guī)定人員組織方式、人員素質要求、提供的

52、設備和場所。完成標志規(guī)定具體項目完成提供的文件名稱和要求，如：網(wǎng)絡布線驗收報告和硬件設備驗收報告等。 2.5 培訓安排訓包括操作員和系統(tǒng)維護人員的培訓。培訓安排包括每種培訓的人員數(shù)量、培訓內容、培訓時間、地點、組織方式和教材，并規(guī)定教員和學員的素質要求，及培訓后學員達到的水平。 3 簡化原型法需求分析的第二個階段如果說第一個階段解決有什么的問題，那么第二個階段解決做什么的問題。主要工作有需求調查準備、到用戶單位進行需求調查分析和進行需求評審。 3.1 需求調查準備需求調查準備工作，在系統(tǒng)的技術協(xié)議簽訂后，嚴格依照技術協(xié)議進行，主要有向用戶單位發(fā)放業(yè)務調查表、建立需求分析文檔原型和建立系統(tǒng)簡化原

53、型。業(yè)務調查表在系統(tǒng)的技術協(xié)議簽訂后，立即通過傳真發(fā)送到用戶單位，要求用戶單位在需求調查人員到達現(xiàn)場之前完成。業(yè)務調查表內容包括：具體業(yè)務的名稱、上級業(yè)務、下級業(yè)務、發(fā)生條件、處理的數(shù)據(jù)和詳細流程（處理崗位、處理方式和審核細節(jié)等）。需求分析文檔原型是根據(jù)技術協(xié)議編寫的需求分析說明書原型，它的格式與標準的需求分析說明書相同。其中的狀態(tài)遷移圖和各種表證單書等不明確的內容，采用相似系統(tǒng)的或由系統(tǒng)分析人員根據(jù)技術協(xié)議和以往經(jīng)驗設計。系統(tǒng)的簡化模型根據(jù)技術協(xié)議的要求，仿照相似系統(tǒng)設計。簡化模型采用可視化的數(shù)據(jù)庫編程語言設計，一般采用數(shù)據(jù)庫應用開發(fā)人員熟悉的PowerBuilder(PB)或Delphi。

54、簡化模型的主要設計要求有：1）充分考慮系統(tǒng)的設計與實現(xiàn)，不得與實際系統(tǒng)脫節(jié)；2）盡量仿真實際系統(tǒng)的操作界面，與實際系統(tǒng)的操作過程完全相同；3）可以單機安裝運行，不與實際數(shù)據(jù)庫連接；4）演示數(shù)據(jù)的存儲可以通過文本文件、單機的數(shù)據(jù)庫或PB外部數(shù)據(jù)源的數(shù)據(jù)窗口；5）對于界面中容易誤解或難以理解的操作，在功能幫助按鈕中給出說明；6）界面中難以實現(xiàn)或工作量很大的功能，以標注方式詳細說明；7）運行穩(wěn)定，并比實際系統(tǒng)對硬件要求低。 3.2 需求調查分析需求調查分析在確認需求調查準備的三項工作完成后，由開發(fā)單位的系統(tǒng)分析人員到用戶單位進行。系統(tǒng)分析人員與用戶單位安排的業(yè)務主管共同討論業(yè)務調查表和系統(tǒng)簡化原型，

55、并不斷修改完善系統(tǒng)簡化原型和文檔原型，最終形成共識，并要求業(yè)務主管在需求分析說明書上簽字。最終系統(tǒng)簡化原型和源代碼留在用戶現(xiàn)場，便于系統(tǒng)的操作員進一步理解分析，直到最終掌握；而且有利于提出進一步的改進意見。改進意見可以隨時通過郵件或傳真直接發(fā)到開發(fā)單位，或由用戶單位的系統(tǒng)維護人員修改簡化原型后，隨時發(fā)到開發(fā)單位，從而便于開發(fā)人員及時修改系統(tǒng)的設計和編碼。 3.3 進行需求評審需求評審一般由用戶單位組織，評審團成員由同行專家、系統(tǒng)分析、設計和測試人員組成。評審的依據(jù)不僅有需求分析說明書，還有系統(tǒng)簡化原型；同時在評審過程中，系統(tǒng)簡化原型不斷進行優(yōu)化。評審的目標是要求需求分析說明書具有正確性、可行性

56、、必要性、具有優(yōu)先級屬性、可驗證性和無二義性5。需求評審報告作為對需求分析的補充和修正，由雙方負責人簽字，以需求分析說明書附件的形式存在，同樣指導下一步的系統(tǒng)設計工作。 4 幾點說明1、此方法適合各種MIS工程的需求分析，特別適合致力于某一領域MIS開發(fā)的軟件公司。采用此方法，開發(fā)同類項目越多，需求分析工作的效率越高。2、在需求分析過程中，由于需要設計系統(tǒng)簡化原型和文檔原型，并充分考慮到系統(tǒng)的設計與實現(xiàn)，因此與其它需求分析方法向比，提高了對需求分析人員的要求。在實際工作中，一般由資深的軟件分析和設計人員進行。3、此方法不僅適合MIS軟件工程，同樣適合其它大型軟件工程。4、由于需求分析工作本身的

57、難度和重要性，此方法同樣要求用戶單位和需求分析人員對需求分析所有工作內容，引起足夠重視；科學安排需求分析工作步驟，某些步驟可以同時進行；所有工作步驟不得應負或疏忽。 5 結束語目前簡化原型法已經(jīng)在多個電力MIS工程中應用，大大提高了需求分析的工作效率。實踐證明，簡化原型法具有以下特點：1）簡化的系統(tǒng)原型開發(fā)工作量大大降低，修改和補充方便；2）簡化原型大大縮短了需求分析人員與業(yè)務主管之間的距離，便于交流；并大大加強了需求分析人員與業(yè)務主管對系統(tǒng)的認識，有利于發(fā)現(xiàn)和解決問題；3）簡化原型的設計提前考慮了系統(tǒng)的設計與實現(xiàn)，大大降低了軟件工程的風險；4）簡化原型增加了系統(tǒng)操作員對實際系統(tǒng)的認識，大大簡

58、化了工程實施后系統(tǒng)的操作培訓；5）簡化原型可以直接指導工程的設計和編碼，便于系統(tǒng)開發(fā)的組織。這種方法也可以用于其它軟件工程，對于其它需求分析方法的改革也具有指導意義。不要將默契式管理和人性化管理劃等號學而優(yōu)則仕在中國還是一個挺普遍的現(xiàn)象，給批判得也很多！但是原話是“仕而優(yōu)則學，學而優(yōu)則仕”，見于論語子張，其真正含義并不是我們片面理解的“學習優(yōu)秀的就去做官”。同樣，“仕而優(yōu)則學”難道是告訴管理者：“做好了官，有余力則學習！”如果你認定等我有余力才學習嗎？呵呵，那你永遠也沒有有余力的一天。在IT行業(yè)，不少管理者都是技術出身，從論語這句話，我們應該學習到：當走上管理崗位，更加要“邊干邊學”，從工作中

59、學習提高業(yè)務知識和管理體系，持續(xù)改進，才能進入“仕而優(yōu)則學，學而優(yōu)則仕”的良性循環(huán)。（看來和CMMi的本質一致的?。┌咐唬耗橙粘闄z項目組O工作，檢查項目經(jīng)理L對任務的執(zhí)行情況了解和把控，抽查本周內項目組成員C的工作任務時，發(fā)現(xiàn)項目經(jīng)理L對C昨天的工作任務T1的工作完成情況并不了解。為了進一步了解C的工作完成情況，和項目經(jīng)理L、同事C一起檢查昨天C的全日任務T1，該任務是測試業(yè)主方的FTP上傳、下載接口，而本日的任務T2是開發(fā)FTP上傳模塊。先是詢問了同事C在昨天是否還開展了其他任務，答案是沒有；接著詢問任務T1除了使用java的.ftp程序包外，是不是還有特別的業(yè)務邏輯以及異常處理等處理，答

60、案是異常需要寫日志記錄；接著還告訴同事C，程序為了穩(wěn)健性，處理正常的業(yè)務邏輯外，還有很多是針對異常的控制邏輯，除了使用log4j寫入程序日志，還有什么特別的地方，C的回答是沒有。事后和項目經(jīng)理L分析，項目組O的工作方式，停留在按模塊給成員派任務，成員將任務計劃上報，項目經(jīng)理L和技術經(jīng)理LL則合并計劃，解決人員間的任務沖突！但是任務的時間是否合理，沒有進行評估和監(jiān)控，小組評估法也好，專家評估法也好，總之沒有評估監(jiān)控環(huán)節(jié)，項目經(jīng)理L和技術經(jīng)理LL都缺位了。另外，工作的執(zhí)行沒有進行督促，沒有每日的檢查或者抽查，那么小組O里面，誰做到好，誰做得不好，只是拍腦袋；還有，項目組里面到底應該鼓勵誰呢，誰是項