軟件工程課件

1、軟件工程軟件工程課件課件軟件工程軟件工程 第一章第一章概述概述 第二章第二章軟件計劃軟件計劃 第三章第三章軟件需求分析軟件需求分析 第四章第四章軟件總體設(shè)計軟件總體設(shè)計 第五章第五章軟件詳細(xì)設(shè)計軟件詳細(xì)設(shè)計 第六章第六章軟件編碼軟件編碼 第七章第七章軟件測試軟件測試 第八章第八章軟件維護軟件維護 第九章第九章軟件項目管理軟件項目管理 第十章第十章面向?qū)ο蠹夹g(shù)面向?qū)ο蠹夹g(shù)第一章第一課時第一章第一課時幾個基本概念軟件及其組成軟件的概念軟件的組成軟件危機（概念、表現(xiàn)、產(chǎn)生原因與解決辦法）軟件工程軟件發(fā)展簡史（無程序的階段、程序階段、軟件階段與軟件工程階段）軟件生命周期（軟件生存的七個階段：軟件計劃、

2、軟件需求分析、軟件總體設(shè)計、軟件詳細(xì)設(shè)計、軟件編碼、軟件測試、軟件維護 ）第二課時第一章第二課時第一章第二課時軟件開發(fā)模型瀑布模型快速原型瀑布模型的定義瀑布模型的定義瀑布模型遵循軟件生存周期的劃分，明確規(guī)定每個階段的任務(wù)，各個階段的工作順序展開，恰如奔流不息拾級而下的瀑布。問題定義可行性研究需求分析概要設(shè)計詳細(xì)設(shè)計編碼測試運行維護開發(fā)時期計劃時期有錯運行時期 對應(yīng)的文檔資料與系統(tǒng)目標(biāo)方案論證報告或計劃任務(wù)書需求規(guī)格說明書系統(tǒng)功能結(jié)構(gòu)圖設(shè)計規(guī)格書程序規(guī)格書、源程序測試記錄、用戶操作手冊評價報告、維護記錄瀑布模型的特點瀑布模型的特點 (1)軟件生存周期的順序性：只有前一階段工作完成以后，后一階段的

3、工作才能開始，前一階段的輸出文檔，就是后一階段的輸入文檔。只有前一階段有正確的輸出，后一階段才可能有正確的結(jié)果。如果在生存周期的某一階段出現(xiàn)了錯誤，往往要追溯到在它之前的一些階段。 瀑布模型開發(fā)適合于在軟件需求比較明確，開發(fā)技術(shù)比較成熟，工程管理比較嚴(yán)格的場合下使用。 (2)盡可能推遲軟件的編碼：程序設(shè)計也稱為編碼。實踐表明，大、中型軟件編碼開始得越早，完成所需的時間反而越長。瀑布模型在編碼之前安排了需求分析、總體設(shè)計、詳細(xì)設(shè)計等階段，從而把邏輯設(shè)計和編碼清楚地劃分開來，盡可能推遲程序編碼階段。 (3)保證質(zhì)量 ：為了保證質(zhì)量，瀑布模型軟件開發(fā)在每個階段都要完成規(guī)定的文檔，每個階段都要對已完成

4、的文檔進行復(fù)審，以便及早發(fā)現(xiàn)隱患，排除故障。 快速原型快速原型正確的需求定義是系統(tǒng)成功關(guān)鍵。軟件開發(fā)人員需要反復(fù)多次地和用戶交流信息，才能全面、準(zhǔn)確地了解用戶的要求。理想的做法是先根據(jù)需求分析的結(jié)果開發(fā)一個原型系統(tǒng)，請用戶試用一段時間，以便能正確地認(rèn)識到他們的實際需要是什么，這相當(dāng)于工程上先制作“樣品”試用后，作適當(dāng)改進，然后再批量生產(chǎn)一樣，這就是快速原型法。雖然此法要額外花費一些成本，但是可以盡早獲得更正確完整的需求，可以減少測試和調(diào)試的工作量，提高軟件質(zhì)量。因此快速原型法使用得當(dāng)，能減少軟件的總成本，縮短開發(fā)周期，是目前比較流行的實用開發(fā)模式。根據(jù)建立原型的目的不同，實現(xiàn)原型的途徑也有所不

5、同，通常有下述三種類型。 (1)漸增型 (2)用于驗證軟件需求的原型(3)用于驗證設(shè)計方案的原型 快速原型（續(xù)）快速原型（續(xù)）類型之一類型之一先選擇一個或幾個關(guān)鍵功能，建立一個不完全的系統(tǒng)，此時只包含目標(biāo)系統(tǒng)的一部分功能或?qū)δ繕?biāo)系統(tǒng)的功能從某些方面作簡化，通過運行這個系統(tǒng)取得經(jīng)驗，加深對軟件需求的了解，逐步使系統(tǒng)擴充和完善。如此反復(fù)進行，直到軟件人員和用戶對所設(shè)計的軟件系統(tǒng)滿意為止。 漸增型開發(fā)的軟件系統(tǒng)是逐漸增長和完善的，所以從整體結(jié)構(gòu)上不如瀑布型方法開發(fā)的軟件那樣清晰。但是，由于漸增型開發(fā)過程自始至終都有用戶參與，因而可以及時發(fā)現(xiàn)問題加以修改，可以更好地滿足用戶需求。 快速原型（續(xù)）快速原

6、型（續(xù)）類型之二類型之二系統(tǒng)分析人員在確定了軟件需求之后，從中選出某些應(yīng)驗證的功能，用適當(dāng)?shù)墓ぞ呖焖贅?gòu)造出可運行的原型系統(tǒng)，由用戶試用和評價。這類原型往往用后就丟棄，因此構(gòu)造它們的生產(chǎn)環(huán)境不必與目標(biāo)系統(tǒng)的生產(chǎn)環(huán)境一致，通常使用簡潔而易于修改的超高級語言對原型進行編碼。 快速原型（續(xù)）快速原型（續(xù)）類型之三類型之三為了保證軟件產(chǎn)品的質(zhì)量，在總體設(shè)計和詳細(xì)設(shè)計過程中，用原型來驗證總體結(jié)構(gòu)或某些關(guān)鍵算法。如果設(shè)計方案驗證完成后就將原型丟棄，則構(gòu)造原型的工具不必與目標(biāo)系統(tǒng)的生產(chǎn)環(huán)境一致。如果想把原型作為最終產(chǎn)品的一部分，原型和目標(biāo)系統(tǒng)可使用同樣的程序設(shè)計語言?？焖僭蔚拈_發(fā)過程快速原形的開發(fā)過程原 型

7、 設(shè) 計編碼系統(tǒng)定義與用戶需求分析測試原型產(chǎn)品系統(tǒng)的設(shè)計實現(xiàn)完善原型第三課時第一章第三課時第一章第三課時噴泉模型軟件重用模型噴泉模型噴泉模型演化集成測試編程設(shè)計分析噴泉模型原理圖 基于噴泉模型，基于噴泉模型，hodgehodge等人提出將軟件開發(fā)過程等人提出將軟件開發(fā)過程劃分為概念模型分析、系統(tǒng)設(shè)計、對象設(shè)計與實現(xiàn)、劃分為概念模型分析、系統(tǒng)設(shè)計、對象設(shè)計與實現(xiàn)、測試和系統(tǒng)組裝集成等五個階段，它也體現(xiàn)出分析測試和系統(tǒng)組裝集成等五個階段，它也體現(xiàn)出分析和設(shè)計之間的重疊和設(shè)計之間的重疊 概念模型分析：這個階段主概念模型分析：這個階段主要目標(biāo)是建立系統(tǒng)模型。系統(tǒng)模型中的對象是現(xiàn)實要目標(biāo)是建立系統(tǒng)模型。

8、系統(tǒng)模型中的對象是現(xiàn)實世界中的客觀對象的抽象，應(yīng)結(jié)構(gòu)清晰、易于理解、世界中的客觀對象的抽象，應(yīng)結(jié)構(gòu)清晰、易于理解、易于描述其規(guī)范。在分析階段面向問題域，建立起易于描述其規(guī)范。在分析階段面向問題域，建立起對象模型和過程模型。對象模型和過程模型。系統(tǒng)設(shè)計：給出模型對象系統(tǒng)設(shè)計：給出模型對象和過程的規(guī)范描述。和過程的規(guī)范描述。對象設(shè)計與實現(xiàn)：面向?qū)ο髮ο笤O(shè)計與實現(xiàn)：面向?qū)ο笤O(shè)計方法強調(diào)軟件模塊的再用和軟件合成，因而在設(shè)計方法強調(diào)軟件模塊的再用和軟件合成，因而在對象設(shè)計和實現(xiàn)時，并不要求所有的對象都從頭開對象設(shè)計和實現(xiàn)時，并不要求所有的對象都從頭開始設(shè)計，而是充分利用以前的設(shè)計工作。在軟件開始設(shè)計，而

9、是充分利用以前的設(shè)計工作。在軟件開發(fā)時檢索對象庫，若是對象庫中已有的，則可再用；發(fā)時檢索對象庫，若是對象庫中已有的，則可再用；否則，重新定義新的對象，進行設(shè)計和實現(xiàn)。否則，重新定義新的對象，進行設(shè)計和實現(xiàn)。測測試；測試所有的對象及對象相互之間的關(guān)系是否符試；測試所有的對象及對象相互之間的關(guān)系是否符合要求。合要求。 噴泉模型（續(xù)）噴泉模型（續(xù)）系統(tǒng)組裝集成：面向?qū)ο筌浖攸c之一是軟件重用和組裝技術(shù)。對象是數(shù)據(jù)和操作的封裝載體，組裝在一起才構(gòu)成完整的系統(tǒng)。軟件是對象模塊的復(fù)合，而軟件設(shè)計是對象模塊經(jīng)過進程控制而構(gòu)造生成。軟件重用模型軟件重用模型旨在開發(fā)具有各種一般性功能的軟件模塊，將它們組成軟件重

10、用庫，這些模塊設(shè)計時考慮其適應(yīng)各種界面的接口規(guī)格，可供軟件開發(fā)時利用。主要優(yōu)點是減少軟件生產(chǎn)中的重復(fù)開發(fā)，避免軟件開發(fā)人員的大量重復(fù)勞動，提高開發(fā)效率，縮短開發(fā)周期，降低開發(fā)成本。軟件重用庫的模塊不僅要便于選擇使用，而且還應(yīng)具有允許擴充、積累其成分的性能。軟件重用分兩種：(1)重用程序以各種源程序形式存庫；(2)重用程序是經(jīng)過編譯的目標(biāo)程序。軟件重用模式開發(fā)過程如下： 設(shè)計重用庫模塊：重用庫中的模塊要經(jīng)歷模塊定義、功能規(guī)格描述、模塊設(shè)計、編碼、模塊功能測試、模塊登記、模塊目錄編制，此后可放人重用庫中。軟件系統(tǒng)設(shè)計：在重用庫建立后，軟件系統(tǒng)的設(shè)計步驟如下：需求分析，功能定義、設(shè)計，在重用庫中選擇

11、模塊，編碼，測試，驗收，運行維護。 第四課時第一章第四課時第一章第四課時噴泉模型軟件工程的任務(wù)與研究范圍軟件開發(fā)的原則與開發(fā)方法返回噴泉模型噴泉模型瀑布模型要求在軟件開發(fā)的初期就完全確定軟件的需求，這在很多情況下往往是做不到的。螺旋模型試圖克服瀑布模型的這一不足。sm把軟件開發(fā)過程安排為逐步細(xì)化的螺旋周期序列，每經(jīng)歷一個周期，系統(tǒng)就細(xì)化和完善一些。sm每螺旋周期由六個步驟組成： (1)確定任務(wù)目標(biāo)： 根據(jù)初始需求分析項目計劃，確定任務(wù)目標(biāo)、可選方案和限制。(2)選擇對象：對各種軟硬件設(shè)備、開發(fā)方法、技術(shù)、開發(fā)工具、人員、開發(fā)管理等對象進行選擇：并決定軟件是進行研制、購買還是利用現(xiàn)有的。(3)分

12、析約束條件：軟件開發(fā)的時間、經(jīng)費等限制條件。(4)風(fēng)險分析：評估目標(biāo)、對象、約束條件三者之間的聯(lián)系，列出可能出現(xiàn)的問題及問題的嚴(yán)重程度等，把最重要的問題作為尚未解決的關(guān)鍵問題的風(fēng)險。(5)制定消除風(fēng)險的方法：應(yīng)有詳盡的說明和周密的計劃，并估計可能產(chǎn)生的后果。依此來開發(fā)軟件，為制訂下一周期的計劃打下基礎(chǔ)。(6)制定下一周期的工作計劃：在第一個螺旋周期，確定目標(biāo)、選擇對象、分析約束，通過風(fēng)險分析制訂消除風(fēng)險的方法，初步開發(fā)原型1，制定系統(tǒng)生存周期計劃。 噴泉模型（續(xù)）噴泉模型（續(xù)）在第二個螺旋周期，進一步明確系統(tǒng)的目標(biāo)、開發(fā)方案及約束條件，通過風(fēng)險分析制定消除風(fēng)險的方法，在原型1的基礎(chǔ)上開發(fā)原型2

13、。進一步明確軟件需求，進行需求確認(rèn)，修改開發(fā)計劃。 在第三個螺旋周期，再進一步確認(rèn)系統(tǒng)目標(biāo)、開發(fā)方案及約束條件，進行風(fēng)險分析，制訂進一步消除風(fēng)險的方法，在原型2的基礎(chǔ)上開發(fā)原型3。此時可進行產(chǎn)品設(shè)計，再對設(shè)計進行驗證和確認(rèn)，制訂集成測試計劃。在第四個螺旋周期，軟件開發(fā)方案、系統(tǒng)目標(biāo)和約束條件得到確定，在風(fēng)險分析的基礎(chǔ)上，開發(fā)具有實用價值的可操作性原型，此時可對產(chǎn)品進行詳細(xì)設(shè)計，進入編碼、單元測試、集成測試階段，最后進入驗收測試，驗收合格后交付用戶使用，進入運行、維護階段。 噴泉模型原理圖逐步執(zhí)行評價方案，標(biāo)識、消除風(fēng)險計 劃 下 階 段工作運行維護驗證測試集成測試單元測試編碼詳細(xì)設(shè)計風(fēng) 險 分

14、析集成測試計劃設(shè)計驗證與確認(rèn)產(chǎn)品設(shè)計原型3風(fēng)險分析開 發(fā) 計劃需求確認(rèn)軟件需求原型2風(fēng)險分析需求計劃生存周期計劃確 定 目標(biāo)方 案 約束原型1風(fēng)險分析操作性原型確定目標(biāo)方案與約束螺旋模型的開發(fā)過程開發(fā)驗證下一級產(chǎn)品軟件工程的任務(wù)與研究范圍軟件工程的任務(wù)與研究范圍軟件產(chǎn)品的特點軟件工程的研究內(nèi)容與方法軟件工具與軟件支撐環(huán)境軟件管理軟件開發(fā)的原則與方法軟件開發(fā)的原則與方法軟件開發(fā)的原則自頂向下與模塊結(jié)構(gòu)軟件開發(fā)的方法1.非自動形式的系統(tǒng)開發(fā)方法（1）系統(tǒng)流程圖（2）結(jié)構(gòu)分析法（3）結(jié)構(gòu)化設(shè)計法（4）數(shù)據(jù)結(jié)構(gòu)法（5）層次輸入處理輸出方法(hipo法) 2.半自動形式的系統(tǒng)開發(fā)方法（1）軟件需求工程法

15、（2）問題說明語言與分析法 3. 自動形式的系統(tǒng)開發(fā)方法 （hos方法）：由計算機自動確定規(guī)范、自動分析、自動編程、自動執(zhí)行與模擬，以規(guī)范語言axes、資源分配工具rta為工具。能自動進行分析、設(shè)計，工作量少、設(shè)計規(guī)范，也能自動進行修改和維護。該方法適用于系統(tǒng)分析和設(shè)計。第二章第一課時第二章第一課時問題定義與可行性研究問題定義可行性研究問題定義問題定義問題是指用戶的基本要求，就是確切地定義用戶要求解決的問題，即確定問題的性質(zhì)、工程的目標(biāo)和規(guī)模。怎樣定義問題？問題定義的來源是用戶，是提出問題、請求解決的人。若問題是以書面形式提出來，那么分析員應(yīng)該認(rèn)真閱讀和分析書面材料；如果問題是以口頭形式提出，

16、那么分析員應(yīng)該認(rèn)真傾聽并仔細(xì)記錄要點，在適當(dāng)?shù)臅r候認(rèn)真地請用戶解釋。分析員還應(yīng)該通過對用戶的訪問調(diào)查進一步搞清楚，用戶為什么提出這樣的問題，問題的背景是什么，用戶的目標(biāo)是什么。問題定義的目的是要在短時間內(nèi)，對用戶的要求有一個比較準(zhǔn)確的估計，對要實現(xiàn)的系統(tǒng)規(guī)模做到胸中有數(shù)。但僅有這些還不夠，還要搞清用戶不打算干什么，在這個系統(tǒng)中哪些內(nèi)容不用實現(xiàn)。工作的宗旨是搞清要做什么并劃清要實現(xiàn)的系統(tǒng)的范圍邊界。在完成問題定義的過程中，用戶在一開始，可能會給你大堆大堆的表格，因為他們可能認(rèn)為只要把表格給你講清楚，你就會對這個問題定義（續(xù)）問題定義（續(xù)）系統(tǒng)全部弄清楚了。還有一些人可能會給你展示一些企業(yè)的十分詳

17、盡的管理示圖，如物資流管理圖、生產(chǎn)管理圖、計劃財務(wù)管理圖等。因為他們也可能認(rèn)為，只要分析員把這些圖看懂了，就會對他們要建立的系統(tǒng)搞清楚了。但是，在問題定義階段千萬不要陷入到這些表格和圖紙中。因為不管是表格還是圖紙，其中都包含了大量的、只有用戶才能懂的術(shù)語。當(dāng)然，并不是說在問題定義階段，這些圖紙表格沒有一點作用。對一些關(guān)鍵性的語匯可以請用戶講清楚，這樣有利于問題定義的準(zhǔn)確性。 總之，在問題定義階段，分析員應(yīng)盡可能站在較高的角度去抽象、概括所要干的事情。 分析員對問題有了明確認(rèn)識之后，應(yīng)該把自己的認(rèn)識寫成書面報告，提交給用戶和使用部門的負(fù)責(zé)人審查，以檢驗分析員對所要解決的問題的理解是否正確。因為分

18、析員對問題的理解為今后開發(fā)工作確定了方向。分析員對問題理解正確，這是確保今后系統(tǒng)開發(fā)成功的關(guān)鍵。反之，分析員對問題理解不正確，最終開發(fā)出來的問題定義（續(xù)）問題定義（續(xù)）系統(tǒng)必然不能解決實際要求解決的問題。如果一個系統(tǒng)，不能解決要求它解決的問題，那么這個系統(tǒng)就一點價值也沒有，只不過是浪費了開發(fā)它所用的時間和資源。所以及時審查問題的定義是極端重要的。理想的做法是分析員、用戶和使用部門的負(fù)責(zé)人一起閱讀討論這份報告，明確含糊不清的地方，改正不正確的地方。通過修改得到一份大家一致同意的文檔。 在問題定義階段，分析員應(yīng)該對工程成本做出粗略的預(yù)算，并對下階段可行性研究所需要時間和成本做出較精確的估計。 對問

19、題定義的書面報告應(yīng)該盡可能清楚簡潔，最好寫在一頁內(nèi)。這份報告通常應(yīng)包括工程項目的名字，對問題概括定義、項目的目標(biāo)，項目的規(guī)模，對可行性研究的具體建議(既需要用的時間和成本)等等。 一旦分析員和用戶及使用部門的負(fù)責(zé)人對所要解決的問題，取得完全一致的看法且在報告書上簽了字，問題定義階段工作就宣告完成，可行性研究就可以開始?？尚行匝芯靠尚行匝芯克^可行性研究就是分析員站在較高的角度去調(diào)查現(xiàn)行手工系統(tǒng)及用戶提出的項目目標(biāo)，并且去尋找是否有一種手段能夠在現(xiàn)有條件下，實際地達到項目目標(biāo)，并使用戶滿意。同時向用戶指出該系統(tǒng)實現(xiàn)的意義，以使用戶去權(quán)衡花費這樣的代價去實現(xiàn)這樣的系統(tǒng)是否值得。 可行性研究的目的就

20、是用最小的代價在盡可能短的時間內(nèi)，確定問題是否能夠解決，從而確定問題是否值得去解。如何才能達到這個目的呢？進行客觀分析，通過對幾種可能解法，分析其利弊，才能判斷原定系統(tǒng)的目標(biāo)和規(guī)模是否現(xiàn)實，系統(tǒng)完成后所能帶來的效益是否大到值得投資開發(fā)這個系統(tǒng)的程序。因此，可行性研究實質(zhì)上是進行一個大大壓縮簡化了的軟件分析和設(shè)計過程，也就是在較高層上，以較抽象的方式進行軟件分析和設(shè)計的過程?？尚行匝芯繎?yīng)在以下三方面進行：技術(shù)可行性；經(jīng)濟可行性；操作可行性。可行性研究（續(xù)）可行性研究（續(xù)）1.技術(shù)可行性 對技術(shù)可行性研究，首先應(yīng)從對現(xiàn)行系統(tǒng)進行調(diào)查入手。因為現(xiàn)行系統(tǒng)是信息的重要來源。顯然，如果目前有一個系統(tǒng)正被人

21、使用，那么這個系統(tǒng)必定能完成某些有用的工作，因此，新的目標(biāo)系統(tǒng)必須也能完成它的基本功能；另一方面，如果現(xiàn)行系統(tǒng)是完美無缺的，用戶自然不會提出開發(fā)新的系統(tǒng)要求，因此，現(xiàn)行系統(tǒng)必然有某些缺點。新系統(tǒng)必須能解決舊系統(tǒng)中存在的問題。所以，應(yīng)先對現(xiàn)行系統(tǒng)的組成部分、功能和存在問題進行調(diào)查研究。但這種調(diào)查研究不可能做得很細(xì)，對一些內(nèi)容細(xì)節(jié)必須先把它們暫時忽略，而先抓住主要的問題。此時，分析員應(yīng)把調(diào)查到的現(xiàn)行系統(tǒng)的情況畫成高層數(shù)據(jù)流程圖(數(shù)據(jù)流程圖的畫法在第三章介紹)。其次，導(dǎo)出新系統(tǒng)的高層邏輯模型(數(shù)據(jù)流程圖)。新系統(tǒng)的高層的邏輯模型建立在現(xiàn)行系統(tǒng)的高層數(shù)據(jù)流程圖的基礎(chǔ)上。因為通過前一步的工作，分析員對目

22、標(biāo)系統(tǒng)(新系統(tǒng))應(yīng)該具的基本功能和所受的約束，已有一定的了解，使用數(shù)據(jù)流程圖描繪數(shù)據(jù)在系統(tǒng)中可行性研究（續(xù)）可行性研究（續(xù)）流動和處理的情況，從而概括地表達出對新系統(tǒng)的設(shè)想。用數(shù)據(jù)流程圖和數(shù)據(jù)字典來定義新系統(tǒng)的高層邏輯模型。其三，重新定義問題。新系統(tǒng)的邏輯模型實質(zhì)上表達了分析員對新系統(tǒng)必須做什么的看法。此時，分析員應(yīng)該和用戶一起復(fù)查問題定義、工程規(guī)模和目標(biāo)。這次復(fù)查應(yīng)該把數(shù)據(jù)流程圖和數(shù)據(jù)字典作討論的基礎(chǔ)。如果分析員對問題有誤解或者用戶曾經(jīng)遺漏了某些要求，那么現(xiàn)在是發(fā)現(xiàn)和改正這些錯誤的時候了。其四，導(dǎo)出供選擇的解法。分析員應(yīng)從他所建議的系統(tǒng)邏輯模型出發(fā)，推導(dǎo)出若干個較高層次的解決辦法，供比較和選

23、擇。最簡單的途徑，是從技術(shù)角度出發(fā)，考慮解決問題的不同方案。這些不同方案可以在數(shù)據(jù)流程圖上劃分不同的自動化邊界而得到。所以分析員在確定了幾組不同的自動化邊界之后，再針對每組邊界，考慮如何實現(xiàn)所要求的系統(tǒng)。當(dāng)從技術(shù)角度提出了一些系統(tǒng)模型之后，應(yīng)根據(jù)技術(shù)可行性的考慮，初步排除一些不現(xiàn)實的系統(tǒng)。例如，如果要求系統(tǒng)的響應(yīng)時間可行性研究（續(xù)）可行性研究（續(xù)）不超過幾秒鐘，顯然應(yīng)該排除任何批處理方案。把技術(shù)上行不通的解法(方案)去掉之后，就剩下了一組技術(shù)上可行的方案。也就是根據(jù)現(xiàn)有的技術(shù)條件,考慮所提出的方案是否能實現(xiàn)。例如現(xiàn)有的計算機是否能達到所要求的速度,現(xiàn)有的輸入輸出設(shè)備能否承擔(dān)得了要求的數(shù)據(jù)輸入輸

24、出量。一般來說，技術(shù)可行性還可以從硬件(包括外圍設(shè)備)的性能要求、軟件的性能要求(包括操作系統(tǒng)、軟件包、數(shù)據(jù)庫管理系統(tǒng)、各種軟件工具)能源及環(huán)境條件以及軟件系統(tǒng)所采用的技術(shù)是否先進，實現(xiàn)的可能性如何，實現(xiàn)軟件系統(tǒng)的人員素質(zhì)是否具備等方面進行考慮。2.經(jīng)濟可行性研究經(jīng)濟可行性，不僅僅是了解為完成用戶提出的要求是否有足夠的資金支持(這是目前很多分析員重點要做的事情)，而更主要是把成本與獲利分析清楚。也就是對經(jīng)濟合理性進行評價，即帶來的經(jīng)濟效益是否超過其開發(fā)和維護所需要的費用。這工作包括估計費用和估計效益兩個方面。可行性研究（續(xù)）可行性研究（續(xù)）估計費用。主要考慮以下幾部分：設(shè)備費用，包括計算機硬件

25、和軟件的費用；人力費用，包括開發(fā)人員和維護人員的工資；材料費用；管理費用以及維護費用等。估計效益?？梢詮囊韵聨讉€方面考慮：提供了哪些以前提供不了的信息，提供信息的速度提高了多少？質(zhì)量有什么提高？對使用者查詢和使用信息的方便程度有什么提高，節(jié)省多少人力？對組織的領(lǐng)導(dǎo)人和管理人員正確做出決策提供了哪幫助？有時不能直接用金錢來衡量效益，如一個郵購單位，由于能夠及時、準(zhǔn)確地處理訂貨，縮短了顧客收到貨物的時間，從而在競爭中得到了更多的顧客。這一類的收益就不容易用具體金錢來衡量，只能由管理人員根據(jù)經(jīng)驗來做出大約的估計。在估計效益時，要謹(jǐn)慎把各種可能影響效益發(fā)揮的各種因素考慮在內(nèi)，打上折扣。3.操作和維護可

26、行性人員操作和維護可行性的研究是了解當(dāng)用戶所要求的軟件系統(tǒng)可行性研究（續(xù)）可行性研究（續(xù)）建立起來之后 ，用戶對它的操作是否方便？管理和維護是否容易？如果對于一個軟件系統(tǒng)的操作比原有的手工系統(tǒng)還麻煩，那么它是不會受歡迎的。另一方面，如果管理和維護這個軟件系統(tǒng)的人員比原來的手工系統(tǒng)還多，素質(zhì)要求還高，那么這個系統(tǒng)對用戶來說負(fù)擔(dān)太重了。 對于人員操作和維護的可行性，一般可從兩個方面來考慮：一方面從技術(shù)的角度，研究是否能夠給用戶提供一個方便的操作環(huán)境；另一方面從設(shè)備的選擇上來考慮，看看為了完成用戶要求的功能，是否能夠找到一些易于管理和維護的設(shè)備。 從上面的討論中不難看出，可行性研究的出發(fā)點應(yīng)該是從當(dāng)

27、前的物理系統(tǒng)到新的物理系統(tǒng)的轉(zhuǎn)換，它是整個可行性研究的基礎(chǔ)，實際上也是整個系統(tǒng)開發(fā)過程的縮影。因為整個系統(tǒng)實現(xiàn)過程也就是把當(dāng)前的手工系統(tǒng)轉(zhuǎn)化為可用計算機實現(xiàn)的新系統(tǒng)的一個轉(zhuǎn)換過程，只不過這工作比在可行性研究階段更細(xì)致，更具體罷了。 上述從三個方面分別開展的，而實際上它們之間有著密切的聯(lián)系，因此還必須對它們綜合考慮，然后向用戶推薦方案供其選擇。 可行性研究（續(xù)）可行性研究（續(xù)）當(dāng)用戶選定方案之后，分析員應(yīng)對在問題定義階段所規(guī)定的實現(xiàn)目標(biāo)進行修改。因為，這時對系統(tǒng)有了更深入的了解，原來的問題定義可能有的不能實現(xiàn)，還有些需要加上去，也就是說原有的問題邊界不夠準(zhǔn)確，需要糾正，以便今后有一個非常明確的工

28、作目標(biāo)。這是一步極有實質(zhì)意義的工作，它使分析員和用戶最后明確了要解決的問題的邊界以及它的實現(xiàn)方案。一般來說，可行性研究的結(jié)果可導(dǎo)致以下兩種情況：(1) 可行()不可行可行性研究結(jié)束后，要寫出可行性研究報告，提交有關(guān)專家論證和上級主管部門批準(zhǔn)?？尚行匝芯繄蟾孀鳛樗熊浖募Y料的基礎(chǔ)材料，它的格式可以很不相同，但大體的內(nèi)容提綱是一致的。 可行性研究（續(xù)）可行性研究（續(xù)）可行性研究報告的內(nèi)容提綱： (1)背景情況 國內(nèi)外水平、歷史現(xiàn)狀、市場需求。 （2)系統(tǒng)描述 總體方案和技術(shù)路線、課題分解、關(guān)鍵技術(shù)、計劃目標(biāo)和階段目標(biāo)。 (3)價格利益分析 經(jīng)濟可行性，包括經(jīng)費概算和預(yù)期經(jīng)濟效益。 (4)技術(shù)冒

29、險評價 技術(shù)可行性，包括技術(shù)實力、設(shè)備條件和已有工作基礎(chǔ)。 (5)操作方便性評價 操作可行性，一方面從技術(shù)的角度，另一方面從設(shè)備的選擇上考慮。 (6)其他與項目有關(guān)的問題 根據(jù)可行性研究結(jié)果，如果是可行的，那么對這項開發(fā)工程就繼續(xù)進行。此時，分析員應(yīng)對開發(fā)工程制訂一份軟件計劃。這樣，開發(fā)工作轉(zhuǎn)到下一階段。第二課時第二章第二課時第二章第二課時軟件計劃軟件工作范圍（軟件功能、性能、可靠性和接口等問題的描述）資源（軟件、硬件與人力資源）成本估算代碼行技術(shù)任務(wù)分解技術(shù)軟件計劃任務(wù)書的書寫規(guī)范第三課時第二章第三課時第二章第三課時軟件計劃任務(wù)書案例學(xué)分管理系統(tǒng)軟件計劃任務(wù)書項目開發(fā)進度月報編寫規(guī)范上述內(nèi)容

30、請參看書本相應(yīng)頁面的內(nèi)容！返回第三章第一課時第三章第一課時需求分析的定義軟件需求分析(軟件要求分析)是在可行性研究基礎(chǔ)上進行的更細(xì)致的分析工作，是對軟件計劃階段建立的軟件工作范圍的求精和細(xì)化。也就是在對軟件計劃階段確定的工作范圍內(nèi)進一步對目標(biāo)對象和環(huán)境作細(xì)致、深入的調(diào)查分析。需求分析過程實際上是一個調(diào)查研究、分析綜合的過程，是一個抽象思維、邏輯推理的過程。通過調(diào)查研究和分析，充分了解用戶對軟件系統(tǒng)的要求。在此基礎(chǔ)上，把用戶要求表達出來，解決軟件系統(tǒng)“做什么”的問題。也就是建立起系統(tǒng)的邏輯模型，把軟件功能和性能的總體概念描述成具體的軟件規(guī)格說明書。 需求分析的目標(biāo)（1.理清數(shù)據(jù)流或數(shù)據(jù)結(jié)構(gòu)；2.

31、通過標(biāo)識接口細(xì)節(jié)，深入描述功能，確定設(shè)計約束和軟件有效性要求；3.構(gòu)造一個完全、精致的目標(biāo)系統(tǒng)邏輯模型。 ）需求分析的任務(wù)（認(rèn)清問題、分析與綜合、邏輯模型導(dǎo)出與復(fù)審）結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法的策略基本的系統(tǒng)模型結(jié)構(gòu)化分析方法策略分析.輸 入1.軟件系統(tǒng)輸出1輸出2輸出3輸 入.x1231.12.23.33.13.23.43.5頂層0層1層3.3逐層分解方法示意圖結(jié)構(gòu)化分析方法（續(xù)）結(jié)構(gòu)化分析方法（續(xù)）數(shù)據(jù)流圖數(shù)據(jù)流圖數(shù)據(jù)流圖的定義數(shù)據(jù)流圖的組成要素：源點、終點、數(shù)據(jù)流、數(shù)據(jù)文件、數(shù)據(jù)變換數(shù)據(jù)變換的兩種類型：對數(shù)據(jù)結(jié)構(gòu)的變換，如對數(shù)據(jù)的格式重新排列。在原有數(shù)據(jù)內(nèi)容

32、基礎(chǔ)上產(chǎn)生新的數(shù)據(jù)內(nèi)容，如計算平均值或總計。數(shù)據(jù)流圖的畫法、畫數(shù)據(jù)流圖的基本原則（數(shù)據(jù)流程圖中的圖形符號只能包含四種基本元素。數(shù)據(jù)流程圖主圖上的數(shù)據(jù)流必須封閉在外部實體（外部項）之間，實體可以是一個也可是多個。變換框上至少有一個輸出數(shù)據(jù)流和一個輸入數(shù)據(jù)流。數(shù)據(jù)流程圖上的每一個元素都必須有“名字”。）、方法與步驟（參見書本相關(guān)內(nèi)容）注意事項（父子圖的平衡、分解程度與數(shù)據(jù)存儲文件，數(shù)據(jù)流圖是靜態(tài)圖、與傳統(tǒng)框圖的差別、反復(fù)修改的過程）第二課時第三章第二課時第三章第二課時數(shù)據(jù)字典、數(shù)據(jù)字典的定義（數(shù)據(jù)字典就是對數(shù)據(jù)流程圖中，數(shù)據(jù)、變換等進行精確定義。 ）、數(shù)據(jù)定義方法（對數(shù)據(jù)自頂向下的分解。當(dāng)分解到不

33、需要進一步定義，對每個和系統(tǒng)有關(guān)的人都能清楚理解這些數(shù)據(jù)項的含義為止。 ）、數(shù)據(jù)定義中的數(shù)據(jù)結(jié)構(gòu)（順序、選擇、重復(fù)、可選 ）、數(shù)據(jù)字典中的符號（ 表示等價、十 表示和(或連接兩個分量)、 表示重復(fù)花括號內(nèi)的分量、| 表示或即從方括弧內(nèi)列出的若干分量中選擇一個、( ) 表示可選即或括弧里的量可有可無、n.m 表示界域 ）、數(shù)據(jù)流、數(shù)據(jù)存儲、數(shù)據(jù)變換的定義（參見書本相關(guān)內(nèi)容）第三課時第三章第三課時第三章第三課時結(jié)構(gòu)化分析的步驟1.研究目前正在使用的系統(tǒng) 現(xiàn)有的系統(tǒng)(包括人工系統(tǒng))是信息的重要來源。因此，首先要去了解現(xiàn)有系統(tǒng)能完成哪些工作(即功能)，而新的目標(biāo)系統(tǒng)必須也能完成它的基本功能；另一方面，

34、既然提出要開發(fā)新的系統(tǒng)，那么現(xiàn)有的系統(tǒng)必定存在某些問題，而新的目標(biāo)系統(tǒng)必須能夠解決舊系統(tǒng)中存在的問題，也就是給新的目標(biāo)系統(tǒng)提出了新的要求(即功能要求)，所以了解現(xiàn)有系統(tǒng)是開發(fā)新的目標(biāo)系統(tǒng)的基礎(chǔ)。對現(xiàn)有系統(tǒng)(人工系統(tǒng))的了解，是要了解對現(xiàn)有系統(tǒng)能做什么，同時畫出描繪現(xiàn)有系統(tǒng)的高層數(shù)據(jù)流程圖。2.導(dǎo)出新系統(tǒng)的高層數(shù)據(jù)流程圖(即邏輯模型) 好的設(shè)計，通?？偸菑默F(xiàn)有系統(tǒng)出發(fā)導(dǎo)出現(xiàn)有系統(tǒng)的邏輯模型，然后參考現(xiàn)有系統(tǒng)的邏輯模型，設(shè)想出新系統(tǒng)的邏輯模型。 通常第一步的工作，對新的目標(biāo)系統(tǒng)應(yīng)該具有的基本功能和所結(jié)構(gòu)化分析步驟（續(xù)）結(jié)構(gòu)化分析步驟（續(xù)）受的約束條件，已有一定的了解，把這些了解用數(shù)據(jù)流程圖概括地描

35、繪出對新系統(tǒng)的設(shè)想。同時定義系統(tǒng)中使用的數(shù)據(jù)，構(gòu)造初步的數(shù)據(jù)字典。這樣，數(shù)據(jù)流程圖和數(shù)據(jù)字典共同定義了新的目標(biāo)系統(tǒng)的高層邏輯模型。(在可行性研究階段完成)3.完善數(shù)據(jù)流程圖 在第二步畫出新系統(tǒng)的高層數(shù)據(jù)流程圖中，許多數(shù)據(jù)的定義和一些細(xì)節(jié)都沒有考慮進去?，F(xiàn)在應(yīng)著手解決這個問題。 （1）沿著數(shù)據(jù)流程圖回溯 為了對數(shù)據(jù)流程圖中的數(shù)據(jù)流和數(shù)據(jù)存儲進行定義，通常是從數(shù)據(jù)流程圖的輸出端著手分析。這是因為軟件系統(tǒng)的目標(biāo)是產(chǎn)生這些輸出，輸出數(shù)據(jù)確定了軟件系統(tǒng)必須具有的最基本的組成元素。 輸出數(shù)據(jù)是由哪些數(shù)據(jù)項組成的，通過調(diào)查訪問是不難搞清這個問題。那么每個輸出數(shù)據(jù)項又是從哪里來的呢?因為它是新系統(tǒng)的輸出，那么

36、它們或者是從外面輸入到系統(tǒng)中來，或者是通過運算結(jié)構(gòu)化分析步驟（續(xù)）結(jié)構(gòu)化分析步驟（續(xù)）由系統(tǒng)中產(chǎn)生出來的。為了弄清這些，可以沿著數(shù)據(jù)流程圖從輸出端往輸入端回溯，能夠確定每個數(shù)據(jù)項的來源，與此同時也就初步定義了有關(guān)的算法。 在第二步得到的高層數(shù)據(jù)流程圖中，許多具體細(xì)節(jié)沒有包括在里面。因此，當(dāng)沿著數(shù)據(jù)流程圖回溯時，經(jīng)常會遇到：為了得到某個數(shù)據(jù)項需要用到數(shù)據(jù)流程圖中目前還沒有的數(shù)據(jù)項，或者得出這個數(shù)據(jù)項要用的算法還不完全清楚。為了解決這些問題，需要向用戶和有關(guān)人員請教，他們的回答使分析員對新系統(tǒng)的認(rèn)識更具體更深入了。系統(tǒng)中更多的數(shù)據(jù)項被劃分出來，更多的算法被搞清楚了。一般把分析過程得到的有關(guān)數(shù)據(jù)項的

37、信息、變換的算法簡明地記在數(shù)據(jù)字典中。 （2）用戶復(fù)查 通過沿著數(shù)據(jù)流程圖的回溯過程，把一些數(shù)據(jù)項和變換的算法記錄到數(shù)據(jù)字典中。這個數(shù)據(jù)字典是否準(zhǔn)確完整?算法是否正確?還有沒有必要的變換和數(shù)據(jù)項遺漏了?某些數(shù)據(jù)項的來源搞清楚嗎?結(jié)構(gòu)化分析步驟（續(xù)）結(jié)構(gòu)化分析步驟（續(xù)）對這些問題必須請系統(tǒng)的用戶(直接在這個系統(tǒng)上工作的)對前面步驟得出的結(jié)果仔細(xì)地進行復(fù)查?？梢越柚跀?shù)據(jù)流程圖和數(shù)據(jù)字典，從輸入端開始向用戶解釋輸入數(shù)據(jù)是怎樣一步一步地轉(zhuǎn)變成輸出數(shù)據(jù)。這些解釋集中反映了分析員通過前面分析工作，所獲得的對新目標(biāo)系統(tǒng)的認(rèn)識。這些認(rèn)識是否正確，有沒有遺漏?應(yīng)請用戶及時糾正和補充分析員的認(rèn)識。通過復(fù)查過程驗

38、證了已知的元素，補充了未知的元素。填補了文檔中的空白。 由于復(fù)查可能獲得新的知識，又可能引出新的問題。例如，對新補充進來的數(shù)據(jù)項是怎樣得出來的?它的來源是什么?這些需要進一步的調(diào)查訪問尋求對問題的解答，而且還應(yīng)及時修改和補充數(shù)據(jù)流程圖和數(shù)據(jù)字典，把對系統(tǒng)的新認(rèn)識及時記錄下來。所以，追蹤數(shù)據(jù)流程圖和復(fù)查軟件系統(tǒng)的邏輯模型實質(zhì)上構(gòu)成一個循環(huán)。對數(shù)據(jù)流程圖的分析產(chǎn)生一些問題，這些問題通過復(fù)查得到的答案使分析員對系統(tǒng)有更深人更具體的認(rèn)識，同時可能又引出新的問題，尋找這些新問題的答案導(dǎo)致了對新系統(tǒng)的更進一步的認(rèn)識這樣，每經(jīng)過一次循環(huán)都會對新系統(tǒng)了解更多的細(xì)節(jié)。結(jié)構(gòu)化分析（續(xù)）結(jié)構(gòu)化分析（續(xù)）4.分解細(xì)化

39、數(shù)據(jù)流程圖 通過上面的分析及用戶的復(fù)查，分析員對新系統(tǒng)已有了更進一步了解，此時可對數(shù)據(jù)流程圖中的各個變換進行檢查。如果某個變換的功能還比較復(fù)雜，也就是還比較抽象，就應(yīng)將這個變換功能分解成若干個子功能。這些較低層的子功能就成為一張新的數(shù)據(jù)流程圖上的變換。在新的數(shù)據(jù)流程圖中，也應(yīng)該包括自己的數(shù)據(jù)流和數(shù)據(jù)存儲。數(shù)據(jù)流程圖經(jīng)過分解之后，得到一組新的數(shù)據(jù)流程圖，在圖上，不同的軟件元素之間關(guān)系變得更清楚了。對這組新的數(shù)據(jù)流程圖的分析追蹤可能產(chǎn)生新的問題，對這些問題的解答，又可能在數(shù)據(jù)字典中增加一些新的條目，并且可能導(dǎo)致新的或精化的變換算法的描述。隨著分析過程的進展，經(jīng)過問題與解答的反復(fù)循環(huán)，分析員越來越深

40、入、具體地定義了新系統(tǒng)。通過上面各步就可以得到一套新目標(biāo)系統(tǒng)的分層數(shù)據(jù)流程圖和數(shù)據(jù)字典，也就是得到新系統(tǒng)的邏輯模型。 第四課時第三章第四課時第三章第四課時按功能逐層分解法(hipo法) hipo法的定義hipo法組成圖（參見書本上的相關(guān)內(nèi)容）圖（參見書本上的相關(guān)內(nèi)容）第五課時第三章第五課時第三章第五課時軟件需求分析報告書寫規(guī)范（參見書本的相關(guān)內(nèi)容）軟件需求分析報告案例直通車系統(tǒng)的需求分析報告（參見書本相關(guān)內(nèi)容）返回第四章第一課時第四章第一課時評價一個 “設(shè)計”的標(biāo)準(zhǔn)（有一個明確的設(shè)計步驟、良好的設(shè)計方法、鑒別優(yōu)劣的準(zhǔn)則、好的設(shè)計表示）軟件總體設(shè)計的任務(wù)（從軟件的需求規(guī)格說明書出發(fā)，將設(shè)計對象用

41、數(shù)據(jù)流或數(shù)據(jù)結(jié)構(gòu)的形式表達成完整的抽象實體。這個實體應(yīng)當(dāng)是一個結(jié)構(gòu)清晰、層次分明的模塊組合，應(yīng)當(dāng)可以被評價和細(xì)化，也可以被修改。同時還要定義這個實體與外部環(huán)境的接口。）軟件總體設(shè)計的目標(biāo) （1.軟件實體應(yīng)當(dāng)具有明顯的層次結(jié)構(gòu)，便于軟件元素之間的控制。2.軟件實體應(yīng)當(dāng)模塊化，這些摸塊應(yīng)具有完全獨立的功能。 3.軟件實體與環(huán)境的界面應(yīng)當(dāng)清晰。4.軟件設(shè)計的最終表示軟件設(shè)計規(guī)格說明應(yīng)當(dāng)清晰、簡潔、完整和無岐義。 ）軟件設(shè)計的工作流程（請參見書本上相關(guān)內(nèi)容）軟件總體設(shè)計基礎(chǔ)（模塊、軟件結(jié)構(gòu)、層次機構(gòu)的幾個特點、結(jié)構(gòu)圖、結(jié)構(gòu)圖的優(yōu)點）第二課時第四章第二課時第四章第二課時軟件模塊模塊特點（抽象與封閉性）模

42、塊獨立性的衡量（耦合和聚合 ）第三課時第四章第三課時第四章第三課時軟件的總體設(shè)計準(zhǔn)則1.評價軟件初始結(jié)構(gòu)，通過模塊的分解與合并減少模塊之間的耦合度增加聚合度在設(shè)計初始軟件結(jié)構(gòu)以后，常常會發(fā)現(xiàn)幾個模塊的功能有相似之處，這相似部分不僅增加了編程和調(diào)試的工作量，同時也給維護過程帶來麻煩，應(yīng)當(dāng)消除這樣的重復(fù)。（1）完全相似 這種情況只在數(shù)據(jù)類型上不一致，可采用完全合并，只需在數(shù)據(jù)類型的描述或變量定義上加以改進。（2）局部相似 如圖4-23(a)中，模塊q1和q2具有功能類似的組成部分和不同部分可通過模塊分解消除重復(fù)功能部分。其方法是首先找出模塊q1和q2的功能相似部分，如圖中的虛線部分，然后把這兩個模

43、塊的虛線部分分離出來，構(gòu)成它們的一個公共的下層模塊q，如圖4-23(b)軟件的總體設(shè)計準(zhǔn)則（續(xù)）軟件的總體設(shè)計準(zhǔn)則（續(xù)）所示。如果分解后余下的模塊q1和q2比較簡單，則可以同它們的各自調(diào)用模塊x和y合并，如圖4-23(c)和(d)。這樣圖4-23中的(b)、(c)、(d)都消除了重復(fù)功能的組成部分，這樣模塊間的耦合較小、模塊內(nèi)的聚合較大。（圖的內(nèi)容請參見書本的相應(yīng)頁面）在圖4-24(a)中如果模塊b與模塊c和d之間以及模塊e和f之間耦合較大，可以把模塊b、c、d合并成一個模塊abc，把模塊e和f合并成一個模塊ef，如圖4-24(b)。這樣就使得模塊間耦合減少，模塊內(nèi)聚合增加。2.模塊功能的完善

44、一個完整的功能模塊應(yīng)具有以下三個要素：(1)執(zhí)行某項指定功能的部分 (2)如果需要返回一系列的數(shù)據(jù)給它的調(diào)用者，應(yīng)在完成數(shù)據(jù)處理或結(jié)束時，告訴它的調(diào)用者“文件完”或其他標(biāo)志。(3)出錯處理部分，即在不能完成指定任務(wù)時，必須將產(chǎn)生這種例外情況的原因(出錯標(biāo)志)通知它的調(diào)用者。它們是一個功能模塊的有機組成部分，不應(yīng)當(dāng)分離到其他模塊中去，否則會增加模塊間的耦合。軟件的總體設(shè)計準(zhǔn)則（續(xù)）軟件的總體設(shè)計準(zhǔn)則（續(xù)）3.模塊調(diào)用個數(shù)最好不要超過五個一個模塊擁有的直屬下級模塊的個數(shù)叫模塊的扇出數(shù)。如果一個模塊具有過多的調(diào)用模塊，那么這個模塊扇出數(shù)就過大，如圖4-25(a)，這個模塊就往往包含過多的功能，一般是

45、因為缺乏中間層次的控制模塊，需要將其功能進行分解。如圖4-25(b)。一個模塊的直接上級模塊的個數(shù)叫模塊的扇入數(shù)。一個模塊的扇入表明有多少個上級模塊直接調(diào)用它，扇入越大，則共享該模塊的上級模塊數(shù)目越多，這是有好處的。但不能違背模塊獨立性而單純追求高扇入。4.一個模塊的作用范圍應(yīng)在其控制范圍之內(nèi)一個模塊的作用范圍就是這個模塊內(nèi)一個判定的作用范圍。一個判定的作用范圍是指所有受這個判定影響的那些模塊，只要模塊中含有一些依賴于這個判定的操作，那么這個模塊就在這個判定的作用范圍之內(nèi)。一個模塊的控制范圍包括它自己及其所有的下屬模塊。控制范圍軟件的總體設(shè)計準(zhǔn)則（續(xù)）軟件的總體設(shè)計準(zhǔn)則（續(xù)）是從結(jié)構(gòu)方面來考慮

46、的，而作用范圍是從功能方面考慮的。圖4-26給出了不同的作用范圍控制范圍結(jié)構(gòu)的實例，下面以此來討論模塊之間的聯(lián)系。圖 4-26 作用范圍不在控制范圍之內(nèi)圖 4-27 判斷所處層次太高圖4-26說明作用范圍不在控制范圍之內(nèi)，模塊b2做出判定之后，若需要模塊a工作就必須把信號回送給模塊b、y。這樣就增加了數(shù)據(jù)的傳送量和模塊間的聯(lián)系。因此，這是一個不好的設(shè)計。圖4-27中作用范圍是在控制范圍之內(nèi)，但判定所處層次太高（top），這樣經(jīng)過不必要的數(shù)據(jù)傳送，增加了傳送量，這個結(jié)構(gòu)可以用，但不太好。 圖4-28 判定分支含有不必要的穿越圖4-29 比較理想的結(jié)構(gòu)軟件的總體設(shè)計準(zhǔn)則（續(xù)）軟件的總體設(shè)計準(zhǔn)則（續(xù)

47、）圖4-28中作用范圍在控制范圍之內(nèi)，只有一個判定分支含有一個不必要的穿越，這是個較好的結(jié)構(gòu)。圖4-29中是一個較理想的好結(jié)構(gòu)。如果在設(shè)計過程中發(fā)現(xiàn)作用范圍不在控制范圍內(nèi)時，可以通過下面手段將作用范圍移到控制范圍之內(nèi)。(1)將包含判定的模塊合并到它的調(diào)用模塊中，這樣可使判定處于足夠高的層次。(2)將受判定影響的模塊下移到控制范圍之內(nèi)。(3)將判定上移到足夠高的位置。例如圖4-30(a)中判定的作用范圍不在控制范圍之內(nèi)。把含有判定的模塊d合并到它的調(diào)用模塊a中去，成了圖4-30(b)所示。這樣作用范圍就處在控制之內(nèi)。圖4-30 將包含判定的模塊合并到它的調(diào)用模塊軟件的總體設(shè)計準(zhǔn)則（續(xù)）軟件的總體

48、設(shè)計準(zhǔn)則（續(xù)）又如圖4-31(a)中的模塊x不在模塊a的控制之內(nèi)，把它下移到控制范圍之內(nèi)。如圖4-31(b)所示。圖4-31 將受到判定影響的模塊下移到控制范圍之內(nèi)5.力爭設(shè)計單入口和單出口的模塊，避免“病態(tài)聯(lián)接”一個模塊只有一個入口和一個出口時，這個模塊是比較容易理解的，有利于結(jié)構(gòu)化編制程序，也比較容易維護。但實際上這樣的模塊不多。病態(tài)聯(lián)接是指轉(zhuǎn)移到或引用到另一模塊中去的內(nèi)容耦合。要盡量避免這種病態(tài)聯(lián)接，以減少模塊間的耦合。6.力爭降低模塊接口的復(fù)雜性模塊接口復(fù)雜性是軟件發(fā)生錯誤的一個主要原因。因此，應(yīng)該仔細(xì)設(shè)計模塊接口，使得信息傳遞簡單并且和模塊功能相一致。為說明接口復(fù)雜性的影響，請看下面

49、的例子。例如，求一元二次方程的根的模塊quad-root(tbl，x)其中用數(shù)組tbl傳送方程的系數(shù)，用數(shù)組x回送求得的根。但是模塊quad-軟件的總體設(shè)計準(zhǔn)則（續(xù)）軟件的總體設(shè)計準(zhǔn)則（續(xù)）root接口tbl和x意義不明確，不利于對這個模塊的理解。因此可以將它簡化如下： quad-root(a,b,c，root1，root2)，其中，a，b，c是方程系數(shù)，root1和root2。是求出的方程的兩個根。很明顯，這樣的接口既簡單又與模塊quad-root的功能一致。在設(shè)計模塊接口時，應(yīng)盡量能設(shè)計這樣的模塊接口，以降低模塊接口的復(fù)雜性。7.模塊的大小模塊大小就是模塊含語句數(shù)量的多少。模塊的大小沒有統(tǒng)

50、一的標(biāo)準(zhǔn)。一般來說，模塊的大小以一頁左右為宜。一頁(高級語言50行左右)在一個人智力之內(nèi)，比較容易閱讀和理解。在進行模塊設(shè)計時，首先應(yīng)根據(jù)模塊的獨立性來選取模塊的規(guī)模。如果某個模塊功能是獨立的，那怕程序段較短也不要人為地加長；如果程序段只有一個獨立的功能，那怕程序較長，也不要人為地把它分解成兩個模塊。第四課時第四章第四課時第四章第四課時結(jié)構(gòu)化軟件設(shè)計結(jié)構(gòu)化軟件設(shè)計的定義與特點結(jié)構(gòu)化軟件設(shè)計的類型變換設(shè)計事物型設(shè)計綜合設(shè)計結(jié)構(gòu)化軟件設(shè)計步驟 結(jié)構(gòu)化軟件設(shè)計案例返回第五章第一課時第五章第一課時軟件詳細(xì)設(shè)計的定義：對軟件模塊的過程設(shè)計。 軟件詳細(xì)設(shè)計的任務(wù)：對總體設(shè)計所產(chǎn)生的功能模塊進行過程描述，開

51、發(fā)一個可以直接轉(zhuǎn)換成程序語言代碼的軟件表示。 軟件詳細(xì)設(shè)計的步驟：1.將總體設(shè)計產(chǎn)生的構(gòu)成軟件系統(tǒng)的各功能模塊逐步細(xì)化，形成若干程序模塊；2.運用詳細(xì)設(shè)計工具對程序模塊進行過程描述；3.確定各個模塊間的詳細(xì)接口信息；4.編寫詳細(xì)設(shè)計說明書；5.詳細(xì)設(shè)計評審。 結(jié)構(gòu)化程序設(shè)計：模塊內(nèi)過程的結(jié)構(gòu)化設(shè)計應(yīng)遵循下列準(zhǔn)則： 使用的基本邏輯結(jié)構(gòu)應(yīng)盡量少； 用基本邏輯結(jié)構(gòu)將過程組成的“塊”應(yīng)容易識別；每個“塊”都應(yīng)是單入口和單出口；設(shè)計要易于轉(zhuǎn)換成程序代碼且容易修改。第五章第一課時（續(xù)）第五章第一課時（續(xù)）基本邏輯結(jié)構(gòu)（順序、選擇、直到與當(dāng)型循環(huán)）結(jié)構(gòu)的嵌套（是把結(jié)構(gòu)化的復(fù)合語句當(dāng)作一個簡單的語句來看待）詳

52、細(xì)設(shè)計工具（圖形化工具、表格化工具與語言工具）第二課時第五章第二課時第五章第二課時案例詳細(xì)設(shè)計工具應(yīng)用案例代碼設(shè)計代碼定義種類代碼的設(shè)計原則代碼效驗第三課時第五章第三課時第五章第三課時界面設(shè)計軟件安全控制設(shè)計軟件安全的概念軟件安全的控制方法軟件安全的控制設(shè)計軟件詳細(xì)設(shè)計文檔書寫規(guī)范返回第六章第一課時第六章第一課時源程序設(shè)計要求結(jié)構(gòu)化程序設(shè)計定義原則程序設(shè)計風(fēng)格：源程序文檔化（標(biāo)示符的命名 、程序的注釋 、視覺組織 空格、空行與縮進 ）、數(shù)據(jù)說明、語句結(jié)構(gòu)、輸入與輸出程序效率：效率準(zhǔn)則、算法對效率的影響、影響存儲效率的因素 、影響輸入/輸出的因素 、語言選擇第二課時第六章第二課時第六章第二課時編

53、碼出錯的預(yù)防代碼復(fù)查編碼工具程序復(fù)雜性的度量（上述項目的具體內(nèi)容參見書本）返回第七章第七章第一課時第一課時測試的概念測試的目的1.測試是一個程序的執(zhí)行過程，它的目的在于發(fā)現(xiàn)錯誤；2.一個好的測試用例是極可能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；3.一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。 測試的原則1.避免由程序編寫者自己進行測試，目的在于克服盲目的自信心和對功能要求誤解的延續(xù)性；2.測試用例的設(shè)計和選擇，預(yù)期結(jié)果的定義要有利于錯誤的檢測。無效的、異常的、臨界的或可能引起問題變異的輸入條件比正常的輸入條件更重要。測試用例不僅要檢查程序是否做了應(yīng)該做的事，還要檢查它是否做了不應(yīng)該做的事；3.應(yīng)當(dāng)盡早地不斷

54、地進行軟件測試； 第七章第七章第一課時（續(xù)）第一課時（續(xù)）4.測試用例應(yīng)當(dāng)由測試輸入數(shù)據(jù)及與之對應(yīng)的輸出數(shù)據(jù)構(gòu)成；5.應(yīng)當(dāng)制定嚴(yán)格的測試計劃；6.應(yīng)當(dāng)注意測試中的群集現(xiàn)象，即已經(jīng)發(fā)現(xiàn)了錯誤的位置很可能還存在錯誤，要繼續(xù)重點測試；7.應(yīng)當(dāng)對每一個測試結(jié)果做全面檢查；8.妥善保存測試計劃與測試用例，為以后的維護提供方便。測試方法：黑盒測試（等價劃分、邊界值分析、錯誤推測法、因果圖法 ）；白盒測試（邏輯覆蓋）第二課時第七章第七章第二課時第二課時測試用例設(shè)計 實用測試策略 測試的步驟調(diào)試軟件測試報告返回第八章第一課時第八章第一課時軟件維護的概念軟件維護的類型與工作量比重適應(yīng)性 改正性維維護25% 護2

55、0% 完善性維護50%其 它維護5%影響維護工作量的因素 1.系統(tǒng)大??； 2.程序設(shè)計語言；3.系統(tǒng)年齡；4.數(shù)據(jù)庫技術(shù)的應(yīng)用；5.先進的軟件開發(fā)技術(shù)；6.其他：例如，應(yīng)用的類型、數(shù)學(xué)模型、任務(wù)的難度、開關(guān)與標(biāo)記、if嵌套深度、索引或下標(biāo)數(shù)等，對維護工作量都有影響。此外，許多軟件在開發(fā)時并未考慮將來的修改，這就為軟件的維護帶來許多問題。第二課時第八章第二課時第八章第二課時軟件維護的策略 維護成本軟件維護活動軟件維護機構(gòu)軟件維護申請報告 軟件維護工作流程維護檔案記錄維護評價第三課時第八章第三課時第八章第三課時程序修改的副作用與程序修改的步驟程序修改的步驟分析與理解程序修改程序程序修改的副作用重新

56、驗證程序軟件的可維護性軟件可維護性的定義軟件可維護性的度量第四課時第八章第四課時第八章第四課時提高軟件可維護性的方法建立明確的軟件質(zhì)量目標(biāo)和優(yōu)先級 使用提高軟件質(zhì)量的技術(shù)和工具進行明確的質(zhì)量保證審查選擇可維護的程序設(shè)計語言 改進程序的文檔第五課時第八章第五課時第八章第五課時逆向工程和再工程 軟件配置管理軟件配置管理工具軟件維護報告返回第九章第九章軟件項目管理軟件項目管理軟件項目管理的概念資源管理組織體制人員配備進度計劃圖工程網(wǎng)絡(luò)圖軟件項目的追蹤與控制風(fēng)險管理：風(fēng)險識別、估計、評價、控制軟件過程成熟度模型(cmmcapability maturity model)質(zhì)量保證小項目的管理返回第十章第

57、一課時第十章第一課時面向?qū)ο蠛喗槭且环N全新的軟件開發(fā)方法。它有以下特色：方法的唯一性，即方法是對軟件開發(fā)過程所有階段進行綜合考慮而得到的；從生存期的一個階段到下一個階段的高度連續(xù)性，即在一個階段所用到的部分與在下一個階段所使用的部分是銜接的，所使用的技術(shù)經(jīng)過生存期每一階段后不改變；把面向?qū)ο蠓治?、面向?qū)ο笤O(shè)計和面向?qū)ο蟪绦蛟O(shè)計集成到生存期的相應(yīng)階段。幾個概念面向?qū)ο髮ο箢惱^承多態(tài)性第二課時第十章第二課時第十章第二課時面向?qū)ο蟮拈_發(fā)過程面向?qū)ο蠓椒ǜ倪M了在生存期各個階段之間的界面，因為在生存期各個階段所開發(fā)出來的“部件”都是類。在面向?qū)ο笊嫫诘母鱾€階段對各個類的信息進行細(xì)化，類成為分析、設(shè)計和

58、實現(xiàn)的基本單元。 、應(yīng)用生存期維護組裝測試實例建立信息系統(tǒng)描述論域分析應(yīng)用分析高層設(shè)計類開發(fā)客戶輸入第十章第二課時（續(xù)）第十章第二課時（續(xù)）、類生存期類生存期類規(guī)格說明從既存類演變漸增式的實現(xiàn)漸增式的測試求精與維護類的復(fù)用從廢棄型開發(fā)實現(xiàn)測 試 用例 與 測試開發(fā)、綜合方法把應(yīng)用生存期與類生存期放在一起，給出面向?qū)ο蟮膽?yīng)用開發(fā)過程。 （1）分析階段 第十章第二課時（續(xù)）第十章第二課時（續(xù)）分析階段包括兩個步驟；論域分析和應(yīng)用分析。它們都要標(biāo)識問題論域中的抽象。在分析中，需要找到特定對象，根據(jù)對象的公共特性把它們組成集合，直到最后能夠標(biāo)識出對這個問題的一個抽象。 在分析階段中還要標(biāo)識抽象之間的聯(lián)

59、系，在分析過程中標(biāo)識的對象不是孤立的，在給定的問題環(huán)境中，對象與其他對象相互影響。這些相互影響就構(gòu)成應(yīng)用系統(tǒng)的結(jié)構(gòu)中對象之間的聯(lián)系。這些聯(lián)系在應(yīng)用系統(tǒng)中常常用對象之間的消息來表示，叫做消息連接消息是一個對象發(fā)出的讓另一個對象做某個動作的請求。在面向?qū)ο蟮膽?yīng)用中控制流由兩部分構(gòu)成：每個操作內(nèi)部的控制流加上對象之間的消息模式。 ()論域分析 論域分析開發(fā)應(yīng)用論域的模型。論域分析應(yīng)在應(yīng)用分析前進行，因為在了解問題前應(yīng)當(dāng)對問題敞開思想考慮?？蛻艨赡軙淖冃枨螅谑碌诙n時（續(xù)）第十章第二課時（續(xù)）而且問題環(huán)境也可能改變，所以，論域分析應(yīng)考察問題論域內(nèi)的一個較寬的范圍，分析覆蓋的范圍應(yīng)比直接要解決的問題更多。論域分析最大的價值是抽象的開發(fā)，這些抽象表示了個問題論域中的基本概念，它們形成的軟件庫還可支持許多應(yīng)用的開發(fā)。 ()應(yīng)用分析 應(yīng)用(或系統(tǒng))分析細(xì)化在