軟件工程生命周期各階段介紹課件

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

瀑布模型

快速原型

第一章第二課時軟件開發(fā)模型4瀑布模型的定義瀑布模型遵循軟件生存周期的劃分，明確規(guī)定每個階段的任務(wù)，各個階段的工作順序展開，恰如奔流不息拾級而下的瀑布。

問題定義可行性研究需求分析概要設(shè)計詳細設(shè)計編碼測試運行維護開發(fā)時期計劃時期有錯運行時期對應(yīng)的文檔資料與系統(tǒng)目標方案論證報告或計劃任務(wù)書需求規(guī)格說明書系統(tǒng)功能結(jié)構(gòu)圖設(shè)計規(guī)格書程序規(guī)格書、源程序測試記錄、用戶操作手冊評價報告、維護記錄瀑布模型的定義瀑布模型遵循軟件生存周期的劃分，明確規(guī)定每個5瀑布模型的特點(1)軟件生存周期的順序性：只有前一階段工作完成以后，后一階段的工作才能開始，前一階段的輸出文檔，就是后一階段的輸入文檔。只有前一階段有正確的輸出，后一階段才可能有正確的結(jié)果。如果在生存周期的某一階段出現(xiàn)了錯誤，往往要追溯到在它之前的一些階段。瀑布模型開發(fā)適合于在軟件需求比較明確，開發(fā)技術(shù)比較成熟，工程管理比較嚴格的場合下使用。(2)盡可能推遲軟件的編碼：程序設(shè)計也稱為編碼。實踐表明，大、中型軟件編碼開始得越早，完成所需的時間反而越長。瀑布模型在編碼之前安排了需求分析、總體設(shè)計、詳細設(shè)計等階段，從而把邏輯設(shè)計和編碼清楚地劃分開來，盡可能推遲程序編碼階段。(3)保證質(zhì)量：為了保證質(zhì)量，瀑布模型軟件開發(fā)在每個階段都要完成規(guī)定的文檔，每個階段都要對已完成的文檔進行復(fù)審，以便及早發(fā)現(xiàn)隱患，排除故障。

瀑布模型的特點(1)軟件生存周期的順序性：只有前一階段工6快速原型正確的需求定義是系統(tǒng)成功關(guān)鍵。軟件開發(fā)人員需要反復(fù)多次地和用戶交流信息，才能全面、準確地了解用戶的要求。理想的做法是先根據(jù)需求分析的結(jié)果開發(fā)一個原型系統(tǒng)，請用戶試用一段時間，以便能正確地認識到他們的實際需要是什么，這相當于工程上先制作“樣品”試用后，作適當改進，然后再批量生產(chǎn)一樣，這就是快速原型法。雖然此法要額外花費一些成本，但是可以盡早獲得更正確完整的需求，可以減少測試和調(diào)試的工作量，提高軟件質(zhì)量。因此快速原型法使用得當，能減少軟件的總成本，縮短開發(fā)周期，是目前比較流行的實用開發(fā)模式。根據(jù)建立原型的目的不同，實現(xiàn)原型的途徑也有所不同，通常有下述三種類型。(1)漸增型(2)用于驗證軟件需求的原型(3)用于驗證設(shè)計方案的原型

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

快速原型（續(xù)）——類型之一先選擇一個或幾個關(guān)鍵功能，建立8快速原型（續(xù)）——類型之二系統(tǒng)分析人員在確定了軟件需求之后，從中選出某些應(yīng)驗證的功能，用適當?shù)墓ぞ呖焖贅?gòu)造出可運行的原型系統(tǒng)，由用戶試用和評價。這類原型往往用后就丟棄，因此構(gòu)造它們的生產(chǎn)環(huán)境不必與目標系統(tǒng)的生產(chǎn)環(huán)境一致，通常使用簡潔而易于修改的超高級語言對原型進行編碼。

快速原型（續(xù)）——類型之二系統(tǒng)分析人員在確定了軟件需求之9快速原型（續(xù)）——類型之三為了保證軟件產(chǎn)品的質(zhì)量，在總體設(shè)計和詳細設(shè)計過程中，用原型來驗證總體結(jié)構(gòu)或某些關(guān)鍵算法。如果設(shè)計方案驗證完成后就將原型丟棄，則構(gòu)造原型的工具不必與目標系統(tǒng)的生產(chǎn)環(huán)境一致。如果想把原型作為最終產(chǎn)品的一部分，原型和目標系統(tǒng)可使用同樣的程序設(shè)計語言?？焖僭停ɡm(xù)）——類型之三為了保證軟件產(chǎn)品的質(zhì)量，在總體10快速原形的開發(fā)過程原型設(shè)計編碼系統(tǒng)定義與用戶需求分析測試原型產(chǎn)品系統(tǒng)的設(shè)計實現(xiàn)完善原型第三課時快速原形的開發(fā)過程原型設(shè)計編碼系統(tǒng)定義與用戶需求分析測試原型11第一章第三課時噴泉模型軟件重用模型第一章第三課時噴泉模型12噴泉模型演化集成測試編程設(shè)計分析噴泉模型原理圖基于噴泉模型，Hodge等人提出將軟件開發(fā)過程劃分為概念模型分析、系統(tǒng)設(shè)計、對象設(shè)計與實現(xiàn)、測試和系統(tǒng)組裝集成等五個階段，它也體現(xiàn)出分析和設(shè)計之間的重疊①概念模型分析：這個階段主要目標是建立系統(tǒng)模型。系統(tǒng)模型中的對象是現(xiàn)實世界中的客觀對象的抽象，應(yīng)結(jié)構(gòu)清晰、易于理解、易于描述其規(guī)范。在分析階段面向問題域，建立起對象模型和過程模型。②系統(tǒng)設(shè)計：給出模型對象和過程的規(guī)范描述。③對象設(shè)計與實現(xiàn)：面向?qū)ο笤O(shè)計方法強調(diào)軟件模塊的再用和軟件合成，因而在對象設(shè)計和實現(xiàn)時，并不要求所有的對象都從頭開始設(shè)計，而是充分利用以前的設(shè)計工作。在軟件開發(fā)時檢索對象庫，若是對象庫中已有的，則可再用；否則，重新定義新的對象，進行設(shè)計和實現(xiàn)。④測試；測試所有的對象及對象相互之間的關(guān)系是否符合要求。

噴泉模型演化集成測試編程設(shè)計分析噴泉模型原理圖基于噴泉模13噴泉模型（續(xù)）⑤系統(tǒng)組裝集成：面向?qū)ο筌浖攸c之一是軟件重用和組裝技術(shù)。對象是數(shù)據(jù)和操作的封裝載體，組裝在一起才構(gòu)成完整的系統(tǒng)。軟件是對象模塊的復(fù)合，而軟件設(shè)計是對象模塊經(jīng)過進程控制而構(gòu)造生成。

噴泉模型（續(xù)）⑤系統(tǒng)組裝集成：面向?qū)ο筌浖攸c之一是軟件重用14軟件重用模型旨在開發(fā)具有各種一般性功能的軟件模塊，將它們組成軟件重用庫，這些模塊設(shè)計時考慮其適應(yīng)各種界面的接口規(guī)格，可供軟件開發(fā)時利用。主要優(yōu)點是減少軟件生產(chǎn)中的重復(fù)開發(fā)，避免軟件開發(fā)人員的大量重復(fù)勞動，提高開發(fā)效率，縮短開發(fā)周期，降低開發(fā)成本。軟件重用庫的模塊不僅要便于選擇使用，而且還應(yīng)具有允許擴充、積累其成分的性能。軟件重用分兩種：(1)重用程序以各種源程序形式存庫；(2)重用程序是經(jīng)過編譯的目標程序。軟件重用模式開發(fā)過程如下：①設(shè)計重用庫模塊：重用庫中的模塊要經(jīng)歷模塊定義、功能規(guī)格描述、模塊設(shè)計、編碼、模塊功能測試、模塊登記、模塊目錄編制，此后可放人重用庫中。②軟件系統(tǒng)設(shè)計：在重用庫建立后，軟件系統(tǒng)的設(shè)計步驟如下：需求分析，功能定義、設(shè)計，在重用庫中選擇模塊，編碼，測試，驗收，運行維護。

第四課時軟件重用模型旨在開發(fā)具有各種一般性功能的軟件模塊，將它們組15第一章第四課時噴泉模型軟件工程的任務(wù)與研究范圍軟件開發(fā)的原則與開發(fā)方法返回第一章第四課時噴泉模型返回16噴泉模型瀑布模型要求在軟件開發(fā)的初期就完全確定軟件的需求，這在很多情況下往往是做不到的。螺旋模型試圖克服瀑布模型的這一不足。SM把軟件開發(fā)過程安排為逐步細化的螺旋周期序列，每經(jīng)歷一個周期，系統(tǒng)就細化和完善一些。SM每—螺旋周期由六個步驟組成：(1)確定任務(wù)目標：根據(jù)初始需求分析項目計劃，確定任務(wù)目標、可選方案和限制。(2)選擇對象：對各種軟硬件設(shè)備、開發(fā)方法、技術(shù)、開發(fā)工具、人員、開發(fā)管理等對象進行選擇：并決定軟件是進行研制、購買還是利用現(xiàn)有的。(3)分析約束條件：軟件開發(fā)的時間、經(jīng)費等限制條件。(4)風(fēng)險分析：評估目標、對象、約束條件三者之間的聯(lián)系，列出可能出．現(xiàn)的問題及問題的嚴重程度等，把最重要的問題作為尚未解決的關(guān)鍵問題的風(fēng)險。(5)制定消除風(fēng)險的方法：應(yīng)有詳盡的說明和周密的計劃，并估計可能產(chǎn)生的后果。依此來開發(fā)軟件，為制訂下一周期的計劃打下基礎(chǔ)。(6)制定下一周期的工作計劃：在第一個螺旋周期，確定目標、選擇對象、分析約束，通過風(fēng)險分析制訂消除風(fēng)險的方法，初步開發(fā)原型1，制定系統(tǒng)生存周期計劃。

噴泉模型瀑布模型要求在軟件開發(fā)的初期就完全確定軟件的需求，這17噴泉模型（續(xù)）在第二個螺旋周期，進一步明確系統(tǒng)的目標、開發(fā)方案及約束條件，通過風(fēng)險分析制定消除風(fēng)險的方法，在原型1的基礎(chǔ)上開發(fā)原型2。進一步明確軟件需求，進行需求確認，修改開發(fā)計劃。在第三個螺旋周期，再進一步確認系統(tǒng)目標、開發(fā)方案及約束條件，進行風(fēng)險分析，制訂進一步消除風(fēng)險的方法，在原型2的基礎(chǔ)上開發(fā)原型3。此時可進行產(chǎn)品設(shè)計，再對設(shè)計進行驗證和確認，制訂集成測試計劃。在第四個螺旋周期，軟件開發(fā)方案、系統(tǒng)目標和約束條件得到確定，在風(fēng)險分析的基礎(chǔ)上，開發(fā)具有實用價值的可操作性原型，此時可對產(chǎn)品進行詳細設(shè)計，進入編碼、單元測試、集成測試階段，最后進入驗收測試，驗收合格后交付用戶使用，進入運行、維護階段。

噴泉模型（續(xù)）在第二個螺旋周期，進一步明確系統(tǒng)的目標、開18噴泉模型原理圖逐步執(zhí)行評價方案，標識、消除風(fēng)險計劃下階段工作運行維護驗證測試集成測試單元測試編碼詳細設(shè)計風(fēng)險分析集成測試計劃設(shè)計驗證與確認產(chǎn)品設(shè)計原型3風(fēng)險分析開發(fā)計劃需求確認軟件需求原型2風(fēng)險分析需求計劃生存周期計劃確定目標方案約束原型1風(fēng)險分析操作性原型確定目標方案與約束螺旋模型的開發(fā)過程開發(fā)驗證下一級產(chǎn)品噴泉模型原理圖逐步執(zhí)行評價方案，標識、消除風(fēng)險計劃下階段工作19軟件工程的任務(wù)與研究范圍軟件產(chǎn)品的特點軟件工程的研究內(nèi)容與方法軟件工具與軟件支撐環(huán)境軟件管理軟件工程的任務(wù)與研究范圍軟件產(chǎn)品的特點20軟件開發(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）軟件需求工程法（2）問題說明語言與分析法3.自動形式的系統(tǒng)開發(fā)方法（HOS方法）：由計算機自動確定規(guī)范、自動分析、自動編程、自動執(zhí)行與模擬，以規(guī)范語言AXES、資源分配工具RTA為工具。能自動進行分析、設(shè)計，工作量少、設(shè)計規(guī)范，也能自動進行修改和維護。該方法適用于系統(tǒng)分析和設(shè)計。軟件開發(fā)的原則與方法軟件開發(fā)的原則21第二章第一課時問題定義與可行性研究

問題定義

可行性研究第二章第一課時問題定義與可行性研究22問題定義問題是指用戶的基本要求，就是確切地定義用戶要求解決的問題，即確定問題的性質(zhì)、工程的目標和規(guī)模。怎樣定義問題？問題定義的來源是用戶，是提出問題、請求解決的人。若問題是以書面形式提出來，那么分析員應(yīng)該認真閱讀和分析書面材料；如果問題是以口頭形式提出，那么分析員應(yīng)該認真傾聽并仔細記錄要點，在適當?shù)臅r候認真地請用戶解釋。分析員還應(yīng)該通過對用戶的訪問調(diào)查進一步搞清楚，用戶為什么提出這樣的問題，問題的背景是什么，用戶的目標是什么。問題定義的目的是要在短時間內(nèi)，對用戶的要求有一個比較準確的估計，對要實現(xiàn)的系統(tǒng)規(guī)模做到胸中有數(shù)。但僅有這些還不夠，還要搞清用戶不打算干什么，在這個系統(tǒng)中哪些內(nèi)容不用實現(xiàn)。工作的宗旨是搞清要做什么并劃清要實現(xiàn)的系統(tǒng)的范圍邊界。在完成問題定義的過程中，用戶在一開始，可能會給你大堆大堆的表格，因為他們可能認為只要把表格給你講清楚，你就會對這個問題定義問題是指用戶的基本要求，就是確切地定義用戶要求解決23問題定義（續(xù)）系統(tǒng)全部弄清楚了。還有一些人可能會給你展示一些企業(yè)的十分詳盡的管理示圖，如物資流管理圖、生產(chǎn)管理圖、計劃財務(wù)管理圖等。因為他們也可能認為，只要分析員把這些圖看懂了，就會對他們要建立的系統(tǒng)搞清楚了。但是，在問題定義階段千萬不要陷入到這些表格和圖紙中。因為不管是表格還是圖紙，其中都包含了大量的、只有用戶才能懂的術(shù)語。當然，并不是說在問題定義階段，這些圖紙表格沒有一點作用。對一些關(guān)鍵性的語匯可以請用戶講清楚，這樣有利于問題定義的準確性?？傊?，在問題定義階段，分析員應(yīng)盡可能站在較高的角度去抽象、概括所要干的事情。分析員對問題有了明確認識之后，應(yīng)該把自己的認識寫成書面報告，提交給用戶和使用部門的負責(zé)人審查，以檢驗分析員對所要解決的問題的理解是否正確。因為分析員對問題的理解為今后開發(fā)工作確定了方向。分析員對問題理解正確，這是確保今后系統(tǒng)開發(fā)成功的關(guān)鍵。反之，分析員對問題理解不正確，最終開發(fā)出來的問題定義（續(xù)）系統(tǒng)全部弄清楚了。還有一些人可能會給你展示一些24問題定義（續(xù)）系統(tǒng)必然不能解決實際要求解決的問題。如果一個系統(tǒng)，不能解決要求它解決的問題，那么這個系統(tǒng)就一點價值也沒有，只不過是浪費了開發(fā)它所用的時間和資源。所以及時審查問題的定義是極端重要的。理想的做法是分析員、用戶和使用部門的負責(zé)人一起閱讀討論這份報告，明確含糊不清的地方，改正不正確的地方。通過修改得到一份大家一致同意的文檔。在問題定義階段，分析員應(yīng)該對工程成本做出粗略的預(yù)算，并對下階段可行性研究所需要時間和成本做出較精確的估計。對問題定義的書面報告應(yīng)該盡可能清楚簡潔，最好寫在一頁內(nèi)。這份報告通常應(yīng)包括工程項目的名字，對問題概括定義、項目的目標，項目的規(guī)模，對可行性研究的具體建議(既需要用的時間和成本)等等。一旦分析員和用戶及使用部門的負責(zé)人對所要解決的問題，取得完全一致的看法且在報告書上簽了字，問題定義階段工作就宣告完成，可行性研究就可以開始。問題定義（續(xù)）系統(tǒng)必然不能解決實際要求解決的問題。如果一25可行性研究所謂可行性研究就是分析員站在較高的角度去調(diào)查現(xiàn)行手工系統(tǒng)及用戶提出的項目目標，并且去尋找是否有一種手段能夠在現(xiàn)有條件下，實際地達到項目目標，并使用戶滿意。同時向用戶指出該系統(tǒng)實現(xiàn)的意義，以使用戶去權(quán)衡花費這樣的代價去實現(xiàn)這樣的系統(tǒng)是否值得?？尚行匝芯康哪康木褪怯米钚〉拇鷥r在盡可能短的時間內(nèi)，確定問題是否能夠解決，從而確定問題是否值得去解。如何才能達到這個目的呢？進行客觀分析，通過對幾種可能解法，分析其利弊，才能判斷原定系統(tǒng)的目標和規(guī)模是否現(xiàn)實，系統(tǒng)完成后所能帶來的效益是否大到值得投資開發(fā)這個系統(tǒng)的程序。因此，可行性研究實質(zhì)上是進行一個大大壓縮簡化了的軟件分析和設(shè)計過程，也就是在較高層上，以較抽象的方式進行軟件分析和設(shè)計的過程?？尚行匝芯繎?yīng)在以下三方面進行：①技術(shù)可行性；②經(jīng)濟可行性；③操作可行性。可行性研究所謂可行性研究就是分析員站在較高的角度去調(diào)查現(xiàn)行手26可行性研究（續(xù)）1.技術(shù)可行性

對技術(shù)可行性研究，首先應(yīng)從對現(xiàn)行系統(tǒng)進行調(diào)查入手。因為現(xiàn)行系統(tǒng)是信息的重要來源。顯然，如果目前有一個系統(tǒng)正被人使用，那么這個系統(tǒng)必定能完成某些有用的工作，因此，新的目標系統(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)查研究不可能做得很細，對一些內(nèi)容細節(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ǔ)上。因為通過前一步的工作，分析員對目標系統(tǒng)(新系統(tǒng))應(yīng)該具的基本功能和所受的約束，已有一定的了解，使用數(shù)據(jù)流程圖描繪數(shù)據(jù)在系統(tǒng)中可行性研究（續(xù)）1.技術(shù)可行性27可行性研究（續(xù)）流動和處理的情況，從而概括地表達出對新系統(tǒng)的設(shè)想。用數(shù)據(jù)流程圖和數(shù)據(jù)字典來定義新系統(tǒng)的高層邏輯模型。其三，重新定義問題。新系統(tǒng)的邏輯模型實質(zhì)上表達了分析員對新系統(tǒng)必須做什么的看法。此時，分析員應(yīng)該和用戶一起復(fù)查問題定義、工程規(guī)模和目標。這次復(fù)查應(yīng)該把數(shù)據(jù)流程圖和數(shù)據(jù)字典作討論的基礎(chǔ)。如果分析員對問題有誤解或者用戶曾經(jīng)遺漏了某些要求，那么現(xiàn)在是發(fā)現(xiàn)和改正這些錯誤的時候了。其四，導(dǎo)出供選擇的解法。分析員應(yīng)從他所建議的系統(tǒng)邏輯模型出發(fā)，推導(dǎo)出若干個較高層次的解決辦法，供比較和選擇。最簡單的途徑，是從技術(shù)角度出發(fā)，考慮解決問題的不同方案。這些不同方案可以在數(shù)據(jù)流程圖上劃分不同的自動化邊界而得到。所以分析員在確定了幾組不同的自動化邊界之后，再針對每組邊界，考慮如何實現(xiàn)所要求的系統(tǒng)。當從技術(shù)角度提出了一些系統(tǒng)模型之后，應(yīng)根據(jù)技術(shù)可行性的考慮，初步排除一些不現(xiàn)實的系統(tǒng)。例如，如果要求系統(tǒng)的響應(yīng)時間可行性研究（續(xù)）流動和處理的情況，從而概括地表達出對新系統(tǒng)的28可行性研究（續(xù)）不超過幾秒鐘，顯然應(yīng)該排除任何批處理方案。把技術(shù)上行不通的解法(方案)去掉之后，就剩下了一組技術(shù)上可行的方案。也就是根據(jù)現(xiàn)有的技術(shù)條件,考慮所提出的方案是否能實現(xiàn)。例如現(xiàn)有的計算機是否能達到所要求的速度,現(xiàn)有的輸入\輸出設(shè)備能否承擔得了要求的數(shù)據(jù)輸入\輸出量。一般來說，技術(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ā)和維護所需要的費用。這工作包括估計費用和估計效益兩個方面?？尚行匝芯浚ɡm(xù)）不超過幾秒鐘，顯然應(yīng)該排除任何批處理方案。29可行性研究（續(xù)）估計費用。主要考慮以下幾部分：設(shè)備費用，包括計算機硬件和軟件的費用；人力費用，包括開發(fā)人員和維護人員的工資；材料費用；管理費用以及維護費用等。估計效益?？梢詮囊韵聨讉€方面考慮：提供了哪些以前提供不了的信息，提供信息的速度提高了多少？質(zhì)量有什么提高？對使用者查詢和使用信息的方便程度有什么提高，節(jié)省多少人力？對組織的領(lǐng)導(dǎo)人和管理人員正確做出決策提供了哪幫助？…有時不能直接用金錢來衡量效益，如一個郵購單位，由于能夠及時、準確地處理訂貨，縮短了顧客收到貨物的時間，從而在競爭中得到了更多的顧客。這一類的收益就不容易用具體金錢來衡量，只能由管理人員根據(jù)經(jīng)驗來做出大約的估計。在估計效益時，要謹慎把各種可能影響效益發(fā)揮的各種因素考慮在內(nèi)，打上折扣。3.操作和維護可行性人員操作和維護可行性的研究是了解當用戶所要求的軟件系統(tǒng)可行性研究（續(xù)）估計費用。主要考慮以下幾部分：設(shè)備費用，包30可行性研究（續(xù)）建立起來之后，用戶對它的操作是否方便？管理和維護是否容易？如果對于一個軟件系統(tǒng)的操作比原有的手工系統(tǒng)還麻煩，那么它是不會受歡迎的。另一方面，如果管理和維護這個軟件系統(tǒng)的人員比原來的手工系統(tǒng)還多，素質(zhì)要求還高，那么這個系統(tǒng)對用戶來說負擔太重了。對于人員操作和維護的可行性，一般可從兩個方面來考慮：一方面從技術(shù)的角度，研究是否能夠給用戶提供一個方便的操作環(huán)境；另一方面從設(shè)備的選擇上來考慮，看看為了完成用戶要求的功能，是否能夠找到一些易于管理和維護的設(shè)備。從上面的討論中不難看出，可行性研究的出發(fā)點應(yīng)該是從當前的物理系統(tǒng)到新的物理系統(tǒng)的轉(zhuǎn)換，它是整個可行性研究的基礎(chǔ)，實際上也是整個系統(tǒng)開發(fā)過程的縮影。因為整個系統(tǒng)實現(xiàn)過程也就是把當前的手工系統(tǒng)轉(zhuǎn)化為可用計算機實現(xiàn)的新系統(tǒng)的一個轉(zhuǎn)換過程，只不過這工作比在可行性研究階段更細致，更具體罷了。上述從三個方面分別開展的，而實際上它們之間有著密切的聯(lián)系，因此還必須對它們綜合考慮，然后向用戶推薦方案供其選擇。

可行性研究（續(xù)）建立起來之后，用戶對它的操作是否方便？管31可行性研究（續(xù)）當用戶選定方案之后，分析員應(yīng)對在問題定義階段所規(guī)定的實現(xiàn)目標進行修改。因為，這時對系統(tǒng)有了更深入的了解，原來的問題定義可能有的不能實現(xiàn)，還有些需要加上去，也就是說原有的問題邊界不夠準確，需要糾正，以便今后有一個非常明確的工作目標。這是一步極有實質(zhì)意義的工作，它使分析員和用戶最后明確了要解決的問題的邊界以及它的實現(xiàn)方案。一般來說，可行性研究的結(jié)果可導(dǎo)致以下兩種情況：(1)可行

(２)不可行可行性研究結(jié)束后，要寫出可行性研究報告，提交有關(guān)專家論證和上級主管部門批準。可行性研究報告作為所有軟件文件資料的基礎(chǔ)材料，它的格式可以很不相同，但大體的內(nèi)容提綱是一致的。

可行性研究（續(xù)）當用戶選定方案之后，分析員應(yīng)對在問題定義32可行性研究（續(xù)）可行性研究報告的內(nèi)容提綱：

(1)背景情況

國內(nèi)外水平、歷史現(xiàn)狀、市場需求。（2)系統(tǒng)描述總體方案和技術(shù)路線、課題分解、關(guān)鍵技術(shù)、計劃目標和階段目標。

(3)價格利益分析經(jīng)濟可行性，包括經(jīng)費概算和預(yù)期經(jīng)濟效益。

(4)技術(shù)冒險評價

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

軟件需求分析(軟件要求分析)是在可行性研究基礎(chǔ)上進行的更細致的分析工作，是對軟件計劃階段建立的軟件工作范圍的求精和細化。也就是在對軟件計劃階段確定的工作范圍內(nèi)進一步對目標對象和環(huán)境作細致、深入的調(diào)查分析。需求分析過程實際上是一個調(diào)查研究、分析綜合的過程，是一個抽象思維、邏輯推理的過程。通過調(diào)查研究和分析，充分了解用戶對軟件系統(tǒng)的要求。在此基礎(chǔ)上，把用戶要求表達出來，解決軟件系統(tǒng)“做什么”的問題。也就是建立起系統(tǒng)的邏輯模型，把軟件功能和性能的總體概念描述成具體的軟件規(guī)格說明書。

需求分析的目標（1.理清數(shù)據(jù)流或數(shù)據(jù)結(jié)構(gòu)；2.通過標識接口細節(jié)，深入描述功能，確定設(shè)計約束和軟件有效性要求；3.構(gòu)造一個完全、精致的目標系統(tǒng)邏輯模型。）需求分析的任務(wù)（認清問題、分析與綜合、邏輯模型導(dǎo)出與復(fù)審）結(jié)構(gòu)化分析方法第三章第一課時需求分析的定義36結(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)化分析方法結(jié)構(gòu)化分析方法的策略.輸入1....輸出1輸出37結(jié)構(gòu)化分析方法（續(xù)）——數(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)容基礎(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ù)修改的過程）第二課時結(jié)構(gòu)化分析方法（續(xù)）——數(shù)據(jù)流圖數(shù)據(jù)流圖的定義第二課時38第三章第二課時數(shù)據(jù)字典１、數(shù)據(jù)字典的定義（數(shù)據(jù)字典就是對數(shù)據(jù)流程圖中，數(shù)據(jù)、變換等進行精確定義。）２、數(shù)據(jù)定義方法（對數(shù)據(jù)自頂向下的分解。當分解到不需要進一步定義，對每個和系統(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)容）第三課時第三章第二課時數(shù)據(jù)字典第三課時39第三章第三課時結(jié)構(gòu)化分析的步驟

1.研究目前正在使用的系統(tǒng)現(xiàn)有的系統(tǒng)(包括人工系統(tǒng))是信息的重要來源。因此，首先要去了解現(xiàn)有系統(tǒng)能完成哪些工作(即功能)，而新的目標系統(tǒng)必須也能完成它的基本功能；另一方面，既然提出要開發(fā)新的系統(tǒng)，那么現(xiàn)有的系統(tǒng)必定存在某些問題，而新的目標系統(tǒng)必須能夠解決舊系統(tǒng)中存在的問題，也就是給新的目標系統(tǒng)提出了新的要求(即功能要求)，所以了解現(xiàn)有系統(tǒng)是開發(fā)新的目標系統(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)的邏輯模型。通常第一步的工作，對新的目標系統(tǒng)應(yīng)該具有的基本功能和所第三章第三課時結(jié)構(gòu)化分析的步驟40結(jié)構(gòu)化分析步驟（續(xù)）受的約束條件，已有一定的了解，把這些了解用數(shù)據(jù)流程圖概括地描繪出對新系統(tǒng)的設(shè)想。同時定義系統(tǒng)中使用的數(shù)據(jù)，構(gòu)造初步的數(shù)據(jù)字典。這樣，數(shù)據(jù)流程圖和數(shù)據(jù)字典共同定義了新的目標系統(tǒng)的高層邏輯模型。(在可行性研究階段完成)3.完善數(shù)據(jù)流程圖在第二步畫出新系統(tǒng)的高層數(shù)據(jù)流程圖中，許多數(shù)據(jù)的定義和一些細節(jié)都沒有考慮進去。現(xiàn)在應(yīng)著手解決這個問題。（1）沿著數(shù)據(jù)流程圖回溯為了對數(shù)據(jù)流程圖中的數(shù)據(jù)流和數(shù)據(jù)存儲進行定義，通常是從數(shù)據(jù)流程圖的輸出端著手分析。這是因為軟件系統(tǒng)的目標是產(chǎn)生這些輸出，輸出數(shù)據(jù)確定了軟件系統(tǒng)必須具有的最基本的組成元素。輸出數(shù)據(jù)是由哪些數(shù)據(jù)項組成的，通過調(diào)查訪問是不難搞清這個問題。那么每個輸出數(shù)據(jù)項又是從哪里來的呢?因為它是新系統(tǒng)的輸出，那么它們或者是從外面輸入到系統(tǒng)中來，或者是通過運算結(jié)構(gòu)化分析步驟（續(xù)）受的約束條件，已有一定的了解，把這些了解41結(jié)構(gòu)化分析步驟（續(xù)）由系統(tǒng)中產(chǎn)生出來的。為了弄清這些，可以沿著數(shù)據(jù)流程圖從輸出端往輸入端回溯，能夠確定每個數(shù)據(jù)項的來源，與此同時也就初步定義了有關(guān)的算法。在第二步得到的高層數(shù)據(jù)流程圖中，許多具體細節(jié)沒有包括在里面。因此，當沿著數(shù)據(jù)流程圖回溯時，經(jīng)常會遇到：為了得到某個數(shù)據(jù)項需要用到數(shù)據(jù)流程圖中目前還沒有的數(shù)據(jù)項，或者得出這個數(shù)據(jù)項要用的算法還不完全清楚。為了解決這些問題，需要向用戶和有關(guān)人員請教，他們的回答使分析員對新系統(tǒng)的認識更具體更深入了。系統(tǒng)中更多的數(shù)據(jù)項被劃分出來，更多的算法被搞清楚了。一般把分析過程得到的有關(guān)數(shù)據(jù)項的信息、變換的算法簡明地記在數(shù)據(jù)字典中。（2）用戶復(fù)查通過沿著數(shù)據(jù)流程圖的回溯過程，把一些數(shù)據(jù)項和變換的算法記錄到數(shù)據(jù)字典中。這個數(shù)據(jù)字典是否準確完整?算法是否正確?還有沒有必要的變換和數(shù)據(jù)項遺漏了?某些數(shù)據(jù)項的來源搞清楚嗎?……結(jié)構(gòu)化分析步驟（續(xù)）由系統(tǒng)中產(chǎn)生出來的。為了弄清這些，可以沿42結(jié)構(gòu)化分析步驟（續(xù)）對這些問題必須請系統(tǒng)的用戶(直接在這個系統(tǒng)上工作的)對前面步驟得出的結(jié)果仔細地進行復(fù)查。可以借助于數(shù)據(jù)流程圖和數(shù)據(jù)字典，從輸入端開始向用戶解釋輸入數(shù)據(jù)是怎樣一步一步地轉(zhuǎn)變成輸出數(shù)據(jù)。這些解釋集中反映了分析員通過前面分析工作，所獲得的對新目標系統(tǒng)的認識。這些認識是否正確，有沒有遺漏?應(yīng)請用戶及時糾正和補充分析員的認識。通過復(fù)查過程驗證了已知的元素，補充了未知的元素。填補了文檔中的空白。由于復(fù)查可能獲得新的知識，又可能引出新的問題。例如，對新補充進來的數(shù)據(jù)項是怎樣得出來的?它的來源是什么?這些需要進一步的調(diào)查訪問尋求對問題的解答，而且還應(yīng)及時修改和補充數(shù)據(jù)流程圖和數(shù)據(jù)字典，把對系統(tǒng)的新認識及時記錄下來。所以，追蹤數(shù)據(jù)流程圖和復(fù)查軟件系統(tǒng)的邏輯模型實質(zhì)上構(gòu)成一個循環(huán)。對數(shù)據(jù)流程圖的分析產(chǎn)生一些問題，這些問題通過復(fù)查得到的答案使分析員對系統(tǒng)有更深人更具體的認識，同時可能又引出新的問題，尋找這些新問題的答案導(dǎo)致了對新系統(tǒng)的更進一步的認識……這樣，每經(jīng)過一次循環(huán)都會對新系統(tǒng)了解更多的細節(jié)。結(jié)構(gòu)化分析步驟（續(xù)）對這些問題必須請系統(tǒng)的用戶(直接在這個系43結(jié)構(gòu)化分析（續(xù)）4.分解細化數(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)，分析員越來越深入、具體地定義了新系統(tǒng)。通過上面各步就可以得到一套新目標系統(tǒng)的分層數(shù)據(jù)流程圖和數(shù)據(jù)字典，也就是得到新系統(tǒng)的邏輯模型。

第四課時結(jié)構(gòu)化分析（續(xù)）4.分解細化數(shù)據(jù)流程圖第四課時44第三章第四課時按功能逐層分解法(HIPO法)HIPO法的定義

HIPO法組成Ｈ圖（參見書本上的相關(guān)內(nèi)容）ＩＰＯ圖（參見書本上的相關(guān)內(nèi)容）

第五課時第三章第四課時按功能逐層分解法(HIPO法)第五課時45第三章第五課時軟件需求分析報告書寫規(guī)范（參見書本的相關(guān)內(nèi)容）軟件需求分析報告案例——《ＩＰ直通車系統(tǒng)的需求分析報告》（參見書本相關(guān)內(nèi)容）返回第三章第五課時軟件需求分析報告書寫規(guī)范（參見書本的相關(guān)內(nèi)容）46第四章第一課時評價一個“設(shè)計”的標準（有一個明確的設(shè)計步驟、良好的設(shè)計方法、鑒別優(yōu)劣的準則、好的設(shè)計表示）軟件總體設(shè)計的任務(wù)（從軟件的需求規(guī)格說明書出發(fā)，將設(shè)計對象用數(shù)據(jù)流或數(shù)據(jù)結(jié)構(gòu)的形式表達成完整的抽象實體。這個實體應(yīng)當是一個結(jié)構(gòu)清晰、層次分明的模塊組合，應(yīng)當可以被評價和細化，也可以被修改。同時還要定義這個實體與外部環(huán)境的接口。）軟件總體設(shè)計的目標（1.軟件實體應(yīng)當具有明顯的層次結(jié)構(gòu)，便于軟件元素之間的控制。2.軟件實體應(yīng)當模塊化，這些摸塊應(yīng)具有完全獨立的功能。3.軟件實體與環(huán)境的界面應(yīng)當清晰。4.軟件設(shè)計的最終表示——軟件設(shè)計規(guī)格說明應(yīng)當清晰、簡潔、完整和無岐義。）軟件設(shè)計的工作流程（請參見書本上相關(guān)內(nèi)容）軟件總體設(shè)計基礎(chǔ)（模塊、軟件結(jié)構(gòu)、層次機構(gòu)的幾個特點、結(jié)構(gòu)圖、結(jié)構(gòu)圖的優(yōu)點）第二課時第四章第一課時評價一個“設(shè)計”的標準（有一個明確的設(shè)計步驟47第四章第二課時軟件模塊模塊特點（抽象與封閉性）模塊獨立性的衡量（耦合和聚合）第三課時第四章第二課時軟件模塊第三課時48第四章第三課時軟件的總體設(shè)計準則

1.評價軟件初始結(jié)構(gòu)，通過模塊的分解與合并減少模塊之間的耦合度增加聚合度在設(shè)計初始軟件結(jié)構(gòu)以后，常常會發(fā)現(xiàn)幾個模塊的功能有相似之處，這相似部分不僅增加了編程和調(diào)試的工作量，同時也給維護過程帶來麻煩，應(yīng)當消除這樣的重復(fù)。（1）完全相似這種情況只在數(shù)據(jù)類型上不一致，可采用完全合并，只需在數(shù)據(jù)類型的描述或變量定義上加以改進。（2）局部相似如圖4-23(a)中，模塊Q1和Q2具有功能類似的組成部分和不同部分．可通過模塊分解消除重復(fù)功能部分。其方法是首先找出模塊Q1和Q2的功能相似部分，如圖中的虛線部分，然后把這兩個模塊的虛線部分分離出來，構(gòu)成它們的一個公共的下層模塊Q，如圖4-23(b)第四章第三課時軟件的總體設(shè)計準則49軟件的總體設(shè)計準則（續(xù)）所示。如果分解后余下的模塊Q‘1和Q’2比較簡單，則可以同它們的各自調(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.模塊功能的完善一個完整的功能模塊應(yīng)具有以下三個要素：(1)執(zhí)行某項指定功能的部分(2)如果需要返回一系列的數(shù)據(jù)給它的調(diào)用者，應(yīng)在完成數(shù)據(jù)處理或結(jié)束時，告訴它的調(diào)用者“文件完”或其他標志。(3)出錯處理部分，即在不能完成指定任務(wù)時，必須將產(chǎn)生這種例外情況的原因(出錯標志)通知它的調(diào)用者。它們是一個功能模塊的有機組成部分，不應(yīng)當分離到其他模塊中去，否則會增加模塊間的耦合。軟件的總體設(shè)計準則（續(xù)）所示。如果分解后余下的模塊Q‘1和Q50軟件的總體設(shè)計準則（續(xù)）3.模塊調(diào)用個數(shù)最好不要超過五個一個模塊擁有的直屬下級模塊的個數(shù)叫模塊的扇出數(shù)。如果一個模塊具有過多的調(diào)用模塊，那么這個模塊扇出數(shù)就過大，如圖4-25(a)，這個模塊就往往包含過多的功能，一般是因為缺乏中間層次的控制模塊，需要將其功能進行分解。如圖4-25(b)。一個模塊的直接上級模塊的個數(shù)叫模塊的扇入數(shù)。一個模塊的扇入表明有多少個上級模塊直接調(diào)用它，扇入越大，則共享該模塊的上級模塊數(shù)目越多，這是有好處的。但不能違背模塊獨立性而單純追求高扇入。4.一個模塊的作用范圍應(yīng)在其控制范圍之內(nèi)一個模塊的作用范圍就是這個模塊內(nèi)一個判定的作用范圍。一個判定的作用范圍是指所有受這個判定影響的那些模塊，只要模塊中含有一些依賴于這個判定的操作，那么這個模塊就在這個判定的作用范圍之內(nèi)。一個模塊的控制范圍包括它自己及其所有的下屬模塊。控制范圍軟件的總體設(shè)計準則（續(xù)）3.模塊調(diào)用個數(shù)最好不要超過五個51軟件的總體設(shè)計準則（續(xù)）是從結(jié)構(gòu)方面來考慮的，而作用范圍是從功能方面考慮的。圖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è)計準則（續(xù)）是從結(jié)構(gòu)方面來考慮的，而作用范圍是從52軟件的總體設(shè)計準則（續(xù)）圖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è)計準則（續(xù)）圖4-28中作用范圍在控制范圍之內(nèi)，53軟件的總體設(shè)計準則（續(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)該仔細設(shè)計模塊接口，使得信息傳遞簡單并且和模塊功能相一致。為說明接口復(fù)雜性的影響，請看下面的例子。例如，求一元二次方程的根的模塊QUAD-ROOT(TBL，x)其中用數(shù)組TBL傳送方程的系數(shù)，用數(shù)組x回送求得的根。但是模塊QUAD-軟件的總體設(shè)計準則（續(xù)）又如圖4-31(a)中的模塊x不在模54軟件的總體設(shè)計準則（續(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行左右)在一個人智力之內(nèi)，比較容易閱讀和理解。在進行模塊設(shè)計時，首先應(yīng)根據(jù)模塊的獨立性來選取模塊的規(guī)模。如果某個模塊功能是獨立的，那怕程序段較短也不要人為地加長；如果程序段只有一個獨立的功能，那怕程序較長，也不要人為地把它分解成兩個模塊。第四課時軟件的總體設(shè)計準則（續(xù)）ROOT接口TBL和x意義不明確55第四章第四課時結(jié)構(gòu)化軟件設(shè)計結(jié)構(gòu)化軟件設(shè)計的定義與特點結(jié)構(gòu)化軟件設(shè)計的類型變換設(shè)計事物型設(shè)計綜合設(shè)計結(jié)構(gòu)化軟件設(shè)計步驟

結(jié)構(gòu)化軟件設(shè)計案例返回第四章第四課時結(jié)構(gòu)化軟件設(shè)計返回56第五章第一課時軟件詳細設(shè)計的定義：對軟件模塊的過程設(shè)計。

軟件詳細設(shè)計的任務(wù)：對總體設(shè)計所產(chǎn)生的功能模塊進行過程描述，開發(fā)一個可以直接轉(zhuǎn)換成程序語言代碼的軟件表示。

軟件詳細設(shè)計的步驟：1.將總體設(shè)計產(chǎn)生的構(gòu)成軟件系統(tǒng)的各功能模塊逐步細化，形成若干程序模塊；2.運用詳細設(shè)計工具對程序模塊進行過程描述；3.確定各個模塊間的詳細接口信息；4.編寫詳細設(shè)計說明書；5.詳細設(shè)計評審。

結(jié)構(gòu)化程序設(shè)計：模塊內(nèi)過程的結(jié)構(gòu)化設(shè)計應(yīng)遵循下列準則：①使用的基本邏輯結(jié)構(gòu)應(yīng)盡量少；②用基本邏輯結(jié)構(gòu)將過程組成的“塊”應(yīng)容易識別；③每個“塊”都應(yīng)是單入口和單出口；④設(shè)計要易于轉(zhuǎn)換成程序代碼且容易修改。第五章第一課時軟件詳細設(shè)計的定義：對軟件模塊的過程設(shè)計。57第五章第一課時（續(xù)）基本邏輯結(jié)構(gòu)（順序、選擇、直到與當型循環(huán)）結(jié)構(gòu)的嵌套（是把結(jié)構(gòu)化的復(fù)合語句當作一個簡單的語句來看待）詳細設(shè)計工具（圖形化工具、表格化工具與語言工具）第二課時第五章第一課時（續(xù)）基本邏輯結(jié)構(gòu)（順序、選擇、直到與當型循環(huán)58第五章第二課時案例——詳細設(shè)計工具應(yīng)用案例代碼設(shè)計代碼定義種類代碼的設(shè)計原則代碼效驗第三課時第五章第二課時案例——詳細設(shè)計工具應(yīng)用案例第三課時59第五章第三課時界面設(shè)計軟件安全控制設(shè)計軟件安全的概念軟件安全的控制方法軟件安全的控制設(shè)計軟件詳細設(shè)計文檔書寫規(guī)范返回第五章第三課時界面設(shè)計返回60第六章第一課時源程序設(shè)計要求結(jié)構(gòu)化程序設(shè)計定義原則程序設(shè)計風(fēng)格：源程序文檔化（標示符的命名、程序的注釋、視覺組織——空格、空行與縮進）、數(shù)據(jù)說明、語句結(jié)構(gòu)、輸入與輸出程序效率：效率準則、算法對效率的影響、影響存儲效率的因素、影響輸入/輸出的因素、語言選擇第二課時第六章第一課時源程序設(shè)計要求第二課時61第六章第二課時編碼出錯的預(yù)防代碼復(fù)查編碼工具程序復(fù)雜性的度量（上述項目的具體內(nèi)容參見書本）返回第六章第二課時編碼出錯的預(yù)防返回62第七章——第一課時測試的概念測試的目的

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)當盡早地不斷地進行軟件測試；

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

適應(yīng)性改正性維維護25%護20%

完善性維護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)與標記、IF嵌套深度、索引或下標數(shù)等，對維護工作量都有影響。此外，許多軟件在開發(fā)時并未考慮將來的修改，這就為軟件的維護帶來許多問題。第二課時第八章第一課時軟件維護的概念適應(yīng)性66第八章第二課時軟件維護的策略

維護成本軟件維護活動軟件維護機構(gòu)軟件維護申請報告

軟件維護工作流程維護檔案記錄維護評價第三課時第八章第二課時軟件維護的策略第三課時67第八章第三課時程序修改的副作用與程序修改的步驟程序修改的步驟分析與理解程序修改程序程序修改的副作用重新驗證程序軟件的可維護性軟件可維護性的定義軟件可維護性的度量第四課時第八章第三課時程序修改的副作用與程序修改的步驟第四課時68第八章第四課時提高軟件可維護性的方法

建立明確的軟件質(zhì)量目標和優(yōu)先級

使用提高軟件質(zhì)量的技術(shù)和工具

進行明確的質(zhì)量保證審查

選擇可維護的程序設(shè)計語言

改進程序的文檔第五課時第八章第四課時提高軟件可維護性的方法第五課時69第八章第五課時逆向工程和再工程

軟件配置管理軟件配置管理工具軟件維護報告返回第八章第五課時逆向工程和再工程返回70第九章——軟件項目管理軟件項目管理的概念資源管理組織體制人員配備進度計劃ＧＡＮＴＴ圖ＰＥＲＴ工程網(wǎng)絡(luò)圖軟件項目的追蹤與控制風(fēng)險管理：風(fēng)險識別、估計、評價、控制軟件過程成熟度模型(CMM—capabilityMaturityModel)質(zhì)量保證小項目的管理返回第九章——軟件項目管理軟件項目管理的概念返回71第十章第一課時面向?qū)ο蠛喗?/p>

是一種全新的軟件開發(fā)方法。它有以下特色：

方法的唯一性，即方法是對軟件開發(fā)過程所有階段進行綜合考慮而得到的；從生存期的一個階段到下一個階段的高度連續(xù)性，即在一個階段所用到的部分與在下一個階段所使用的部分是銜接的，所使用的技術(shù)經(jīng)過生存期每一階段后不改變；把面向?qū)ο蠓治?、面向?qū)ο笤O(shè)計和面向?qū)ο蟪绦蛟O(shè)計集成到生存期的相應(yīng)階段。幾個概念面向?qū)ο髮ο箢惱^承多態(tài)性第二課時第十章第一課時面向?qū)ο蠛喗榈诙n時72第十章第二課時面向?qū)ο蟮拈_發(fā)過程

面向?qū)ο蠓椒ǜ倪M了在生存期各個階段之間的界面，因為在生存期各個階段所開發(fā)出來的“部件”都是類。在面向?qū)ο笊嫫诘母鱾€階段對各個類的信息進行細化，類成為分析、設(shè)計和實現(xiàn)的基本單元。

１、應(yīng)用生存期

維護組裝測試實例建立信息系統(tǒng)描述論域分析應(yīng)用分析高層設(shè)計類開發(fā)客戶輸入第十章第二課時面向?qū)ο蟮拈_發(fā)過程維護組裝實例信息論域應(yīng)用高層73第十章第二課時（續(xù)）２、類生存期

類生存期類規(guī)格說明從既存類演變漸增式的實現(xiàn)漸增式的測試求精與維護類的復(fù)用從廢棄型開發(fā)實現(xiàn)測試用例與測試開發(fā)３、綜合方法

把應(yīng)用生存期與類生存期放在一起，給出面向?qū)ο蟮膽?yīng)用開發(fā)過程。

（1）分析階段

第十章第二課時（續(xù)）２、類生存期類生存期類規(guī)格說明從既存74第十章第二課時（續(xù)）分析階段包括兩個步驟；論域分析和應(yīng)用分析。它們都要標識問題論域中的抽象。在分析中，需要找到特定對象，根據(jù)對象的公共特性把它們組成集合，直到最后能夠標識出對這個問題的一個抽象。在分析階段中還要標識抽象之間的聯(lián)系，在分析過程中標識的對象不是孤立的，在給定的問題環(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)當對問題敞開思想考慮。客戶可能會改變需求，第十章第二課時（續(xù)）分析階段包括兩個步驟；論域分析和應(yīng)用75第十章第二課時（續(xù)）而且問題環(huán)境也可能改變，所以，論域分析應(yīng)考察問題論域內(nèi)的一個較寬的范圍，分析覆蓋的范圍應(yīng)比直接要解決的問題更多。論域分析最大的價值是抽象的開發(fā)，這些抽象表示了—個問題論域中的基本概念，它們形成的軟件庫還可支持許多應(yīng)用的開發(fā)。(ＩＩ)應(yīng)用分析應(yīng)用(或系統(tǒng))分析細化在論域分析階段所開發(fā)出來的信息，并且把注童力集中于當前要解決的問題。在分析階段中有一些不能映像到設(shè)計階段的類，這些類表示了落到應(yīng)用分析外面的信息。因為通過論域分析，分析人員具有了較寬的論域知識，因而能開發(fā)出更好的抽象。傳統(tǒng)的方法學(xué)人為地把系統(tǒng)分析與設(shè)計過程分離開來，這就把系統(tǒng)設(shè)計和開發(fā)人員與對問題了解最清楚的專家隔離開來。面向?qū)ο髴?yīng)用分析階段是一個迭代的過程。分析階段標識了在問題論域中的實體?？梢允褂迷趩栴}陳述中的名詞作為對象。對象容易標識，這是因為問題論域容易訪問。

第十章第二課時（續(xù)）而且問題環(huán)境也可能改變，所以，論域分76第十章第二課時（續(xù)）在系統(tǒng)分析與高層設(shè)計之間的界限逐漸變得模糊。分析員常?？疾煲粋€問題論域并注重抽象的概念，而不是只看單獨的對象。例如，在空中交通控制系統(tǒng)中，分析員不可能也不能指望標識每一架單獨的將由系統(tǒng)處理的班機。必須標識班機概念，并把它作為該問題論域的一個重要的概念。（2）高層設(shè)計在一個純面向?qū)ο蟓h(huán)境中，系統(tǒng)設(shè)計與類設(shè)計常常處于同一過程中，但還是應(yīng)當把系統(tǒng)與類的設(shè)計分開。在高層設(shè)計階段，設(shè)計應(yīng)用的頂層視圖。這相當于開發(fā)一個表示系統(tǒng)的類的界面。通過建立一個應(yīng)用類的實例并發(fā)送一個消息給它來完成系統(tǒng)的‘執(zhí)行’。（3）類的開發(fā)設(shè)計階段基本上是類的開發(fā)，因為一個應(yīng)用往往是用一個類表示，它亦可分成幾個類。高層設(shè)計將標識對各個類的要求，且給出類的定義。這個階段貫穿于類的生存期．結(jié)果是一組類，它們的開發(fā)獨立于待開發(fā)的應(yīng)用，但可支持該應(yīng)用。第十章第二課時（續(xù)）在系統(tǒng)分析與高層設(shè)計之間的界限逐漸變77第十章第二課時（續(xù)）（4）實例的建立這個階段的結(jié)果就是對問題的最后解決。它集中在類的開發(fā)，這些類表示了解決的各個局部．在此階段，要建立對象的實例，這些對象對應(yīng)于在分析階段所標識的實體。在論域分析階段所標識的聯(lián)系是應(yīng)用級的聯(lián)系．這些聯(lián)系通過實例之間傳送的消息來表示．開發(fā)的最后一部分是建立實例之間的通信通道。這些通道可以通過把引用從一個對象傳遞到另一個對象來建立。（５）組裝測試這一階段把系統(tǒng)組裝成一個完整的應(yīng)用來進行測試；各個類的封裝和類測試的完備性可減少組裝測試所需要的時間。面向?qū)ο髴?yīng)用的界面通?？上駟蝹€對象的界面那樣進行定義。充分隔離單個操作，減少改變操作的次序所造成的綜合影響。（6）應(yīng)用維護第十章第二課時（續(xù)）（4）實例的建立78第十章第二課時（續(xù)）維護的要求將影響應(yīng)用和各個類。繼承聯(lián)系可幫助擴充現(xiàn)有的應(yīng)用，加入新的行為，或者改變某些行為的工作方式。信息隱蔽使得能在單個的類中調(diào)試一個代碼過程．而不致像水中的漣漪那樣擴散，波及系統(tǒng)中的許多類。應(yīng)用的維護包括在系統(tǒng)的操作中定位故障、在現(xiàn)有的系統(tǒng)中加入新的行為，有些缺陷產(chǎn)生于類實例間的不合格的連接，即不合理的消息．應(yīng)用的維護能夠簡化對類實例的定位、修改其類的實現(xiàn)、通過改變消息或接收消息的次序來改變應(yīng)用中特殊對象的角色新的行為可通過定義新的類和建立實例來實現(xiàn)。多數(shù)維護活動發(fā)生在類級。把類的實現(xiàn)與其規(guī)格說明分離可局部化修改的影響。為了修正問題要求對類的界面做出改變的情況很少見。然而，為了在系統(tǒng)中增加新的行為，偶爾改變界面的需求還是會有的。第三課時第十章第二課時（續(xù)）維護的要求將影響應(yīng)用和各個類。繼承聯(lián)79第十章第三課時系統(tǒng)體系結(jié)構(gòu)

一個面向?qū)ο笙到y(tǒng)的體系結(jié)構(gòu)通過它的成分對象和對象間的聯(lián)系來確定。這種體系結(jié)構(gòu)反映了問題論域，因為它主要由問題論域的對象構(gòu)成。圖9-6顯示了一個系統(tǒng)的對象與處理體系結(jié)構(gòu)間的相互影響。從軟件庫到獨立的處理畫出幾根線，表明處理的內(nèi)部由幾個不同類的實例構(gòu)成，而一個類可能為幾個處理提供實例。在傳統(tǒng)的開發(fā)模式情形下，把應(yīng)用分成幾個處理。需要設(shè)計面向處理的體系結(jié)構(gòu)，建立問題論域的模型。若基礎(chǔ)的硬件、編譯器或操作系統(tǒng)改變，則處理的體系結(jié)構(gòu)可能也需要改變。因此，把它移植或提到新的環(huán)境需要花費一定的代價。而面向?qū)ο蠓缎椭械膶ο蟮捏w系結(jié)構(gòu)是對問題論域的對象進行模型化，因此，設(shè)計相對穩(wěn)定。同時可把對問題論域的考慮與環(huán)境相關(guān)的考慮分開。圖9.7表明，類的軟件庫獨立于處理的體系結(jié)構(gòu)。一個類的實例可能出現(xiàn)在幾個不同處理中，也可能僅出現(xiàn)在一個處理中。類的抽象特性提供了模塊化體系結(jié)構(gòu)。把類的實現(xiàn)與它的界面第十章第三課時系統(tǒng)體系結(jié)構(gòu)80第十章第三課時（續(xù)）分離，系統(tǒng)的行為可以相對容易地徹底改變．例如應(yīng)用用戶界面的各個實例進行代換，可以得到不同的界面．引入不同類的實例，可以提供不同的調(diào)度算法或不同的存儲模式．體系結(jié)構(gòu)還要反映對象之間發(fā)送的消息，它應(yīng)是很靈活的?？蛻?服模型比較容易實現(xiàn)和動態(tài)地修改。保持問題的體系結(jié)構(gòu)模型將有助于重新配置以滿足在問題論域中的改變。］面向?qū)ο蠓治雠c高層設(shè)計

面向?qū)ο蠓治觯?、面向?qū)ο蠓治?OOA)２、論域分析３、應(yīng)用分析４、面向?qū)ο竽Ｐ图夹g(shù)高層設(shè)計

第四課時第十章第三課時（續(xù)）分離，系統(tǒng)的行為可以相對容易地徹底改變．81第十章第四課時類的設(shè)計類設(shè)計的目標通過復(fù)用設(shè)計類類設(shè)計方法類設(shè)計的一個案例類的實現(xiàn)與測試應(yīng)用程序的實現(xiàn)返回第十章第四課時類的設(shè)計返回82《軟件工程》課件張權(quán)范《軟件工程》課件張權(quán)范83《軟件工程》第一章概述第二章軟件計劃第三章軟件需求分析第四章軟件總體設(shè)計第五章軟件詳細設(shè)計第六章軟件編碼第七章軟件測試第八章軟件維護第九章軟件項目管理第十章面向?qū)ο蠹夹g(shù)《軟件工程》第一章概述84第一章第一課時幾個基本概念軟件及其組成軟件的概念軟件的組成軟件危機（概念、表現(xiàn)、產(chǎn)生原因與解決辦法）軟件工程軟件發(fā)展簡史（無程序的階段、程序階段、軟件階段與軟件工程階段）軟件生命周期（軟件生存的七個階段：軟件計劃、軟件需求分析、軟件總體設(shè)計、軟件詳細設(shè)計、軟件編碼、軟件測試、軟件維護）第二課時第一章第一課時幾個基本概念第二課時85第一章第二課時軟件開發(fā)模型

瀑布模型

快速原型

第一章第二課時軟件開發(fā)模型86瀑布模型的定義瀑布模型遵循軟件生存周期的劃分，明確規(guī)定每個階段的任務(wù)，各個階段的工作順序展開，恰如奔流不息拾級而下的瀑布。

問題定義可行性研究需求分析概要設(shè)計詳細設(shè)計編碼測試運行維護開發(fā)時期計劃時期有錯運行時期對應(yīng)的文檔資料與系統(tǒng)目標方案論證報告或計劃任務(wù)書需求規(guī)格說明書系統(tǒng)功能結(jié)構(gòu)圖設(shè)計規(guī)格書程序規(guī)格書、源程序測試記錄、用戶操作手冊評價報告、維護記錄瀑布模型的定義瀑布模型遵循軟件生存周期的劃分，明確規(guī)定每個87瀑布模型的特點(1)軟件生存周期的順序性：只有前一階段工作完成以后，后一階段的工作才能開始，前一階段的輸出文檔，就是后一階段的輸入文檔。只有前一階段有正確的輸出，后一階段才可能有正確的結(jié)果。如果在生存周期的某一階段出現(xiàn)了錯誤，往往要追溯到在它之前的一些階段。瀑布模型開發(fā)適合于在軟件需求比較明確，開發(fā)技術(shù)比較成熟，工程管理比較嚴格的場合下使用。(2)盡可能推遲軟件的編碼：程序設(shè)計也稱為編碼。實踐表明，大、中型軟件編碼開始得越早，完成所需的時間反而越長。瀑布模型在編碼之前安排了需求分析、總體設(shè)計、詳細設(shè)計等階段，從而把邏輯設(shè)計和編碼清楚地劃分開來，盡可能推遲程序編碼階段。(3)保證質(zhì)量：為了保證質(zhì)量，瀑布模型軟件開發(fā)在每個階段都要完成規(guī)定的文檔，每個階段都要對已完成的文檔進行復(fù)審，以便及早發(fā)現(xiàn)隱患，排除故障。

瀑布模型的特點(1)軟件生存周期的順序性：只有前一階段工88快速原型正確的需求定義是系統(tǒng)成功關(guān)鍵。軟件開發(fā)人員需要反復(fù)多次地和用戶交流信息，才能全面、準確地了解用戶的要求。理想的做法是先根據(jù)需求分析的結(jié)果開發(fā)一個原型系統(tǒng)，請用戶試用一段時間，以便能正確地認識到他們的實際需要是什么，這相當于工程上先制作“樣品”試用后，作適當改進，然后再批量生產(chǎn)一樣，這就是快速原型法。雖然此法要額外花費一些成本，但是可以盡早獲得更正確完整的需求，可以減少測試和調(diào)試的工作量，提高軟件質(zhì)量。因此快速原型法使用得當，能減少軟件的總成本，縮短開發(fā)周期，是目前比較流行的實用開發(fā)模式。根據(jù)建立原型的目的不同，實現(xiàn)原型的途徑也有所不同，通常有下述三種類型。(1)漸增型(2)用于驗證軟件需求的原型(3)用于驗證設(shè)計方案的原型

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

快速原型（續(xù)）——類型之一先選擇一個或幾個關(guān)鍵功能，建立90快速原型（續(xù)）——類型之二系統(tǒng)分析人員在確定了軟件需求之后，從中選出某些應(yīng)驗證的功能，用適當?shù)墓ぞ呖焖贅?gòu)造出可運行的原型系統(tǒng)，由用戶試用和評價。這類原型往往用后就丟棄，因此構(gòu)造它們的生產(chǎn)環(huán)境不必與目標系統(tǒng)的生產(chǎn)環(huán)境一致，通常使用簡潔而易于修改的超高級語言對原型進行編碼。

快速原型（續(xù)）——類型之二系統(tǒng)分析人員在確定了軟件需求之91快速原型（續(xù)）——類型之三為了保證軟件產(chǎn)品的質(zhì)量，在總體設(shè)計和詳細設(shè)計過程中，用原型來驗證總體結(jié)構(gòu)或某些關(guān)鍵算法。如果設(shè)計方案驗證完成后就將原型丟棄，則構(gòu)造原型的工具不必與目標系統(tǒng)的生產(chǎn)環(huán)境一致。如果想把原型作為最終產(chǎn)品的一部分，原型和目標系統(tǒng)可使用同樣的程序設(shè)計語言?？焖僭停ɡm(xù)）——類型之三為了保證軟件產(chǎn)品的質(zhì)量，在總體92快速原形的開發(fā)過程原型設(shè)計編碼系統(tǒng)定義與用戶需求分析測試原型產(chǎn)品系統(tǒng)的設(shè)計實現(xiàn)完善原型第三課時快速原形的開發(fā)過程原型設(shè)計編碼系統(tǒng)定義與用戶需求分析測試原型93第一章第三課時噴泉模型軟件重用模型第一章第三課時噴泉模型94噴泉模型演化集成測試編程設(shè)計分析噴泉模型原理圖基于噴泉模型，Hodge等人提出將軟件開發(fā)過程劃分為概念模型分析、系統(tǒng)設(shè)計、對象設(shè)計與實現(xiàn)、測試和系統(tǒng)組裝集成等五個階段，它也體現(xiàn)出分析和設(shè)計之間的重疊①概念模型分析：這個階段主要目標是建立系統(tǒng)模型。系統(tǒng)模型中的對象是現(xiàn)實世界中的客觀對象的抽象，應(yīng)結(jié)構(gòu)清晰、易于理解、易于描述其規(guī)范。在分析階段面向問題域，建立起對象模型和過程模型。②系統(tǒng)設(shè)計：給出模型對象和過程的規(guī)范描述。③對象設(shè)計與實現(xiàn)：面向?qū)ο笤O(shè)計方法強調(diào)軟件模塊的再用和軟件合成，因而在對象設(shè)計和實現(xiàn)時，并不要求所有的對象都從頭開始設(shè)計，而是充分利用以前的設(shè)計工作。在軟件開發(fā)時檢索對象庫，若是對象庫中已有的，則可再用；否則，重新定義新的對象，進行設(shè)計和實現(xiàn)。④測試；測試所有的對象及對象相互之間的關(guān)系是否符合要求。

噴泉模型演化集成測試編程設(shè)計分析噴泉模型原理圖基于噴泉模95噴泉模型（續(xù)）⑤系統(tǒng)組裝集成：面向?qū)ο筌浖攸c之一是軟件重用和組裝技術(shù)。對象是數(shù)據(jù)和操作的封裝載體，組裝在一起才構(gòu)成完整的系統(tǒng)。軟件是對象模塊的復(fù)合，而軟件設(shè)計是對象模塊經(jīng)過進程控制而構(gòu)造生成。

噴泉模型（續(xù)）⑤系統(tǒng)組裝集成：面向?qū)ο筌浖攸c之一是軟件重用96軟件重用模型旨在開發(fā)具有各種一般性功能的軟件模塊，將它們組成軟件重用庫，這些模塊設(shè)計時考慮其適應(yīng)各種界面的接口規(guī)格，可供軟件開發(fā)時利用。主要優(yōu)點是減少軟件生產(chǎn)中的重復(fù)開發(fā)，避免軟件開發(fā)人員的大量重復(fù)勞動，提高開發(fā)效率，縮短開發(fā)周期，降低開發(fā)成本。軟件重用庫的模塊不僅要便于選擇使用，而且還應(yīng)具有允許擴充、積累其成分的性能。軟件重用分兩種：(1)重用程序以各種源程序形式存庫；(2)重用程序是經(jīng)過編譯的目標程序。軟件重用模式開發(fā)過程如下：①設(shè)計重用庫模塊：重用庫中的模塊要經(jīng)歷模塊定義、功能規(guī)格描述、模塊設(shè)計、編碼、模塊功能測試、模塊登記、模塊目錄編制，此后可放人重用庫中。②軟件系統(tǒng)設(shè)計：在重用庫建立后，軟件系統(tǒng)的設(shè)計步驟如下：需求分析，功能定義、設(shè)計，在重用庫中選擇模塊，編碼，測試，驗收，運行維護。

第四課時軟件重用模型旨在開發(fā)具有各種一般性功能的軟件模塊，將它們組97第一章第四課時噴泉模型軟件工程的任務(wù)與研究范圍軟件開發(fā)的原則與開發(fā)方法返回第一章第四課時噴泉模型返回98噴泉模型瀑布模型要求在軟件開發(fā)的初期就完全確定軟件的需求，這在很多情況下往往是做不到的。螺旋模型試圖克服瀑布模型的這一不足。SM把軟件開發(fā)過程安排為逐步細化的螺旋周期序列，每經(jīng)歷一個周期，系統(tǒng)就細化和完善一些。SM每—螺旋周期由六個步驟組成：(1)確定任務(wù)目標：根據(jù)初始需求分析項目計劃，確定任務(wù)目標、可選方案和限制。(2)選擇對象：對各種軟硬件設(shè)備、開發(fā)方法、技術(shù)、開發(fā)工具、人員、開發(fā)管理等對象進行選擇：并決定軟件是進行研制、購買還是利用現(xiàn)有的。(3)分析約束條件：軟件開發(fā)的時間、經(jīng)費等限制條件。(4)風(fēng)險分析：評估目標、對象、約束條件三者之間的聯(lián)系，列出可能出．現(xiàn)的問題及問題的嚴重程度等，把最重要的問題作為尚未解決的關(guān)鍵問題的風(fēng)險。(5)制定消除風(fēng)險的方法：應(yīng)有詳盡的說明和周密的計劃，并估計可能產(chǎn)生的后果。依此來開發(fā)軟件，為制訂下一周期的計劃打下基礎(chǔ)。(6)制定下一周期的工作計劃：在第一個螺旋周期，確定目標、選擇對象、分析約束，通過風(fēng)險分析制訂消除風(fēng)險的方法，初步開發(fā)原型1，制定系統(tǒng)生存周期計劃。

噴泉模型瀑布模型要求在軟件開發(fā)的初期就完全確定軟件的需求，這99噴泉模型（續(xù)）在第二個螺旋周期，進一步明確系統(tǒng)的目標、開發(fā)方案及約束條件，通過風(fēng)險分析制定消除風(fēng)險的方法，在原型1的基礎(chǔ)上開發(fā)原型2。進一步明確軟件需求，進行需求確認，修改開發(fā)計劃。在第三個螺旋周期，再進一步確認系統(tǒng)目標、開發(fā)方案及約束條件，進行風(fēng)險分析，制訂進一步消除風(fēng)險的方法，在原型2的基礎(chǔ)上開發(fā)原型3。此時可進行產(chǎn)品設(shè)計，再對設(shè)計進行驗證和確認，制訂集成測試計劃。在第四個螺旋周期，軟件開發(fā)方案、系統(tǒng)目標和約束條件得到確定，在風(fēng)險分析的基礎(chǔ)上，開發(fā)具有實用價值的可操作性原型，此時可對產(chǎn)品進行詳細設(shè)計，進入編碼、單元測試、集成測試階段，最后進入驗收測試，驗收合格后交付用戶使用，進入運行、維護階段。

噴泉模型（續(xù)）在第二個螺旋周期，進一步明確系統(tǒng)的目標、開100噴泉模型原理圖逐步執(zhí)行評價方案，標識、消除風(fēng)險計劃下階段工作運行維護驗證測試集成測試單元測試編碼詳細設(shè)計風(fēng)險分析集成測試計劃設(shè)計驗證與確認產(chǎn)品設(shè)計原型3風(fēng)險分析開發(fā)計劃需求確認軟件需求原型2風(fēng)險分析需求計劃生存周期計劃確定目標方案約束原型1風(fēng)險分析操作性原型確定目標方案與約束螺旋模型的開發(fā)過程開發(fā)驗證下一級產(chǎn)品噴泉模型原理圖逐步執(zhí)行評價方案，標識、消除風(fēng)險計劃下階段工作101軟件工程的任務(wù)與研究范圍軟件產(chǎn)品的特點軟件工程的研究內(nèi)容與方法軟件工具與軟件支撐環(huán)境軟件管理軟件工程的任務(wù)與研究范圍軟件產(chǎn)品的特點102軟件開發(fā)的原則與方法軟件開發(fā)的原則

自頂向下與模塊結(jié)構(gòu)軟件開發(fā)的方法1.非自動形式的系統(tǒng)開發(fā)方法（1）系統(tǒng)流程圖（2）