軟件定義階段總結

1、軟件定義階段總結軟件定義階段各章回顧對軟件定義各個階段的進一步認識與軟件工程相關的一些補充內容軟件工程中一些有爭議的觀念給大家的幾條建議Chap01 軟件工程學概述軟件工程的基本原理和方法（7條原理2種方法）軟件工程方法學：生命周期方法學（傳統(tǒng)方法學），采用結構化技術來完成軟件開發(fā)的各項任務。面向對象方法 面向對象方法對象類繼承用消息通信。軟件生命周期劃分：問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼和單元測試、綜合測試、運行維護等8個階段軟件過程：瀑布模型、快速原型模型、增量模型、風險驅動的螺旋模型?？尚行匝芯磕康氖沁M一步探討問題定義階段所確定的問題是否有可行的解?？尚行匝芯窟^程

2、1、經過定義問題，分析問題，提出解法的反復過程，最終提出一個符合系統(tǒng)目標的高層次的邏輯模型。2、 然后根據(jù)系統(tǒng)的這個邏輯模型設想各種可能的物理系統(tǒng)，并且從技術、經濟和操作等各方面分析這些物理系統(tǒng)的可行性。3、最后，系統(tǒng)分析員提出一個推薦的行動方針，提交用戶和使用部門負責人審查批準。 Chap02 可行性研究-1可行性研究-2系統(tǒng)流程圖實質上是物理數(shù)據(jù)流圖，它描繪組成系統(tǒng)的主要物理元素以及信息在這些元素間流動和處理的情況。 數(shù)據(jù)流圖的基本符號只有四種，它是描繪系統(tǒng)邏輯模型的極好工具。數(shù)據(jù)字典是關于數(shù)據(jù)的信息的集合，對數(shù)據(jù)流圖中包含的所有元素的定義的集合。通常數(shù)據(jù)字典和數(shù)據(jù)流圖共同構成系統(tǒng)的邏輯模

3、型。成本效益分析是可行性研究的一項重要內容 。需求分析是軟件生命周期的一個重要階段，它最根本的任務是確定為了滿足用戶的需要系統(tǒng)必須做什么。 通過分析應該得出用數(shù)據(jù)流圖、ER圖、數(shù)據(jù)字典和和IPO圖（或PDL等其他描述算法的工具）描繪的精確的系統(tǒng)邏輯模型。還可以用層次方框圖或Warnier圖等圖形工具輔助描繪系統(tǒng)中的數(shù)據(jù)結構。為了減少冗余、簡化修改步驟，往往需要規(guī)范數(shù)據(jù)的存儲結構。需求分析的結果是軟件開發(fā)的基礎，必須仔細驗證它的正確性 。Chap03 需求分析軟件定義各個階段的進一步認識深入“問題定義”問題定義是軟件工程過程中重要的一環(huán)，也是最簡短的階段，通常在一天或更少的時間內完成。但它是一個

4、項目的開始，也就是根基，如果問題定義不明確、不完整，會直接影響到以后的工作，問題定義決定了整個軟件工程是否能朝著正確的方向前進。錯誤的問題定義把問題定義當作是需求分析把問題定義當作一件小事把問題定義當作解決方法避重就輕地定義問題規(guī)范問題定義思想上重視客觀、全面地定義嚴格評審深入分析可行性研究可行性分析是要決定“做還是不做”。即使可行性分析是客觀的、科學的，但決策仍有可能是錯誤的。因為決策者是人，人會沖動，有賭博心態(tài)。如果可行性分析表明做某件事的成功率是10%，失敗率是90%，倘若該事情的意義非常大，決策者也許會一拍腦袋：“豁出去，干！”于是這世界就多了一份極喜與極悲。可行性分析的四大要素：經濟

5、、技術、社會環(huán)境和人。目前國內很多軟件公司做系統(tǒng)集成項目，如果談談系統(tǒng)集成項目的可行性分析將很有意思。可是那些系統(tǒng)集成項目大多是政府機構的，由于軟件行業(yè)尚不規(guī)范并且客戶方存在腐敗現(xiàn)象，所以業(yè)內流傳“沒有做不了的系統(tǒng)集成項目”。軟件公司的注意力幾乎全集中在“如何拿到項目訂單”以及“拿到訂單后如何蒙混過關”上，喪失了 “可行性分析”的機會。聯(lián)想集團領導人柳傳志曾說：“沒錢賺的事我們不干；有錢賺但投不起錢的事不干；有錢賺也投得起錢但沒有可靠的人選，這樣的事也不干?！绷鴤髦緸闆Q策立了上述準則，同時也為可以行性分析指明了重點。 經濟可行性-1經濟可行性分析主要包括：“成本收益”分析和“短期長遠利益”分析

6、。成本收益分析最容易理解，如果成本高于收益則表明虧損了，如果成本大大高于收益那就虧大了。商人都不喜歡做吃虧的事情。有些商店成天貼著“最后一天跳樓大拍賣”的標語，意思是：我準備吃大虧讓你占便宜，同志，你快上鉤吧。要考慮的成本：（1）辦公室房租。 （2）辦公用品，如桌、椅、書柜、照明電器、空調等。 （3）計算機、打印機、網絡等硬件設備。 （4） 、 等通訊設備以及通訊費用。（5）資料費。 （6）辦公消耗，如水電費、打印復印費等。經濟可行性-2（7）軟件開發(fā)人員與行政人員的工資。 （8）購買系統(tǒng)軟件的費用，如買操作系統(tǒng)、數(shù)據(jù)庫、軟件開發(fā)工具等。有些老板買盜版的系統(tǒng)軟件，卻按市場價算成本，可從美國佬那

7、里賺一筆。 （9）做市場調查、可行性分析、需求分析的交際費用。 （10）公司人員培訓費用。 （11）產品宣傳費用。如果用Internet作宣傳，則要考慮建設Web站點的費用。 （12）如果客戶是政府部門，還要充分考慮用于吃喝玩樂、行賄的費用。 （13）如果公司的風水不好，會有很多莫名其妙的管理費。每戳一個紅艷艷的公章都要化一把鈔票。經濟可行性-3短期長遠利益分析 短期利益容易把握，風險較低。國內軟件公司經常出現(xiàn)一窩蜂地去做信息管理系統(tǒng)、多媒體光盤、系統(tǒng)集成項目或Internet服務。每當我們沉迷于短期利益不思進取時，應該好好回憶童年時代那些偉大的抱負，給自己一些激勵。 長遠利益難以把握，風險較

8、大。能為了長遠利益不惜短期虧損的人，要么是雄心勃勃的將帥之才，要么是“紙上談兵”、“眼高手底”的那一類庸人。國內目前有不少Internet企業(yè)，只投入不產出。為了成就將來的霸業(yè)，甘愿現(xiàn)在拼財力、比耐性。最后存活下來的幾個公司將瓜分市場。 技術可行性（1）在給定的時間內能否實現(xiàn)需求說明中的功能。如果在項目開發(fā)過程中遇到難以克服的技術問題，麻煩就大了。輕則拖延進度，重則斷送項目。 （2）軟件的質量如何？有些應用對實時性要求很高，如果軟件運行慢如蝸牛，即便功能具備也毫無實用價值。有些高風險的應用對軟件的正確性與精確性要求極高，如果軟件出了差錯而造成客戶利益損失，那么軟件開發(fā)方可要賠慘了。 （3）軟件

9、的生產率如何？如果生產率低下，能賺到的錢就少，并且會逐漸喪失競爭力。在統(tǒng)計軟件總的開發(fā)時間時，不能漏掉用于維護的時間。軟件維護是非常拖后腿的事，它能把前期拿到的利潤慢慢地消耗光。如果軟件的質量不好，將會導致維護的代價很高，企圖通過偷工減料而提高生產率，是得不償失的事。 技術可行性分析可以簡單地表述為：做得了嗎？做得好嗎？做得快嗎？社會環(huán)境可行性社會環(huán)境的可行性至少包括兩種因素：市場與政策。市場又分為未成熟的市場、成熟的市場和將要消亡的市場。涉足未成熟的市場要冒很大的風險，要盡可能準確地估計潛在的市場有多大？自己能占多少份額？多長時間能實現(xiàn)？ 擠進成熟的市場，雖然風險不高，但油水也不多。如果供大

10、于求，即軟件開發(fā)公司多，項目少，那么在競標時可能會出現(xiàn)惡性殺價的情形。國內第一批賣計算機的、做系統(tǒng)集成的公司發(fā)了財，別人眼紅了也擠進來，這個行業(yè)的平均利潤也就下降了。將要消亡的市場就別進去了。盡管很多程序員懷念DOS時代編程的那種淋漓盡致，可現(xiàn)在沒人要DOS應用軟件了。學校教學尚可用用DOS軟件，商業(yè)軟件公司則不可再去開發(fā)DOS軟件。政策對軟件公司的生存與發(fā)展影響非常大。整個90年代，中國電信的收費相當高，僅此一招就把國內互聯(lián)網企業(yè)打得奄奄一息。某些軟件行業(yè)的利潤很高，但可能存在地方保護政策，使競爭不公平。政策不當將阻礙軟件公司的健康發(fā)展，可最怕的還是政府干預企業(yè)的正當行為。人的因素有句名言：

11、“人分四類人物，人才，人手，人渣?！?如果一個軟件公司里上述四類人齊全了，那么最好的分工是讓“人物”當領導，“人才”做第一線的開發(fā)人員，“人手”做行政人員，“人渣”負責行賄。 對于公司的領導與開發(fā)人員“行還是不行”?！叭宋铩碑吘故巧贁?shù)，“人才”可是濟濟的。舉重若輕的那類“人才”可以做領導，舉輕若重的那類人才適合做軟件開發(fā)人員。假如一群持有學士、碩士和博士文憑的畢業(yè)生到軟件公司應聘，該如何錄用呢？先選擇本科畢業(yè)生，因為他們正當青春、干勁十足、不擺架子、不恥下問、要求不高、奉獻甚多。其次選擇碩士畢業(yè)生，如果該生沒象范進中舉時那么老，并且在讀碩士時沒有天天去造文章而丟棄了編程工作，那么讓有經驗的學士

12、程序員帶他們煅練幾個月就可以用了。如果學士、碩士被其它公司取光了，那只好撿幾個博士充數(shù)。 通過前邊的學習，我們會發(fā)現(xiàn)需求析是最為重要的一個過程，在這個過程中，系統(tǒng)分析員和軟件工程師確定顧客的需要。只有在確定了這些需要后他們才能夠分析和尋求新系統(tǒng)的解決方法。 在軟件工程的歷史中，很長時間里人們一直認為需求分析是整個軟件工程中最簡單的一個步驟，但在過去十年中越來越多的人認識到它是整個過程中最關鍵的一個過程。假如在需求分析時分析者們未能正確地認識到顧客的需要的話，那么最后的軟件實際上不可能達到顧客的需要，或者軟件無法在規(guī)定的時間里完工。項目需求分析難在哪里？-1客戶說不清楚需求客戶對需求只有朦朧的感

13、覺，說不清楚具體的需求。如果客戶本身就懂軟件開發(fā)，能把需求說得清清楚楚，這樣的需求分析將會非常輕松、愉快。如果客戶全不懂軟件，但信任軟件開發(fā)方，這事也好辦。分析人員可以引導客戶，先闡述常規(guī)的需求，再由客戶否定不需要的，最終確定客戶真正的需求。最怕的就是“不懂裝懂”或者“半懂充內行”的客戶，他們會提出不切實際的需求。如果這些客戶甚至覺得自己是上帝的爸爸，那么溝通和協(xié)商都會很困難。項目需求分析難在哪里？-2需求自身經常變動“據(jù)歷史記載，沒有一個軟件的需求改動少于三次。唯一只改動需求兩次的客戶是個死人。這個可憐的家伙還是在運送第三次需求的路上被車子撞死的?！?因此我們應先接受“需求會變動”這個事實，

14、免得在需求變動時驚慌失措。明白“需求會變動”這個道理后，在進行需求分析時就要留點神： （1）盡可能地分析清楚哪些是穩(wěn)定的需求，哪些是易變的需求。以便在進行系統(tǒng)設計時，將軟件的核心建筑在穩(wěn)定的需求上，否則將會吃盡苦頭。 （2）在合同中一定要說清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。分析人員或客戶理解有誤軟件系統(tǒng)分析人員不可能都是全才?？蛻舯磉_的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致開發(fā)人員白干活，吃力不討好。所以分析人員寫好需求說明書后，要請客戶方的各個代表驗證。如果問題很復雜，雙方都不太明白，就有必要請開發(fā)人員快速構造軟件的原型，雙方

15、再次論證需求說明書是否正確。由于客戶大多不懂軟件，他們可能覺得軟件是萬能的，會提出一些無法實現(xiàn)的需求。有時客戶還會把軟件系統(tǒng)分析人員的建議或答復給想歪了。有一個軟件人員滔滔不絕地向客戶講解在“信息高速公路上做廣告”的種種好處，客戶聽得津津有味。最后，心動的客戶對軟件人員說：“好得很，就讓我們馬上行動起來吧。請您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做?！?項目需求分析難在哪里？-3軟件項目獲取用戶需求的溝通技巧軟件需求過程包括了5個主要活動：需求獲取、需求分析和確認、編寫需求規(guī)格說明書、需求驗證和需求管理。進行需求分析的時候應該按照上邊的步驟去做。需求獲取需求的收集、分析、細化、核

16、實并組織的步驟，并將它編寫成文檔。這個活動包括了編寫項目視圖和范圍文檔、用戶群分類、選擇用戶代表、建立核心隊伍、確定使用實例、召開聯(lián)合會議、分析用戶工作流程、確定質量屬性、檢查問題報告和需求重用10個具體任務。需求分析和確認-11、繪制關聯(lián)圖，用于定義系統(tǒng)與系統(tǒng)外部實體間的邊界和接口的簡單模型； 2、創(chuàng)建開發(fā)原型，當開發(fā)人員或用戶不能明確某些需求時，開發(fā)一個系統(tǒng)原型，這樣使得許多概念和可能發(fā)生的事更為直觀明了； 3、分析可行性，在允許的成本、性能要求下，分析每項需求實施的可行性，明確每項需求實現(xiàn)相聯(lián)系的風險，包括與其它需求的沖突，涉及各類用戶的利益平衡，對外界因素的依賴和技術障礙；需求分析和確

17、認-24、確定需求優(yōu)先級：分析方法來確定使用實例、系統(tǒng)特性或單項需求實現(xiàn)的優(yōu)先級別，以優(yōu)先級為基礎確定產品版本將包括哪些特性或哪類需求； 5、為需求建立模型，為需求建立圖形分析模型是軟件需求規(guī)格說明極好的補充說明，可以為系統(tǒng)需求從多個角度建模； 6、編寫數(shù)據(jù)字典，創(chuàng)建數(shù)據(jù)字典數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結構的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義； 7、應用質量功能調配，將系統(tǒng)特性、屬性與對客戶的重要性聯(lián)系起來，提供了一種分析方法以明確哪些是客戶最為關注的特性。編寫需求規(guī)格說明書-1需求開發(fā)的最終成果是客戶和開發(fā)小組對將要開發(fā)的產品達成一致協(xié)議，這一協(xié)議就是通過文檔化的需求規(guī)格說明書來體

18、現(xiàn)。需求規(guī)格說明書包括項目視圖和范圍文檔說明了系統(tǒng)的業(yè)務需求，而使用實例文檔則說明了用戶需求。這個活動需要完成下面幾個任務：1、采用模版,在你的組織中要為編寫軟件需求規(guī)格說明書等文檔定義一種標準模板,該模板為記錄系統(tǒng)需求和各種其它與需求相關的重要信息提供了統(tǒng)一的結構； 2、指明需求來源，為了讓所有項目風險承擔者明白需求規(guī)格說明書中為何提供這些功能需求，要能追溯每項需求的來源，來源可能是一種使用實例或其它客戶要求，也可能是某項更高層系統(tǒng)需求、業(yè)務規(guī)范、政府法規(guī)、標準或別的外部來源，這些來源應該記錄在需求的跟蹤能力矩陣中；編寫需求規(guī)格說明書-23、為每項需求注上標號，為了需求的可跟蹤性和可修改性的

19、質量標準，必須唯一確定每個軟件需求，為制定一種慣例來為需求規(guī)格說明書中的每項需求提供一個獨立的可識別的標號或記號; 4、記錄業(yè)務規(guī)范，是指關于系統(tǒng)的操作原則，比如誰能在什么情況下采取什么動作,將這些編寫成需求規(guī)格說明書中的一個獨立部分，或一獨立的業(yè)務規(guī)范文檔; 5、創(chuàng)建需求跟蹤能力矩陣，建立一個矩陣把每項需求來源、定義與實現(xiàn)、測試它的設計和代碼部分聯(lián)系起來,這樣有利于需求的管理和需求變更影響范圍的評估。需求驗證-1需求的驗證是為了確保需求說明準確、完整，表達必要的質量特點,需求將要作為系統(tǒng)設計和最終驗證的依據(jù),因此一定要保證它的正確性。需求驗證務必確保符合完整性、正確性、靈活性、必要性、無二義

20、性、一致性、可跟蹤性及可驗證性這些良好特征。這個活動需要完成下面幾個任務：1、審查需求文檔，對需求文檔進行正式審查是保證軟件質量的有效的方法。組織一個由不同代表（如用戶，分析人員，設計人員，測試人員）組成的小組，對需求規(guī)格說明書及相關模型進行仔細的檢查；需求驗證-22、依據(jù)需求編寫測試用例，根據(jù)用戶需求所要求的產品特性寫出系統(tǒng)的功能測試用例作為系統(tǒng)測試依據(jù)； 3、編寫用戶手冊，在需求開發(fā)早期即可起草一份用戶手冊，用它作為需求規(guī)格說明的參考并輔助需求分析; 4、確定合格的標準，需求說明中描述什么樣的產品才算滿足用戶的要求和適合他們使用的，將合格的測試建立在使用情景描述或使用實例的基礎之上。需求管

21、理-1需求管理是組織、控制和文檔化需求的系統(tǒng)方法，也是一種建立和維護用戶和開發(fā)組織對于改變系統(tǒng)功能的協(xié)議。需求開發(fā)的結果經驗證批準就定義了開發(fā)工作的需求基線,這個基線在客戶和開發(fā)人員之間就構筑了一個需求約定，需求管理包括在項目進展過程中維持需求約定一致性和精確性的活動。現(xiàn)在很多商業(yè)化的需求管理工具都能很好的支持需求管理活動。這個活動需要完成下面幾個任務：1、確定變更控制過程,確定一個選擇、分析和決策需求變更的過程,所有的需求變更都需遵循此流程; 2、建立軟件變更控制委員會(SCCB，Software Change Control Board),組織一個由項目風險承擔者組成的小組作為變更控制委員

22、會，由他們來評估和確定需求變更; 3、進行變更影響分析,評估需求變更對項目進度、資源、工作量和項目范圍以及其它需求的影響; 需求管理-24、跟蹤變更影響的產品,當進行某項需求變更時，參照需求跟蹤能力矩陣找到相關的其它需求、設計文檔、源代碼和測試用例，這些相關部分可能也需要修改； 5、建立基準和控制版本,需求文檔確定一個基線，這是一致性需求在特定時刻的快照，之后的需求變更就遵循變更控制過程即可; 6、維護變更的歷史記錄,記錄變更需求文檔版本的日期以及所做的變更、原因，還包括由誰負責更新和更新的新版本號等情況; 7、跟蹤每項需求的狀態(tài),這里狀態(tài)包括確定、已實現(xiàn)、暫緩、新增、變更等。建立一個數(shù)據(jù)庫，

23、其中每一條記錄記錄一項需求; 8、衡量需求穩(wěn)定性,記錄基線需求的數(shù)量和每周或每月的變更（添加、修改、刪除）數(shù)量。軟件開發(fā)經驗談 規(guī)范與文檔介紹綱要軟件與軟件危機編碼風格軟件設計及文檔一些CASE工具軟件與軟件危機軟件及其特點定義與硬件相互依存包括程序、相關數(shù)據(jù)及其說明文檔特點是一種邏輯實體，具有抽象性沒有明顯的制造過程（開發(fā)后復制）在使用過程中，無磨損、老化的問題，但存在軟件退化問題（硬件、環(huán)境以及需求的變化）軟件與軟件危機軟件危機及其原因軟件危機：在軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題對開發(fā)成本和進度的估計常常不準確用戶對“已完成”系統(tǒng)不滿意的現(xiàn)象經常發(fā)生軟件產品的質量往往靠不?。˙

24、ug）軟件的可維護程度非常之低軟件通常沒有適當?shù)奈臋n資料成本不斷提高開發(fā)生產率的提高趕不上硬件的發(fā)展和人們需求的增長軟件與軟件危機軟件危機及其原因軟件危機的原因與軟件本身的特點有關與開發(fā)和維護的方法不正確有關忽視軟件開發(fā)前期的需求分析開發(fā)過程沒有統(tǒng)一的、規(guī)范的方法論的指導，文檔資料不齊全，忽視人與人的交流忽視測試階段的工作，提交用戶的軟件質量差輕視軟件的維護軟件與軟件危機校園中的軟件開發(fā)編程至上，淡化分析設計文檔稀少，樣例、方法、內容風格不統(tǒng)一，忽視整體規(guī)范化組織松散，合作意識不強鉆研技術，追求編程技巧軟件生命力低，難于實用和發(fā)展壯大.編碼風格編排格式：Tab鍵縮進、空行、長句的分行.注釋：文

25、件、函數(shù)/過程、數(shù)據(jù)結構、控制流.各種名字的命名方法：匈牙利命名法.界面風格的統(tǒng)一：對話框/多文檔/單文檔、大小、字體、顏色、用詞.宏的使用：便于擴展、變更、意義明確數(shù)據(jù)結構的引入與管理：數(shù)據(jù)與操作的封裝性文件、模塊的組織：規(guī)模，功能、數(shù)據(jù)的相關性低耦合性：如何支持低的依賴性和高的復用性高內聚力：如何支持可管理的低復雜性異常的考慮與處理編碼風格如何在校培養(yǎng)編碼風格？程序設計語言：編排格式、變量函數(shù)的命名數(shù)據(jù)結構：數(shù)據(jù)結構的選擇與使用、宏的使用編譯原理（操作系統(tǒng)）設計：更復雜的數(shù)據(jù)結構的設計，耦合性與內聚力，嘗試界面的制作，文件、模塊的組織，異常的考慮與處理其他意識、自覺、勤奮、自立、嚴謹、不恥

26、下問軟件設計與文檔文檔(設計說明)的重要性開發(fā)者之間交流的有效手段；幫助開發(fā)者記憶設計思想；引導人們快速地理解軟件；文檔的復用寫文檔的困惑程序中不是有注釋嗎？寫什么呢？用什么寫呢？文檔與程序的一致性軟件設計與文檔軟件分析設計方法結構化分析設計：數(shù)據(jù)流圖, .；面向對象的分析設計: UML, .關系數(shù)據(jù)庫: E-R, 關系模型；軟件分析設計的表現(xiàn)頭腦+紙筆+代碼由人思考輸入的文檔利用工具建模生成的文檔 文本+圖形軟件設計與文檔如何在學校培養(yǎng)寫文檔程序設計語言：注釋的習慣數(shù)據(jù)結構：數(shù)據(jù)結構的實驗報告編譯原理（操作系統(tǒng)）設計：設計報告現(xiàn)存的問題：檢查力度不夠如何在學校培養(yǎng)軟件分析設計軟件工程等課程貴

27、在實踐和意識CASE工具-青鳥系統(tǒng)簡介國家科技攻關課題成果，北大牽頭研制面向對象的軟件開發(fā)環(huán)境研究過程“七五”期間，青鳥J型系統(tǒng)“八五”期間，青鳥II型“九五”期間，青鳥III型(JB3)系統(tǒng)基于異構平臺、具有多信息源接口支持面向對象技術，支持軟件復用完善并初步實現(xiàn)青鳥軟件生產線（基于構件構架模式的軟件工業(yè)化生產技術）的思想CASE工具-青鳥系統(tǒng)構件-構架軟件構件技術構件：應用系統(tǒng)中可以明確辨識的構成成分可復用的構件：具有相對獨立的功能屬性有用性有用的功能可用性易于理解與使用質量構件及其變形能正確工作適應性可進行參數(shù)化的配置可移植性內容：源代碼、需求規(guī)約、系統(tǒng)和軟件的構架、文檔、測試計劃、測試

28、案例和數(shù)據(jù)CASE工具-青鳥系統(tǒng)構件-構架軟件構架對系統(tǒng)整體結構的刻劃，包括全局組織與控制結構構件間通訊、同步和數(shù)據(jù)訪問協(xié)議設計元素間的功能分配，物理分布設計元素集成，伸縮性和性能，設計選擇意義發(fā)現(xiàn)不同系統(tǒng)在較高級別上的共同特性獲得正確的構架以進行正確的系統(tǒng)設計根據(jù)一些原則在不同的軟件構架中選擇有利于系統(tǒng)較高級別性質的描述和分析一些不正確的觀念-1觀念之一：我們擁有一套講述如何開發(fā)軟件的書籍，書中充滿了標準與示例，可以幫助我們解決軟件開發(fā)中遇到的任何問題。 客觀情況：好的參考書無疑能指導我們的工作。充分利用書籍中的方法、技術和技巧，可以有效地解決軟件開發(fā)中大量常見的問題。但實踐者并不能因此依賴

29、于書籍，這是因為：（1）現(xiàn)實的工作中，由于條件千差萬別，即使是相當成熟的軟件工程規(guī)范，常常也無法套用。（2）軟件技術日新月異，沒有哪一種軟件標準能長盛不衰。祖?zhèn)髅胤皆谀承╊I域很吃香，而在軟件領域則意味著落后。觀念之二：我們擁有最好的開發(fā)工具、最好的計算機，一定能做出優(yōu)秀的軟件。 客觀情況：良好的開發(fā)環(huán)境只是產出成果的必要條件，而不是充分條件。如果擁有好環(huán)境的是一群庸人，難保他們不干出南轅北轍的事情。一些不正確的觀念-2觀念之三：如果我們落后于計劃，可以增加更多的程序員來解決。 客觀情況：軟件開發(fā)不同于傳統(tǒng)的農業(yè)生產，人多不見得力量大。如果給落后于計劃的項目增添新手，可能會更加延誤項目。因為：（

30、1）新手會產生很多新的錯誤，使項目混亂。（2）老手向新手解釋工作以及交流思想都要花費時間，使實際開發(fā)時間更少。所以科學的項目計劃很重要，不在乎計劃能提前多少，重在恰如其分。如果用“大躍進”的方式奔向共產主義，只會產生倒退的后果。 觀念之四：既然需求分析很困難，不管三七二十一先把軟件做了再說，反正軟件是靈活的，隨時可以修改。 客觀情況：對需求把握得越準確，軟件的修修補補就越少。有些需求在一開始時很難確定，在開發(fā)過程中要不斷地加以改正。軟件修改越早代價越少，修改越晚代價越大，就跟治病一樣道理。一些有爭議的觀念-1爭議之一：如果軟件運行較慢，是換一臺更快的計算機，還是設計一種更快的算法？ 觀點：如果

31、開發(fā)軟件的目的是為了學習或是研究，那么應該設計一種更快的算法。如果該軟件已經用于商業(yè)，則需謹慎考慮：若換一臺更快的計算機能解決問題，則是最快的解決方案。改進算法雖然可以從根本上提高軟件的運行速度，但可能引入錯誤以及延誤進程。技術狂毫無疑問會選擇后者，因為他們覺得放棄任何可以優(yōu)化的機會就等于犯罪。 類似的爭議還有：是買現(xiàn)成的程序，還是徹底自己開發(fā)？技術人員和商業(yè)人士常常會有不同的選擇。 爭議之二：有最好的軟件工程方法，最好的編程語言嗎？ 觀點：在軟件領域永遠沒有最好的，只有更好的。能解決問題的都是好方法或是好語言。程序員在最初學習Basic、Fortran、 Pascal、C、C+等語言時會感覺

32、一個比一個好，不免有喜新厭舊之舉。而如今的Visual Basic、Delphi、Visual C+、Java等語言各有所長，真的難分優(yōu)劣。開發(fā)人員應該根據(jù)客觀條件，選擇自己熟悉的方法和語言，才能保證合格的質量與生產率。一些有爭議的觀念-2爭議之三：編程時是否應該多使用技巧？ 觀點：就軟件開發(fā)而言，技巧的優(yōu)點在于能另辟蹊徑地解決一些問題，缺點是技巧并不為人熟知。若在程序中用太多的技巧，可能會留下隱患，別人也難以理解程序。鑒于一個局部的優(yōu)點對整個系統(tǒng)而言是微不足道的，而一個錯誤則可能是致命的。建議用自然的方式編程，少用技巧。 狼三則的故事告訴我們“失敗的技巧通常是技倆”。當我們在編程時無法判斷是

33、用了技巧還是用了技倆，那就少用。賣油翁的故事又告訴我們“熟能生巧”，表明技巧是自然而然產生的，而不是賣弄出來的。 爭議之四：軟件中的錯誤是否可按嚴重程度分等級？ 觀點：在定量分析時，可以將錯誤分等級，以便于管理。微軟的一些開發(fā)小組將錯誤分成四個等級 。 一級嚴重：錯誤導致軟件崩潰。 二級嚴重：錯誤導致一個特性不能運行并且沒有替代方案。 三級嚴重：錯誤導致一個特性不能運行但有替代方案。 四級嚴重：錯誤是表面化的或是微小的。Seven Suggestions to Computer Science Students1、不要玩游戲，至少不要玩網絡游戲2、不要用分數(shù)衡量自己專業(yè)能力。自己一定要多去寫程序，多去看代碼肯定是對的。對于軟件專業(yè)同學千萬不要認為一分紙上試題可以代表你專業(yè)的能力。最初學習程序語言都是堅持每天寫50-100行以上代碼，這樣才能快速熟悉語法和程序入門基礎。3、培養(yǎng)學習的能力。老師帶領下學會一個東西很容易，嘗試之前自己